BRK extract GML omzetten naar GDB

Datasets BRK
#1

Goedemiddag,

Ik wil met behulp van FME de extract van de download API (PDOK API - Swagger UI) omzetten van GML bestanden naar een file geodatabase zodat wij deze kunnen gebruiken in onze gis omgeving.

Nu krijg ik bij de transformatie een aantal warnings en errors waar ik niet zo van goed weet hoe ik het op moet lossen. Kunnen jullie mij misschien verder helpen?

Errors in kwestie

Creating reader for format: CityGML
Trying to find a DYNAMIC plugin for reader named `CITYGML’
Loaded module ‘CITYGML’ from file ‘E:\Program Files (x86)\FME_2019_32\plugins/CITYGML.dll’
FME API version of module ‘CITYGML’ matches current internal version (3.8 20190820)
Opening the CITYGML reader with source dataset ‘E:\FME_productie\Kadaster\Workbench\extract\dkk_openbareruimtelabel.gml’
Parsing XML document ‘E:\FME_productie\Kadaster\Workbench\extract\dkk_openbareruimtelabel.gml’
The XML Reader is using xfMap ‘E:\Program Files (x86)\FME_2019_32\xml\CityGML\CityGML_xfMap.xml’
Parsing XML document ‘E:\FME_productie\Kadaster\Workbench\extract\dkk_openbareruimtelabel.gml’
Cannot find a matching schema named ‘CityModel’ in the known set of schemas: ‘gml_FeatureCollection, kk_brkkadastralekaartCollection, oz_KadastraleGrens, oz_Perceel’. Known schema sources are: ‘Schema from Schema Feature, GML_1’. Please verify writer feature type configuration.
Error running translation.

#2

De Kadastralekaart v4 is gebaseerd op IMKAD GML Applicatieschema’s, met daarin “stukjes” CityGML uit de BGT (Panden incl Nummeraanduidingen, Openbareruimtelabels). Dit is sowieso een klus om “plat te slaan” naar welke database dan ook. Je zult sowieso een mapping moeten definiëren, “subfeatures” uitpluizen. Daarbij moet je “dicht op de data zitten”. In mijn optiek wordt in IMKAD niet heel nauwkeurig de regels van GML Applicatie Schema gevolgd, zodat generieke tooling daar moeite mee heeft (correct me if I’m wrong). Ik ken FME niet goed genoeg, maar zie telkens een worsteling daar met GML verwerking.

Je kunt ook kijken naar NLExtract, deze gebruikt Stetl voor BRK-v3 verwerking met onder water ogr2ogr, v4 (waarin dus BGT objecten nieuw zijn) zit in de pipeline via dit issue: BRK Kadastrale Kaart (DKK) ETL: upgrade voor BRK-DKK v4 · Issue #272 · nlextract/NLExtract · GitHub . Als output zou je evt FGDB kunnen doen.

#3

Hallo @JWSjoel,

Je lijkt dynamic weg te schrijven. Staat je schema source op “Schema From Schema Feature”?
afbeelding
En schrijf je je schema mee?

Ik heb er geen problemen mee als ik de openbareruimtelabel.gml met FME inlees als GML en dynamisch wegschrijf.

#4

Ik maak gebruik van het schema brkkadastralekaart_v4_0_0.xsd zoals te vinden op de schema site. En ik schrijf inderdaad dynamisch weg. ‘‘Schema From Schema Feature’’ staat hierbij ook aan. Is het de bedoeling om elk GML bestand apart te transformeren of kan dit in 1 keer? Als je een duidelijke beschrijving kan geven van je werkende settings dan graag.

#5

Omdat het schema niet heel nauwkeurig wordt gevolgd, kon ik de features inlezen met ignore schema:
image

Ik kan me voorstellen dat dit onwenselijk is voor jouw toepassing. Bovendien werken deze settings dan weer niet voor Perceel en KadastraleGrens. Daar werkt de CityGML reader wél.