Mi empresa utiliza el tipo de datos geometry( the_geom) para almacenar datos geoespaciales.

Recientemente me he familiarizado con el concepto de tipo de datos geography( the_geog) que, según tengo entendido, almacena SRIDjunto con la geometría.

¿Cuáles son las diferencias entre geographyy geometry, y hay alguna ventaja de usar uno de ellos en grandes bases de datos?

Las características de geografía siempre se almacenan en WGS84 antes de PostGIS 2.2; desde entonces se puede utilizar cualquier sistema de referencia espacial basado en lon / lat. Las mediciones basadas en características geográficas se realizarán en metros en lugar de unidades CRS y PostGIS utilizará cálculos geodésicos en lugar de geometría plana.

No todas las funciones son compatibles con la geometría, pero puede emitir entre geometría y geografía. Para ver la lista de funciones actual, consulte: https://postgis.net/docs/PostGIS_Special_Functions_Index.html#PostGIS_GeographyFunctions

No creo que sea posible recomendar geografía o geometría para grandes bases de datos. Depende de lo que esté haciendo con sus datos. Como los cálculos en la esfera son más complicados, esperaría que los análisis sean más lentos en las características geográficas. También debe transformar todos sus datos a WGS84 para usar la geografía.

Si realiza muchas mediciones y, por ejemplo, tiene que comparar tamaños de polígonos grandes, tendría sentido utilizar la geografía en lugar de la geometría.

Encontré lo siguiente útil: http://postgis.net/workshops/postgis-intro/geography.html

El tema también se trata en "PostGIS en acción" (ISBN: 9781935182269).

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

Creo que la diferencia más significativa es que con el tipo de geografía, los cálculos se realizan en una esfera que representa la tierra en lugar de la superficie plana utilizada en los cálculos realizados en las características del tipo de geometría.

Los documentos son bastante buenos: http://postgis.net/docs/manual-1.5/ch04.html#PostGIS_Geography

El tipo de geografía se agregó más recientemente, por lo que se admiten / implementan menos funciones.

Quizás encuentre que esta característica, y la respuesta, es inútil, pero una de las ventajas de trabajar con geometrías es que puede trabajar sin ninguna referencia espacial (es decir, SRID configurado en -1).

Actualmente estoy trabajando en una aplicación que filtra datos LiDAR en el aire, entre sus fuentes de datos se encuentra una base de datos PostGIS, que proporciona indexación espacial de primera clase ( RTree sobre GiST ) y hace frente a un gran volumen de datos sin problemas. Dado que esa aplicación no requiere manipular o analizar características geográficas, no se necesita SRID, evitando así la sobrecarga que puede traer.