Meilleures pratiques pour les bases de données et les API avec des données géographiques couvrant l'antiméridienne

Quelle est la meilleure pratique pour stocker des entités géographiques (lignes, polygones et leurs équivalents en plusieurs parties) lorsque ces entités s'étendent sur l'antiméridien (± 180 ° de longitude), et doivent être envoyées et reçues des applications Web clientes sous le nom de GeoJSON?

Je commence à travailler sur une API Web côté serveur avec le soutien d'une base de données Postgres / PostGIS pour travailler avec les traces de cyclones tropicaux historiques et prévus et les rayons du vent. De nombreux cyclones dans l'océan Pacifique ont la fâcheuse tendance à traverser l'antiméridien, parfois plusieurs fois dans leur durée de vie:

En tant que Néo-Zélandais vivant près de l'antiméridien, j'ai rencontré ce problème assez souvent dans les données régionales pour avoir des stratégies d'adaptation, mais j'aimerais vraiment savoir ce qui est considéré comme la meilleure pratique. Malheureusement, il n'y a aucune question étiquetée antiméridienne , il est donc difficile de rechercher des questions connexes. Les questions que j'ai vues lutter contre ce problème semblent toutes demander des conseils très spécifiques à l'application. Cette question traite brièvement de l'antiméridienne dans le cas d'un polygone GeoJSON couvrant la terre sans frontière. Cette question est assez proche de ce que je demande.

