[Dutch] Digitale Kadastrale Kaart polygonen

[Just van den Broecke]

Hoi Rein et al,

De wereld van de GML-leveringen, en zeker de basisregistraties, zit 
helaas niet zo eenvoudig in elkaar. De issues zijn legio:

- iedere basisregistratie heeft eigen interpretatie van GML constructies 
(ipv GML Applicatie Schema, m.i. alleen BGT via CityGML, BAG is XML, 
IMKAD niet compliant)
- een GFS-bestand wordt bij eerste ogr2ogr "run" aangemaakt, daar hoeven 
niet alle feature-typen/geometrieen in te zitten van de dataset. Eigen 
GFS bijhouden, ook alleen al voor de veldnamen "waarde" ipv 
"oppervlakte" , is zinvol.
- geometrie in GML kent specifieke "Point", of zeer ruime definities 
"sequence of Geometry", m.a.w. uit XSD niet af te leiden

Iets generieks zal toch een parser-achtige constructie moeten zijn en 
alle features moeten "doorakkeren". Per basisregistratie kun je ook nog 
speciale zaken hebben als "historie" (meerdere voorkomens per object id) 
bijv BAG. Het is niet voor niets dat NLExtract bestaat :-).

Meerdere geometrieën per feature, bijv:
- BRK-DKK perceel: de Point is label-plaats, m.i. overbodig
- BRT/Top10NL: wegdeel: Punt/Lijn/Vlak, nuttig
- BGT idem

Voor de laatste twee gebruikt NLExtract een "splitter-script" om de 
features "plat te slaan" tot 3 feature-typen, bijv wegdeel_lijn, _vlak, 
_punt. Zie bijv 
https://github.com/opengeogroep/NLExtract/blob/master/top10nl/etl/xsl/top10-split_v1.2.xsl 


Frank en ik komen graag een keer langs bij Kadaster ;-).

Met vriendelijke groet,

--Just


