Per 1 januari 2026 zijn de volgende wijzigingen doorgevoerd voor de Bestuurlijke Gebieden:
Een grenswijziging tussen de gemeenten Brummen en Rheden
Een grenswijziging tussen de gemeenten Leidschendam-Voorburg en ’s-Gravenhage
Een grenswijziging tussen de gemeenten Koggenland en Hoorn
Een grenswijziging tussen de gemeenten Haarlem en Velsen
Daarnaast zijn er een aantal kleine correcties op de kadastrale grenzen doorgevoerd die gevolgen hebben voor de weergave van de Bestuurlijke Gebieden op de kaart. Deze correcties zijn het gevolg van herstelacties, juridisch is er niets gewijzigd.
Historie Bestuurlijke Gebieden en Bestuurlijke Grenzen
De Bestuurlijke Gebieden van voorgaande jaren blijven als download beschikbaar, dit geldt vanaf 2021. De historie voorafgaand aan 2021 is te vinden onder de Bestuurlijke Grenzen historie. Bij ieder nieuw jaar van de Bestuurlijke Gebieden verdwijnt er een jaar uit de historie van de Bestuurlijke Grenzen.
Uitleg of meer lezen?
Voor uitleg van afkortingen en begrippen die gaan over webservices en OGC API’s, klik hier
Zowel de oude als nieuwe URL lijken te werken, maar de data die de oude URL teruggeeft, bevat dus de nieuwe namespace (van de nieuwe URL…?)
Voor zover ik kan terugvinden, is daar geen berichtgeving over geweest.
Maar waar het mij om gata is dat tot de update van de dataset op 29-1-2026 de ‘namespace’ van de oude service/url nog wel correct waren, maar na de update dus zijn aangepast.
De webservice werkt dus nog wel obv de oude URL, maar de data bevat andere ‘data’, waardoor we nu problemen hebben met het uitlezen/verwerken.
Dat is vind ik verder niet terug in die communicatie.
Beste @RHoek,
Je hebt inderdaad gelijk. We waren in onze vorige reactie iets te snel geloof ik .
De ‘namespace’ had inderdaad niet mogen wijzigen. Dit is inmiddels aangepast in de services. Als het goed is werkt deze weer naar behoren.
Hoi @Yvette_PDOK
Heel erg bedankt voor het herstellen van de namespace.
We wilde hadden nu al een issue gemaakt om de nieuwe URL’s te gaan hanteren (meestal wacht we het uitfaseren af), maar met deze aanpassing kunnen onze klanten nu direct verder.
Even afgezien van de Namespace: Als je software de Capabilities gebruikt, dan zou je software ook met een initiele call naar de oude url, de features en descriptions moeten ophalen van de nieuwe url. Een stukje uit de capabilities van https://service.pdok.nl/kadaster/bestuurlijkegebieden/wfs/v1_0:
Wij gebruiken de ‘capabilities’ niet, maar sturen op pure XML-calls.
Daarbij zo dan nog steeds hetzelfde probleem optreden naar mijn idee => de response XML zou dan nog steeds een andere namespace bevatten, met hetzelfde probleem als gevolg…
Je software had kunnen zien dat de URL waar ie de Capabilities vandaan haalt, anders zijn dan de URL waar GetFeatures opgehaald worden - iets dat overigens wel vaker voorkomt - dus niet noodzakelijkerwijs een probleem hoeft te vormen.
Wat je daarmee bedoelt begrijp ik niet, een Capabilities document is xml, maar goed, dat doet verder ook niet ter zake. Ik beschouw het zelf als best practice om mijn webclients af te laten gaan op de capabilities, omdat de server daarmee publiceert wat ze wel en niet kan - wat betekent dat je koppeling flexibeler word. Natuurlijk voorkom je daar niet alles mee, maar je kunt wel dingen signaleren - zoals een verschil in domein of path bijvoorbeeld (wat dan weer een call to action word - is een service verplaatst bijvoorbeeld), zodat zaken niet direct omvallen, maar graceful dienst weigeren.
Het signaleren van verandereingen is zeker geen gek idee, maar zal dus altijd een extra aanroep tot gevolg hebben. Daarnaast wordt wel goed gecommuniceerd vanuit PDOk wanneer services vervallen, waardoor wij er tot op heden nooit tegenaan liepen (behalve nu ivm een probleem met de service zelf…)
Bij PDOK hebben we een analyse gedaan bij alle andere datasets. Het bleek dat er meerdere services (WFS’en) waarbij de namespace was aangepast wat niet had gemoeten. Dit is inmiddels aangepast en overal staat dit nu weer goed.
Onze excuses voor het eventuele ongemak.
.