¿Cuál es la mejor práctica para almacenar características geográficas (líneas, polígonos y sus equivalentes multiparte) cuando estas características abarcan el antimeridiano (± 180 ° de longitud) y deben enviarse y recibirse de las aplicaciones web del cliente como GeoJSON?
Estoy comenzando a trabajar en una API web del lado del servidor con soporte de una base de datos Postgres / PostGIS para trabajar con pistas de ciclones tropicales históricas y pronosticadas y radios de viento. Muchos ciclones en el Océano Pacífico tienen la desafortunada tendencia a cruzar el antimeridiano, a veces varias veces en su vida útil:
Como neozelandés que vive cerca del antimeridiano, he encontrado este problema con la frecuencia suficiente en los datos regionales para tener algunas estrategias de afrontamiento, pero me gustaría descubrir qué se considera la mejor práctica. Lamentablemente, no hay preguntas existentes etiquetadas como antimeridian , por lo que es difícil buscar preguntas relacionadas. Esas preguntas que he visto lidiar con este problema parecen estar buscando consejos muy específicos para cada aplicación. Esta pregunta discute brevemente el antimeridiano para el caso de un polígono GeoJSON que abarca la Tierra sin límite. Esta pregunta está bastante cerca de lo que estoy preguntando.
Necesito almacenar ciclones históricos y pronosticados en una base de datos espacial, pero anticipo que habrá problemas con el antimeridiano. Por ejemplo, una línea que comienza en la latitud / longitud (0,179)y termina en (0,-179)es ambigua con respecto a su dirección: si toma el camino corto a través del antimeridiano o "envuelve" todo el planeta. ¿Cómo debe almacenarse dicha ruta en una base de datos espacial (específicamente estoy trabajando con PostGIS pero espero que la solución sea lo suficientemente genérica)? Algunas ideas que tengo:
- No modifique las geometrías de las características y cambie la ambigüedad a las aplicaciones del cliente.
- Divida cualquier característica que cruce el antimeridiano en una geometría multiparte con un salto en el antimeridiano . ( La especificación GeoJSON admite CRS con nombre ).
- Trabaje con proyecciones no globales para diferentes cuencas ciclónicas o regiones oceánicas que no tienen esa discontinuidad.
- Explotando el hecho de que nunca se ha observado que un ciclón viaje alrededor del planeta entero, almacene las coordenadas de los ciclones comenzando en el rango de latitud
(90,-90)compensado por una fase de 360 ° (manteniendo a los otros -180–180 °) - Aprovechando el hecho de que un ciclón es extremadamente improbable al sur del extremo sur de África, use un descanso a 30 ° de longitud (como en el mapa anterior).
- Permita que las coordenadas se extiendan más allá del rango válido de EPSG 4326 , por ejemplo,> 180 ° y <-180 ° para cualquier característica que pase el antimeridiano.
- Codificación Delta , como en TopoJSON (por ejemplo, comenzar en
(0,-179)y luego la siguiente coordenada es-3latitud oeste). No tengo idea de si implementar esto o cómo hacerlo al almacenar datos en PostGIS, pero esta es una gran solución para enviar datos a las aplicaciones del cliente. - Alguna forma de notación vectorial o coordenadas polares. (Parece bastante difícil e inusual).
De estos, no me gustan las ideas 2–5 porque no son genéricas, pero me gustan porque tienen sentido para mi aplicación en particular. Para las aplicaciones que solo se ocupan de datos en el Océano Pacífico, pueden tener mucho sentido, por lo que no quiero descartarlas por completo como opciones.
Las ideas 6 y 7 fueron extraídas del blog de Tom MacWright , que vale la pena leer, pero no es concluyente con respecto al antimeridiano.
Idea 4 es utilizada por GeographicaGS 'GeodesicLinesToGISPython , que a su vez está utilizando fiona.transform.transform_geomun desplazamiento antimeridiano de 360 °. A su vez, Fiona está usando OGR -wrapdateline. Supongo que es un precedente muy sólido y en realidad bastante genérico.
Junto con el tema del almacenamiento, necesito considerar cómo se deben enviar tales funciones a las aplicaciones del cliente, y cómo mi aplicación debe considerar los datos que se le envían (por ejemplo, un pronosticador humano que cambia la trayectoria del pronóstico de un ciclón en el Pacífico). El formato de intercambio probablemente será GeoJSON, pero no tiene que serlo.
Lamentablemente, la especificación GeoJSON no es explícita sobre los problemas antimeridianos. 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 a menudo hace que sea imposible realizar tareas simples (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, como tal, las representaciones de líneas que cruzan el meridiano 180 también pueden interpretarse como dar la vuelta al mundo.
En OpenStreetMap, las áreas (como el límite de Rusia) se dividen en el meridiano 180.
Mi lectura es que GeoJSON no tiene una representación estándar particular de características que abarquen antimeridios, y se deja deliberadamente ambigua (las geometrías de múltiples partes tal vez resolverían el problema). De manera similar, en OpenStreetMap hay divisiones de geometría en el antimeridiano, aunque no sé si esas características divididas son multiparte o en realidad son registros discretos.
Esto parece bastante problemático, especialmente desde la perspectiva de hacer un cuadro delimitador u otras solicitudes espaciales que abarcan esta línea, pero también al analizar y desinfectar entradas y cualquier actualización de las geometrías de entidades. Es por eso que estoy tratando de determinar una mejor práctica con la que pueda intentar conformarme.
