Which values are allowed for the accept-crs header?

[johannesbattjes]

The documentation on the Accept-Crs header in POST Zaken says:

string
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).

The word "default" suggests that other EPSG values are allowed, but the word "value" suggests that only EPSG:4326 is allowed.

Question: which values are allowed in this header?

[johannesbattjes]

Same question for Content-Crs

[michielverhoef]

I just test this against the referentie implementatie of the Zaken API and only the value of EPSG:4326 is allowed for both Accept-Crs and Content-Crs.

Het is niet mijn vakgebied maar op de GIS Stackexchange site zie ik dit staan:

If you're really going to pick a nit: EPSG 4326 defines a full coordinate reference system, providing spatial meaning to otherwise meaningless pairs of numbers. It means "latitude and longitude coordinates on the WGS84 reference ellipsoid."

Als ik de rest van de pagina doorlees staat er met zoveel woorden dat EPSG:4326 meer informatie geeft over hoe de getalswaarden geplaatst moeten worden. Bij WGS84 moet dit er apart bij vermeld worden.

De toelichting EPSG4326 is hetzelfde als WGS84 is dus een beetje kort door de bocht en moet uit de OAS verwijderd worden.

Beantwoord dit je vraag?

[johannesbattjes]

Hoi Michiel,
nee.
Mijn vraag is "welke waardes zijn toegestaan in de header"
Uit de zin "I just test this against the referentie implementatie of the Zaken API and only the value of EPSG:4326 is allowed for both Accept-Crs and Content-Crs." lijkt dat alleen EPSG:4326 is toegstaan.

Kun je dat bevestigen? (in dat geval zal ik onmiddellijk een wijzigingsverzoek indienen)

[michielverhoef]

Dat is correct, alleen EPSG:4326 is toegestaan.

In het verleden hebben we hier naar gekeken maar is besloten om geen andere formaten toe te staan omdat dan ofwel de Zaken API moet converteren zodat een locatie ook in andere formaten opvraagbaar is of als zoekparameter te gebruiken is. En welke formaten zouden dan nog meer ondersteund moeten worden?

Dit is zo buiten scope van de Zaken API dat we dit niet gaan doen. Mijns inziens is het beter om bijvoorbeeld een apart locatie register te maken waar deze functionaliteit in zit en vanuit de Zaken API daar naar te verwijzen. Eventuele conversie logica kan dan daar ondergebracht worden.

[johannesbattjes]

Onze ZRC staat wel een hele waslijst aan EPSG toe. Implementatie daarvan was triviaal: de database, in ons geval Postgresql, doet de conversie tussen formaten. Ik denk dat alle databases dit wel kunnen. In elk geval zou het het logisch zijn RD (EPSG:28992) te ondersteunen. Juist de conversie vooraf is duur en bewerkelijk.
Iedere app die een zaak gaat aanmaken, moet de coordinaten nu eerst omzetten naar EPSG:4326.

Ik heb nu wel aanvullende vraag: waarom moet de header uberhaupt meegestuurd?
Immers je kunt in de header niet de gewenste EPSG meesturen. Alleen EPSG:4326 is mogelijk.

[michielverhoef]

'Onze ZRC staat wel een hele waslijst aan EPSG toe. '

In dat geval voldoet jullie ZRC niet aan de standaard.

Hoewel ik nog steeds niet helemaal overtuigd ben dat dit soort (geo) gegevens in een zaken register horen ben ik wel benieuwd hoe een dergelijke oplossing dan in de standaard terecht zou moeten komen.

[johannesbattjes]

"In dat geval voldoet jullie ZRC niet aan de standaard"
Dat klopt maar dat weet ik dus pas sinds vandaag. Verder zou dit dan een afwijking zijn waar geen enkele consumer last van heeft.

Ik schrik ook van deze mededeling: "Hoewel ik nog steeds niet helemaal overtuigd ben dat dit soort (geo) gegevens in een zaken register horen".
Al onze geo-toepassingen zijn hier op gebaseerd. Inmiddels gebruikt ook externe applicatie Geoweb de ZRC.

Zou je deze vraag nog willen beantwoorden?
"waarom moet de header uberhaupt meegestuurd? Immers je kunt in de header niet de gewenste EPSG meesturen. Alleen EPSG:4326 is mogelijk."

[michielverhoef]

