search

VNG-Realisatie / StUF-Standaarden

Repository met de issues uit en in de oude Drupal community omgeving en de nieuwe issues
https://vng-realisatie.github.io/StUF-Standaarden/
6 stars 3 forks source link

bg0310 berichten valideren niet tegen gml3.2.2 #13

Closed HenriKorver closed 4 months ago

HenriKorver commented 3 years ago

Na de overgang naar BAG2.0 levert het Kadaster de geometrie met als namespace gml versie 3.2.2 in plaats van gml versie 3.1.1.2. Dit leidt ertoe dat bg0310 berichten waarin deze geometrie wordt opgenomen niet valideren tegen de bestaande schema's.

Er lijkt nu een patch nodig te zijn op de bg0310-schema's, zodra BAG1.0 niet meer gebruikt wordt. Voor nu kan het probleem opgelost worden door de nieuwe geometrie met de oude namespace in de berichten op te nemen, maar dit is niet erg netjes.

melsk-r commented 3 years ago

Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ERR0521. De lijst met onderhoudsverzoeken vind je hier.

melsk-r commented 3 years ago

Op het eerste gezicht leek de eenvoudigste wijze om dit probleem op te lossen het wijzigen in het BAG extract van de namespaceidentifier voor gml 3.2.2 naar die voor gml 3.1.1.2. Daarmee zouden alle gml 3.2.2 elementen in een klap gml 3.1.1.2 elementen worden. Onderzoek heeft echter uitgewezen dat daarvoor de in StUF-BG gebruikte gml 3.1.1.2 structuren te veel afwijken van dezelfde structuren in de gml 3.2.2 versie.

Dat betekent dat versie 3.2.2 van gml beschikbaar gesteld moet gaan worden in de XML-Schema's van StUF-BG 3.10. Aangezien niet alle geometrie in StUF-BG 3.10 vanuit de BAG komt en er dus delen zijn die op versie 3.1.1.2 gebaseerd blijven zullen beide versies naast elkaar in StUF-BG opgenomen moeten worden waarbij alleen de geometrie elementen die uit de BAG afkomstig zijn naar gml 3.2.2 getild moeten worden.

Deze patch zal alleen in die omgevingen ingevoerd moeten worden waar gebruik gemaakt wordt van het BAG 2.0 extract. Alle andere omgevingen kunnen gebruik blijven maken van de huidige patch (29). Ook voor StUF-ZKN zal een nieuwe patch worden uitgebracht waarvoor dezelfde voorwaarde geldt.

michielverhoef commented 3 years ago

Als er een nieuwe patch voor StUF-ZKN uitgebracht gaat worden, is het dan ook noodzakelijk om een nieuwe patch voor Zaak- Documentservices uit te brengen? Wordt daar gebruik gemaakt van het nieuwe BAG 2.0 extract?

mvdbro commented 3 years ago

Heeft deze versie wijziging van gml3.1.1.2 naar gml3.2.2 niet ook consequenties voor BAG applicaties die bg0310-mutaties doorgeven. Zodra deze BAG applicatie overgaat op BAG2.0, wordt de geometrie vastgelegd in gml3.2.2 en zal die ook als zodanig in bg0310 berichten terecht komen. Het verwondert me dat dit probleem nog door niemand gesignaleerd is.

RuudKathmann commented 3 years ago

Typische een standaard voorbeeld van ketenproblematiek. Hadden we daarvoor niet een standaardregel dat tenminste een jaar twee versies naast elkaar gebruikt zouden moeten kunnen worden. Betekent dit dan niet dat we in StUF bg voorlopig nog GML 3.1.1.2 moet ondersteunen, naast GML 3.2.2. Dus een patch uitbrengen voor StUF bg waarin beide GML versies mogelijk zijn.

michielverhoef commented 3 years ago

De standaardregel is volgens mij dat VNG tenminste twee versies (de huidige en voor-laatste) ondersteunt. Het lijkt me ondoenlijk en vooral onwenselijk om een StUF versie uit te brengen waarin beide versies van GML mogelijk zijn. Dat wordt voor ontwikkelaars een leuke puzzel om dit in te bouwen, om het zachtjes uit te drukken.

Dan is het imo beter om zowel een StUF versie die GML 3.1.1.2 (de nu huidige) als eentje die GML 3.2.2 (de komende patch, als die doorgaat) ondersteunt uit te brengen. Gebruikers kunnen dan kiezen welke StUF versie ze willen toepassen.

melsk-r commented 3 years ago

Vergeet je daarmee niet de volgende opmerking die ik eerder in dit issue heb gemaakt:

Aangezien niet alle geometrie in StUF-BG 3.10 vanuit de BAG komt en er dus delen zijn die op versie 3.1.1.2 gebaseerd blijven zullen beide versies naast elkaar in StUF-BG opgenomen moeten worden waarbij alleen de geometrie elementen die uit de BAG afkomstig zijn naar gml 3.2.2 getild moeten worden.

