Definitie geometrieVoorVisualisatie (van Informatiepolygoon)

[herman-vandenberg]

De 'geometrieVoorVisualisatie' is nu gedefinieerd als GM_Surface (verplicht attribuut). In geval de Informatiepolygoon gelijk is aan de Graafpolygoon is er geen visualisatie van het gebied tussen beide polygonen. Daarnaast is het denkbaar dat dit gebied (bij bijv. tracémeldingen) resulteert in multi-geometrieen (zie ook https://github.com/Geonovum/imkl2015-review/issues/210). Voorgesteld wordt om dit attribuut te specificeren als GM_Object [0..1].

[PalmJanssen]

Het betreft dit onderdeel in het model:

GM_Object is natuurlijk heel algemeen. GM_MultiSurface ligt meer voor de hand. Het is wel een model aanpassing.

[herman-vandenberg]

_GMMultiSurface lijkt me inderdaad een beter voorstel.

[PalmJanssen]

Lezende de ISO19107 definitie van GM_MultiSurface kan een multiSurface 0..n elementen bevatten. Dat betekent dat we met een GM_MultiSurface ook een GM_Surface kunnen opnemen.

[herman-vandenberg]

Inderdaad. Door geen elementen op te nemen binnen een is deze geometrie wél XSD-valide. Het is arbitrair of je deze oplossingsrichting kiest. Zie `

`

[PalmJanssen]

stel voor om toch GM_Object te gebruiken, met daar naast een constraint die zegt dat de geometrie een Surface of een MultiSurface is.

Voordeel is dit de minste impact op het model heeft en dat het volledig backwards compatibel is.

[herman-vandenberg]

Op basis van het voorstel van Paul Janssen nog even geverifieerd of een geometrie van het type GM_Surface backwards compatible is met een nieuwe definiëring als GM_MultiSurface. Dit blijkt inderdaad NIET zo te zijn! Om wel backwards compatible te zijn, moeten we dus inderdaad naar GM_Object. In issue #210 was hier overigens al wél rekening mee gehouden.

Zie hieronder de foutmelding bij een XSD-validatie:

[adam-ludera-intive]

Reading this thread and comparing it with the information given in the Git Hub information pages, those seem to be contradicted.

The https://github.com/kadaster/klic-win/tree/master/Geplande%20wijzigingen/Informatiepolygoon says: "Gerelateerd aan IMKL issue 240 zijn de volgende keuzes gemaakt: [...] Er is voor de B2B-aanvraag een extra validatie regel toegevoegd ter voorkoming van invalide IMKL: Als de combinatie van graafpolygoon en informatiepolygoon leidt tot een geometrieVoorVisualisatie die een meervoudig polygoon is, wordt de aanvraag afgekeurd."

I read the above as: in the case when the B2B request would cause geometrieVoorVisualisatie to be two separate surfaces, the request would be rejected. This further means that the geometrieVoorVisualisatie will always be one surface.

However, the thread here speaks about the introduction of GM_Object to support multiple surfaces.

The latter, for us, is more reasonable, also because of tracémeldingen, where otherwise, requesting of Information area will not be possible. The former (i.e. only one surface allowed) adds additional, cumbersome, geometry validation rule, making the complete B2B request even more complex.

[herman-vandenberg]

@adam-ludera-intive This is precisely the reason why this issue was raised. As long as the geometrieVoorVisualisatie is defined as Surface, it is not possible to support multisurface's. We therefore have a great interest in being able to adjust this type a.s.a.p.

[adam-ludera-intive]

@herman-vandenberg thank you for replying promptly.

I then understand that there is an intention of Kadaster to allow for requesting Information Polygon shape that would result in geometrieVoorVisualisatie to be multiple surfaces, correct?

For example, the KLIC request as per below schematics would be then allowed? (the blue boundaries with fill are Dig Polygon and red boundaries represent the Information Polygon)

[herman-vandenberg]

@adam-ludera-intive; yes, this is our intention. When this is allowed in a next version of IMKL, it is possible to use the Informatiepolygoon and Graafpolygoon as designed in your drawing.

[PalmJanssen]

verwerkt in uml

[PalmJanssen]

In documentatie zichtbaar in: https://docs.geostandaarden.nl/kl/imkl/#wibon-uitleveren-van-gebiedsinformatie

[JustinRoodenburg]

Toelichting op implementatie van het Kadaster:

Inleiding: De Graafpolygoon is het gebied waarin gegraven mag worden De Informatieopoygoon is gebied waarover informatie wordt gevraagd (dit is inclusief de graafpolygoon) De geometrieVoorVisualisatie is dan het gedeelte wat buiten de graafpolygoon valt, maar binnen de informatiepolygoon.

Werking: Bij het doen van een KLIC-melding worden de Informatieopoygoon en de Graafpolygoon opgegeven. De geometrieVoorVisualisatie wordt dan berekend door de twee van elkaar af te trekken. In theorie zou hierdoor een geometrie voor visualisatie kunnen ontstaan van het type multivlak; echter wordt hier sinds de invoering van de informatiepolygoon op gevalideerd en worden er alleen informatiepolygonen goedgekeurd waarbij er geen multivlak ontstaat voor de geometrieVoorVisualisatie.

De wijziging is als volgt:	imkl 1.2.1	IMKL 2.0
GM_Surface	GM_object

Merk op dat GM_object een generieker type is waaronder zowel GM_Surface als GM_MultiSurface vallen. Daardoor is in het geval van simpele polygonen (zoals we die nu ook al kennen), geen verschil zichtbaar in de GI.xml tussen IMKL 1.2.1 en IMKL 2.0.

Afgesproken is dat KLIC in ieder geval tot het einde van de overgangsperiode blijft valideren op de combinatie van graafpolygoon en informatiepolygonen om zo te garanderen dat er geen multivlak ontstaat voor de geometrieVoorVisualisatie.

Na de overgang zal er gecontroleerd bepaald worden hoe we gebruik kunnen maken van deze nieuwe mogelijkheid.

De transformatie regels zoals vastgesteld door de TCS zijn te vinden via: https://github.com/kadaster/klic-win/tree/master/Toekomstige%20wijzigingen/Toelichting%20specifieke%20onderwerpen/Implementatie%20upgrade%20KLIC%20standaarden#overgangsperiode