Práticas recomendadas para bancos de dados e APIs com dados geográficos abrangendo o antimeridiano

Qual é a melhor prática para armazenar recursos geográficos (linhas, polígonos e seus equivalentes multipartes) quando esses recursos abrangem o antimeridiano (longitude de ± 180 °) e precisam ser enviados e recebidos de aplicativos Web clientes como GeoJSON?

Estou iniciando o trabalho em uma API Web do lado do servidor, com suporte de um banco de dados Postgres / PostGIS, para trabalhar com trilhas de ciclones tropicais históricas e previstas e raios de vento. Muitos ciclones no Oceano Pacífico têm a infeliz tendência de atravessar o antimeridiano, às vezes várias vezes na vida útil:

Como neozelandês morando perto do antimeridiano, encontrei esse problema com frequência suficiente em dados regionais para ter algumas estratégias de enfrentamento, mas gostaria de descobrir o que é considerado uma prática recomendada. Infelizmente, não há perguntas marcadas com antimeridiano , por isso é difícil procurar por questões relacionadas. Todas as perguntas que eu vi enfrentando esse problema parecem estar procurando conselhos muito específicos de aplicativos. Esta pergunta discute brevemente o antimeridiano para o caso de um polígono GeoJSON de abrangência da Terra sem limite. Esta pergunta está bem próxima do que estou perguntando.

Preciso armazenar ciclones históricos e de previsão em um banco de dados espacial, mas prevejo que haverá problemas com o antimeridiano. Por exemplo, uma linha que começa na latitude / longitude (0,179)e termina em (0,-179)é ambígua em relação à sua direção: se ela percorre o caminho curto através do antimeridiano ou "envolve" o planeta inteiro. Como esse caminho deve ser armazenado em um banco de dados espacial (especificamente eu estou trabalhando com o PostGIS, mas espero que a solução seja genérica o suficiente)? Algumas idéias que tenho:

1. Não faça alterações nas geometrias dos recursos e mude a ambiguidade para os aplicativos clientes.
2. Divida qualquer recurso que cruze o antimeridiano em uma geometria multiparte com uma quebra no antimeridiano . ( A especificação GeoJSON suporta CRSs nomeados .)
3. Trabalhe com projeções não globais para diferentes bacias de ciclones ou regiões oceânicas que não têm essa descontinuidade
4. Explorando o fato de nunca ter sido observado um ciclone percorrer todo o planeta, armazene as coordenadas dos ciclones começando na faixa de latitude (90,-90) deslocadas por uma fase de 360 ​​° (mantendo os outros -180–180 °)
5. Explorando o fato de que um ciclone é extremamente improvável ao sul da ponta sul da África, faça uma pausa a 30 ° de longitude (como no mapa acima).
6. Permita que as coordenadas se estendam além do intervalo válido de EPSG 4326 , por exemplo,> 180 ° e <-180 ° para todos os recursos que passam no antimeridiano.
7. Codificação delta , como em TopoJSON (por exemplo, comece em (0,-179)e a próxima coordenada será a -3latitude oeste). Não tenho idéia de como implementar isso ao armazenar dados no PostGIS, mas essa é uma ótima solução para o envio de dados para aplicativos clientes.
8. Alguma forma de notação vetorial ou coordenadas polares. (Parece bastante difícil e incomum.)

Destas, não gosto das idéias 2–5 porque não são genéricas, mas gosto delas porque fazem sentido para minha aplicação específica. Para aplicativos que lidam apenas com dados no Oceano Pacífico, eles podem fazer muito sentido, então não quero descontá-los completamente como opções.

As idéias 6 e 7 foram retiradas do blog de Tom MacWright , que vale a pena ler, mas não é conclusivo com relação ao antimeridiano.

A idéia 4 é usada pelo GeographicaGS 'GeodesicLinesToGISPython , que por sua vez usa fiona.transform.transform_geomcom um deslocamento antimeridiano de 360 ​​°. Por sua vez, Fiona está usando OGRs -wrapdateline. Suponho que seja um precedente muito sólido e realmente bastante genérico.

Em conjunto com a questão do armazenamento, preciso considerar como esses recursos devem ser enviados para aplicativos clientes e como meu aplicativo deve considerar os dados postados de volta (por exemplo, um meteorologista humano que altera a faixa de previsão de um ciclone no Pacífico). O formato de intercâmbio provavelmente será GeoJSON, mas não precisa ser.

Infelizmente, a especificação GeoJSON não é explícita sobre questões antimeridianas. Isto da Wikipedia :

Muitas bibliotecas de software geográfico ou formatos de dados projetam o mundo em um retângulo; muitas vezes esse retângulo é dividido exatamente no 180º meridiano. Isso geralmente impossibilita a execução de tarefas simples (como representar uma área ou uma linha) no 180º meridiano. Alguns exemplos:

• A especificação GeoJSON não menciona o manuseio do 180º meridiano em sua especificação; portanto, as representações de linhas que cruzam o 180º meridiano também podem ser interpretadas como em todo o mundo.

• No OpenStreetMap, áreas (como a fronteira da Rússia) são divididas no 180º meridiano.

Minha leitura é que o GeoJSON não possui uma representação padrão específica dos recursos de abrangência antimeridiana e é deliberadamente deixado ambíguo (geometrias de várias partes talvez resolveriam o problema). Da mesma forma, no OpenStreetMap, existem divisões de geometria no antimeridiano, embora eu não saiba se esses recursos de divisão são multipartes ou, na verdade, são registros discretos.

Isso parece bastante problemático, especialmente da perspectiva de fazer caixas delimitadoras ou outras solicitações espaciais que abrangem essa linha, mas também na análise e limpeza de entradas e em quaisquer atualizações para caracterizar geometrias. É por isso que estou tentando determinar as melhores práticas com as quais posso me adaptar.

Falando puramente da perspectiva de armazenamento e análise de dados, o geographytipo de PostGIS foi projetado com o antimeridiano em mente (entre vários objetivos de design). Existem várias funções projetadas especificamente para o geographytipo .

Por exemplo, considere um LineString em Taveuni, Fiji ( mapeado com o Great Circle Mapper ), que abrange o antimeridiano:

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

O comprimento desta geodésica é de cerca de 46 km. Da mesma forma, ST_Area funcionaria corretamente em um polígono da ilha, mesmo com as coordenadas de longitude saltando entre +179 e -179.

A conversão de um EPSG: 4326 geometrypara um geographytipo também normaliza as coordenadas, por exemplo, a longitude da última coordenada é> 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]]}

é convertido de volta para exatamente o mesmo geographytipo no primeiro exemplo, mas agora com a saída GeoJSON. Você pode optar por ignorar o AVISO (ou por exemplo SET client_min_messages TO WARNING;) e converter todos os tipos de geometrias engraçadas em geographytipos.

Mostrar geographytipos em mapas fora do PostGIS é uma história diferente, e esperamos que melhores respostas tenham esse aspecto.

Certamente, a resposta preferida é (1), ou seja, os clientes fazem a "coisa certa". Um bom caso a considerar é o polígono que representa o continente da Antártica aproximado por esse arquivo 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>

A codificação ou mudança de delta onde ocorre a quebra da longitude não ajudará em dados como esse. Trabalhando nisso, uma projeção específica para a Antártica funcionará, mas essa dificilmente é uma solução geral.

Surpreendentemente, o Google Earth Pro não exibe esse polígono corretamente (a menos que você use o modo "estrutura de tópicos"). Veja aqui