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:
- Não faça alterações nas geometrias dos recursos e mude a ambiguidade para os aplicativos clientes.
- Divida qualquer recurso que cruze o antimeridiano em uma geometria multiparte com uma quebra no antimeridiano . ( A especificação GeoJSON suporta CRSs nomeados .)
- Trabalhe com projeções não globais para diferentes bacias de ciclones ou regiões oceânicas que não têm essa descontinuidade
- 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 °) - 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).
- 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.
- 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. - 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.
