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:
- Nehmen Sie keine Änderungen an Feature-Geometrien vor und verlagern Sie die Mehrdeutigkeit auf Client-Anwendungen.
- 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 .)
- Arbeiten Sie mit nicht-globalen Projektionen für verschiedene Zyklonbecken oder Ozeanregionen, die keine solche Diskontinuität aufweisen
- 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). - 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).
- 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.
- 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. - 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.
