Kan QGIS een vlak exporteren naar IMGEO GML of IMRO gml?

Voor de omgevingswet zijn we aan het kijken of we geometrie (vlakken) kunnen exporteren naar GML. Exporteren naar .gml kan wel, maar de vlakken worden niet zichtbaar in een gml-viewer die we gebruiken. Ik heb begrepen dat hiervoor een van de speciale standaarden nodig is: nl. IMRO 2006, IMRO 2008, IMRO 2012, IMGEO GML of StuF-Geo IMGeo.
Weet iemand of ik vanuit QGIS naar een van deze formaten kan exporteren?

ik ben benieuwd naar een beetje meer achtergrondinformatie.
Wij gebruiken plansoftware dat overweg kan met shape-files.
Wat ik doe is in QGIS werkingsgebiedjes maken op basis van de RO-gml bestanden en BGT-bestanden. Vervolgens deze exporteren naar shape en in de plansoftware importeren om die werkingsgebieden te annoteren aan de regels.

Wat willen jullie met de gml-viewer bekijken?

Wij gebruiken Tercera Go en daarin zien we de vlakken niet verschijnen als het niet via de imro-standaard is geëxporteerd. Wij vragen ons ook af welke vlakken we kunnen gebruiken voor de werkingsgebieden. Zelf tekenen? BGT vlakken gebruiken? Het is lastig om hier informatie over te vinden.

klopt, dat er weinig (geen?) informatie over te vinden is, loop ik als gemeentelijk bevoegd gezag ook tegenaan. Ben nog in de fase zelf wat te proberen en te ontdekken. Het is ook wel logisch, omdat je als bevoegd gezag zelf mag bepalen hoe en waar de begrenzing van regels lopen.
Dat alle bevoegd gezagen te maken krijgen met ‘openbaar gebied’ en dat elk bevoegd gezag dan nu op zijn manier dat gebied mag (en moet) vastleggen, was opzich wel te voorzien. Maar blijkbaar geen reden voor een landelijke organisatie om daar richtlijnen over te geven van wat handig is om te doen.

Ook wij (niet gemeente Haarlem, maar ik woon daar) hebben TerceraGo. Hoe ik het zie is om in applicaties als QGIS of ArcGIS de werkingsgebieden te ‘tekenen’ als in: overnemen van bestaande geometrieeen zoals de bestaande IMRO bestemmingsplannen, BAG, BGT, BRK. Vervolgens daar een shape-file van te exporteren en die te importeren in Tercera als zijnde de geometrie voor het werkingsgebied.

Van de BGT vind ik vooral het gegeven ‘erf’ heel geschikt als begrenzing van ‘openbaar gebied’. Openbaar Gebied is dan het Ambtsgebied minus de Panden en Erf-objecten. Het komt niet altijd helemaal goed uit, maar (in stedelijk gebied) wel een goed startpunt om je werkingsgebied ‘openbaar gebied’ mee te maken.

1 like

Dank voor je antwoord! We gaan nog even verder puzzelen.

Een gml opgesteld volgens de omgevingswet STOP/TPOD standaarden kun je niet zomaar inlezen in QGIS. Dat kan wel met de GIO-import plugin van LandGoed: GIO gml import plugin — QGIS Python Plugins Repository

Voor het opstellen (en trouwens ook inlezen) van gml-bestanden conform de Omgevingswet STOP/TPOD standaarden heeft Geonovum een plugin ter beschikking gesteld: https://geonovum.github.io/TPOD/DSO_Qgisplugin3.zip

1 like

Al het echt alleen gaat om het importeren in Tercera, dan zou ik aan hen vragen welke formaten ze ondersteunen.

Omdat QGIS zo handig is en wij in de Drechtsteden met de plansoftware van KV werken even een vraag over de QGIS plugin van Geonovum.
Ik heb de installatiehandleiding gevolgd maar de plugin verschijnt niet in de lijst. In de vorige LTR van QGIS is het me wel gelukt. Kan het zijn dat mijn QGIS versie 3.34 te nieuw is voor de plugin? Of moet ik nog een handmatige aanpassing doorvoeren om 'm te kunnen activeren?

Misschien is er iets misgegaan.

Als je in QGISvia het menu de profielmap opent, dan kom je in de map waarin alle instellingen, maar ook alle plugins zijn opgeslagen. Elke plugin heeft daarin een eigen mapje. Controleer of de plugin die je zoekt staat tussen de plugins die je wel ziet.

Dank je voor het meedenken.
De bestanden van de plugin staan in de map C:\Users[username]\AppData\Roaming\QGIS\QGIS3\profiles\default\python\plugins\dso_gml

