Minha empresa usa o tipo de dados geometry( the_geom) para armazenar dados geoespaciais.

Recentemente, familiarizei-me com o conceito de geography( the_geog) tipo de dados que, como eu o entendo, armazena o SRIDjunto com a geometria.

Quais são as diferenças entre geographye geometry, e há alguma vantagem em usar um deles em grandes bancos de dados?

Os recursos geográficos são sempre armazenados no WGS84 antes do PostGIS 2.2; desde então, qualquer sistema de referência espacial baseado em lat / lat pode ser usado. As medidas baseadas nos recursos geográficos serão em metros, em vez de unidades CRS, e o PostGIS usará cálculos geodésicos em vez de geometria plana.

Nem todas as funções suportam geometria, mas você pode converter entre geometria e geografia. Para a lista de funções atual, consulte: https://postgis.net/docs/PostGIS_Special_Functions_Index.html#PostGIS_GeographyFunctions

Acho que não é possível recomendar geografia ou geometria para bancos de dados grandes. Depende do que você está fazendo com seus dados. Como os cálculos na esfera são mais complicados, eu esperaria que as análises fossem mais lentas nos recursos geográficos. Você também precisa transformar todos os seus dados em WGS84 para usar a geografia.

Se você fizer muitas medições e, por exemplo, precisar comparar tamanhos de polígonos grandes, faria sentido usar a geografia em vez da geometria.

Eu achei o seguinte útil: http://postgis.net/workshops/postgis-intro/geography.html

O tópico também é abordado em "PostGIS in Action" (ISBN: 9781935182269).

Eu uso minhas "regras práticas" intuitivas ... É útil para uma decisão rápida,

• Sobre o seu DATABASE : se os recursos e / ou análises espaciais são de escala continental e precisam de precisão (aplicações sérias), use a geografia . Caso contrário, use geometria: quando todo o banco de dados for sobre a mesma região ( escala na cidade ) ou você não precisar de precisão etc., precisará apenas de geometria.
  Veja regra semelhante na palestra de sugestão do @underdark .

• Sobre suas necessidades em termos de BALANÇO DE DESEMPENHO / PRECISÃO : a geometria é mais rápida; se você precisa de desempenho e pensa em usar a geografia, faça seus benchmarks primeiro.

Conceitos chave

Nesta página, vemos algumas palavras-chave e o foco em alguns conceitos: precisão , desempenho e algo como flexibilidade / mercadoria de uso .

Como lembrado por outros, a diferença, para armazenamento e cálculos, é o uso da esfera na geografia e do plano na geometria:

• a esfera (geografia) é melhor, mais precisa. Veja o exemplo de Los Angeles / Paris .
• evolução da geografia: como diz @DavidF, "o tipo de geografia foi adicionado mais recentemente, portanto, menos funções são suportadas / implementadas".

Talvez no ano de 2020 todos os bancos de dados de GIS sejam configurados com o mesmo padrão SRID / EPSG (equivalente ao código 4326 atual, para WGS84). Hoje, a geografia não é uma opção padrão devido a limitações de desempenho e funcionais.

Discussão

Na minha opinião, é uma questão de "melhores práticas", não um profundo problema técnico / teórico.

Precisão

Depois de estimar o erro nos seus dados, faça seus testes e compare os resultados: os ganhos de precisão com a geografia são maiores que o erro dos dados? A função ST_Distance (com agregadores MAX e AVG ) é a principal referência nesse tipo de experimento.

atuação

Exemplos de benchmarks em uma área urbana de ~ 100km2 (diâmetro ~ 11km), todos armazenados como geometria, em um sistema de coordenadas UTM planar. NOTA: começando com a conversão de geometria / geografia usada com freqüência - freqüentemente porque algumas funções não existem e outras, como ST_Buffer e ST_Intersection, fazem a conversão internamente.

Banco # 1: uma tabela com ~ 87000 polígonos representando lotes urbanos, cada um com poli com (avg) ~ 13 pontos,

 BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geom AS 
        SELECT gid, the_geom FROM urbanlots; ROLLBACK;
 -- time 2080 ms   ~ 2.0 s
 BEGIN; EXPLAIN ANALYSE CREATE TABLE temp_geog AS 
        SELECT gid, Geography(ST_Transform(the_geom,4326)) AS geog 
        FROM urbanlots; ROLLBACK;
 -- time 12374 ms ~ 12.4 s  ~ 6 * geometry.

