De QGIS BGT plugin

Jan-Willem van Aalst schreef een mooi stukje over het gebruik van de BGT in QGIS met als voorbeeld weer een van zijn bekende prachtige kaarten. Hiervoor is het wel nodig om de complete BGT in Postgis te laden. Dat is misschien een beetje overkill als je geïnteresseerd bent in pakweg 1 gemeente.

Zou QGIS ook op een makkelijker manier overweg kunnen met de BGT? Laten we als proef eens van de BGT download site (https://www.pdok.nl/nl/producten/pdok-downloads/download-basisregistratie-grootschalige-topografie) een deel van de BGT downloaden (hier de gemeente Bodegraven-Reeuwijk):

selection_268

Als resultaat krijg je een zipfile met flink wat gml-bestanden. Deze kun je vanuit de verkenner zo in QGIS slepen en het resultaat is (na soms flink wachten) een stuk of 30 kaartlagen en een niet zo mooi opgemaakt kaartbeeld:

selection_272

Een kenner ziet direct dat er iets mis is gegaan. De BGT is vlakdekkend, en de getoonde kaart niet!

Om te begrijpen waar dit probleem vandaan komt is het nodig iets meer te weten van gml. De Nederlandse overheid heeft ervoor gekozen om de open standaard gml te gebruiken voor het uitwissel van geo-informatie. Gml is daarbij inderdaad een standaard en geen bestandsformaat! De standaard is zeer rijk en staat een hele mooie objectgerichte modellering toe waarbij objecten zowel een punt-, een lijn- als een vlakgeometrie hebben. Maar zulke objecten zijn natuurlijk wel moeilijk te gebruiken in de meeste GIS-programma’s die net zoals QGIS graag punten, lijnen en vlakken in aparte kaartlagen zetten.

Als voorbeeld zien we hier de panden (bgt_pand.gml) die zowel een puntlocatie als een vlak aan zich hebben:selection_270

Indien we dan in de gml gaan kijken (dat kan, het is een gewoon tekstbestand), dan zien we dat zo’n pand een imgeo:geometrie2dGrondvlak attribuut heeft, en een imgeo:nummeraanduidingreeks.

In het bgt_vegetatieobject.gml zien we zelfs punten, lijnen en vlakken:

selection_269

Er zijn hier meerdere objecten zichtbaar, twee punten boven op elkaar (de sterren), een lijn (rood gestippeld) en een vlak (groen).

Het gebruik van de identify tool leert dat het vlak, de lijn en een van de punten een “haag” betreft. Het andere punt betreft een boom.

Bij het inlezen van dit soort bestanden waarbij bij sommige objecten wel, en bij andere objecten niet meerdere typen geometrieen zijn opgenomen wordt het voor de onderliggend software die het bestand in moet lezen moeilijk te bepalen wat ingelezen moet worden. Zo krijg je al gauw de nummeraanduidingreeks van de panden terwijl je QGIS vraagt de vlakken in te lezen.

Gelukkig is de software niet al te moeilijk ervan te overtuigen om de juiste dingen in te lezen. Bij FOSS4GNL (28 juni 2017) werd door mij al een plugin aangekondigd die dat zou regelen. De BGT import plugin staat inmiddels bij de QGIS plugins en regelt het inlezen door een klein bestandje aan te maken waarin precies staat waar de geometrie elementen in het gml bestand zitten. QGIS gebruikt dat vervolgens om het gml bestand goed in te lezen.

selection_271

Indien je een BGT bestand importeert met de plugin, dan maakt de plugin een kopie (of een symlink als dat kan) van het gml bestand, met de toevoeging _P, _V, _L in de bestandsnaam voor punten, lijnen en vlakken respectievelijk. Vervolgens wordt naast elk _X.gml bestand een _X.gfs bestand geplaatst op basis waarvan QGIS op de juiste manier de punten, lijnen of vlakken kan inlezen. Je hebt de plugin daarna dus niet meer nodig om zo’n _X.gml bestand goed in te lezen!

Als voorbeeld de bgt_pand.gml direct ingelezen met QGIS (er zijn alleen punten ingelezen):

selection_275

En met gebruik van de plugin (zowel de punten als de vlakken zijn ingelezen):

selection_276

Overigens is het voor de snelheid belangrijk om alleen die geometrie typen aan te vinken die daadwerkelijk in het gml bestand zitten. Anders moet de plugin de hele gml uitpluizen op zoek naar een geometrie type dat er niet is. Dat kan lang duren!

Met behulp van de plugin is het gebruik van de BGT gml bestanden niet zo moeilijk meer en hoef je niet over te gaan tot het gebruik van Postgis en/ of NL-extract.

Wel is het jammer dat je niet zomaar de prachtige visualisatie van Jan-Willem van Aalst kunt gebruiken. Nu maar hopen dat iemand een mooie visualisatie maakt (en deelt!)voor de bestanden die je rechtstreeks met de BGT import plugin inleest.

8 thoughts on “De QGIS BGT plugin”

  1. Handig die plugin bedankt. Ik heb nog wel een andere vraag: Ik wil dit vervolgens omzetten naar dxf om de pdok in te lezen in microstation maar het exporteren lukt me niet. De DXF kan microstation niet inlezen. Wat doe ik verkeerd?

    1. Tja, .dxf is geen open standaard, met alle problemen van dien. Middels veel ‘reverse engineering’ moeten ontwikkelaars proberen de boel aan elkaar te knutselen. Dat gaat niet altijd goed.

      Mijn ervaringen zijn het best via ogr2ogr. Je zou kunnen proberen bijv. de _V.gml bestanden mbv ogr2ogr om te zetten naar .dxf. Eerst vanuit Qgis de laag opslaan als een shapefile, en daarna mbv ogr2ogr converteren naar .dxf is ook een kansrijke optie.

  2. Beste Marco,

    Hartelijk dank voor de plugin, deze is erg handig. Kan het zijn dat er bij de ‘scheiding’ iets mis gaat? In het gebied wat ik aan het testen ben is er een polygoon van een geluidsscherm (vlak), met daarin een hartlijn (lijn). De GML wordt netjes gesplitst in _L en _V alleen het lijnen-bestand (_L) geeft zowel de omtrek van de polygoon als de hartlijn, terwijl ik hier alleen de hartlijn zou verwachten.

    Alvast bedankt voor de reactie!

    1. Gerbert,
      Er kan natuurlijk altijd iets misgaan. Maar dan zou het mis moeten gaan in ogr, de bibliotheek die in QGIS alle vectordata inleest. En ogr is wel erg goed …

      Weet je zeker dat in het lijnen bestand zowel een vlak als een lijn zit? Is het niet de omtrek (begrenzing) zowel als de hartlijn. Dat zouden in beide gevallen lijnen zijn, en technisch klopt het dan. Of dat ook is wat je wilt weet ik niet.

      1. Beste Marco,

        Er lijken twee dingen mis te gaan:
        – Op sommige plekken is er inderdaad zowel een omtreklijn als een hartlijn aanwezig. Dat zit dus gewoon in de BGT zelf. Volgens mij heeft de bronhouder dat niet goed gedaan, maar daar kan de plugin niets aan doen.

        – Maar met de bestanden zelf lijkt ook iets niet goed te gaan. In QGIS splitst de plugin de bestanden netjes naar _L en _V, maar ik gebruik deze bestanden om ze in te lezen in een ander softwarepakket. Daar wordt ook onderscheid gemaakt in lijnen en vlakken. Maar als ik het vlakken bestand in dat pakket inlees, worden er veel meer vlakken geladen dan in QGIS (op plekken waar in QGIS alleen een lijn aanwezig is). Als ik het vlakken bestand uit QGIS exporteer naar shape en die vervolgens in mijn softwarepakket inlaadt, gaat het wel goed. Kan het zijn dat er op dit punt toch een foutje in de GML zit? Voor andere BGT lagen gaat het namelijk wel goed.

        1. Beste Gerbert,

          De plugin verandert aan de .gml bestanden niets. De enige reden dat er een _L en een _V gemaakt wordt is dat er dan een _L.gfs of _V.gfs bestand naast gezet kan worden. In de .gfs bestanden wordt door de plugin de info geschreven die door ogr gebruikt wordt om de gml goed in QGIS in te lezen.

          Blijkbaar gebruikt jouw andere software-pakket geen ogr om de gml in te lezen. Dan werkt het dus niet. De plugin is dan ook bedoeld om de gml bestanden in QGIS in te lezen …

  3. Vanaf qgis 3 (nu nog 2.99) zal de gmlAS plugin voor qgis beschikbaar komen. Daarmee wordt het mogelijk om volledige application schema’s zoals BGT te openen in QGIS.

    De werking van gmlAS is gebaseerd op het automatisch aanmaken van een relationele database (postgres of sqlite) op basis van het xml schema document. Vervolgens wordt de GML ingelezen in de aangemaakte tabellen. Als gebruiker kun je vervolgens bepaalde tabellen als lagen aan de qgis view toevoegen en objecten bekijken en zelfs bewerken. Later kun je het bestand weer als een GML exporteren.

    Een interessante feature die ik wil noemen is de mogelijkheid om tabellen die na import toch geen data zouden gaan bevatten niet aangemaakt worden. Door de geneste structuur van veel application schemas is de hoeveelheid aangemaakte tabellen doorgaans erg groot. Hiermee houdt je dat een beetje in de perken.

    Je kunt meer lezen op
    https://github.com/BRGM/gml_application_schema_toolbox

Geef een reactie

Je e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *

De volgende HTML tags en attributen zijn toegestaan: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>