[PB-GNM]

Geomodule update voor JSON-FG

[PB-GNM]

@lvdbrink : zou je deze willen reviewen

[lvdbrink]

Ik kwam een paar typos tegen.

Ik vraag me af of we GML en WKT inderdaad nog willen beschrijven als alternatieven voor GeoJSON en JSON-FG. Destijds hebben we als werkgroep GML en WKT genoemd als mogelijk alternatief omdat JSON-FG nog in de kinderschoenen stond. Nu JSON-FG een goedgekeurde standaard is, hebben we GML en WKT misschien niet meer nodig in REST APIs. JSON-gebaseerde formaten zijn een veel betere fit.

[TimvdLippe]

Ik heb niet inhoudelijk naar de wijziging gekeken, maar wil even kort aangeven dat als GML en WKT worden verwijderd uit deze module, dat een breaking change is. En dus ook een breaking change voor de ADR, aangezien we vanuit de ADR naar deze module refereren. We hebben liever nog geen nieuwe major versie van de ADR, dus als jullie expliciet behoefte hier aan hebben dan kunnen we daar het gesprek over starten.

[lvdbrink]

Ah, goed punt. Ik wil een breaking change liever vermijden. Ik kan er mee leven dat GML en WKT nog blijven staan.

[TimvdLippe]

Jullie zouden wel een noot kunnen toevoegen dat voor nieuwe oplossing JSON-FG de voorkeur heeft. Daarmee voorkom je hopelijk dat nieuwe oplossingen doorgaan op de minder gewenste manier.

[PB-GNM]

@lvdbrink : zou je deze nog een keer willen reviewen. Ik heb meerdere commits gedaan.

[PB-GNM]

@strijm : Kun jij dit pullrequest zien en zou je hem dan ook willen reviewen?

[TimvdLippe]

Kunnen jullie #24 (comment) hier ook in meenemen?

[PB-GNM]

Kunnen jullie #24 (comment) hier ook in meenemen?

Zal ik doen!

[PB-GNM]

@TimvdLippe Ik heb aebdf7e als commit toegevoegd.

Maar: Ik zie "Hal" op nog 3 plekken:

1. In de voorbeelden 13, 14 en 15
2. In de note daaronder
3. In A2 in de informatieve referenties

Moeten ze daar ook weg?

[TimvdLippe]

Zoals ik het issue begrijp wel ja, al ben ik hier niet de expert. Je kan het altijd nog aan Joost vragen voor de zekerheid, maar ik denk dus dat bij de anderen precies hetzelfde moet gebeuren.

[strijm]

Links wijzen nog naar r3 van core module i.p.v. r4.

[strijm]

Bij het WKT en WKB formaat staan nu voorbeelden. Het zou consquent zijn om ook een voorbeeld voor GeoJSON, JSON-FG en evt. nog GML toe te voegen (voor request en response).
Daarbij is het interessant dat een object zoals gedefinieerd in een informatiemodel vertaald moet worden naar een feature structuur. Uitleg:
Bij een object zijn de attributen meestal op hetzelfde niveau gedefinieerd, oftewel geometrie en overige attributen staan op hetzelfde niveau. Daarnaast kunnen objecten meerdere geometrieën bevatten (zie IMGeo). In XML/GML is de structuur (ongeveer) hetzelfde als in het informatiemodel. Attributen zijn daar XML elementen en geometrieën zijn elementen in GML formaat op hetzelfde niveau. Als een object meerdere geometrieën bevat dan staan die dus op hetzelfde niveau.
Voor GeoJSON en JSON-FG werkt het anders dan bij XML/GML. Een object wordt in GeoJSON of JSON-FG formaat een feature waarbij de geometrie op het hoogste niveau staat en alle andere attributen van het object binnen een properties structuur worden opgenomen. Dit is anders dan het object in het informatiemodel. Één GeoJSON of JSON-FG feature kan maar één geometrie bevatten. Een object met meerdere geometrieën kan dus niet naar één GeoJSON of JSON-FG feature worden vertaald. Het is mogelijk om een evt. tweede geometrie in de properties op te nemen, maar de vraag is of GIS pakketten die dan nog herkennen als geometrie. Een alternatief kan ook zijn om twee features te definiëren voor iedere geometrie en in beide de overige object attributen in de properties mee te geven, maar bij de data uitwisseling (bv. doorgeven van mutaties) tussen bronhouders en landelijke voorzieningen is dat niet handig omdat dan altijd eerst beide features weer gecombineerd moeten worden tot één object om ervoor te zorgen dat er één en niet twee mutaties worden vastgelegd. In dat geval zou het handiger zijn om een JSON structuur conform het object te definiëren waarin alle geometrieën als GeoJSON of JSON-FG worden meegegeven op hetzelfde niveau als de overige attributen, maar dat is waarschijnlijk weer niet bruikbaar in GIS applicaties.
Kortom, het is dus afhankelijk van de toepassing hoe geometrie uitgewisseld kan of moet worden. V.w.b. de data uitwisseling tussen bronhouders en landelijke voorzieningen moeten we aansluiten op het informatiemodel. Bij het toepassen van GeoJSON of JSON-FG is het goed om bij het opstellen van het informatiemodel al rekening te houden met het feit dat een feature maar één geometrie kan bevatten en wat dat betekent voor de definitie van objecten in het informatiemodel.
Bij de toepassing in GIS applicaties is het belangrijk om te voldoen aan de specificaties van GeoJSON en JSON-FG zodat GIS applicaties de data correct kunnen interpreteren en weergeven.
De vraag is dan: hoe gaan we hier in de verschillende situaties mee om en hoe standaardiseren we dat?

[PB-GNM]

Ik heb nu alle reviews verwerkt, behalve het laatste punt van @strijm, want dat is een punt dat nadere discussie nodig heeft en ik wil de publicatie van de bijgewerkte versie daar niet op laten wachten.
@TimvdLippe: Hij mag nu gemerged worden.

[TimvdLippe]

Wijzigingen aan normatieve modulen (waaronder geospatial) moeten worden goedgekeurd in een Technisch Overleg API. Het eerstvolgend TO API is 26 november (https://github.com/Logius-standaarden/Overleg/tree/main/API/2026-11-26). Zullen we hem dan agenderen?

Let wel dat Mark (of eigenlijk Kadaster) het eens moet zijn met de wijziging. Dus het is wel nodig dat van tevoren er afstemming is zodat op het TO de goedkeuring kan worden gegeven. Als er dan geen consensus is, dan zal goedkeuring bij een later TO moeten worden gegeven.

[PB-GNM]

@strijm , Ik heb best wel wat aangepast na jouw laatste opmerking, maar dus nog niet het vraagstuk over meerdere geometrieën in één feature. Zou je er nog één keer naar willen kijken?
Is het wat jou betreft Oké als we het nu publiceren zonder het probleem van meerdere geometrieën per feature te adresseren?
Zou je daar een issue van willen maken?