BGT begroeid terreindeel en ondersteunend wegdeel steeds vaker niet leesbaar via GDAL

Datasets BGT
#1

Steeds meer gml bestanden van begroeid terrein deel en ondersteunend wegdeel niet meer leesbaar via GDAL. :frowning:
Waarom zou je het makkelijk maken als het ook moeilijk kan.

#2

Wat gaat er mis dan? Heb je ook voorbeelden? Ligt het aan de gml-bestanden of aan GDAL?

Als je verbetering wil moet je denk ik iets meer doen dan klagen.

2 likes
#3

Daar heb je een punt, mijn irritatie is ontstaan omdat het aanvankelijk goed functioneerde.

Ik zie dat op steeds meer locaties de begroeidTerreindeel en ondersteunendWegdeel niet worden ingeladen vanwege steeds eenzelfde soort foutmelding. Ik vermoed dat het ligt aan een nieuwe manier van opslaan/genereren van deze bestanden. Onlangs voor een project in Franeker kon ik gewoon alle bestanden inladen (begin van de week) in de loop van de week had ik het bestand opnieuw binnengehaald en gaven zowel de begroeidTerreindeel als de ondersteunendWegdeel nu een foutmelding. Typish is dat ik deze foutmeldingen uitsluitend krijg bij deze twee lagen. Ook op andere locaties.

Voor het begroeid terreindeel heb ik het proberen uit te zoeken. Hier werd in het geval van Franeker de volgende foutmelding gegenereerd:

  1. Solution exception:Did not get at least 3 values or invalid number of set of coordinates gml:posList165939.559 578110.965 165939.758 578109.007 165942.823 578088.182 165943.314 578085.620</gml:posList>

Het lijkt daarbij te gaan om Ă©Ă©n van de volgende 2 objecten.

  • G0070.80825dc0926b4c91bac2cdfd69ec7a36
  • G0070.f850c971b97c417fb34a9b49debc1a38

Ik heb niet kunnen achterhalen waarom deze fout ontstaat. Als ik de gml omzet naar json en de geometrie genereer, lijkt er niet direct iets aan de hand. De geometrie ziet er goed uit en krijg ik geen foutmeldingen. Alle polylijnen zijn keurig gesloten. Wel is vreemd dat ik deze gml:posList niet heb kunnen vinden in het gml gestand. Wel een gml:posList met 1 coördinaat meer.

{165941.818, 578110.982, 0}
{165939.559, 578110.965, 0}
{165939.758, 578109.007, 0}
{165942.823, 578088.182, 0}
{165943.314, 578085.62, 0}

De eerste coördinaat van het lijstje wordt niet in de foutmelding weergeven, maar zou mogelijk wel de oorzaak kunnen zijn.

Helaas kun je hier geen zip bestanden van een gml uploaden.
Ik heb het bestand gedownload met de volgende request:

https://api.pdok.nl/lv/bgt/download/v1_0/full/custom