Met jouw voorstel zou dit alleen ondervangen kunnen worden met een scenario waarbij beide versies van StUF-BG naast elkaar gebruikt worden. De ene keer om geometrie vanuit de BAG te communiceren en de andere keer om geometrie niet afkomstig uit de BAG te communiceren. Lijkt me zeer onwenselijk want complex en foutgevoelig.

Ik denk dus dat de enige optie is om zowel gml 3.1.1.2 als gml 3.2.2 in 1 StUF-BG versie te ondersteunen.

mvdbro commented 3 years ago

Het binnen bg0310 ondersteunen van zowel GML 3.1.1.2 als GML 3.2.2 lijkt me onmogelijk. Ik heb zelf bij het omzetten van BAG2.0 naar bg0310 voor de oplossing gekozen om simpelweg de namespace in de gml te wijzigen van 3.1.1.2 naar 3.2.2. Voor zover ik kan nagaan (en dat is niet ver genoeg), leidt dit niet tot problemen.

Een nieuwe versie van bg0311 uitbrengen ten behoeve van GML 3.2.2 lijkt me een erg zwaar middel, omdat dit nogal wat consequenties heeft voor bestaande applicaties. Alle applicaties die BAG geometrie gebruiken moeten dan over naar bg0311. Ik voel daarom meer voor de oplossing om het toch maar in een patch te doen en gebruikers te laten kiezen welke versie ze gebruiken voor het valideren van berichten.

Ik heb daarnaast nog de vraag of de door Robert Melskens gesignaleerde verschillen tussen GML 3.1.1.2 en GML 3.2.2 ook spelen op het niveau van xml en of hij daarvan een voorbeeld zou kunnen geven. Eén zo'n verschil zou het verplicht geworden zijn van het attribute gml:id kunnen zijn, maar dit probleem kan je oplossen door dat uit de xml te verwijderen. Ook voor andere eventuele verschillen zou geanalyseerd kunnen worden of dit oplosbaar is door aanpassen van de xml. Het versieprobleem kan dan worden opgelost door de namespace en eventuele andere zaken aan te passen bij het vertalen van BAG2.0 naar bg0310. Iedereen blij.

melsk-r commented 3 years ago

Maarten, je schrijft:

Het binnen bg0310 ondersteunen van zowel GML 3.1.1.2 als GML 3.2.2 lijkt me onmogelijk.

Waarom is dit volgens jou onmogelijk? We kunnen toch beide versies importeren, ze hebben immers een andere namespace en bij het refereren naar de gewenste complextypes kan dus gebruik gemaakt worden van verschillende namespace-prefixes.

mvdbro commented 3 years ago

Het kan inderdaad wel als je voor de BAG geometrie overgaat naar GML 3.2.2 en de rest van de geometrie ongewijzigd laat. Ik had het gelezen als voor de BAG geometrie een keuze tussen beide en dat lijkt me niet mogelijk.

melsk-r commented 3 years ago

De gml XSD schema's zijn gelardeerd met substitutionGroups en het is daarom lastig en bovenal te tijdrovend om een uitputtend onderzoek te doen. Ik heb daarom net zolang gezocht totdat ik op een afwijking tussen beide modellen stuitte.

De 'geometrie' elementen binnen StUF-BG 3.10 waarvan de structuur moet worden vervangen door een gml 3.2 structuur kunnen door het gebruik van de substitutionGroup techniek het element 'Surface' bevatten. In dat element vond ik een afwijking. Bij vervanging van gml 3.1.1.2 door gml 3.2 zou de structuur van dat ‘Surface’ element dus wijzigen.

In de gml 3.1.1.2 bevat het 'Surface' element achtereenvolgens de optionele elementen:

De gml 3.2.2 standaard voegt daar tussen de laatste 2 elementen de eveneens optionele elementen 'gml:descriptionReference' en 'gml:identifier' aan toe.

mvdbro commented 3 years ago

De hamvraag lijkt mij te zijn of BAG 2.0 gebruik maakt van nieuwe mogelijkheden van gml 3.2.2. Zo niet, dan is verreweg de eenvoudigste oplossing om de xml te converteren van gml 3.2.2 naar gml 3.1.1.2, omdat er dan niets in de schema's hoeft te worden aangepast. Het lijkt me goed als deze vraag in overleg met het Kadaster een antwoord krijgt. Ze hebben richting mij al aangegeven dat de conversie naar 3.1.1.2 mogelijk zou zijn, maar het lijkt me goed als ze dit ook richting VNG Realisatie bevestigen.

HenriKorver commented 3 years ago

Goed plan. Ik zal contact opnemen met Kadaster/BAG voor formele bevestiging. Pieter Dijkstra toch?

mvdbro commented 3 years ago

Pieter Dijkstra lijkt me een prima ingang.

sbrouwer71 commented 3 years ago

