Laag-informatie uit GML GeometrieBesluitobject_P1

Datasets Ruimtelijke Plannen
#1

Hallo,

Ik heb een vraag over de provinciale verordening van Zeeland zichtbaar mbv (Provinciale Omgevingsverordening Provincie Zeeland 2018, 7e wijziging NL.IMRO.9929.WijzOVOmgVer2018-VA07):
https://www.ruimtelijkeplannen.nl/viewer/view?planidn=NL.IMRO.9929.WijzOVOmgVer2018-VA07

De kaart bestaat vervolgens uit 3 lagen:
Bestaande Natuur
Agrarische gebied van ecologische betekenis
Nieuwe natuur

Als ik het bijbehorende GML-bestand download en converteer met ogr2ogr
ogr2ogr -f “ESRI Shapefile” test.shp NL.IMRO.9929.WijzOVOmgVer2018-VA07.gml

krijg ik o.a. een GeometrieBesluitobject_P1.shp bestand met enkel de velden gml_id en idealisati (en de geometrie).

Het onderscheid tussen de 3 genoemde lagen is dan nog enkel te maken door een substring uit het gml_id (1308,1309 of 1310) te halen of direct per ogr2ogr commando (voorbeeld Nieuwe natuur)
ogr2ogr -f “ESRI Shapefile” NL_IMRO_9929_WijzOVOmgVer2018_VA07_GeometrieBesluitobject_P1_Nieuwe_natuur.shp NL.IMRO.9929.WijzOVOmgVer2018-VA07.gml -sql “SELECT * FROM GeometrieBesluitobject_P1 WHERE “gml_id” LIKE ‘%1310%’” -skipfailures -overwrite

Is er een manier om direct een bestand te maken waarin het onderscheid tussen de drie genoemde lagen duidelijker zit ipv via een gml_id-substring query, de informatie lijkt wel te zitten in het betreffende gml-bestand.
Ik heb al van alles geprobeerd o.a. met een xsd-bestand ed. (in ArCGIS 10.6.1 met Interoperability connection, gml) die de structuur van het xml-bestand zou moeten beschrijven.

Bij voorbaat mijn dank.

Bas van Bemmel
Planbureau voor de Leefomgeving

#2

Beste Bas,

Door de specifieke manier waarop IMRO-documenten zijn opgebouwd kan ogr ze wel inlezen en converteren, maar over het algemeen met ernstig informatieverlies.

In IMRO bestanden verwijzen de objecten (met de inhoudelijke infomatie) middels een xlink naar de bijbehorende geometrie. Bij direct converteren met ogr kijkt ogr alleen naar de geometrie en negeert alle object informatie.

ogr kent een optie voor het resolven van xlinks (GML - Geography Markup Language — GDAL documentation). Daarmee wordt dan inderdaad de object informatie ingelezen, en de geometrie daaraan geknoopt. In het algemeen leidt dit tot veel herhalingen (er zijn altijd veel objecten die naar het gehele plangebied verwijzen). Daarnaast wil het naar mijn ervaring nog wel eens leiden tot het niet geheel en correct inlezen van de geometrie als er gebruik wordt gemaakt van multigeometrie in het IMRO bestand.

Dat laatste probleem kan eventueel opgelost worden door het volgende fragment zo vaak als het voorkomt te verwijderen uit de resolved versie van de gml:



                </gml:patches>
            </gml:Surface>
          </imro:geometrie>
          <imro:idealisatie>exact</imro:idealisatie>
        </imro:GeometrieBesluitobject_P3>
      </imro:begrenzing>
      <imro:begrenzing>
        <imro:GeometrieBesluitobject_P3>
          <imro:geometrie>
            <gml:Surface srsName="urn:ogc:def:crs:EPSG::28992">
              <gml:patches>

(bij automatisering middels “zoek en vervang” is dan het flexibel omgaan met witruimte wel van belang)

Normaal gesproken is het gemakkelijker om in QGIS de RuimtelijkePlannen plugin (Ruimtelijke Plannen — QGIS Python Plugins Repository) te gebruiken. Daarvoor dient het betreffende plan wel opgenomen te zijn in ruimtelijkeplannen.nl. Helaas lijkt dat voor het door jou genoemde plan niet het geval.

Marco

#3

Halo Marc,

Allereerst bedankt voor de reactie .

Ook dank aangaande de tip over de plugin van ruimtelijkeplannen. Ik zie dat het plantype: provinciale verordening niet gesupport wordt. (ik werk met QGIS-versie 3.14.16-Pi)
Ik krijg dan de melding Error: plantype not supported. Zijn er plannen om provinciale verordeningen ook te supporten mbv de plugin?

Aangaande de gml-coversie heb ik naar je advies gekeken en dat gaf wel al veel meer inzicht.

Ik heb verdere pogingen gedaan met de gml-driver dmv:

ogr2ogr -f “ESRI Shapefile” NLIMRO9929WijzOVOmgVer2018VA07_shp -a_srs “EPSG:28992” -fieldTypeToString StringList,IntegerList,Date --config GML_SKIP_RESOLVE_ELEMS HUGE --config GML_SKIP_RESOLVE_ELEMS NONE --config GML_EXPOSE_FID NO --config GML_EXPOSE_GML_ID NO NL.IMRO.9929.WijzOVOmgVer2018-VA07.gml

