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

datakwaliteit: weet wat je eet

Ingewijden in de Nederlanse geoscene weten elkaar goed te vinden voor de uitwisseling van data. Dat is een groot goed dat we vooral moeten koesteren, bijvoorbeeld door elkaar op 13 april op de GIS Tech weer te treffen.

Toch staan we voor een professionaliseringsslag op dit gebied: In de geo-beleidsnota Gideon werden al een aantal geodataketens onderscheiden, mét het voornemen deze compleet in beeld te brengen. Dat komt nog maar moeizaam van de grond.

Dat zou toch niet zo moeilijk mogen zijn: veel van die data wordt al meer dan 10 jaar op diverse plaatsen gebruikt, dus er is veel kennis aanwezig over de "functionele behoeftestelling", oftwel welke rol speelt een dataset in de bedrijfsprocessen.

Waar we nog een professionaliseringsslag moeten maken is de vorm waarin data de keten doorloopt: ik zie te vaak een dataset per jaar van vorm verschillen: andere veldnamen, zelfde veldnaam maar andere definitie, ander type datacompressie, ander geodataformaat. Terwijl dat met ETL-tools als FME en ArcGIS/Modelbuilder toch eenvoudig goed te regelen moet zijn.

Als die vorm nou bij iedere levering hetzelfde is wordt het voor de ontvangende partij eenvoudiger er consistentiechecks op uit te voeren. door bijvoorbeeld een aantal controlescripts die bij binnenkomst op een dataset kunnen worden losgelaten.

Daarna komt de echte professionaliseringsslag: bij constateren van fouten de boel terugsturen in plaats van als gebruiker zelf te gaan repareren. Blijkbaar is dat nu nog de weg van de minste weerstand. En lost het probleem slechts op één gebruikersplek op.

Tijd voor een kwaliteitskeurmerk: niet zo zwaar aangezet als een basisregistratie, wel een "goedgekeurd door gebruikers"-stempel. Met een eervolle vermelding in het Nationaal Georegister!

Niet de cijfers maar de voorstelling van de cijfers

Mooi stukje van filosoof Bas Haring in de Volkskrant van 30 januari. Haring probeert daarin zich iets voor te stellen bij een aantal getallen: 13.000 door het CBR afgelaste rijexamens, 7 miljard aardbewoners. Aan zijn studenten vroeg hij te schatten wat voor een gebied je nodig hebt om die aardlingen een vierkante meter ruimte te bieden. Schattingen liepen uiteen van de gezamelijke oppervlakte van Frankrijk, Spanje en Portugal tot de optelsom van Europa en Azië.
Allemaal wat ruim geschat want, zo legt Bas Haring uit, het is iets meer dan de oppervlakte van Gelderland. Dat vind ik dan wel weer wat krap maar met de gezamelijke oppervlakte van Noord- en Zuid-Holland en Flevoland heb je die benodigde 7000 vierkante kilometer te pakken.

Het ministerie van VROM had in het begin van deze eeuw ook door dat gangbare oppervlaktematen te abstract zijn: het ingeschatte ruimtetekort werd daarom gepresenteerd als "de oppervlakte van Zuid-Holland".

Blijkbaar zijn grote getallen al gauw onvoorstelbaar: werk aan de winkel voor kartografen en andere infografici om die met GIS zo zorgvuldig berekende cijfers inzichtelijk te maken. jammer dat je in de gangbare GIS systemen iet kunt kiezen voor dit soort oppervlaktematen. Mapinfo, ArcGIS en al die anderen willen ons alleen in vierkante (kilometers) en (nog liever) acres laten rekenen. "referentieoppervlakte" is nog geen keuze van eenheden. Volgende release wellicht?

ictprofessionaliteitsindicator?

Geluk zit in kleine dingen: vandaag heb ik de term "ictprofessionaliteitsindicator"(nul hits op Google, kan ik een nieuw woord ergens registreren?) gedefinieerd voor de snelheid waarmee een nieuwe collega beschikt over een account om mee in te loggen, mail te ontvangen, benodigde applicaties en rechten op netwerkschijven.
Nieuw bedrijfsrecord: binnen 26 uur (een dag en een beetje) na binnenkomst van nieuwe collega A. was alles geregeld, ook "lastige" applicaties als ArcGIS, Photoshop en Illustrator.
Hebben alle tijdsinvesteringen afgelopen zomer om met de I&A afdeling en de outsourcingspartner alle rechten, profielen etc. op te schonen mooi vruchten afgeworpen.

En wellicht een mooie vraag bij sollicitaties: als ik hier ga werken, hoe snel is mijn werkplek dan operationeel?

Kwaliteit van metadata (2)

Gisteren bij ESRI Nederland de presentatie van de metadata-editor GeoSticker 3.0 bijgewoond.
Opvallend was dat een flink aantal van de vragen en opmerkingen uit het ca 35-koppige publiek betrekking had op portalen in het algemeen en het Nationaal Georegister (NGR) in het bijzonder: wat is de waarde van de inhoud van het NGR? Kan ik er blind op varen (dus een positief stelsel in kadastertermen) of is de opname in het NGR weliswaar conform NGR vereisten maar zegt dat nog niets over de juistheid van het aangebodene (een negatief stelsel). Oftewel: Moet het NGR een "doorbitch" aanstellen?

Een stapje verder is het NGR als Nederlands Inspire portaal. Dat is andere koek, want dan wordt je als data-provider aansprakelijk voor hetgeen je aanbiedt. Ja, dan bedenk je je wel 2 keer voor je enthousiast aan het uploaden slaat.

Mijn idee: trek het uit elkaar. Maak van het NGR een "loosely coupled" (!) portaal dat geen absolute waarheid nastreeft maar een uitnodigende, inspirende (!) samenwerkingsplek wordt.
Maak daarnaast van een Nederlands Inspire portaal dat formeel, afrekenbaar, 100% betrouwbaar, 24 uur/dag, 7 dagen/week beschikbaar is. dan heb je een helder verwachtingsmanagement waarbij creativiteit en formaliteit elkaar nou eens niet in de weg hoeven zitten

Kwaliteit van metadata

Nu het Nationaal Georegister (NGR, zie http://www.nationaalgeoregister.nl/) gevuld begint te raken valt op dat er nogal verschil zit in de kwaliteit van de aangeboden waar. Bij georegisters die door één organnisatie worden beheerd is die kwaliteit vaak constanter (dat is niet noodzakerlijkerwijs hetzelfde als hoger).

Een goede reden om met een aantal mensen uit de NGR werkgroep "content managament" eens naar de kwaliteitsaspecten van de metadata te kijken. Googelen op "kwaliteit van metadata" levert 20 hits op, dus daar valt nog wel wat zendingswerk in te verrichten.

Eerst maar eens de vraag stellen wat voor kwaliteit we verwachten van het NGR, daarna hoe we tot die kwaliteit kunnen komen. En omdat het NGR een heel brede doelgroep heeft is de kwaliteitsverwachting niet eenvoudig: we stoppen met z'n allen wel datasets in het NGR maar weten nog niet zo goed wie die datasets er uit halen.