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

24

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:

insira a descrição da imagem aqui

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 , 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.

alphabetasoup
fonte
11
Essa é uma pergunta muito boa, anteriormente eu usei um sistema de coordenadas feito à mão a partir de 90 graus, mas eu estava preocupado apenas com uma área muito pequena. Realmente não há nada para 'envolver' adequadamente; Eu acho que é porque não há massa de terra (de importância) abrangendo 180 e muito poucas pessoas precisam mapear sobre ele, todo o problema recebe muito pouca atenção.
Michael Stimson 4/16
Ótima pergunta. Eu acho que você está tentando o destino com o ponto 4, embora na prática não haja razão para que as coordenadas não possam se estender além do 360, usando o mod para recuperá-las. O Delta parece a solução mais extensível e pode até ter algum benefício em termos de compactação de dados, mas, como você diz, transfere a responsabilidade para o cliente.
John Powell
Alguns dos comentários sobre o GeoJSON estão desatualizados desde o 1.0 RC. Um exemplo é que as definições de CRS no GeoJSON estão obsoletas ( sgillies.net//2014/08/06/pruning-crs-from-geojson.html ). Vou editar isso eventualmente.
alphabetasoup

Respostas:

7

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.

Mike T
fonte
2
Uma limitação é que uma geografia não deve ser maior / maior que 180º (consulte as Perguntas frequentes avançadas ). No entanto, você pode simplesmente usar essa regra para os vértices e fazer alguma coisa boba como esta : LINESTRING(179.9 -17, 60 -16.9, -60 -16.8, -179.8 -16.7)que espécie de envoltórios ao redor.
Mike T
0

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 captura de tela do Google Earth Pro

cffk
fonte
Não sei muito sobre o Google Earth, então não sei como ativar o modo de estrutura de tópicos. Mas aqui você tem um polígono válido que abrange o antimeridiano e, na sua imagem, vemos que o Google Earth falha em processá-lo corretamente: então, como é essa evidência de que passar a ambiguidade para o aplicativo cliente é uma prática recomendada se o Google Earth não conseguir lidar com isso? isto? Aliás, o QGIS me fornece problemas de renderização com esse polígono no SRID 4326, mas não se eu introduzir uma linha no antimeridiano (exceto ... bem, a linha). O original é exibido de maneira brilhante se eu usar uma projeção estereográfica antártica.
alphabetasoup
Justo. No entanto, como as coordenadas kml estão restritas à latitude e longitude, não há nada que você, usuário, possa fazer para ajudar o Google Earth neste exemplo em particular. O ônus está nos mantenedores do Google Earth para corrigir esse problema no lado do cliente. (Infelizmente, eles mostram pouca inclinação para fazê-lo!)
cffk