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!).