¿Cuál es la mejor práctica para almacenar rasgos geográficos (líneas, polígonos y sus equivalentes multiparte) cuando estos rasgos abarcan el antimeridiano (±180° de longitud), y necesitan ser enviados y recibidos por aplicaciones web cliente como GeoJSON?
Estoy empezando a trabajar en una API web del lado del servidor con apoyo de una base de datos Postgres/PostGIS para trabajar con pistas de ciclones tropicales y radios de viento históricos y previstos. Muchos ciclones en el Océano Pacífico tienen la desafortunada tendencia a cruzar el antimeridiano, a veces varias veces en su vida:
Como neozelandés que vive cerca del antimeridiano, me he encontrado con este problema lo suficientemente a menudo en los datos regionales como para tener algunas estrategias de afrontamiento, pero me gustaría averiguar realmente qué se considera la mejor práctica. Desgraciadamente, no existen preguntas etiquetadas antimeridiano Por lo tanto, es difícil buscar preguntas relacionadas. Las preguntas que he visto luchando contra este problema parecen buscar consejos muy específicos para la aplicación. Esta pregunta discute brevemente el antimeridiano para el caso de un polígono GeoJSON que abarca toda la tierra y no tiene límites. Esta pregunta se acerca bastante a lo que estoy pidiendo.
Necesito almacenar los ciclones históricos y previstos en una base de datos espacial, pero preveo que habrá problemas con el antimeridiano. Por ejemplo, una línea que comienza en la latitud/longitud (0,179) y terminando en (0,-179) es ambiguo con respecto a su dirección: si toma el camino corto a través del antimeridiano, o "envuelve" todo el planeta. ¿Cómo debería almacenarse dicha trayectoria en una base de datos espacial (concretamente estoy trabajando con PostGIS pero espero que la solución sea lo suficientemente genérica)? Algunas ideas que tengo:
- No hacer ningún cambio a las geometrías de las características y trasladar la ambigüedad a las aplicaciones de los clientes.
- Dividir cualquier rasgo que cruce el antimeridiano en un geometría multiparte con ruptura en el antimeridiano . ( La especificación GeoJSON admite CRSs con nombre .)
- Trabajar con proyecciones no globales para diferentes cuencas ciclónicas o regiones oceánicas que no tienen esa discontinuidad
- Aprovechando el hecho de que nunca se ha observado que un ciclón dé la vuelta a todo el planeta, almacenar las coordenadas de los ciclones a partir de la latitud
(90,-90)compensado por una fase de 360°. (manteniendo los otros -180-180°) - Aprovechando el hecho de que un ciclón es extremadamente improbable al sur del extremo sur de África, utilice un ruptura a 30° de longitud (como en el mapa anterior).
- Permitir coordenadas que se extienden más allá del rango válido de la EPSG 4326 Por ejemplo, > 180° y < -180° para cualquier característica que pase el antimeridiano.
- Codificación delta como en TopoJSON (por ejemplo, empezar en
(0,-179)y la siguiente coordenada es-3latitud oeste). No tengo ni idea de si se puede implementar esto cuando se almacenan los datos en PostGIS, pero es una gran solución para enviar datos a las aplicaciones de los clientes. - Alguna forma de notación vectorial o coordenadas polares. (Parece bastante difícil e inusual).
De éstas, no me gustan las ideas 2-5 porque no son genéricas, pero sí me gustan porque tienen algún sentido para mi aplicación particular. Para aplicaciones que sólo tratan con datos en el Océano Pacífico, podrían tener mucho sentido, así que no quiero descartarlas completamente como opciones.
Las ideas 6 y 7 fueron tomadas de Blog de Tom MacWright que vale la pena leer, pero no es concluyente con respecto al antimeridiano.
La idea 4 es utilizada por GeographicaGS' GeodesicLinesToGISPython que a su vez utiliza fiona.transform.transform_geom con un desplazamiento antimeridiano de 360°. A su vez, Fiona está utilizando el sistema OGR -wrapdateline . Supongo que es un precedente muy sólido y en realidad bastante genérico.
Junto con la cuestión del almacenamiento, tengo que considerar cómo deben enviarse esas características a las aplicaciones de los clientes, y cómo debe considerar mi aplicación los datos que se le envían (por ejemplo, un pronosticador humano que cambia la trayectoria prevista de un ciclón en el Pacífico). El formato de intercambio será probablemente GeoJSON, pero no tiene por qué serlo.
Lamentablemente, la especificación GeoJSON no es explícita en lo que respecta a las cuestiones antimeridianas. Esto de Wikipedia :
Muchas bibliotecas de software geográfico o formatos de datos proyectan el mundo en un rectángulo; muy a menudo este rectángulo se divide exactamente en el meridiano 180. Esto hace que a menudo sea imposible realizar tareas sencillas (como representar un área o una línea) sobre el meridiano 180. Algunos ejemplos:
La especificación GeoJSON no menciona el manejo del meridiano 180 en su especificación, por lo que las representaciones de las líneas que cruzan el meridiano 180 pueden ser interpretadas como si dieran la vuelta al mundo.
En OpenStreetMap, las zonas (como la frontera de Rusia) se dividen en el meridiano 180.
Mi lectura es que GeoJSON no tiene una representación estándar particular de los rasgos que abarcan el antimeridiano, y se deja deliberadamente ambigua (las geometrías de varias partes tal vez resolverían la cuestión). Del mismo modo, en OpenStreetMap hay divisiones geométricas en el antimeridiano, aunque no sé si esas características divididas son multipartes o son realmente registros discretos.
Esto se siente bastante problemático, especialmente desde la perspectiva de hacer cajas delimitadoras u otras solicitudes espaciales que abarcan esta línea, pero también en el análisis y la limpieza de la entrada y cualquier actualización de las geometrías de las características. Por eso estoy tratando de determinar una mejor práctica a la que pueda intentar ajustarme.
