Basisregistraties, datamodellen en interoperabiliteit

Recent leverde ik een nieuwe versie op van de BGT Import plugin voor QGIS. De noodzaak van die plugin beschreef ik al eerder op QGIS.nl.

Bij het werken aan die plugin bekroop me (niet voor het eerst) het gevoel dat we iets niet helemaal goed doen bij het ontsluiten van al die prachtige open geodata zoals BAG, BGT, RuimtelijkePlannen, Top10NL, etc.

Het grootste deel van die gegevens is in kaartvorm of als data ontsloten door PDOK in geowebservices langs open standaarden als WMS, WMTS en WFS. Dat is mooi en werkt over het algemeen goed, hoewel ook hier minder interoperabele constructies worden gekozen zoals blijkt uit deze discussie.

Daarnaast is die data ook beschikbaar in GML-formaat. Naar verwachting is deze data bedoeld om te gebruiken, maar waarin dan?

Omdat het hier geodata betreft zou je verwachten dat deze data eenvoudig is in te lezen in een GIS-pakket. En omdat de overheid ervoor heeft gekozen om open standaarden verplicht te stellen en het gebruik van Open Source aan te moedigen zou je denken dat deze data eenvoudig is in te lezen in QGIS.

Het direct inlezen van de data in QGIS leidt onherroepelijk tot dataverlies. De oorzaak daarvan is eenvoudiger dan het lijkt.

Een gml is altijd opgezet volgens een datamodel. Voor elke dataset gebruiken we een ander datamodel dat recht doet aan de dataset. Zo modelleren we bestemmingsplannen volgens een ander datamodel (IMRO) dan de BGT (IMGEO).

De datamodellen die hiervoor worden gebruikt gaan steeds uit van objecten, die hier voor de eenvoud maar worden benoemd als “dingen met eigenschappen”. Een (of meer) van die eigenschappen is dan steeds geometrie, die we gebruiken om het object op kaart af te beelden.

De objecten moeten vervolgens in kaartlagen worden gedwongen om bruikbaar te zijn in een GIS. Hoe makkelijk dat gaat, en of er dan informatie verloren gaat, hangt sterk af van de wijze waarop het object is gemodelleerd.

Naar mijn overtuiging is er bij de modellering teveel aandacht aan het “ideaal” modelleren van de objecteigenschappen vanuit het oogpunt van het maken en beheren van de data. En is er veel te weinig aandacht voor het eenvoudig gebruik van de data.

Nu is de situatie zo dat voor elke dataset een speciaal programma ontwikkeld moet worden om deze te gebruiken. De eerder genoemde BGT Import plugin is daar een voorbeeld van, maar natuurlijk ook het terecht befaamde (maar voor niet-ontwikkelaars ook notoir lastig te gebruiken) NL-Extract.

Een belangrijk doel van het gebruik van open standaarden, namelijk het bevorderen van de interoperabiliteit staat hiermee op de tocht. Ook bij PDOK maakt men zich hier zorgen over gezien de discussie die is opgestart over het ‘platslaan’ van informatiemodellen.

Maar wellicht is het veel constructiever om bij het modelleren van de data interoperabiliteit meer aandacht te geven. Het vermijden van exotische contructies waarvan op voorhand zeker is dat er speciaal programmatuur moet worden geschreven om deze te kunnen gebruiken zou al veel helpen.

Een mooi voorbeeld is de BGT. De standaard software componenten waarmee QGIS gml inleest is al heel slim en weet in veel gevallen de data netjes in te lezen zonder informatieverlies. Maar … in sommige gevallen staat deze software op het verkeerde been en leest dan de verkeerde informatie in. Met een simpele ingreep in de wijze waarop de objecten zijn gemodelleerd had dit voorkomen kunnen worden.

De laag “openbareruimtelabel” uit de BGT is op een wijze gemodelleerd waarmee geen enkel (?) GIS pakket uit de voeten kan. Het accepteren van enige redundancy bij het opslaan van de gegevens in gml had ervoor gezorgd dat deze laag wel direct in een GIS inleesbaar was geweest, zonder het gebruik van een speciaal stukje code.

De nu in onwtikkeling zijnde standaarden voor de omgevingswet (STOP/TPOD) doen niet vermoeden dat de situatie in de toekomst beter gaat zijn. In STOP/TPOD wordt tekst geannoteerd waarbij geometrie aan een stuk(je) tekst gekoppeld kan worden als werkingsgebied. Het uiteindelijke document is xml waarin stukjes gml zijn opgenomen.

Het is me niet gelukt om met standaard beschikbare tooling of enkele eenvoudige ingrepen zo’n document (dat ik nota bene zelf heb gemaakt) in te lezen. Daarnaast kan ik niet makkelijk bedenken hoe de informatie uit zo’n document zinnig in een GIS kan worden getoond. (ondanks dat ik de STOP/TPOD standaarden heel aardig ken).

Zou het niet beter zijn om bij het modelleren al te bedenken hoe de data het best in een kaartlaag-georienteerd GIS getoond kan worden? En dan de modellering daar een (beetje) op aan te passen? En exotische, moeilijk in te lezen, constructies te laten voor wat ze zijn.

Met zo’n houding zou interoperabiliteit sterk worden verbeterd, en zo al die prachtige open data laagdrempeliger ter beschikking komen voor een ieder. En dat zonder dat daar speciale software voor moet worden aangeschaft of geschreven.

Wil je iets bijdragen aan deze discussie, doe dat dan op het geoforum.