BGT Inladen & ontbreken subcategorieën in QGis

[Joes]

Hi allen,
Ik probeer al een hele tijd de BGT van een bepaald gebied te downloaden van PDOK download viewer om vervolgens in QGis te laden.
Zoals de meeste weten download je dan een .zip file met verschillende .GML datasets daarin.

Via de BGT plugin in QGis link ik vervolgens het gedownloade bestand naast ‘Importeer BGT data uit zip’. Wanneer ik deze vervolgens dan inlaadt, verschijnt alleen de .GML van ‘bak (punt)’ en ‘begroeidterreindeel (vlak)’ inclusief alle subcategoriëen hiervan (boomteelt, bouwland, duin, etc.).
Alle andere categorieën uit de .zip ontbreken.
Heeft iemand enig idee hoe dit kan?

Ik heb daarnaast geprobeerd om verschillende .gml’s uit die gedownloade .zip handmatig toe te voegen. De data verschijnt, alleen ontbreken verder alle subcategorieën wanneer de .gml’s handmatig toegevoegd worden (dus alles uit bijvoorbeeld ‘bgt_wegdeel.gml’ staat onder 1 laag en is niet te filteren in de verschillende soorten wegen).

Het is mij bekend dat enkele jaren geleden een verandering is doorgevoerd m.b.t. de BGT waardoor de plugin niet meer volledig werkt zoals vóór die verandering. Heeft dat hier mee te maken?

Thanks!

[Anton]

Welke versie gebruik je van de BGT Import plugin? En welke QGIS?

Als ik hier test met QGIS 3.30 en plugin BGT Import 3.16 dan lijkt alles wel correct:

[Joes]

Hi Anton,

Bij mij zijn voor beide precies dezelfde versies geïnstalleerd.
Voor het gemak even een screenshot toegevoegd van wat ik te zien krijg.

Ik neem aan dat jij als formaat ook citygml hebt geselecteerd in PDOK?
Moet toegeven dat ik gmllight of stufgeo formaat nog niet uitgeprobeerd heb, maar het lijkt me zeer onwaarschijnlijk dat daar het probleem ligt aangezien citygml vaak toch de standaard is.

[Anton]

Stufgeo heb je inderdaad niets aan, is volgens mij alleen voor berichtenverkeer tussen LV en leverancier.

Ik denk dat je de maker van de plugin @marco_duiker het beste even kan vragen, wie weet kan hij er iets zinnigs over zeggen.

[wvdbee]

Ik kan de bevinding van Joes bevestigen. Veel foutlopers vandaag meegemaakt met de BGT-import-plugin; zelfs op BGT-downloads die eerder wél importeerden, raar genoeg.

Wat ik zie in de python-logs is dat het script vastloopt op het moment dat een objecttype aan de beurt is die niet gevonden lijkt te kunnen worden. Voorbeeld: na het importeren van onbegroeid_terrendeel_V wil de plugin onbegroeid_terreindeel_L importeren. Probleem met het vinden van dat objecttype/gml/zip-bestand en het script faalt.
Volgende deel van het script, het tonen van wél geïmporteerde BGT-objecten wordt vervolgens uitgevoerd Je ziet dan een deels geïmporteerde BGT in je QGIS-project.

Voorbeeld uit een logfile.
GML-bestand is overigens wél aanwezig in getoonde Local\Temp-map; even gecontroleerd.

Ik weet niet of @marco_duiker de plugin nog beheert. Laatste update dateert van 2 jaar geleden, zie ik op Github.

Mijn setup: QGIS-3.30.3, GDAL 3.7.0, laatste BGTImport-plugin, Windows 11.

[marco_duiker]

Jahoor, de plugin wordt door mij nog steeds beheerd.

Terugmeldingen van gebruikers zijn daarvoor essentieel. Ik gebruik de plugin namelijk zelf niet. Ik werk eigenlijk ook nooit met de BGT.

Maak alsjeblieft een issue aan op github, en voeg daar dan bij de gedownloade zip en de berichtenlog van QGIS.

Volgende week ga ik er dan even naar kijken.

Vriendelijke groet,Marco

[wvdbee]

@marco_duiker
Issue aangemaakt.

Importer breekt af na foutmelding over mapnaam in TEMP-map

Wim

