Onder elk gml-bestand ligt een datamodel dat beschrijft hoe de data in elkaar zit.
Logischerwijs gebruiken we voor het uitwisselen van gegevens over ruimtelijke ordening een ander datamodel (IMRO) dan bij het uitwisselen van gegevens over grootschalige topografie (IMBGT).
Daarom is er niet 1 “catch all” omzetting die van gml bijvoorbeeld shapefiles maakt. Bij het goed omzetten van data is het belangrijk rekening te houden met de opbouw daarvan zoals beschreven in het datamodel. Zo’n datamodel is er meestal in computer-leesbare versie (xsd soms aangevuld met schematron) en een mesn leesbare versie (bijvoorbeeld de RO-standaarden documenten).
Bij QGIS (eigenlijk OGR de onderliggende bibliotheek die de data voor QGIS inleest) heeft men een ander, verrassend vruchtbaar, pad gekozen. Eerst wordt het bestand geheel doorgelezen en geanalyseerd (er ontstaat dan een .gfs bestand), en daarna pas ingelezen. Dit gaat vaak verrassend goed en levert een bruikbaar bestemmingsplan op.
In andere gevallen gaat dat minder goed (BGT) en is er een speciale plugin gemaakt die QGIS helpt de data goed in te lezen.
Dat alles laat onverlet dat er ook veel kennis over het datamodel (en vaak ook domeinkennis) nodig is om de data daadwerkelijk goed te kunnen gebruiken.
In de praktijk zie ik dat het met ESRI software vaak heel moeilijk (tot vrijwel onmogelijk) is om de open geodata die de overheid langs de verplichte standaarden (formum standaardisatie) naar buiten brengt op een goede manier in te lezen. Daarom heeft ESRI-Nederland een dataplatform waar zulke data in direct inleesbare vorm te verkrijgen is. Helaas komt het nogal eens voor dat er dan wat aan gewijzigd is. En verder haal je de data dan niet bij de bron, en persoonlijk vindt ik dat voor basisregistraties een zeer belangrijk punt.
Wat nu te doen met die bestemmingsplannen?
Ik adviseer om te focussen op de gegevens die je echt nodig hebt en de rest even te negeren. Vervolgens in het Informatiemodel RO 2012 opzoeken hoe dit gemodelleerd is en dat proberen terug te vinden in de data (gewoon kijken in de browser of een goede tekst editor maakt al heel veel duidelijk).
Daarna converteren, het liefst met een tool waarvan je weet dat ie het goed doet (een FME workbench van iemand anders, QGIS of OGR ofzo).
En dan de belangrijkste stap: controleren of er data is kwijtgeraakt of samengenomen op een manier die je op het verkeerde been zet.
En dan is er in het geval van bestemmingsplannen NOG een belangrijke stap: het lezen van het bestemmingsplan zelf. Niet alle relevante gegevens (denk aan bouwhoogtes, bebouwingspercentages, meetvoorschriften, etc) zijn in de .gml opgenomen. Grote delen kunnen geregeld zijn in de voorschriften (en welke delen dat zijn verschilt per bestemmingsplan).
Overigens kent QGIS de ruimtelijkeplannen plugin waarmee oa bestemmingsplannen direct uit de landelijke voorziening worden getoond op basis van WFS. Dan kun je veel van bovenstaande stappen overslaan (maar zeker niet het lezen van het bestemmingsplan).
Overigens zou zoiets ook heel gemakkelijk ook voor het ESRI platform gemaakt kunnen worden; de code is vrij beschikbaar, klein van omvang en niet ingewikkeld.
). Maar dat is alweer een tijdje terug en alleen voor een klein pilot-gebied. De bedoeling is dat ik in januari met een volgend gebied aan de slag ga. Mijn doel is dan om het script opnieuw onder de loep te nemen en zoveel mogelijk hard-coded variabelen geautomatiseerd te laten invullen. Als dat lukt kan ik de pythonscripts wellicht breder inzetten.
Dat is helaas bestede tijd die je als ondernemer niet kan declareren.