J'ai besoin de stocker les cyclones historiques et prévus dans une base de données spatiale, mais je prévois qu'il y aura des problèmes avec l'antiméridien. Par exemple, une ligne commençant à la latitude / longitude (0,179)et se terminant à (0,-179)est ambiguë en ce qui concerne sa direction: si elle prend le court chemin à travers l'antiméridien, ou "s'enroule" autour de la planète entière. Comment un tel chemin doit-il être stocké dans une base de données spatiale (en particulier, je travaille avec PostGIS mais j'espère que la solution est suffisamment générique)? Quelques idées que j'ai:

1. Ne modifiez pas les géométries des entités et déplacez l'ambiguïté vers les applications clientes.
2. Divisez toute entité traversant l'antiméridien en une géométrie en plusieurs parties avec une coupure à l'antiméridien . ( La spécification GeoJSON prend en charge les CRS nommés .)
3. Travailler avec des projections non mondiales pour différents bassins cycloniques ou régions océaniques qui n'ont pas une telle discontinuité
4. Exploiter le fait qu'un cyclone n'a jamais été observé se déplacer sur toute la planète, stocker les coordonnées des cyclones commençant dans la plage de latitude (90,-90) compensée par une phase à 360 ° (en gardant les autres -180-180 °)
5. En exploitant le fait qu'un cyclone est extrêmement improbable au sud de la pointe sud de l'Afrique, utilisez une pause à 30 ° de longitude (comme sur la carte ci-dessus).
6. Autorisez les coordonnées à s'étendre au-delà de la plage valide de l'EPSG 4326 , par exemple> 180 ° et <-180 ° pour toutes les entités qui passent l'antiméridien.
7. Encodage delta , comme dans TopoJSON (par exemple, commencer à (0,-179)puis la coordonnée suivante est la -3latitude ouest). Je n'ai aucune idée si ou comment implémenter cela lors du stockage de données dans PostGIS, mais c'est une excellente solution pour envoyer des données aux applications clientes.
8. Une certaine forme de notation vectorielle ou de coordonnées polaires. (Cela semble plutôt difficile et inhabituel.)

Parmi celles-ci, je n'aime pas les idées 2 à 5 car elles ne sont pas génériques, mais je les aime parce qu'elles ont un certain sens pour mon application particulière. Pour les applications ne traitant que des données dans l'océan Pacifique, elles peuvent avoir beaucoup de sens, donc je ne veux pas les exclure complètement en tant qu'options.

Les idées 6 et 7 ont été tirées du blog de Tom MacWright , qui mérite d'être lu mais n'est pas concluant en ce qui concerne l'antiméridien.

L'idée 4 est utilisée par GeographicaGS 'GeodesicLinesToGISPython , qui à son tour utilise fiona.transform.transform_geomun décalage antiméridien à 360 °. À son tour, Fiona utilise des OGR -wrapdateline. Je suppose que c'est un précédent très solide et en fait plutôt générique.

Parallèlement à la question du stockage, je dois réfléchir à la manière dont ces fonctionnalités doivent être envoyées aux applications clientes et à la manière dont mon application doit prendre en compte les données qui y sont renvoyées (par exemple, un prévisionniste humain modifiant la trajectoire d'un cyclone dans le Pacifique). Le format d'échange sera probablement GeoJSON, mais ce n'est pas obligatoire.

Malheureusement, la spécification GeoJSON n'est pas explicite sur les problèmes d'antiméridiens. Ceci de Wikipedia :

De nombreuses bibliothèques de logiciels géographiques ou formats de données projettent le monde dans un rectangle; très souvent, ce rectangle est divisé exactement au 180e méridien. Cela rend souvent impossible d'effectuer des tâches simples (comme représenter une zone ou une ligne) sur le 180e méridien. Quelques exemples:

• La spécification GeoJSON ne mentionne pas la gestion du 180e méridien dans sa spécification, en tant que telle, les représentations des lignes traversant le 180e méridien peuvent tout aussi bien être interprétées comme faisant le tour du monde.

• Dans OpenStreetMap, les zones (comme la frontière de la Russie) sont divisées au 180e méridien.

Ma lecture est que GeoJSON n'a pas de représentation standard particulière des entités s'étendant sur les antiméridiens, et il est délibérément laissé ambigu (des géométries en plusieurs parties pourraient peut-être résoudre le problème). De même, dans OpenStreetMap, il existe des divisions géométriques à l'antiméridien, bien que je ne sais pas si ces entités divisées sont en plusieurs parties ou sont en fait des enregistrements discrets.

Cela semble plutôt problématique, en particulier du point de vue de la création de boîtes englobantes ou d'autres demandes spatiales qui couvrent cette ligne, mais également lors de l'analyse et de la désinfection des entrées et des mises à jour des géométries des entités. C'est pourquoi j'essaie de déterminer une meilleure pratique à laquelle je peux me conformer.

Parlant uniquement du point de vue du stockage et de l'analyse des données, le geographytype de PostGIS a été conçu en pensant à l'antiméridien (parmi plusieurs objectifs de conception). Il existe plusieurs fonctions spécialement conçues pour le geographytype .

Par exemple, considérons un LineString à travers Taveuni, Fidji ( mappé avec Great Circle Mapper ), qui chevauche l'antiméridien:

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

La longueur de cette géodésique est d'environ 46 km. De même, ST_Area fonctionnerait correctement sur un polygone de l'île, même avec des coordonnées de longitude sautant entre +179 et -179.

La conversion d'un EPSG: 4326 geometryen un geographytype normalise également les coordonnées, par exemple la longitude de la dernière coordonnée est> 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]]}

est reconverti au même geographytype exact dans le premier exemple, mais maintenant avec la sortie GeoJSON. Vous pouvez choisir d'ignorer l'AVIS (ou par exemple SET client_min_messages TO WARNING;) et convertir toutes sortes de géométries amusantes en geographytypes.

L'affichage des geographytypes sur des cartes en dehors de PostGIS est une autre histoire, et j'espère que de meilleures réponses toucheront cet aspect.

Sûrement, la réponse préférée est (1), c'est-à-dire que les clients font la «bonne chose». Un bon cas à considérer est le polygone représentant le continent de l'Antarctique approximé par ce fichier kml

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

L'encodage ou le décalage delta où la rupture de longitude se produit n'aidera pas avec des données comme celle-ci. Travailler une projection spécifique à l'Antarctique fonctionnera, mais ce n'est pas une solution générale.

Étonnamment, Google Earth Pro n'affiche pas correctement ce polygone (sauf si vous utilisez le mode "contour"). Vois ici