[marco_duiker]

De boel is uitgeplozen en herleidt tot het volgende:

Sinds versie 3.7.0 gaat GDAL ervan uit dat geometrie van CityGML in 3D is conform de CityGML standaard:
(OGC City Geography Markup Language (CityGML) 3.0 Conceptual Model Users Guide):

Spatial properties of all CityGML feature types are represented using the geometry classes defined in ISO 19107. Spatial representations can have 0-, 1-, 2-, or 3-dimensional extents depending on the respective feature type and Levels of Detail (LOD). The LOD concept is discussed in [ug-levels-of-detail-section] and [ug-geometry-lod-section]. With only a few exceptions, all geometries must use 3D coordinate values.

Voor de een aantal lijngeometrie elementen wordt het attribuut srsDimension niet gebruikt. GDAL gaat er dan van uit dat de poslist steeds x y z waarden bevat ipv xy waarden.

Het toevoegen van srsDimension="2" aan het posList element lost het probleem op.

Voorbeeld: in bgt_ondersteunendWegdeel komt een element voor met ifentificatie:

            <imgeo:identificatie>
                <imgeo:NEN3610ID>
                    <imgeo:namespace>NL.IMGeo</imgeo:namespace>
                    <imgeo:lokaalID>G0274.6d2f97620c5346af9f092ee268d2c6a2</imgeo:lokaalID>
                </imgeo:NEN3610ID>
            </imgeo:identificatie>

Deze bevat een element:

<imgeo:geometrie2dOndersteunendWegdeel><gml:Polygon xmlns:gml="http://www.opengis.net/gml" srsName="urn:ogc:def:crs:EPSG::28992"><gml:exterior><gml:LinearRing><gml:posList srsDimension="2">187888.305 444056.518 …

Hier wordt de srsDimension expliciet genoemd zoals vereist door de standaard.

Daarnaast is er ook ook:

<imgeo:kruinlijnOndersteunendWegdeel><gml:LineString xmlns:gml="http://www.opengis.net/gml"><gml:posList>187888.305 444056.518 …
Hier wordt de srsDimension niet expliciet genoemd hetgeen leidt tot foutief inlezen (GDAL verwacht een posList met x y z ipv x y).

Wijzigen tiot
<imgeo:kruinlijnOndersteunendWegdeel><gml:LineString xmlns:gml="http://www.opengis.net/gml"><gml:posList srsDimension="2">187888.305 444056.518 …
leidt wel tot correct inlezen.

Vraag aan de beheerders van BGT en/ of PDOK: Kan de gml conform de standaarden uitgeleverd worden met het srsDimension attribuut op alle geometrie?

[PieterDijkstraBAG]

Bij deze een reactie vanuit het Kadaster als beheerder van de LV BGT. Je bevinding is terecht. We gaan onderzoeken wat de oorzaak is en hoe dit opgelost kan worden.

[PieterDijkstraBAG]

Het gegeven srsDimension 2 wordt door de Bronhouder in de aanlevering niet meegeleverd en zit daarmee niet in de LV-BGT. De srsDimension is destijds als optioneel gegeven toegevoegd aan de dagelijkse doorlevering naar PDOK. Dit blijkt nu niet te zijn ingeregeld voor de Kruinlijngeometrie.

Als we dit nu alsnog zouden gaan doen, moeten we de gehele BGT volledig doorleveren. Dit zou een (nadelige) effect hebben voor de afnemers van de mutatiedownloads in PDOK.

Om deze impact te voorkomen gaan we dit nu niet oplossen, maar op een later moment als onderdeel van een grotere wijziging waarbij er toch al impact is. Het is nu nog niet bekend wanneer dat zal zijn.

We zullen dit probleem op een known issue lijst plaatsen, zodat bekend is dat dit probleem speelt.

[marco_duiker]

Dank voor de toelichting.

Inmiddels hebben we een quick en dirty hack in de QGIS BGT import plugin gemaakt om de srsDimension “op de vlieg” toe te voegen. Deze hack is in de nieuwste versie van de plugin zoals die in QGIS beschikbaar is opgenomen.

Graag krijg ik bericht wanneer de levering vanuit PDOK weer conform de CityGML standaard is (dus met srsDimension = 2). Dan kunnen we deze hack weer verwijderen.