Best Practices für Datenbanken und APIs mit geografischen Daten, die sich über den Antimeridian erstrecken

Was ist die bewährte Methode zum Speichern von geografischen Features (Linien, Polygone und ihre mehrteiligen Entsprechungen), wenn diese Features den Antimeridian (± 180 ° Länge) umfassen und als GeoJSON an Client-Webanwendungen gesendet und von diesen empfangen werden müssen?

Ich beginne mit der Arbeit an einer serverseitigen Web-API mit Unterstützung einer Postgres / PostGIS-Datenbank, um mit historischen und prognostizierten tropischen Zyklonspuren und Windradien zu arbeiten. Viele Wirbelstürme im Pazifik haben die unglückliche Tendenz, den Antimeridian zu überqueren, manchmal mehrmals in ihrer Lebensdauer:

Als Neuseeländer, der in der Nähe des Antimeridians lebt, bin ich auf dieses Problem in regionalen Daten oft genug gestoßen, um über einige Bewältigungsstrategien zu verfügen, aber ich möchte tatsächlich herausfinden, was als Best Practice angesehen wird. Leider sind keine Fragen vorhanden, die mit Antimeridian markiert sind. Daher ist es schwierig, nach verwandten Fragen zu suchen. Bei all diesen Fragen, die ich mit diesem Problem zu kämpfen habe, scheint es sich um sehr anwendungsspezifische Ratschläge zu handeln. In dieser Frage wird kurz der Antimeridian für den Fall eines erdübergreifenden GeoJSON-Polygons ohne Begrenzung erörtert. Diese Frage kommt meiner Frage ziemlich nahe.

Ich muss historische und prognostizierte Zyklone in einer räumlichen Datenbank speichern, aber ich gehe davon aus, dass es Probleme mit dem Antimeridian geben wird. Beispielsweise ist eine Linie, die bei Breite / Länge beginnt (0,179)und bei endet, in (0,-179)Bezug auf ihre Richtung mehrdeutig: ob sie den kurzen Weg über den Antimeridian nimmt oder den gesamten Planeten "umschlingt". Wie soll ein solcher Pfad in einer räumlichen Datenbank gespeichert werden (insbesondere arbeite ich mit PostGIS, hoffe aber, dass die Lösung allgemein genug ist)? Einige Ideen, die ich habe:

1. Nehmen Sie keine Änderungen an Feature-Geometrien vor und verlagern Sie die Mehrdeutigkeit auf Client-Anwendungen.
2. Teilen Sie ein Feature, das den Antimeridian kreuzt, in eine mehrteilige Geometrie mit einer Unterbrechung am Antimeridian auf . ( Die GeoJSON-Spezifikation unterstützt benannte CRSs .)
3. Arbeiten Sie mit nicht-globalen Projektionen für verschiedene Zyklonbecken oder Ozeanregionen, die keine solche Diskontinuität aufweisen
4. Speichern Sie die Koordinaten von Zyklonen, die im Breitengradbereich beginnen und (90,-90) um eine 360 ​​° -Phase versetzt sind (während die anderen -180–180 ° bleiben).
5. Um die Tatsache auszunutzen, dass ein Zyklon südlich der Südspitze Afrikas äußerst unwahrscheinlich ist, verwenden Sie eine Pause bei 30 ° Länge (wie in der obigen Karte).
6. Erlauben Sie Koordinaten, die über den gültigen Bereich von EPSG 4326 hinausgehen , z. B.> 180 ° und <-180 ° für alle Features, die den Antimeridian überschreiten.
7. Delta-Codierung , wie in TopoJSON (z. B. Start bei (0,-179)und nächste Koordinate ist -3Breitengrad West). Ich habe keine Ahnung, ob oder wie dies beim Speichern von Daten in PostGIS implementiert werden soll, aber dies ist eine großartige Lösung zum Senden von Daten an Clientanwendungen.
8. Irgendeine Form von Vektornotation oder Polarkoordinaten. (Scheint ziemlich schwierig und ungewöhnlich.)

Von diesen mag ich die Ideen 2–5 nicht, weil sie nicht generisch sind, aber ich mag sie, weil sie für meine spezielle Anwendung einen Sinn ergeben. Für Anwendungen, die sich nur mit Daten im Pazifischen Ozean befassen, sind diese möglicherweise sehr sinnvoll, sodass ich sie nicht vollständig als Optionen ausschließen möchte.

Die Ideen 6 und 7 wurden aus dem Blog von Tom MacWright gestrichen , der eine Lektüre wert ist, aber in Bezug auf den Antimeridian nicht schlüssig ist.

Idee 4 wird von GeographicaGS verwendetGeodesicLinesToGISPython , das wiederum fiona.transform.transform_geomeinen Antimeridianversatz von 360 ° verwendet. Im Gegenzug verwendet Fiona OGRs -wrapdateline. Ich nehme an, das ist ein sehr solider Präzedenzfall und eigentlich ziemlich allgemein.

Im Zusammenhang mit der Frage des Speichers muss überlegt werden, wie solche Funktionen an Clientanwendungen gesendet werden sollen und wie meine Anwendung an sie zurückgesendete Daten berücksichtigen soll (z. B. ein menschlicher Prognostiker, der die Prognosespur eines Zyklons im Pazifik ändert). Das Austauschformat wird wahrscheinlich GeoJSON sein, muss es aber nicht sein.