"In dat geval voldoet jullie ZRC niet aan de standaard"
Dat klopt maar dat weet ik dus pas sinds vandaag. Verder zou dit dan een afwijking zijn waar geen enkele consumer last van heeft.

Dat niet, maar het maakt het koppelen van een consumer die gebruik maakt van andere GEO JSON formaten aan een andere dan jullie eigen implementatie wel lastiger. Dan voldoet die consumer dus niet aan de standaard.

Ik schrik ook van deze mededeling: "Hoewel ik nog steeds niet helemaal overtuigd ben dat dit soort (geo) gegevens in een zaken register horen".
Al onze geo-toepassingen zijn hier op gebaseerd. Inmiddels gebruikt ook externe applicatie Geoweb de ZRC.

Ik begrijp dat zaken aan een locatie gekoppeld moeten kunnen worden. Je wilt immers kunnen zoeken op zaken die in een bepaald gebied spelen etc.

Wat deze discussie lastig maakt is dat ik niet thuis ben in GEO JSON en de verschillende formaten die daar in gebruikt worden. Het is voor mij lastig in te schatten hoe ingewikkeld het is om van het ene naar het andere stelse om te schakelen. Bovendien moeten we dan goed bedenken wat we gaan doen wanneer een zaakgeometrie opgeslagen wordt. Hoe gaan we om met een zaak die met formaat X aangemaakt wordt en met formaat Y uitgevraagd of gewijzigd wordt? Kun je zoeken op/binnen de verschillende formaten?

Zou je deze vraag nog willen beantwoorden?
"waarom moet de header uberhaupt meegestuurd? Immers je kunt in de header niet de gewenste EPSG meesturen. Alleen EPSG:4326 is mogelijk."

Dat is een goede vraag. De aanwezigheid van de header parameter impliceert dat het mogelijk moet gaan worden om verschillende formaten te gaan ondersteunen.

Laat ik het zo zeggen, ik ben er niet fundamenteel op tegen maar mis zelf momenteel de kennis om dit voldoende uit te werken. Maar een goed voorstel wordt altijd gewaardeerd.

[MNIJ]

De formulering in de standaard bij dit veld is:

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).

Wij hebben daaruit afgeleid dat de default EPSG:4326 is en dat elke ZRC implementatie dus minimaal dat stelsel moet ondersteunen. Maar uit het feit dat de headers überhaupt bestaan (en ook nog eens verplicht zijn!) hebben we afgeleid dat andere stelsels ook ondersteund mogen worden.

En omdat het Rijkdriehoekstelsel EPSG:28992 nog steeds het leidende coördinatenstelsel is in de overheidswereld is het heel prettig als de ZRC dit ondersteunt. Dat zorgt ervoor dat consumers geen conversie hoeven doen of meerdere stelsels door elkaar hoeven te presenteren.

Voor de goede orde, als een ZRC implementatie meerdere stelsels ondersteunt, betekent dit dus dat een consumer zowel bij het aanmaken als bij het bevragen van zaken zelf kan kiezen welk stelsel gebruikt wordt. Het is dus prima mogelijk om twee consumers op zo'n ZRC aan te sluiten waarbij de ene consumer zaken aanmaakt in stelsel A en de andere consumer die zelfde zaken ophaalt in stelsel B. De ZRC rekent de coördinaten om (gaat razendsnel en eenvoudig op database niveau) en de consumer merkt daar niks van.

[michielverhoef]

Wij hebben daaruit afgeleid dat de default EPSG:4326 is en dat elke ZRC implementatie dus minimaal dat stelsel moet ondersteunen. Maar uit het feit dat de headers überhaupt bestaan (en ook nog eens verplicht zijn!) hebben we afgeleid dat andere stelsels ook ondersteund mogen worden.

Ik snap jullie denkwijze maar de enige toegestane waarde is op dit moment EPS:4326 .

Niet omdat ik dat wil, zo staat met momenteel in de OAS. Een consumer die gebruik maakt van een ander formaat voldoet dus niet aan de standaard. Of dat een gelukkig keuze is geweest en of het niet anders had gemoeten: Ongetwijfeld, laten we dit gebruiken als input voor de doorontwikkeling.

[johannesbattjes]

Zie #2277 voor ons voorstel

[michielverhoef]

Verdere discussie vindt plaats in #2277