On 20-04-16 09:20, deduikertjes wrote:
> Rein,
>
> Misschien is het goed om iets 'breder' te kijken.
>
> Het object georienteerde datamodel laat vele constructies toe die
> moeilijk zijn 'plat te slaan' in het 'kaartlaag met vaste set
> attributen' datamodel zoals vaak wordt gehanteerd in desktop GIS (met
> name zoals we gewend zijn in ESRI-GIS).
>
> Meerdere type geometrie bij een object is maar 1 zo'n probleem.
>
> Uiteindelijk zul je bij het bruikbaar maken van de data in zo'n
> kaartlaag georiënteerd datamodel gewoon heel goed moeten uitzoeken hoe
> het oorspronkelijke datamodel in elkaar zit, en hoe dat het beste
> omgezet kan worden zodat de benodigde info op een logische manier bij de
> gebruiker komt. Liefst zonder dataverlies en constructies met meerdere
> attributen in 1 kolom.
>
> Hoe dat vervolgens technisch in te vullen is een volgende stap. (Het
> verdient natuurlijk wel aanbeveling om bij het opstellen van een
> datamodel van een basisregistratie gelijk al een weg te kiezen die het
> software makkelijk maakt, maar dat is hier al een gepasseerd station).
>
> Let wel, bovenstaand betoog is geschreven zonder naar het specifieke
> datamodel te kijken en te beoordelen in hoeverre het inderdaad zonder
> problemen 'plat te slaan' is.
>
> Met vriendelijke groet, MArco
>
>
> On 19-04-16 19:39, Rein van 't Veer wrote:
>> Beste Osgeo.nl lijst,
>>
>> Allereerst dank dat jullie naar mijn verzoek zouden willen kijken:
>> mijn naam is Rein van 't Veer en ik werk bij Geodan, gedetacheerd bij
>> het Kadaster. In teamverband werk ik aan het project GRID: een
>> vernieuwingsproject om geodata beter beschikbaar te krijgen.
>>
>> Eén van de doelen van het GRID-project is om de onlangs vrijgegeven
>> Digitale Kadastrale Kaart (DKK, handig per provincie te downloaden
>> vanaf
>> https://www.pdok.nl/nl/producten/pdok-downloads/basis-registratie-kadaster/kadastrale-kaart) op
>> andere manieren te ontsluiten - als REST API en als Linked Data. Maar
>> we lopen er even tegenaan dat de dataset, gedownload als GML de nodige
>> uitdagingen bevat. Dit probleem leg ik graag voor aan deze open groep,
>> aangezien het antwoord erop, naar ik hoop, voor anderen waardevol kan
>> zijn die de DKK willen gebruiken.
>>
>> Zo bevat de 'laag' Percelen per perceelsobject twee typen geometrie:
>> een punt-object en (naar ik in de ruwe GML kan zien), een
>> polygoongeometrie. We zijn natuurlijk vooral geïnteresseerd in de
>> laatste, maar deze wordt door QGIS (via GDAL) gevoeglijk genegeerd.
>> GDAL lijkt maar moeizaam om te kunnen gaan met meer dan één geometrie
>> per object.
>>
>> Vraag is nu: hoe krijg ik de polygonen (de brk_krt:begrenzingPerceel)
>> geconverteerd naar GeoJSON? En hoe kan ik niet de punten, maar de
>> polygonen vanuit GML openen in QGIS? GDAL lijkt helaas een voorkeur te
>> hebben voor de puntgeometrieën. De pagina
>> http://www.gdal.org/drv_geojson.html geeft wel enige aanwijzing voor
>> conversie met behulp van de omgevingsvariabele
>> GEOMETRY_AS_COLLECTION=YES, maar dit lijkt niet het gewenste effect te
>> hebben op bijvoorbeeld een opdracht als:
>>
>> $ ogrinfo Perceel.gml
>> Had to open data source read-only.
>> INFO: Open of `Perceel.gml'
>>       using driver `GML' successful.
>> 1: Perceel (Point)
>>
>> $ ogr2ogr -f GeoJSON Perceel.NO.geojson Perceel.gml
>>
>> $ ogrinfo Perceel.NO.geojson
>> ERROR 4: GeoJSON Driver doesn't support update.
>> Had to open data source read-only.
>> INFO: Open of `Perceel.NO.geojson'
>>       using driver `GeoJSON' successful.
>> 1: OGRGeoJSON (Point)
>>
>> $ export GEOMETRY_AS_COLLECTION=YES
>>
>> $ ogrinfo Perceel.YES.geojson
>> ERROR 4: GeoJSON Driver doesn't support update.
>> Had to open data source read-only.
>> INFO: Open of `Perceel.geojson'
>>       using driver `GeoJSON' successful.
>> 1: OGRGeoJSON (Geometry Collection)
>>
>> De Geometry Collection bevat vervolgens enkel punten. GDAL onderkent
>> geen polygonen in de dataset. Hoe kom ik er op een elegante
>> (automatische) manier achter welke typen geometrie er in de dataset
>> zitten? Iemand enig idee hoe dit benaderd kan worden? Ik heb wel een
>> vergelijkbare melding gevonden op
>> <http://gis.stackexchange.com/questions/37217/why-are-the-polygons-in-my-gml-not-rendered>http://gis.stackexchange.com/questions/37217/why-are-the-polygons-in-my-gml-not-rendered maar
>> het handmatig aanpassen van het GDAL .gfs is niet echt een elegante
>> oplossing. Moet ik met Sax of een ander olifantenmiddel de
>> puntgeometrieën eruit filteren? Of kan er een andere library benut
>> worden zoals de Java(Script) Topology Suite?
>>
>> Alles suggesties zijn welkom, alvast veel dank,
>> Rein van 't Veer
>>
>>
>> _______________________________________________
>> Dutch mailing list
>> Dutch op lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/dutch
>
>
>
> _______________________________________________
> Dutch mailing list
> Dutch op lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/dutch
>