GeoJSON und geografische Koordinaten: Längengrad zuerst, WGS 84 und die Rechte-Hand-Regel

Worum es geht

GeoJSON (RFC 7946, zitiert) ist ein JSON-Format für geografische Daten. Eine Position ist ein Array von Zahlen, dessen erste zwei Elemente Längengrad und Breitengrad sind, exakt in dieser Reihenfolge, in Dezimalgrad auf dem Datum WGS 84 (das Koordinatenreferenzsystem urn:ogc:def:crs:OGC::CRS84); ein optionales drittes Element ist die Höhe in Metern über oder unter dem Referenzellipsoid, und Positionen sollten keine weiteren Elemente tragen. Geometrieobjekte sind Point, MultiPoint, LineString, MultiLineString, Polygon, MultiPolygon und GeometryCollection. Ein Feature hat eine geometry (oder null, wenn kein Ort vorliegt), ein properties-Objekt und optional eine id; eine FeatureCollection enthält Features. Eine optionale bbox lautet [west, south, east, north]. Polygonringe sind geschlossen (erste Position gleich letzter Position) und müssen der Rechte-Hand-Regel folgen: Aussenringe gegen den Uhrzeigersinn, Löcher im Uhrzeigersinn, wobei Parser die ältere Orientierung nicht ablehnen sollten.

Warum es wichtig ist

Im Alltag sagt man „Breitengrad, Längengrad", mehrere Kartenbibliotheken übernehmen diese Reihenfolge, und eine Vertauschung der beiden setzt einen Punkt ohne jede Fehlermeldung auf einen anderen Kontinent. Auch das Datum spielt eine Rolle: Koordinaten aus einem anderen Datum, unverändert übernommen, landen um einen vom Datum abhängigen Betrag am falschen Ort – auf einer Weltkarte unsichtbar, für eine Lieferroute aber fatal; ein nationales Gitter in Metern ist überhaupt keine Gradangabe.

So wird es angewendet

• [lon, lat] ausgeben und an der Schnittstelle aus jeder lat/lon-Quelle umrechnen; einen Test mit einem bekannten Ort pflegen, dessen Längen- und Breitengrad sich in Vorzeichen oder Grössenordnung deutlich unterscheiden, damit eine Vertauschung den Test scheitern lässt.
• Koordinaten als JSON-Zahlen führen, nicht als Zeichenketten, und nur mit so vielen Nachkommastellen, wie die Messung rechtfertigt; die RFC hält fest, dass die Anzahl der Nachkommastellen nicht als Unsicherheit zu interpretieren ist, daher die Genauigkeit bei Bedarf in properties festhalten.
• Geometrien, die den Antimeridian überqueren, wie von der RFC empfohlen in Multi*-Teile zerschneiden, damit Renderer keine Linie um die ganze Welt zeichnen.
• Anwendungsdaten in properties ablegen, id stabil halten und bedenken, dass eine Linie zwischen zwei Positionen im Längen-/Breitengrad-Raum gerade verläuft, nicht als Grosskreis; Distanzen mit einer geodätischen Funktion berechnen, niemals mit Pythagoras auf Gradwerten.
• In einer Datenbank Geometrien in einem räumlichen Datentyp mit deklariertem Referenzsystem speichern, damit Indizes und Distanzfunktionen greifen.

Stolpersteine

Fremde Member sind an GeoJSON-Objekten erlaubt, aber die GeoJSON-Typen selbst sind nicht erweiterbar, und der crs-Member aus dem Entwurf von 2008 ist entfallen. Ein Polygon, dessen Aussenring an zweiter Stelle steht, ist ein Loch ohne Aussen. Grosse Sammlungen sollten Feature für Feature erzeugt und verarbeitet werden, nicht als ein einziges Dokument geparst.