então, geography_time = 6 * geometry_time.

Banco # 2: uma tabela com ~ 3500 polígonos representando blocos urbanos, cada um com poli com (avg) ~ 50 pontos: 0,6s vs 2,7s, geography_time = 4,5 * geometry_time.

Banco nº 3: ~ 10000 linhas representando ruas urbanas, cada uma com ~ 5 pontos. ~ 0.87s vs ~ 0.36s, geography_time = 2.4 * geometry_time.

De volta ao Banco 2, criando as tabelas e fazendo consultas,

 EXPLAIN ANALYSE SELECT ST_Area(g.the_geom)+ST_Distance(g.the_geom,t.the_geom) 
         FROM temp_geom g, (SELECT the_geom FROM temp_geom WHERE gid=1) as t;
 -- time 182 ms   ~ 0.2 s
 EXPLAIN ANALYSE SELECT ST_Area(g.geog)+ST_Distance(g.geog,t.geog) 
         FROM temp_geog g, (SELECT geog FROM temp_geog WHERE gid=1) as t;
 -- time 58657 ms  ~ 59 s  ~  300*geometry
 -- curioselly for only distances, geography=4*geometry

Conclusão: para poucas tarefas e bom hardaware, os tempos convergem para o "mesmo tempo aceitável", mas para grandes tarefas, há classificações de desempenho a serem consideradas.

Flexibilidade / Commodity

Nos benchmarks, eu faço uma tarefa diária, verificando o número de pontos (por ST_NPoints) ... É um exemplo de operação que não existe para a geografia, é necessário expor as necessidades. O "elenco de geografia / geometria" é uma tarefa irritante para programadores, mestres, etc.

Ao reutilizar bibliotecas de funções SQL e PL / pgSQL, a geografia precisa de adaptações. E, se você deseja otimizar o código ou evitar problemas de precisão com muitas conversões intermediárias, a ausência de um conjunto completo de funções internas, com a geografia, é outro problema. Programa de geografia, não é uma tarefa fácil.

Somente processo, intercâmbio de dados etc.

Para demanda não usual, sem usuário intensivo como o Mapserver, quando o seu único trabalho (PostGIS) é processar dados de entrada e retornar a qualquer momento (como horas ou dias) os dados processados, a regra geral é "use geography se você são confortáveis! " (consulte "Flexibilidade / commodity" acima). Caso contrário, verifique as regras usuais.
NOTA: é claro que, se sua tarefa (não usual) é apenas mostrar dados do PostGIS para o Mapserver, sem necessidade de processo, preservar o mesmo (geometria ou geografia) dos dados de entrada, é uma decisão melhor.

Acredito que a centralização de dados é outra tarefa em que a geografia é melhor: no contexto em que a diversidade de formatos de entrada e sistemas de referência é usual, o uso de um padrão, como o imposto pela geografia, é benéfico ... A convenção sobre configuração é um bom princípio quando a centralização e o intercâmbio de dados são o foco dos negócios (consulte Google Maps!).

Acredito que a diferença mais significativa é que, com o tipo de geografia, os cálculos são feitos em uma esfera que representa a Terra em oposição à superfície plana usada nos cálculos feitos em recursos do tipo de geometria.

Os documentos são muito bons: http://postgis.net/docs/manual-1.5/ch04.html#PostGIS_Geography

O tipo de região geográfica foi adicionado mais recentemente, portanto, menos funções são suportadas / implementadas.

Talvez você ache que esse recurso - e resposta - é inútil, mas uma das vantagens de trabalhar com geometrias é que você pode trabalhar sem nenhuma referência espacial (ou seja, SRID definido como -1).

Atualmente, estou trabalhando em um aplicativo que filtra dados de LiDAR no ar, entre suas fontes de dados, é um banco de dados PostGIS, que fornece indexação espacial de primeira classe ( RTree sobre GiST ) e lida com grande volume de dados sem problemas. Como esse aplicativo não requer manipulação ou análise de recursos geográficos, nenhum SRID é necessário, evitando assim a sobrecarga que pode gerar.