Leider bezieht sich die GeoJSON-Spezifikation nicht explizit auf Antimeridianprobleme. Dies aus Wikipedia :

Viele geografische Softwarebibliotheken oder Datenformate projizieren die Welt in ein Rechteck. Sehr oft wird dieses Rechteck genau am 180. Meridian geteilt. Dies macht es oft unmöglich, einfache Aufgaben (wie das Darstellen einer Fläche oder einer Linie) über den 180. Meridian zu erledigen. Einige Beispiele:

• In der GeoJSON-Spezifikation wird die Behandlung des 180. Meridians in der Spezifikation nicht erwähnt. Daher können Darstellungen von Linien, die den 180. Meridian kreuzen, genauso gut als Umrundung der Welt interpretiert werden.

• In OpenStreetMap werden Gebiete (wie die Grenze Russlands) am 180. Meridian aufgeteilt.

Ich lese, dass GeoJSON keine bestimmte Standarddarstellung von Antimeridian-überspannenden Merkmalen hat und bewusst nicht eindeutig ist (mehrteilige Geometrien würden das Problem möglicherweise lösen). Ähnlich gibt es in OpenStreetMap Geometrieunterteilungen am Antimeridian, obwohl ich nicht weiß, ob solche geteilten Features mehrteilig sind oder tatsächlich diskrete Datensätze sind.

Dies ist problematisch, insbesondere im Hinblick auf die Erstellung von Bounding Box- oder anderen räumlichen Anforderungen, die sich über diese Linie erstrecken, aber auch beim Parsen und Bereinigen von Eingaben und Aktualisierungen von Feature-Geometrien. Aus diesem Grund versuche ich, eine Best Practice zu ermitteln, der ich mich anpassen kann.

Rein aus Sicht der Datenspeicherung und Analyse wurde der geographyTyp für PostGIS unter Berücksichtigung des Antimeridians (unter mehreren Entwurfszielen) entworfen. Es gibt verschiedene Funktionen, die speziell für diesen geographyTyp entwickelt wurden .

Betrachten Sie beispielsweise einen LineString über Taveuni, Fidschi ( mit Great Circle Mapper abgebildet ), der sich über den Antimeridian erstreckt:

SELECT ST_Length('LINESTRING(179.9 -17, -179.8 -16.7)'::geography);

Die Länge dieser Geodäsie beträgt ca. 46 km. In ähnlicher Weise würde ST_Area auch bei Längenkoordinaten zwischen +179 und -179 auf einem Polygon der Insel korrekt funktionieren.

Durch das Umwandeln eines EPSG: 4326 geometryin einen geographyTyp werden auch die Koordinaten normalisiert, z. B. ist die Länge der letzten Koordinate> 180:

SELECT ST_AsGeoJSON('LINESTRING (179.9 -17, 180.2 -16.7)'::geography);

NOTICE:  Coordinate values were coerced into range [-180 -90, 180 90] for GEOGRAPHY
                           st_asgeojson
------------------------------------------------------------------
 {"type":"LineString","coordinates":[[179.9,-17],[-179.8,-16.7]]}

wird geographyim ersten Beispiel wieder in den exakt gleichen Typ konvertiert , jetzt jedoch mit GeoJSON-Ausgabe. Sie können den HINWEIS (oder z. B. SET client_min_messages TO WARNING;) ignorieren und alle Arten von witzig aussehenden Geometrien als geographyTypen konvertieren .

Das Anzeigen von geographyTypen auf Karten außerhalb von PostGIS ist eine andere Geschichte, und hoffentlich werden bessere Antworten diesen Aspekt berühren.

Sicher ist die bevorzugte Antwort (1), dh die Kunden sollen das "Richtige" tun. Ein guter Fall ist das Polygon, das den Kontinent der Antarktis darstellt und durch diese kml-Datei angenähert wird

<kml> <Folder> <name>Antarctica</name> <Placemark> <name>Antarctica</name> <Polygon> <tessellate>1</tessellate> <outerBoundaryIs> <LinearRing> <coordinates> -58,-63.1,0 -74,-72.9,0 -102,-71.9,0 -102,-74.9,0 -131,-74.3,0 -163,-77.5,0 163,-77.4,0 172,-71.7,0 140,-65.9,0 113,-65.7,0 88,-66.6,0 59,-66.9,0 25,-69.8,0 -4,-70,0 -14,-71,0 -33,-77.3,0 -46,-77.9,0 -61,-74.7,0 -58,-63.1,0 </coordinates> </LinearRing> </outerBoundaryIs> </Polygon> </Placemark> </Folder> </kml>

Eine Delta-Codierung oder -Verschiebung, bei der die Längenunterschiede auftreten, hilft bei solchen Daten nicht. Es funktioniert eine für die Antarktis spezifische Projektion, aber dies ist kaum eine allgemeine Lösung.

Erstaunlicherweise zeigt Google Earth Pro dieses Polygon nicht korrekt an (es sei denn, Sie verwenden den "Gliederungs" -Modus). Siehe hier