Gebruik BGT panden

Datasets BGT
#1

Met enige regelmaat komt er bij PDOK een melding binnen dat niet alle BGT-panden worden getoond wanneer uit een BGT-extract het bestand bgt_pand.gml in bijv. QGIS wordt ingelezen. Er worden alleen bijgebouwen getoond. De oorzaak hiervan is dat hoofdgebouwen bijna altijd een nummeraanduidingreeks hebben. Een Nummeraanduidingreeks is een subfeature binnen een BuildingPart (pand). Als deze aanwezig is, wil QGIS wel het labelpunt hiervan tonen, maar niet meer de vlakgeometrie.

Binnen QGIS is dit op te lossen door het GFS-bestand, bgt_pand.gfs, dat wordt aangemaakt en in dezelfde directory staat als bgt_pand.gml, aan te passen. Om alle pandvlakken te tonen, moet het volgende worden toegevoegd na de regel met ElementPath (regel 4):

<GeomPropertyDefn>
    <Name>geometrie2dGrondvlak</Name>
    <ElementPath>geometrie2dGrondvlak</ElementPath>
    <Type>MultiPolygon</Type>
</GeomPropertyDefn>
<SRSName>EPSG:28992</SRSName>

Sla het GFS-bestand op, verwijder de oude kaartlaag/-lagen uit QGIS en open het bestand bgt_pand opnieuw in QGIS. Deze werkwijze is getest met QGIS 2.18.9.

Enkele opmerkingen:

  • Het GFS-bestand kan worden hergebruikt, maar OGR, dat onder water door QGIS wordt gebruikt, verlangt wel dat de bestandsdatum nieuwer is dan van het GML-bestand. Aangezien een extract-download on-the-fly gegenereerd wordt, zal de bestandsdatum altijd nieuwer zijn. Zorg dat je het GFS-bestand opnieuw opslaat.
  • De nummeraanduidingreeks wordt hiermee niet getoond. Hiervoor moet het GMLFeatureClass element worden gedupliceerd en aangepast. Het tweede element moet worden hernoemd, de GeomPropertyDefn worden aangepast en alle attributen moeten worden nagelopen. De attributen die betrekking hebben op de nummeraanduiding of het label hierbinnen, moeten alleen in het nieuwe element voorkomen. Ik heb dit nog niet gedaan.

Meer informatie over het GFS-bestand is hier te vinden: http://www.gdal.org/drv_gml.html

Voor informatie binnen andere GIS-pakketten, neem contact op met uw leverancier. Indien mensen hiermee ervaring hebben, worden ze aangemoedigd om hun oplossingen hier te delen.

Laag met punten én vlakken toevoegen aan QGIS
#2

Dankjewel Frank! Gisteren was er in het gebruikersoverleg BGT ook sprake van panden die op mysterieuze wijze verdwenen zouden zijn. Hopelijk verklaart jouw observatie deze verdwijningen.

Des te meer een reden om naamgevingen (Nummeraanduidingreeks) als attribuut te zien van een object in plaats van deze als eigen geo-object of subfeature te modelleren om deze op de kaart te kunnen plaatsen. Mooi om mee te nemen in de doorontwikkeling van BGT/IMGeo!

#3

In Qgis kan 1 feature maar 1 geometrie hebben. De plugin “BGT import” lost dit op, hiermee wordt het bestand met panden gesplitst in een bestand met vlakken (bebouwing) en punten (huisnummers) .

#4

De problematiek gaat natuurlijk verder dan alleen panden en huisnummers.

Uiteindelijk dien je het importeren van gml te beschouwen als een database import en niet als het inlezen van een shapefile :wink:. Domeinkennis en het goed controleren van het resultaat zijn en blijven essentieel.

Op QGIS.nl schreef ik een wat uitgebreider stukje waarin de problematiek ook visueel wordt geïllustreerd.

De door Frank genoemde manipulatie van het GFS-bestand wordt door de QGIS BGT-import plugin automatisch uitgevoerd. Niet alleen voor panden, maar voor alle bgt onderdelen.

2 likes
#5

Marco heeft gelijk. Het treedt ook op bij begroeidterreindeel, onbegroeidterreindeel, wegdeel en ondersteunendwegdeel die ieder kruinlijnen hebben. Verder treedt er een issue op met openbareruimtelabels hebben. Die kunnen 1 of meerdere posities hebben. Dit is niet als een multipoint in de GML opgenomen.

Bij NLExtract maken we ook gebruik van GDAL en hiervoor gebruiken wij ook een gemanipuleerde GFS-file. Features met subfeatures knippen we nog eerst op met een XSLT, maar met recente GDAL-versies zou dat niet meer nodig moeten zijn.

Nummeraanduidingsreeksen zijn wat mij betreft ook attributen. De enige reden dat ze een geometrie hebben, is omdat dit van oudsher zo gedaan is (GBKN). Idem voor openbareruimtelabels. Het juist labelen van objecten is eigenlijk een technisch issue, wat in software opgelost moet worden. Aan de andere kant kan ik me wel indenken dat je een bepaalde mate van consistentie in het kaartbeeld wil hebben wanneer dit gevisualiseerd wordt door verschillende softwareproducten. Bij labels zullen de verschillen het grootst zijn.

Openbareruimtelabels zouden eigenlijk op de een of andere manier aan openbare ruimtes gekoppeld moeten worden.