Om de codes voor ander doeleinde te gebruiken moet ik nu bij de gemeente er eerst âGMâ voor plakken.
Dus de vraag aan PDOK: Waarom staat de âGMâ niet voor de gemeente code maar bij alle andere administratieve codes staat er wel een letter aanduiding ?
De gemeentecode bestaande uit 4 cijfers komt oorspronkelijk uit de BRP (tabel 33) en is als zodanig in de BAG en andere basisregistraties overgenomen. De wijken en buurten komen uit de wijk- en buurtkaart van het CBS. Zij hebben de prefixen âWKâ en âBUâ bedacht en in die lijn ook de prefix âGMâ voor de gemeentecode gebruikt.
Zoals @fsteggink aangeeft: âHet is gewoon zo gelopenâŠâ Kan me ook niet herinneren of dit van uit gebruikers overleggen naar voren is gekomen⊠(misschien dat @Jeroen_D dat nog weet?)
Maar goed ik denk dat dit een valide onderwerp is om mee te nemen wanneer de locatieserver herzien gaat worden. (M.a.w. wel/geen prefix⊠in de codes)
Even een stukje nieuwsgierigheid, wie bepaalt het eigenlijk welk nummer provincies en gemeenten hebben? Ik zocht laatst naar een lijstje provinciecodes die met PV beginnen en die vond ik bij het CBS in een publicatie die bij de vierkantstatistieken hoorde geloof ik. Want als je zoekt op âCBS provinciecodesâ dan vind je een ander lijstje dat van 1 tot 11 is genummerd terwijl het overzicht van de gemeentecodes verwijst naar een lijst dat van PV20 tot PV31 is genummerd.
Misschien wel handig om zulke standaardlijsten via PDOK/NGR te verspreiden?
Ja sowieso is het altijd een gedoe met die codes. Er zijn geloof ik niet echt afspraken over. Dus je ziet vaak die codes terug komen in verschillende datasets maar dan net op een ander manier:
Met letter aanduiding of zonder.
Met leading zeros of zonder.
Aangeduid als GM_code of gemeente code of codeâŠ
Ook is het handig dat je uit een buurt code, de wijk en gemeente code kan halen. Helaas doen dan de provincie codes niet mee⊠Dat zou nou ook handig zijn
Ik denk dat het goed is dat die partijen om de tafel gaan zitten om te harmoniserenâŠ
Maar ik meen (vaag) te herinneren dat dit al een keer (mogelijk) is gedaan⊠Misschien dat @CBS en/of @PieterDijkstraBAG dat nog weten? (of dat 't geval is geweest en/of daar navolging aan is gegeven?)
De BAG is geen bron van deze codes. Ik kan wel iets zeggen over de totstandkoming van de gemeentecodes. Vanuit de BAG gebruiken we tabel 33 als de bron. De gemeentecode uit deze tabel wordt overgenomen in de eerste vier cijfers van het BAGID door de gemeente die het object opvoert. Daarnaast gebruiken we tabel 33 om te kunnen bepalen welke gemeente als bronhouder verantwoordelijk is voor een object.
Zie voor de nieuwe gemeentecode die ontstaat in 2021 zie:
In deze discussie wordt gevraagd wie de codes bepaalt. Dat verschilt per code.
De provinciecode die het CBS hanteert is, voor zover ik kon nagaan door CBS zelf geĂŻntroduceerd, waarbij door de komst van de Provincie Flevoland we van PV01 t/m PV11 overgestapt zijn naar PV20 t/m PV31.
De Gemeentecode wordt door de RVIG (onderdeel BZK) bepaald. CBS zet hier zelf GM voor, omdat dat veel koppelproblemen voorkomt. Vooral omdat dan altijd duidelijk is dat het om een tekst gaat, en dat daardoor de voorloopnullen niet wegvallen. CBS is dus een groot voorstander van het gebruik van die 2 letters ervoor.
De Wijk en Buurtcodes worden bepaald door de gemeentes. Hierbij worden de letters WK en BU gebruikt om dezelfde reden waarom wij GM voor gemeentecodes zetten. Omdat dezelfde codes helaas niet elk jaar naar dezelfde indeling verwijzen is het eigenlijk verstandig ook nog een jaartal toe te voegen aan de codes. Dit wordt gebruikt in de dataset CBSgebiedsindelingen in de kolom JRSTATCODE.
Recentelijk hebben wij voor de Bestuurlijke Grenzen API ook de bovenstaande zoektocht gedaan om tot een eenduidige lijst met codes te komen. We zijn daar redelijk uitgekomen omdat we wat achtergrondkennis hadden, maar ik deel dat het prettig zou zijn dat hier in ieder geval 1 bron komt waar je ze kunt vinden (en dan kan het beheer blijven liggen bij de partij die hiervoor verantwoordelijk is).
Voor de bestuurlijke grenzen van alle bevoegde gezagen is er een soortgelijke uitdaging, die hebben wij nu ook in de Bestuurlijke Grenzen API samengebracht (en de data komt dan bij het Kadaster, het Waterschapshuis en het Rijk vandaan) maar ook hier mist een duidelijke bron. Op basis van deze ervaringen en wensen die onder andere van het Digitaal Stelsel Omgevingswet komen wordt er nu gekeken of de Bestuurlijke Grenzen API in ieder geval voor de grenzen ook een stabiele authentieke bron kan krijgen, wellicht kunnen hieruit dan ook de verschillende codes gepubliceerd worden of kan er een vergelijkbare actie komen voor de codes.
Bij de Omgevingswet gebruiken ze deze dingen ook, op meerdere plaatsen: https://geonovum.github.io/TPOD/CIMOW/IMOW%20v1.0.3.pdf , zie 3.2.1 Identificatie van OwObjecten .Daar zijn de eerste ongelukken al weer zichtaar. IMOW doet het met een klein voorloopje, maar bij referentie naar het ambtsgebied moet het met kapitalen (komt uit de bestuurlijke grenzen API).
hoe verhoudt deze discussie zich tot standaarden.overheid.nl
zou het niet beter zijn om naar uriâs over te stappen ipv codes? of in ieder geval een verwijzing naar de owms uri opnemen?
