4.9 GeoJSON ondersteunt alleen WGS84

[mevdschee]

Voor GEO API's wordt bij voorkeur de standaard GeoJSON (RFC-7946) gebruikt.

GeoJSON ondersteunt alleen WGS84:

The coordinate reference system for all GeoJSON coordinates is a geographic coordinate reference system, using the World Geodetic System 1984 (WGS 84) [WGS84] datum, with longitude and latitude units of decimal degrees. (Section 4, see: https://tools.ietf.org/html/rfc7946#section-4)

Deze voorkeur is niet compatible met de voorkeur van het CRS:

7.1.39 API-39: Het voorkeur-coördinatenstelsels (CRS) is ETRS89, maar het CRS wordt niet impliciet geselecteerd

Het lijkt me niet wenselijk dat de voorkeuren elkaar tegenspreken. Verder kan je je vraagtekens zetten bij de waarde van CRS negotiation in combinatie met de GeoJSON voorkeur.

[dvh]

GeoJSON zegt niks (meer) over het CRS, behalve dan dat, tenzij anders afgesproken, men er vanuit mag gaan dat het WGS84 is. Wij spreken hier wel iets anders af, namelijk dat het ETRS89 is. CRS negotiation is van belang om a. dit terug te geven aan de client en b. de mogelijkheid te bieden om ook RD of WGS84 coördinaten te kunnen gebruiken.

[mevdschee]

Het lijkt alsof je je beroept op de uitzondering in de standaard:

However, where all involved parties have a prior arrangement, alternative coordinate reference systems can be used without risk of data being misinterpreted.

En de lessen die geleerd zijn te negeren:

the use of different coordinate reference systems -- especially in the manner specified in [GJ2008] -- has proven to have interoperability issues

Praktisch gezien kunnen de clients niet herprojecteren en is je opmerking dat clients andere coordinaten kunnen gebruiken te betwisten:

In general, GeoJSON processing software is not expected to have access to coordinate reference system databases or to have network access to coordinate reference system transformation parameters.

Daarom vind ik het toch onverstandig om het, met deze controverse, in een nationale standaard op te nemen.

[dvh]

WGS84 is dusdanig onnauwkeurig dat als je ETRS89 als WGS84 interpreteert je in de praktijk geen probleem hebt. Echter is ETRS89 in Europa (en dus ook in Nederland) vele malen nauwkeuriger, waardoor je de volgende situatie krijgt:

• als je als client de default (ETRS89) interpreteert als WGS84 is er niks aan de hand
• als je als client op de juiste manier ETRS89 herprojecteert heb je een veel nauwkeuriger plaatsbepaling dan met WGS84
• als je persé WGS84 wil kun je daar met CRS negotiation alsnog om vragen

[mevdschee]

Bedankt voor je argumentatie voor een shortcut in de implementatie. Los van de vraag of dit een wenselijke implementatie is, vraag ik me af waarom je zou afwijken van de RFC (in een standaard document).

@dvh Ik ben van mening dat ook je beweringen "GeoJSON zegt niks over het CRS" en "de mogelijkheid te bieden om ook RD te gebruiken" niet in lijn zijn met de RFC.

Nogmaals, ik raad af om tegenstrijdige voorkeuren in de standaard op te nemen.

[dvh]

Heb je ook de motivatie gelezen waarom ze het crs attribuut hebben verwijderd uit de GeoJSON standaard? Ze zitten nu helemaal op de lijn dat GeoJSON slechts de structuur voorschrijft om geometrieën te beschrijven, ongeacht welk CRS er gebruikt wordt. Omdat er geen plek meer is om de CRS specifiek te benoemen is de default WGS84, tenzij er op een andere manier (los van de GeoJSON standaard) duidelijk gemaakt wordt dat men het als een ander coördinatenstelsel moet interpreteren.

De belangrijkste reden om af te wijken is overigens dat een juiste conversie van ETRS en RD (beiden reeds en zeer nauwkeurig aanwezig bij praktisch alle geodata van de overheid) naar WGS84 erg moeilijk en kostbaar is (het verschilt namelijk al per seconde, als we als Nederland (RD) gezamenlijk met de rest van Europa (ETRS89) met de hele aardplaat (weg)bewegen van/naar andere aardplaten). Omdat er voor RD weinig client libraries zijn en je ETRS89 in principe ook kunt interpreteren als WGS84 is ETRS89 als default m.i. een juiste keuze.

[mevdschee]

Ze zitten nu helemaal op de lijn dat GeoJSON slechts de structuur voorschrijft om geometrieën te beschrijven, ongeacht welk CRS er gebruikt wordt.

Interessant, waar kan ik hier meer over lezen? Ik ken alleen de RFC.

[dvh]

https://macwright.org/2015/03/23/geojson-second-bite.html en de vele discussies die hierop volgden. Maar, vooral:

So, the take-home lesson of data projections is that they’re useful for extremely-high precision datasets. But such data is rare, and usually the GeoJSON default of EPSG:4326 is a better choice for sharing and storing data.

Behalve in Nederland, als er íets is dat we al die jaren heel nauwkeurig hebben ingemeten dan zijn het wel geometrieën ;-)