Maar, ik heb nĂ©t de oplossing gevonden voor mijn probleem: de map en bestanden stonden nog niet op “persoonlijk” (optie in Verkenner). Ik werk namelijk op een laptop die onder beheer staat van onze ICT-afdeling en blijkbaar heeft QGIS geen toegang tot mappen/bestanden die in een “beheerd” roaming user profile staan.

Even nieuw leven in dit draadje blazen.
Wat me bij gebruik van de plugin van Geonovum is opgevallen is dat er - schijnbaar willekeurig - afrondingsfouten in de GML staan (14 decimalen in plaats van de gebruikelijke 3).
Hebben anderen die deze plugin gebruiken daar ook last van? Of is er in QGIS een instelling mogelijk om de afronding naar 3 decimalen af te dwingen vóór het activeren van de plugin?

Dit gedrag (14 ipv 3 decimalen) heb ik vaker gezien. Kan het zijn dat je 14 decimalen ipv 3 decimalen in bochten tegen komt? Zo ja dan kan de oorzaak liggen in CAD-herkomst doordat CAD-applicaties de bochten vaak ‘stroken’ terwijl GIS de bochten berekent.

Daarvan is geen sprake, de vlakken waarmee ik heb gewerkt waren niet afkomstig van of gebaseerd op CAD-data. Dan zou ik trouwens de afrondingsverschillen meer in reeksen verwachten in de GML.

Met behulp van de geoprocessing tool “snap to grid” kan afgerond worden op 3 decimalen.

Als de geometrie invalide wordt bij afronden op 3 decimalen, en je hebt het vinkje “valide maken” aanstaan, dan komen er aslnog meer decimalen om de boel weer valide te maken.

Eerst afronden op 3 decimalen, dan validiteit waarborgen en dan pas de plugin gebruiken zou goede resultaten moeten geven.

1 like

Dank je Marco!
Helaas lijkt het niet de oplossing, want welke optie in de plugin ik ook gebruik (getest met vinkjes afronden en valide maken aan/uit) en geen van deze opties geeft een goede GML.
Kan je voor de stappen die je noemt aangeven of je die in de toolbox of in de plugin hebt ingesteld? Of screenshots toevoegen?

Ik vermoed dat er een fout in de plugin zit die dit gedrag veroorzaakt. Daarom heb ik bij Geonovum een melding ingeschoten om dit issue te onderzoeken en indien mogelijk op te lossen.

Er zitten nog wat andere verbeterpuntjes in deze plugin maar dat neem ik van meteen mee als ik contact heb met Geonovum. De plugin laat QGIS crashen als je meer dan Ă©Ă©n GIO wil opslaan door de plugin open te laten staan, te wisselen van laag en dan op Apply te klikken. En daarnaast nog wat GUI dingetjes.

Dit gebeurt dus in de toolbox, en niet in de plugin.

Dit gebeurt dus niet in de plugin!

Dit gebeurt dus wel in de plugin.

Enneh, het vinkje “valide maken” in de plugin zou ik dus uit laten staan, want de geometrie is al valide voor deze erin gaat.

Wellicht kun jij een bestand wat geen valide gml oplevert hier posten? Dan kunnen we je beter helpen.

Ik heb de gpkg bijgesloten, benieuwd of jullie iets kunnen vinden.
Deelgebieden.gpkg (404 KB)

Poeh, dat zijn wel gelijk heel veel kaartlagen. Het zou helpen als je alleen die zou delen die problemen opleveren.

Anyhow, zelfs voor afronding zijn Woonwijken, Dordwijkzone en hulplijnen niet valide mbt geometrie. Dat zul je eerst moeten fixen voor je een goed resultaat kunt bereiken.

Beter nog, eerst alle geometrie afronden op 3 decimalen. Dan alles valide maken en dan pas met de plugin aan de slag.

Alle lagen geven soortgelijke afrondingsissues. Als je testen wil pak dan bv Poldergebied of Staart. De stappen die je noemt had ik al zo gedaan.
Ik zal ook eens met andere geometrie gaan testen, en afkomstig uit andere databronnen.

Tja, daar kan die plogin weinig aan doen. De “standaard” manier om geometrie valkide te maken (ST_makeValid) verplaatst een punt de minimum afstand benodigd om de geometrie weer valide te maken. Da’s altijd met meer dan 3 decimalen.

Wat je wel kunt doen is de geometrie eerst afronden, en dan stapsgewijs bufferen en controleren van de niet-valide geometrieen:

  • eerst een buffer met afstand 0
  • dan naar binnen bufferen met een kleine afstand (bijvoorbeeld 10 centimeter) en daarna weer naar buiten bufferen met 10cm.
  • dan zelfde procedure met 1 meter, etc