Vernieuwde versie WKPB-services bij PDOK

Datasets
1

Per 17 juni 2026 is er een nieuwe versie van de Publiekrechtelijke Beperkingen (WKPB) door PDOK naar productie gebracht. Dit is een belangrijke stap in de modernisering van deze dataset. Waar voorheen meer dan 80 lagen werden aangeboden, heeft de WMS nu 59 lagen en de OGC API Features nog maar twee collecties. Voor beide dataproducten zijn de visualisaties aangepast.

Waarom deze verandering?

De oorspronkelijke inrichting met tachtig lagen bleek technisch niet meer uitbreidbaar en daardoor niet langer houdbaar. Daarnaast uitten afnemers zorgen over de gebruiksvriendelijkheid en performance. Door het aantal lagen drastisch te reduceren en het onderscheid visueel te maken via styling en vectortiles, wordt de dataset eenvoudiger te gebruiken én beter schaalbaar. De oorspronkelijke WKPB grondslagen zijn gegroepeerd per wet en de omgevingswetgrondslagen zijn in losse lagen zichtbaar.

Wat is er nieuw?

• Minder lagen: Multivlak en multilijn vervangen de 80 afzonderlijke lagen in de OGC API Features, in de WMS zijn het 59 lagen geworden.
• Nieuwe stijl: Gebaseerd op het attribuut codeGroep, vergelijkbaar met de stijl van verspreidingsgebieden in andere datasets.
• OGC API’s: Naast WMS/WFS/Atom worden nu ook vectortiles en features aangeboden via OGC API’s.

Nieuwe URL's:
De nieuwe services van de dataset Publiekrechtelijke Beperkingen (WKPB) zijn te benaderen via onderstaande URL’s:
WMS: https://service.pdok.nl/kadaster/brk-publiekrechtelijke-beperkingen-wkpb/wms/v2_0?SERVICE=WMS&REQUEST=GetCapabilities
WFS: https://service.pdok.nl/kadaster/brk-publiekrechtelijke-beperkingen-wkpb/wfs/v2_0?SERVICE=WFS&REQUEST=GetCapabilities
ATOM: https://service.pdok.nl/kadaster/brk-publiekrechtelijke-beperkingen-wkpb/atom/index.xml
OGC API: https://api.pdok.nl/kadaster/brk-publiekrechtelijke-beperkingen-wkpb/ogc/v1/

Oude URL's:
De oude services van de dataset WKPB gaan per 17-12-2026 uit productie. PDOK verzoekt gebruikers om zo spoedig mogelijk over te stappen op de nieuwe URL’s.
WMS: https://service.pdok.nl/kadaster/wkpb/wms/v1_0?request=GetCapabilities &service=WMS
WFS: https://service.pdok.nl/kadaster/wkpb/wfs/v1_0?request=GetCapabilities& service=WFS
ATOM: https://service.pdok.nl/kadaster/wkpb/atom/v1_0/index.xml

Uitleg of meer lezen?

2

Het lijkt er op dat in de 1e 3 url’s een streepje mist. Dus dat het

brk-publiekrechtelijke-beperkingen-wkpb

moet zijn in plaats van

brk-publiekrechtelijke-beperkingenwkpb

3

Bedankt voor je alertheid! Ik heb de url’s aangepast.

1 like
4

Ik bemerk dat bij alle veldnamen (attributen) in de WFS en OGC-API van elkaar verschillen. Die in de WFS zijn NEN3610 compliant, die in de OGC-API niet. Bijvoorbeeld het veld (attribuut) naamGroep in de WFS en naam_groep in de OGC-API.
Is er een reden waarom deze afwijkend zijn?

5

Korte (niet technische) reactie: NEN3610 schrijft voor technische koppelvlakken geen casing voor. Bij PDOK volgen we de casing van de geopackage standaard (waar we mee werken) die we ook binnen APIs willen gaan uitserveren. Daarmee hebben we een uniforme casing in de attribuutwaarden binnen de scope van een OGC API.

Uitgebreidere uitleg:
NEN3610 schrijft voor het logisch model (NEN 3610:2022 nl, 8.4.4.2 P62) pascalCase voor, maar voor het technisch model schrijft de NEN 3610 geen casing voor, alleen om rekening te houden met de specificaties en waar mogelijk het logisch model te volgen. Dat technisch model is waar we het hier over hebben.

We verwerken en serveren geodata bij PDOK uit in Geopackages. We hebben de ambitie om op termijn geopackages in OGC APIs uit te serveren. De geopackage standaard schrijft voor het eigen model snake_case voor. Dit is ook gebruikelijk bij databases. De OGC API Features en JSON standaarden schrijven niet hard een casing voor (PDF alert! it does not attempt to impose ECMAScript’s internal data representations on other programming languages, via). Bij PDOK hebben we er voor gekozen om de attribuutnamen die we in onze OGC APIs uitserveren te baseren op de geopackages (zoals ze worden aangeleverd). Op deze manier sluiten deze aan op de geopackages als deze ook in deze APIs worden uitgeserveerd.