Utilizo mis "reglas generales" intuitivas ... Es útil para una decisión rápida,
Acerca de su BASE DE DATOS : si las características y / o el análisis espacial son de escala continental y necesitan precisión (aplicaciones serias), use la geografía . De lo contrario, use geometría: cuando toda la base de datos es aproximadamente la misma región ( escala de ciudad ), o no necesita precisión, etc., solo necesita geometría.
Vea una regla similar en la conferencia sugerida de @underdark .
Acerca de sus necesidades en términos de BALANCE DE RENDIMIENTO / PRECISIÓN : la geometría es más rápida; Si necesita rendimiento y piensa utilizar la geografía, primero haga sus puntos de referencia.
Conceptos clave
En esta página, vemos algunas palabras clave y el enfoque en algunos conceptos: precisión , rendimiento y algo así como flexibilidad / comodidad de uso .
Como lo recuerdan otros, la diferencia, para la tienda y los cálculos, es el uso de la esfera en la geografía y el plano en la geometría:
- la esfera (geografía) es mejor, más precisa. Vea el ejemplo de Los Ángeles / París .
- evolución de la geografía: como dice @DavidF, "el tipo de geografía se agregó más recientemente, por lo que se admiten / implementan menos funciones".
Quizás en el año 2020 todas las bases de datos SIG se establecerán en el mismo SRID / EPSG estándar (equivalente al código 4326 actual, para WGS84). Hoy en día, la geografía no es una opción predeterminada debido al rendimiento y las limitaciones funcionales.
Discusión
En mi opinión, es una cuestión de "mejores prácticas", no un problema técnico / teórico profundo.
Precisión
Después de estimar el error en sus datos, haga sus pruebas y compare los resultados: ¿las ganancias de precisión con la geografía son mayores que el error de datos? La función ST_Distance (con los agregadores MAX y AVG ) es la referencia principal en este tipo de experimento.
Actuación
Ejemplos de puntos de referencia en un área urbana de ~ 100 km2 (diámetro ~ 11 km), todos almacenados como geometría, en un sistema de coordenadas planas UTM. NOTA: comenzando con la conversión de geometría / geografía utilizada con frecuencia, con frecuencia porque algunas funciones no existen y otras, como ST_Buffer y ST_Intersection, realizan la conversión internamente.
Banco # 1: una tabla con ~ 87000 polígonos que representan lotes urbanos, cada uno con poli con (promedio) ~ 13 puntos,
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.
entonces, geography_time = 6 * geometry_time.
Banco # 2: una tabla con ~ 3500 polígonos que representan bloques urbanos, cada uno con poli con (promedio) ~ 50 puntos: 0.6s vs 2.7s, geography_time = 4.5 * geometry_time.
Banco # 3: ~ 10000 líneas que representan calles urbanas, cada una con ~ 5 puntos. ~ 0.87s vs ~ 0.36s, geography_time = 2.4 * geometry_time.
De vuelta al Banco # 2, creando las tablas y haciendo 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
Conclusión: para tareas pequeñas y buen hardware, los tiempos convergen en el "tiempo aceptable", pero para tareas grandes, hay que considerar las calificaciones de rendimiento.
Flexibilidad / Producto
En los puntos de referencia, hago una tarea diaria, comprobando el número de puntos (por ST_NPoints) ... Es un ejemplo de operación que no existe para la geografía, necesita reparto. El "reparto de geografía / geometría" es una tarea molesta para programadores, maestros, etc.
Al reutilizar bibliotecas de funciones SQL y PL / pgSQL, la geografía necesita adaptaciones. Y, si desea optimizar el código, o evitar problemas de precisión con muchas conversiones intermedias, la ausencia de un conjunto completo de funciones integradas, con geografía, es otro problema. Programa para geografía, no es una tarea fácil.
Solo proceso, intercambio de datos, etc.
Para una demanda no habitual, sin un usuario intensivo como Mapserver, cuando su único trabajo (PostGIS) es procesar datos de entrada y devolver en cualquier momento (como horas o días) los datos procesados, la regla general es "usar geografía si son cómodos! " (Ver "Flexibilidad / Producto" más arriba). Si no, verifique las reglas habituales.
NOTA: por supuesto, si su tarea (no habitual) solo muestra datos de PostGIS a Mapserver, sin necesidad de proceso, para preservar la misma (geometría o geografía) de sus datos de entrada, es una mejor decisión.
Creo que la centralización de datos es otra tarea en la que la geografía es mejor: en un contexto donde la diversidad de formatos de entrada y sistemas de referencia son habituales, el uso de un estándar, como el impuesto por la geografía, es beneficioso ... La convención sobre la configuración es Un buen principio cuando la centralización y el intercambio de datos son el foco del negocio (¡vea Google Maps!).