¿Cuáles son los pros y los contras de la geografía y los tipos de geometría de PostGIS?

79

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

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

¿Cuáles son las diferencias entre geography y geometry , y hay alguna ventaja de usar una de ellas en grandes bases de datos?

    
pregunta Adam Matan 02.03.2011 - 14:31

4 respuestas

68

Las características geográficas 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 estará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 puedes realizar el reparto entre la geometría y la geografía. Para ver la lista de funciones actual, consulte: enlace

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

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

Encontré útil lo siguiente: enlace

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

    
respondido por el underdark 02.03.2011 - 14:52
38

Uso mis "reglas de oro" 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 geography . De lo contrario, use la geometría: cuando toda la base de datos es aproximadamente la misma región ( ciudad-escala ), o si no necesita precisión, etc. solo necesita geometría.
    Vea una regla similar en sugerencia de lectura de @underdark .

  • Sobre sus necesidades en términos de DESEMPEÑO / PRECISIÓN BALANCE: la geometría es más rápida; Si necesita rendimiento y piensa utilizar la geografía, haga primero 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 .

Según lo recordado por otros, la diferencia, para almacenamiento y cálculos, es el uso de esfera en geografía y plano en geometría:

  • la esfera (geografía) es mejor, más precisa. Consulte 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 soportan / implementan menos funciones".

Quizás en el año 2020 todas las bases de datos GIS se configurarán con el mismo estándar SRID / EPSG (equivalente al código 4326 actual, para WGS84). Hoy en día, la geografía no es una opción predeterminada debido a las limitaciones funcionales y de rendimiento.

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 más altas que el error de los datos? La función ST_Distance (con MAX y AVG agregadores ) es la referencia principal en este tipo de experimento.

Rendimiento

Ejemplos de benchmarks en un área urbana de ~ 100km2 (diámetro ~ 11km), todos almacenados como geometría, en un sistema de coordenadas UTM planar. NOTA: a partir de la conversión de geometría / geografía de uso frecuente, con frecuencia porque algunas funciones no existen y otras, como ST_Buffer y ST_Intersection, realizan conversiones internas.

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.

Volver 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 al "tiempo aceptable al mismo tiempo", pero para tareas grandes, hay que tener en cuenta las clasificaciones de rendimiento.

Flexibilidad / Productos básicos

En los puntos de referencia que hago una tarea del día a día, verificando el número de puntos (por ST_NPoints ) ... Es un ejemplo de operación que no existe para la geografía, se debe emitir. El "molde 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 de geografía, no es una tarea fácil.

Solo proceso, intercambio de datos, etc.

Para la demanda no habitual, sin un usuario intensivo como Mapserver, cuando su único trabajo (PostGIS) es procesar los datos de entrada y devolver en cualquier momento (como horas o días) los datos procesados, la regla empírica es "usar Geografía si te sientes cómodo! (ver "Flexibilidad / Producto" más arriba). Si no, revisa las reglas habituales.
NOTA: por supuesto, si su tarea (no habitual) solo muestra datos de PostGIS a Mapserver, sin necesidad de un 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 el contexto en el que es habitual la diversidad de los formatos de entrada y los sistemas de referencia, el uso de un estándar, como el que impone la geografía. , es beneficioso ... Convención sobre configuración es un buen principio cuando la centralización y el intercambio de datos son el enfoque comercial (vea Google Maps !).

    
respondido por el Peter Krauss 23.12.2014 - 16:19
11

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 de tipo de geometría.

Los documentos son bastante buenos: enlace

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

    
respondido por el DavidF 02.03.2011 - 15:31
8

Tal vez encuentre que esta función y su respuesta son inútiles, pero una de las ventajas de trabajar con geometrías es que puede trabajar sin ninguna referencia espacial (es decir, SRID establecido 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 al alto volumen de datos sin problema. Dado que esa aplicación no requiere manipular o analizar las características geográficas, no se necesita SRID, evitando así la sobrecarga que puede traer.

    
respondido por el dariapra 02.03.2011 - 21:28

Lea otras preguntas en las etiquetas