Dit resulteert in 4 shp-bestanden

  • Besluitgebied_P.shp: 1 geometrie
  • Besluitvlak_P.shp: 3 geometrieën het is telkens het laatst voorkomende record uit de laag GeometrieBesluitobject_P1
  • GeometrieBesluitobject_P1.shp:8205 geometrieën (op basis van de gml_id is te acherhalen Agrarische gebied van ecologische betekenis 220 (gml_id met substring 1309),Bestaande natuur 7735 (gml_id met substring 1308),Nieuwe natuur 250 (gml_id met substring 1310)
  • GeometriePlangebied.shp: 1 geometrie

Hieronder een deel van de gml voor Besluitvlak_P id NL.IMRO.9929PRIMA201200000000413.

imro:featureMember
<imro:Besluitvlak_P gml:id=“NL.IMRO.9929PRIMA201200000000413”>
imro:identificatie
imro:NEN3610ID
imro:namespaceNL.IMRO</imro:namespace>
imro:lokaalID9929PRIMA201200000000413</imro:lokaalID>
</imro:NEN3610ID>
</imro:identificatie>
imro:typePlanobjectbesluitvlak_P</imro:typePlanobject>
imro:naamAgrarische gebied van ecologische betekenis</imro:naam>
imro:themanatuur</imro:thema>
imro:verwijzingNaarTekstInfo
imro:TekstReferentie_PV
imro:verwijzingNaarTekstpt_NL.IMRO.9929.WijzOVOmgVer2018-VA07.xml#NL.IMRO.PT.s07b3dc90-b5c6-4468-8f26-e5ef75b63fc5</imro:verwijzingNaarTekst>
imro:typeTekstbijlage bij regel zonder voorbereidingsbescherming</imro:typeTekst>
</imro:TekstReferentie_PV>
</imro:verwijzingNaarTekstInfo>
imro:verwijzingNaarTekstInfo
imro:TekstReferentie_PV
imro:verwijzingNaarTekstpt_NL.IMRO.9929.WijzOVOmgVer2018-VA07.xml#NL.IMRO.PT.s6dd9adff-eafa-4e45-a065-c0b730efa3d2</imro:verwijzingNaarTekst>
imro:typeTekstregel zonder voorbereidingsbescherming</imro:typeTekst>
</imro:TekstReferentie_PV>
</imro:verwijzingNaarTekstInfo>
imro:cartografieInfo
imro:CartografieInfo
imro:kaartnummer2</imro:kaartnummer>
imro:kaartnaam10. Agrarische gebied van ecologische betekenis</imro:kaartnaam>
imro:symboolcodeS001</imro:symboolcode>
</imro:CartografieInfo>
</imro:cartografieInfo>
<imro:besluitgebied xlink:href="#NL.IMRO.9929.WijzOVOmgVer2018-VA07"/>
<imro:begrenzing xlink:href="#PRIMA2012ID.1309_18780_1_P1"/>
<imro:begrenzing xlink:href="#PRIMA2012ID.1309_18828_1_P1"/>
<imro:begrenzing xlink:href="#PRIMA2012ID.1309_18842_1_P1"/>
<imro:begrenzing xlink:href="#PRIMA2012ID.1309_18851_1_P1"/>
<imro:begrenzing xlink:href="#PRIMA2012ID.1309_18854_1_P1"/>
<imro:begrenzing xlink:href="#PRIMA2012ID.1309_18873_1_P1"/>
<imro:begrenzing xlink:href="#PRIMA2012ID.1309_18908_1_P1"/>
<imro:begrenzing xlink:href="#PRIMA2012ID.1309_18932_1_P1"/>
<imro:begrenzing xlink:href="#PRIMA2012ID.1309_18950_1_P1"/>

De ID’s voor Agrarische gebied van ecologische betekenis zijn dus wel degelijk aanwezig.(de PRIMA2012ID.1309************ codes). Kennelijk is de conversie nu in staat om maar 1-ID mee te nemen (er wordt een 1:1 relatie gelegd terwijl het eigenlijk 1:n is)

Daarna heb ik nog een poging gedaan met de GMLAS-driver die voor zover ik kan overzien gebruikt maakt van het xsd bestand (IMRO2012)

ogr2ogr -f “ESRI Shapefile” NLIMRO9929WijzOVOmgVer2018VA07_shp -a_srs “EPSG:28992” -oo REMOVE_UNUSED_FIELDS=YES -oo REMOVE_UNUSED_LAYERS=YES -oo XSD=IMRO2012.xsd -fieldTypeToString StringList,IntegerList,Date --config GML_ATTRIBUTES_TO_OGR_FIELDS YES --config GML_SKIP_RESOLVE_ELEMS HUGE --config GML_SKIP_RESOLVE_ELEMS NONE --config GML_EXPOSE_FID NO --config GML_EXPOSE_GML_ID NO GMLAS:NL.IMRO.9929.WijzOVOmgVer2018-VA07.gml

Dit levert de volgende bestanden op:
besluitgebied_p.shp
besluitvlak_p.shp
featurecollectionimro.shp
geometriebesluitobject_p1.shp
geometrieplangebied.shp
metadataimrobestand.shp
en nog een nog een reeks losse dbf’s

Bij het openen van shp-bestanden zie je echter geen geometrieën alleen de tabel is te openen. (voor geometriebesluitobject_p1 is nu een veld ogr_pkid zichtbaar)

Wat ik dus eigenlijk wil dat er een veld komt te staan bij GeometrieBesluitobject_P1 met daarin aangegeven of het Bestaande natuur, Nieuwe natuur of Agrarische gebied van ecologische betekenis betreft of dat Besluitvlak_P uit 8205 geometrieën bestaat (ipv nu 3).

Wat ik niet helemaal volgt is dat landelijke voorziening INSPIRE Download Service van Ruimtelijke plannen wel al in het goede format komt na conversie met ogr2ogr.
Ik neem dat zij ook alle xml’s-gml van de bronhouders bij elkaar nemen (mergen?) en door een of andere datamodel trekken? Is dat ergens openbaar beschikbaar hoe zij dit doen.

Alvast bedankt.

Met vriendelijke groet,
Bas

#4

Om je vraag iets netter af te pellen:

Ik denk dat je op zoek bent naar alle objecten die voorkomen op de kaart “Bestaande Natuur”. Evenzo ben je op zoek naar alle objecten die voorkomen op de kaart “Agrarische gebied van ecologische betekenis” en alle objecten die voorkomen op de kaart “Nieuwe natuur”.

Let hierbij op: objecten kunnen op meerdere kaarten voorkomen. Dit lijkt in jouw bestand niet voor te komen.

Als je de optie gebruikt om xlinks te resolven, ontstaat er een 2e gml bestand, met .resolved.gml als extensie. Daarin zit de informatie die je zoekt. De geometrie wordt mooi samengenomen per object (dit kun je zien als je de gml opent in een goede tekst editor). Helaas kan ogr er bij dit bestand zelf niet goed mee uit de voeten. Je ziet van elke kaartlaag alleen de eerste geometrie.
Ik zou denken dat dit middels het manipuleren van het .gfs bestand te fixen zou moeten zijn. Helaas hebben enige pogingen daartoe niet tot succes geleid.
Als alternatief kan er misschien ook iets met een slimme xml transformatie worden gedaan.

De GMLAS driver levert in combinatie met GML-bestanden die volgens een van de Nederlandse IM* modellen zijn opgesteld meestal een enorme partij losse tabellen op, en wat bestanden (vaak maar 1) met geometrie. Het is vervolgens aan de gebruiker om de losse tabellen weer op een zinnige manier aan elkaar te koppelen. Over het algemeen ontbreken daarvoor de juiste sleutels.

De ruimtelijkeplannen plugin ondersteunt inderdaad geen provinciale verordeningen (was ik vergeten). Dit geldt eigenlijk voor alle planvormen die meerdere kaarten (dus geen lagen, zoals jij in je vraag suggereert) kunnen bevatten. In dit geval kan de planinformatie niet uit de generieke ruimtelijkeplannen WFS service gehaald worden. Er is dan een WFS service per plan. Uiteraard kan ondersteuning hiervoor wel gebouwd worden, maar met de dreigende omgevingswet lijkt het niet voor de hand liggend om hier nu nog in te gaan investeren.

Bij mij weten is de software die het kadaster gebruikt om de bronbestanden van de bronhouders te verwerken niet openbaar. Overigens is het ook niet heel moeilijk om zulke software te bouwen (ik heb dat wel eens gedaan), maar het vraagt wel veel kennis van het RO domein en de specifieke manier waarop ruimtelijkeplannen zijn opgebouwd.

#5

hmm, eigen documentatie lezen helpt ook. Na het resolven heb ik

              </gml:patches>
            </gml:Surface>
          </imro:geometrie>
          <imro:idealisatie>exact</imro:idealisatie>
        </imro:GeometrieBesluitobject_P1>
      </imro:begrenzing>
      <imro:begrenzing>
        <imro:GeometrieBesluitobject_P1>
          <imro:geometrie>
            <gml:Surface srsName="urn:ogc:def:crs:EPSG::28992">
              <gml:patches>

vervangen door niks. Daarna ging inlezen met ogr prima:
NL.IMRO.9929.WijzOVOmgVer2018-VA07.gpkg (2,8 MB)

Het verdient wel aanbeveling het resultaat te controleren!

#6

Excuses voor de wat late reactie. Dank voor de moeite en de uitgebreide uitleg.

Ik ben inderdaad op zoek naar alle objecten. Ik had het resolved bestand ook al bekeken maar kwam daar niet echt verder mee.

Ik heb het bestand bekeken in QGIS (in ArcMap 10.6.1 kreeg ik de melding Query description is out of sync) en het ziet er goed uit, ik kan ermee uit de voeten. Het is een multipart shape met 3 records.

Overigens verwerk ik de data uiteindelijk in Geodms software (van ObjectVison) tbv de ruimtelijke modellering.

Met groet
Bas