[mevdschee]

Boven de alinea die je quote staat:

UPDATE: 2008 geojson.org GeoJSON supported alternative coordinate reference systems other than ESPG:4326, but this capability was removed in the current GeoJSON standard. So, this section is of historical interest but you shouldn’t use the crs member or try to put projected data into GeoJSON: you should instead reproject it to WGS84 first.

Heb je dat gezien?

[dvh]

Jazeker. Daarom moet je ook verder lezen voor de usecases waarin het wél denkbaar is ;-) En die usecase hebben wij in NL toevallig te pakken. Alles reprojecten naar WGS84 is geen realistische optie. FYI: dit is overigens niet iets wat zomaar is verzonnen ihkv de NL API Strategie, het verwijderen van crs uit GeoJSON was eind 2015 best wel een issue bij in ieder geval Geonovum, Kadaster en DSO. Na lange discussies en verdiepend onderzoek naar de achterliggende reden was dit uiteindelijk de meest haalbare uitkomst.

[mevdschee]

Alles reprojecten naar WGS84 is geen realistische optie.

Ik heb ook niet gezegd dat de GeoJSON voorkeur een goede keuze is, sterker nog, het lijkt me (vanwege de problematische verplichte herprojectie naar WGS84) GEEN goede keuze.

En om ook een constructieve bijdrage te leveren hierbij een suggestie: we kunnen ook standaardiseren op ETRS89, de GeoJSON voorkeur vervangen door WKT en de CRS negotiation volledig schrappen.

[dvh]

-100 :)

[mevdschee]

Ik vind dit een ongepaste manier van communiceren.

[dvh]

Excuses, dacht dat dat redelijk geaccepteerd was op Github. Volgens mij is je punt duidelijk en die van mij ook, alleen zijn we het blijkbaar totaal niet met elkaar eens.

[mevdschee]

We zijn het wel met elkaar eens dat er geen andere coordinaten stelsel (zeker geen RD) wordt ondersteund in de RFC. Je geeft echter aan dat het Kadaster heeft gekozen de GeoJSON standaard niet te volgen. Ik stel voor dat we niet dezelfde beslissing maken. Over hoe het dan wel moet kunnen we het wat mij betreft oneens zijn.

[ehotting]

Je geeft echter aan dat het Kadaster heeft gekozen de GeoJSON standaard niet te volgen. Ik stel voor dat we niet dezelfde beslissing maken.

Hier is werkelijk al heel, heel veel discussie over gevoerd waarbij een hoop gecombineerde expertise vele uren verbrand hebben. Kadaster is behoorlijk leidend als het gaat om Geo in context NL overheden. Hoewel ik sympathie heb voor de opvatting ben ik er vrij zeker van dat deze discussie op dit moment niet meer zal leiden tot aanpassing van de API strategie. Over de gewisselde argumenten en gemaakte afwegingen zijn boeken te schrijven. :)

[dvh]

@mevdschee Nou, daar zijn we het volgens mij nog niet mee eens. De RFC geeft aan dat het wat hen betreft WGS84 is, maar dat je vrij bent om andere coördinatenstelsels te gebruiken. Hoe je dit kenbaar maakt in je 'contract' tussen client en server zoek je dan zelf maar uit. GeoJSON blijft desondanks een hele mooie manier om een geometrie in een object uit te drukken, dat vaak direct en eenvoudig geconsumeerd kan worden in een heleboel client libraries (buiten de geowereld lijkt bijvoorbeeld WKT hiervoor een stuk minder populair). Daarnaast moeten we ook nog kunnen dealen met geometrieën in de request, als de client een geometrie meestuurt in een zoekopdracht, bijvoorbeeld een Point van iemands telefoon.

Desondanks zou ik ook het liefste overal WGS84 zien, maar met RD als oorspronkelijk plan ben ik persoonlijk al heel blij dat we ETRS89 kunnen afspreken. Het is een soort "maas in de wet" van GeoJSON, maar na ellenlange discussies (ook op meetups met developers) bleek dit de "minst slechte" oplossing.

[mevdschee]

Okay, dan leg ik me daarbij neer.