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:
- Ne modifiez pas les géométries des entités et déplacez l'ambiguïté vers les applications clientes.
- 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 .)
- Travailler avec des projections non mondiales pour différents bassins cycloniques ou régions océaniques qui n'ont pas une telle discontinuité
- 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 °) - 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).
- 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.
- 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. - 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.