Het koppelvlak tussen BAG-applicaties en de LV is nog steeds gebaseerd op gml-3.1.1.2. Er zou dus geen informatie in de LV-BAG moeten kunnen staan die niet in deze versie van gml kan worden opgenomen.

Daarmee lijkt het mij onzin om in BG over te stappen naar de nieuwere gml-versie. De component die het BAG-extract doorzet naar binnengemeentelijke afnemers moet de vertaling naar StUF-BG 03.10 zonder informatieverlies kunnen uitvoeren.

PieterDijkstraKadaster commented 3 years ago

Hierbij alvast een eerste reactie van mijn kant.

We leveren de GML in versie 3.2.2 omdat dat de vigerende versie van de GML standaard is. We BAG extract is overigens als product niet specifiek voor gemeenten ontwikkeld.

We gaan de verschillen tussen 3.1.1.2 en 3.2.2 in kaart brengen, om meer duidelijkheid te kunnen bieden over de conversie. Zodra ik daar meer informatie over heb, meld ik dat hier

PieterDijkstraKadaster commented 3 years ago

We hebben er naar gekeken. Hierbij de uitkomst van onze analyse:

Er zijn hier maar twee verschillen:

  1. De namespace is anders GML-3.1.1.2: http://www.opengis.net/gml GML-3.2.2: http://www.opengis.net/gml/3.2
  2. srsDimension staat op een ander element GML-3.1.1.2: bij ieder element GML-3.2.2: bij root element Daarbij is alleen de namespace van belang.

Om de xsd aan te passen waardoor bijvoorbeeld het woonplaats xml document uit het extract weer valide is, kan het volgende gedaan worden bij de extracten 2.0 xsd's:

  1. Verwijder: .\xsd\lvbag\imbag\gml\3.2*
  2. Voeg toe: .\xsd\lvbag\imbag\gml\3.1.1.2* (uit de xsd's van de Kernvoorziening 2.0)
  3. Voeg toe: .\xsd\lvbag\imbag\gml\xlink* (uit de xsd's van de Kernvoorziening 2.0)
  4. Wijzig: .\xsd\lvbag\imbag\IMBAGLV\objecten\v20200601\IMBAGLV_Objecten-2.1.0.xsd:
  5. xmlns:gml="http://www.opengis.net/gml/3.2" wordt xmlns:gml="http://www.opengis.net/gml"
  6. wordt

En meer was niet nodig.

Omdat we geen gebruik maken van de mogelijkheden van GML-3.2.2 is het wijzigen van de gml namespace in het XML document om te voldoen aan gml-3.1.1.2.

Wil je het XML document ook nog valideren, dan moeten er ook nog xsd's aangepast worden. In het voorbeeld hebben we alleen de Woonplaats gecontroleerd tegen Baarle-Nassau, wat toch de leukste woonplaats van Nederland is (qua geometrie in ieder geval).

melsk-r commented 3 years ago

Pieter,

Ik had eerder ook wat onderzoek gedaan en was daarbij tegen de onderstaande wijziging aan gelopen. Zijn jullie daar niet tegenaan gelopen?

De 'geometrie' elementen binnen StUF-BG 3.10 waarvan de structuur moet worden vervangen door een gml 3.2 structuur kunnen door het gebruik van de substitutionGroup techniek het element 'Surface' bevatten. In dat element vond ik een afwijking. Bij vervanging van gml 3.1.1.2 door gml 3.2 zou de structuur van dat ‘Surface’ element dus wijzigen.

In de gml 3.1.1.2 bevat het 'Surface' element achtereenvolgens de optionele elementen:

* gml:metaDataProperty
* gml:description
* gml:name

De gml 3.2.2 standaard voegt daar tussen de laatste 2 elementen de eveneens optionele elementen 'gml:descriptionReference' en 'gml:identifier' aan toe.

PieterDijkstraKadaster commented 3 years ago

Wij (van de LV BAG) gebruiken deze velden niet en voor zover wij weten worden deze verder ook vrijwel niet gebruikt. Als er toch ergens in de keten gebruik gemaakt wordt van deze velden, dan horen we het graag. Dan kijken we hier alsnog naar.

melsk-r commented 3 years ago

Alle bovenstaande post lezend concluderen wij dat het eerste voorstel dat ik op 20 januari heb gepost en dat Maarten vd Broek op 15 februari nog even aanhaalt de voorkeur geniet. Dus gewoon het simpelweg wijzigen in het BAG extract van de namespaceidentifier voor gml 3.2.2 naar die voor gml 3.1.1.2. Deze werkwijze gaan we documenteren in Sectie 4 (Compatibiliteit met BAG 2018) van het keuzenVerStUFfing RSGB document.

Zoals gebruikelijk zullen we ter review eerst een pre-patch aanbieden waarin dit issue op deze wijze wordt opgelost. De patch zelf verwachten we begin mei te publiceren.

melsk-r commented 3 years ago

In de pre-patch 30 is de volgende paragraaf toegevoegd aan de 'keuzenVerStUFfing RSGB':

afbeelding