{
  "featuretypes": [
    "begroeidterreindeel",
    "kunstwerkdeel",
    "onbegroeidterreindeel",
    "ondersteunendwaterdeel",
    "ondersteunendwegdeel",
    "openbareruimte",
    "overbruggingsdeel",
    "pand",
    "spoor",
    "straatmeubilair",
    "vegetatieobject",
    "waterdeel",
    "wegdeel"
  ],
  "format": "citygml",
  "geofilter": "POLYGON((164548.944713 578729.090304,164948.944713 578729.090304,164948.944713 579129.090304,164548.944713 579129.090304,164548.944713 578729.090304))"
}
``` bestanden
#4

Googelen op de foutmelding leverde dit op:

Het lijkt er op dat in de genoemde GML een bonte mix van 2D en 3D coördinaten wordt gebruikt.

1 like
#5

@gisnederland,

Dank je voor de tip. Ik ga het uitzoeken. Het zou een goede verklaring kunnen zijn.

#6

Dit probleem (en vele andere) wordt opgelost door de BGTimport plugin.

1 like
#7

zie ook: BGT Inladen & ontbreken subcategorieën in QGis - #7 door wvdbee

1 like
#8

Helaas gebruik ik geen Qgis. Het zou ook fijn zijn als dit in de GML wordt aangepakt.

#9

het importgedeelte van de plugin kun je ook zonder QGIS gebruiken. In https://github.com/MarcoDuiker/QGIS_BGT_Import/blob/master/bgt_utils/utils.py staat de functie import_to_geopackage.

Die kun je gewoon vanuit python aanroepen. je moet dan wel gdal geinstalleerd hebben.

3 likes
#10

Dat hebben ze beloofd. kan wellicht wel ff duren 


#11

Update van wat we eerder onder BGT Inladen & ontbreken subcategorieën in QGis - #8 door marco_duiker gemeld hebben:

Wij zouden dit ook graag in de GML oplossen. Maar om dit op te lossen moeten we een complete doorlevering van de BGT aan PDOK doen. Dit zou een (nadelige) effect hebben voor de afnemers van de mutatiedownloads in PDOK. De impact op de BGT-keten is te groot om door te voeren.

Daarom staat deze actie vooralsnog niet ingepland.

#12

Wegdeel, OnbegroeidTerreindeel, BegroeidTerreindeel en OndersteunendWegdeel hebben twee geometrieën: een 2D vlakgeometrie en een 2D kruinlijngeometrie. Bij het inlezen in QGIS of andere software wordt veelal één geometrie opgepakt. Bij begroeidTerreindeel en ondersteunendWegdeel komt als attribuut eerst de lijngeometrie en vervolgens de vlakgeometrie. QGIS/GDAL pakt volgens mij de eerste geometrie. De foutmelding zou dus kunnen ontstaan als expliciet geometrietype Vlak wordt verwacht. Ik loop hier ook tegenaan bij het importeren van BegroeidTerreindeel en OndersteunendWegdeel in bijvoorbeeld PostGIS m.b.v. OGR.

1 like
#13

In OGR kun je met -select <field_list> aangeven welke kolommen je wilt meenemen, ook geo-kolommen.

Van ogr2ogr — GDAL documentation):

Comma-delimited list of fields from input layer to copy to the new layer. A field is skipped if mentioned previously in the list even if the input layer has duplicate field names. (Defaults to all; any field is skipped if a subsequent field with same name is found.) Geometry fields can also be specified in the list.

2 likes
#14

Ha, dit probleem kwam ook in NLExtract ineens naar boven. Maar: het probleem zit volgens mij niet (alleen) in de BGT data, maar in de (recente) manier waarop GDAL/OGR met de situatie (srsDimension mist) omgaat.

Bij recente versies van GDAL, ongeacht BGT data datum, gaat het niet goed (ERROR 1: Did not get at least 3 values 
,) zoals boven, bijv bij aanroep van ogrinfo en ogr2ogr. Lijkt alleen bij aanroep vanuit Python op te treden (?).

Zonder hier mijn hele onderzoek te dupliceren: vind de details en de oplossing in dit NLExtract issue.

In het kort is mijn bevinding:

  • recente GDAL versies gaan anders om met ontbreken srsDimension in (City)GML, ook bij bijv 4 jaar oude BGT data
  • de oplossing is een CityGML-specifieke, (niet-gedocumenteerde?) GDAL config parameter aptly named: GML_SRS_DIMENSION_IF_MISSING

Bijv in ogr2ogr: --config GML_SRS_DIMENSION_IF_MISSING 2, dus forceer 2D. In NLExtract gaat daarmee inlezen BGT, bijv. Begroeidterreindeel, weer goed.

2 likes
#15

Achtergrond (en zeepkist): Het is begonnen in GDAL 3.6 om default dimensie 3 voor CityGML te gebruiken, zie deze commit en GDAL issue. Dat gaf weer andere problemen (zie boven). Maar de niet-gedocumenteerde, config GML_SRS_DIMENSION_IF_MISSING, was er al in 2016 via dit issue pre-GitHub zelfs


Kunnen we natuurlijk op mopperen maar:

  • GDAL is misschien de meest gebruikte library in zowel Open als proprietary GIS
  • tegelijk is/was het GDAL project bij tijden underfunded, zelfs door 1 persoon onderhouden
  • dat gaat nu gelukkig veel beter, maar er kunnen altijd nog sponsors bij, zie de GDAL sponsor pagina, voor NLExtract ook overigens.

Bovendien is m.i. het gebruik van CityGML als basis voor BGT achteraf een bizarre ontwerp keuze, die zaken onnodig complex maakt:

  • nergens in BGT wordt de CityGML core syntax/namespace gebruikt: zoals Lod1, Lod2 etc
  • daardoor kan (denk ik) ‘echte’ CityGML software er niets mee
  • voorzover ik zie, wordt in ieder CityGML Feature Element de BGT inhoud middels een imgeo: XML Namespace ingebed, soms zelfs genest, Sub-Feature Elementen met ook weer geometrie, nog meer complexiteit en in NLExtract custom code nodig.
  • BGT GML levering had net zo goed in een standaard GML schema gepast, zelfs GML v2

Nu ja, de ontwerpers hadden mogelijk ook voorzien dat dit iets tijdelijks zou zijn en dat er snel naar 3D/core CityGML zou worden gegaan voor BGT. I.h.a. zouden wel eens moeten nagaan of deze vorm van (EA XSD Applicatie Schema’s) modelleren wel bestendig is. Vergelijk bijvoorbeeld OpenStreetMap met een open “tagging-model”, waarin meerdere zeg Basisregistratie-achtige features tezamen geïntegreerd zijn, zelfs in 1 database, en een ecosysteem van tools en toepassingen daardoor gemakkelijker ontstaat
Ok, mijn stokpaardje nu op stal!

2 likes
#16

Mee eens, die heb ik ook nooit begrepen


:scream:
Alsjeblieft niet zeg. Als je OSM eens goed gaat bekijken en er wat dieper in gaat graven, kom je dus echt bijna per OSM Mapper een eigen datamodel tegen. En je loopt nu al tegen het feit aan dat je de verschillende bronhouders uit de BGT kunt halen door de verschillende interpretaties, toepassing van verplichte/niet verplichte zaken, enzovoorts enzovoorts. Met dat OSM datamodel waar ik de kriebels van krijg word dat helemaal onbruikbaar, tenzij de inwinning en bijhouding van de hele BGT door 1 enkele partij word gedaan


Dan zal ik de mijne nu ook op stal zetten, maar ik kon het toch niet laten :wink: :smile:

1 like
#17

Wat betreft OSM: tagging soep/chaos, eigenwijsheid van de individuele mapper, en “amateurisme” i.h.a., worden vaak als kritiek-argumenten gebruikt. Alle voordelen van de OSM-infrastructuur , de locale communities, het uniforme ecosysteem van APIs tools/apps, komen daarmee op de achtergrond. Vaak zonder te weten plukken velen de vruchten van OSM middels apps zoals Komoot, Waze, maps.me, e.v.a. en kaarten als OpenBasisKaart, OpenTopo (TopoPlus), map5topo, etc.

Hier nu off-off-topic, maar wil daar, bijv “Wat kan het OSM systeem voor de Basisregistraties betekenen”, graag eens een nieuw topic of meetup over beginnen.

Komen we ook een beetje uit de GeoForum-topic-modus van “(Open Source) Product X / PDOK Service Y werkt niet voor mij”, maar kunnen we, gezamelijk ons geo-domein vakinhoudelijk verder ontwikkelen!

Edit: de USGS heeft ooit zo’n experiment (intern OSM stack/tools gebruiken) gedaan,lang geleden, werd op FOSS4G 2011 Denver gepresenteerd Eric B. Wolf, o.a., ik vond nog een PDF Rapport.

1 like
#18

Nog sterker: los van infra/API/toosl: alleen al het OSM “datamodel” tagging/soep (“chaos”, die overigens vĂ©Ă©l minder chaos is dan menigeen denkt) is volgens mij een nuttige spiegel voor iedere informatiemodelleur.
Waar “formele” informatiemodellen de wereld “a priori” probeert te beschreven doet OSM dat ad-hoc: als je als OSm-mapper iets tegenkomt wat nog niet bestaat verzin je ter plekke een nieuwe “tag”.
Soort van “waterfall” vs.“agile” tegenstelling dus :slightly_smiling_face:
(oh nee, geen tegenstelling: maar 2 elkaar aanvullende methoden!)

1 like