ZRC: Sta RD en ETRS89 toe in de Accept-Crs en Content-Crs headers

[johannesbattjes]

In de ZRC zijn de Accept-Crs en Content-Crs-headers verplicht bij het aanmaken en ophalen van zaken.
De default waarde daarvan is EPSG:4326 (WGS84).
Volgens de reactie op #2275 zijn andere waardes dan EPSG:4326 niet toegestaan. Het voorstel is andere EPSG-waardes wel toe te staan, tenminste EPSG:28992 (RD) en EPSG:4258 (ETRS89).

Redenen
De Nederlandse wet zou gevolgd moeten worden in een standaard van Nederlandse gemeenten. Geonovum (https://www.geonovum.nl/themas/coordinaatstelsels) zegt hierover:

RD en ETRS89 zijn bij wet aangewezen als officiële Nederlandse standaard

Veelgebruikte Nederlandse coordinaatstelsels zouden moeten ondersteund worden. Daar behoren RD en ETRS89 toe, zie bijvoorbeeld https://docs.geostandaarden.nl/crs/crs/.

Voor ZRC-consumer apps die een ander stelsel gebruiken dan EPSG:4326, zoals EPSG::28992 (RD), is het nu bewerkelijk om een zaak op te slaan. De app moet namelijk eerst de coördinaten transformeren. Dit is opgelost als de ZRC EPSG::28992 accepteert.

De huidige omschrijving van de headers is ambigue en verwarrend. De beschrijving luidt (bij POST zaak bij Accept-Crs):

Value: "EPSG:4326"
Het gewenste 'Coordinate Reference System' (CRS) van de geometrie in het antwoord (response body). Volgens de GeoJSON spec is WGS84 de default (EPSG:4326 is hetzelfde als WGS84).

Het veld Value: "EPSG:4326" impliceert dat alleen één waarde mogelijk is, maar

• Het feit dat de header er is wekt de verwachting dat er verschillende waardes gebruikt kunnen worden;
• De omschrijving zegt dat in de header het gewenste referentiestelsel wat suggereert dat er een keuze is;
• De omschrijving spreekt van een default. Maar een defaultwaarde bij een veld betekent dat deze waarde toegepast wordt als
  meerdere waardes mogelijk zijn en de waarde niet wordt opgegeven. Dit suggereert dat ook een andere waarde kan worden opgegeven.
  Er is dus één reden om te denken dat precies één waarde mogelijk is terwijl er meerdere redenen zijn om aan te nemen dat meerdere waardes mogelijk zijn. Deze ambiguiteit en verwarring moet opgelost worden.

[sergei-maertens]

Historisch was het de bedoeling support voor Europese en RD stelsel toe te voegen, dit heeft het verder gewoon nooit tot de standaard dan wel referentie-implementatie gehaald (de inspiratie was de API richtlijnen van de DSO). Dus de eerdere discussie waarbij de beschrijving dit impliceert is een correcte interpretatie. Als MVP was EPSG:4326 geïmplementeerd, verder waren er geen luid genoege stakeholders dan wel prio hiervoor door de PO.

Conversie op DB niveau is met PostgreSQL inderdaad een fluitje van een cent, zou met andere databases ook prima moeten kunnen - de transformaties zijn publiek beschreven.

Vooral binnen NL lijkt het me zinvol om RD te ondersteunen omdat je hogere nauwkeurigheid van geometrie bereikt en de BAG/Kadaster ook bij voorkeur RD gebruiken.

[HenriKorver]

Als het goed is wordt dit issue nu opgelost in PR #2495. In de aanvullende regel zrc-028 wordt gesteld dat naast "EPSG:4326" ook andere coördinatenstelsels gebruikt mogen worden indien de Zaken API provider die ook ondersteunt.

@johannesbattjes @sergei-maertens Zijn jullie het hiermee eens?

[sergei-maertens]

Het lijkt me onverstandig om willekeur toe te laten, ik zou echt met een enum van de 3 vernoemde stelsels werken - RD, Europees en globaal EPSG 4326

Er zijn zo veel verschillende stelsels/projecties met minimale verschillen dat je hiermee mismatch tussen servers en clients in de hand werkt. Als developer die de standaard gebruikt wil ik duidelijkheid: deze 3 stelsels, niet meer, niet minder. Geen gokwerk, geen onderhandse afspraken tussen leveranciers over wat wel/niet. Een standaard kent geen kleur, geen commerciële belangen, maar moet de gemeenten in de kracht zetten om aansluitingen te kunnen realiseren en vervangen zonder verrassingen.

Ik sluit me verder 100% aan bij het voorstel en de motivering van Johannes.

[HenriKorver]

@sergei-maertens Eens, het lijkt mij ook beter om het aantal mogelijke crs-stelsels te beperken. Daarom heb ik een enumeratie met de 3 genoemde stelsels toegevoegd, zie commit 2655c63. Zo beter?

[sergei-maertens]

Ja, beter zo!

[HenriKorver]

@johannesbattjes Kun jij ook akkoord geven? Dan voer ik deze wijziging ook door op alle andere plekken waar crs-headers voorkomen.

[johannesbattjes]

Akkoord met de drie waardes, prima.

Maar deze snap ik niet: "De andere twee waarden, "EPSG:4258" (Europa) en EPSG:28992 (Nederland), mogen alleen worden gebruikt als de API-provider deze ondersteund"
Of lees ik verkeerd? Ik kijk niet zo vaak code changes.
Het lijkt me dat juist de ZRC alle drie moet ondersteunen en dat de consumer mag kiezen.

[HenriKorver]

Maar deze snap ik niet: "De andere twee waarden, "EPSG:4258" (Europa) en EPSG:28992 (Nederland), mogen alleen worden gebruikt als de API-provider deze ondersteund"
Of lees ik verkeerd?

Nee je leest het goed, in eerste instantie dacht ik met deze formulering ervoor te zorgen dat de wijziging backwards compatible zou zijn, immers bestaande ZRC-implementaties hoeven dan niet aangepast te worden. Echter bij nader inzien is het alleen maar default maken van de EPSG:4326 waarde eigenlijk ook al niet meer backwards compatible, want bestaande ZRC-providers moeten ook hiervoor hun software aanpassen.

Het lijkt me dat juist de ZRC alle drie moet ondersteunen en dat de consumer mag kiezen.

Oké ik denk dat ik het met je eens ben, maar dit zal dan wel een implementatie-inspanning met zich meebrengen voor alle andere ZRC-leveranciers.

[HenriKorver]

Zojuist specificatie aangepast zodat ZRC alle drie de coördinatenstelsels moet ondersteunen, zie commit
9ad959d.

@johannesbattjes en @sergei-maertens: Is het nu helemaal naar wens?

[sergei-maertens]

Jazeker, en laat die providers maar aan de bak gaan 😉 (sorry @joeribekker )