Nieuwe postcodegrenzen geven greep op geodatakwaliteit (1)

De inkt van het -voor mij verrassende- bericht over het faillissement van geodatamakelaar Bridgis was nog niet droog of op diverse plekken ontstonden er discussies en initiatieven over het zélf vervaardigen van een bestand met postcodegrenzen. Niet dat erop dit moment in het geheel geen bronnen meer zijn voor zo'n bestand, bij mijn weten levert First Element nog steeds de Bridgis versie, terwijl Geodan al sinds jaar en dag zelf zo'n bestand maakt en vermarkt.
In de Nederlandse open source geo community werd de discussie of we geen crowdsourced 6 positie postcodevlakkenkaart zouden kunnen maken aangezwengeld door Jan-Willem van Aalst, en een weekje later zag ik dat Esri Nederland ook aan het experimenteren is met het zelf uitwerken van een algoritme om aan de hand van de BAG, het NWB en andere open data tot een landsdekkend 6-positie postcodevlakkenbestand te komen.

Los van de vraag over nut en noodzaak van het zelf maken van zo'n dataset, over eigenaarschap en hoe je een en ander "vermarkt" is zijn deze initiatieven erg interessant voor het thema datakwaliteit. Het is een prima oefening in het definiëren van  kwaliteitsparameters: waar moet een 6-positie postcodevlak (en zijn "vader" en "grootvader", de 5- en 4-positie vlakken) eigenlijk aan voldoen?

Een primaire eis lijkt mij dat alle adrespunten van een 6-positie postcode binnen het resulterende vlak moeten liggen. Maar zelfs dat is niet altijd evident; de plaatsing van een verblijfsobjectpunt in de BAG is soms discutabel: neem je als BAG-beheerder de bij een appartement de locatie van de gemeenschappelijke ingang (vaak ook de locatie van de brievenbus) of prik je dat VBO-punt op het verblijfsobject zelf? Die 355 verblijfsobjecten in de 42 verdiepingen tellende Haagse Toren zijn op dat punt een mooie uitdaging! Zoek 'm maar op in de BAG-viewer: bij postcode 2516LX.

Voor het oog van de kaartlezer is het daarnaast prettig als de grenzen van de postcodegebieden er een beetje smakelijk uitzien: liefst geharmoniseerd met topografie wegen, spoorlijnen, rivieren en kanalen. En voor het koppelen van data ook handig als de grenzen waar mogelijk samenvallend met wijk- en buurtgrenzen zoals CBS en gemeenten die hanteren. Maar dat dan wel met zo min mogelijk vertices (tussenpunten): performance is immers ook een kwaliteit.


Historie opbouwen zou natuurlijk mooi zijn, maar dan leg ik de lat wel heel erg hoog; als ik er van uitgaan dat het een landsdekkend bestand moet opleveren ontkom je er niet aan dat bij het ontstaan van een nieuwe 6-positie postcode de buurvlakken iets van hun oorspronkelijke territorium moeten prijsgeven. O ja, wat is dan eigenlijk landsdekkend? Moet het IJsselmeer in 6-positie postcodes worden verkaveld? Het Hollands Diep? De Rijn, IJssel, Waal en Maas. Het Uddelermeertje?

Nog een stap verder redenerend kun je je afvragen waarvoor je eigenlijk een 6-positie vlakkenkaart zou willen toepassen. Voor het weergeven van een absoluut verschijnsel (bijvoorbeeld: aantal inwoners) is een figuratieve kaart beter geschikt, voor het weergeven van een relatief verschijnsel (zoals inwonerdichtheid) zou dit de extra eis opleveren dat de oppervlakte van de te maken postcodevlakken een direct relatie heeft met het aantal adressen (of nog scherper: verblijfsobjecten) in dat postcodegebiedje. Dat wordt wel heel complex. Mag ik die even parkeren?

Zoals u op de GeoBuzz kon merken is Alterra bezig met het opzetten van een framework waarmee de vraag "wat is datakwaliteit?" beter moet kunnen worden beantwoord. Misschien zijn deze bottom-up postcodegrenzen een leuke case: het vereist geen specifieke domeinkennis (over bijv. bodem, geluid of natuur), de discussie leeft al op diverse plekken, en is concreet genoeg om ook direct toepasbaar te zijn.

Ik ben er nog niet over uitgepraat, zoals de lezer aan de titel al merkte. Stay tuned voor meer aspecten, en voortschrijdend inzicht