Mi empresa utiliza geometry (the_geom) tipo de datos para el almacenamiento de datos geoespaciales.
Recientemente he sabido que el concepto de geography (the_geog) tipo de datos que, como yo lo entiendo, las tiendas de la SRID junto con la geometría.
¿Cuáles son las diferencias entre geography y geometry, y hay alguna ventaja de la utilización de uno de ellos en grandes bases de datos?
Geografía características se almacenan siempre en WGS84. Las mediciones basadas en la geografía funciones serán en metros en lugar de CRS unidades y PostGIS utilizará geodésico cálculos en lugar de la geometría plana.
Sólo hay una lista limitada de funciones para manipular y analizar la geografía de las características (pero puede convertir entre geometría y geografía). La geografía es apoyado por: las funciones de medición, ST_Intersects, ST_Intersection, ST_Buffer, ST_Covers y ST_CoveresBy.
Yo no creo que sea posible recomendación de la geografía o de la geometría de las grandes bases de datos. Depende de lo que están haciendo con sus datos. Como los cálculos sobre la esfera es más complicado, yo esperaría análisis a ser más lento en la geografía de las características. Usted también tiene que transformar todos tus datos de WGS84 a utilizar la geografía.
Si usted hace un montón de mediciones y, por ejemplo, comparar los tamaños de los grandes polígonos, tendría sentido el uso de la geografía en lugar de la geometría.
He encontrado los siguientes útiles: http://workshops.opengeo.org/postgis-intro/geography.html
El tema también se trata en "PostGIS en la Acción" (ISBN: 9781935182269).
Puedo usar mi intuitiva "reglas de oro"... es útil para una decisión rápida,
Acerca de su BASE de datos: si las características y/o análisis espacial son de escala continental, y la necesidad de precisión (aplicaciones serias) el uso de la geografía. Otro uso de la geometría: cuando todos los de la base de datos es acerca de la misma (de la ciudad de escala) de la región, o que no necesitan de precisión, etc. usted necesita sólo la geometría.
Ver regla similar a la de sugerir conferencia de @underdark.
Acerca de sus necesidades en términos de RENDIMIENTO o de PRECISIÓN del BALANCE: la geometría es más rápido; si usted necesita el rendimiento y pensar en el uso de geografía, hacer sus primeros puntos de referencia.
En esta página vamos a ver algunas palabras clave y el foco en algunos de los conceptos: la precisión, el rendimiento, y algo así como la flexibilidad y productos básicos de uso.
Como recordado por los demás, la diferencia, para la tienda y hacer los cálculos, es el uso de la esfera de la geografía y el plano de la geometría:
Tal vez en el año 2020 todas las bases de datos de SIG se establece la misma norma SRID/EPSG (equivalente a la de hoy en día 4326 código, por WGS84). Hoy en día la geografía no es una opción por defecto, porque de rendimiento y limitaciones funcionales.
En mi opinión es una cuestión de "buenas prácticas", que no es profunda técnico/problema teórico.
Después de estimar el error en sus datos, hacer sus pruebas y comparar resultados: la precisión de las ganancias con la geografía son más altos que los de error de los datos? El ST_Distance función (con MAX y AVG agregadores) es la principal referencia en este tipo de experimento.
Ejemplos de puntos de referencia en una zona urbana de ~100km2 (diámetro ~11 km), todos almacenados como la geometría, en un plano sistema de coordenadas UTM. NOTA: a partir de la frecuencia utiliza la geometría y geografía de la conversión de frecuencia debido a que algunas funciones no existen y algunos otros, como ST_Buffer y ST_Intersection, hacer la conversión de forma interna.
Banco#1: una tabla con ~87000 polígonos que representan solares urbanos, cada uno con poli (avg) ~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.
así, geography_time=6*geometry_time.
Banco#2: una tabla con ~3500 polígonos que representan bloques urbanos, cada uno con poli (avg) ~50 puntos: 0.6 s vs 2,7 s, geography_time=4.5*geometry_time.
Banco#3: ~10000 líneas que representan las calles de la ciudad, cada una con ~5 puntos. ~0.87 s vs ~0.36 s, geography_time=2.4*geometry_time.
De regreso a la Banca#2, la creación de las tablas y realizar 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 poco y bueno hardaware, las veces que convergen en el "aceptable-a la misma hora", pero para las grandes tareas, hay índices de rendimiento a tener en cuenta.
En los puntos de referencia que hago de un día-por-día tarea, comprobar el número de puntos ( ST_NPoints)... es un ejemplo de la operación de que no existe para la geografía, las necesidades de yeso. La "geografía, la geometría del elenco" es una tarea molesta para los programadores, maestros, etc.
A la hora de reutilizar las bibliotecas de SQL y PL/pgSQL funciones, la geografía, la necesidad de adaptaciones. Y, si desea optimizar el código, o evitar la precisión de problemas con un montón de intermediario de las conversiones, la ausencia de un conjunto completo de construir-en funciones, con la geografía, es otro problema. Programa de geografía, no es una tarea fácil.
Para los no habituales de la demanda, sin intensivo de usuario como Mapserver, cuando tu solo (PostGIS) el trabajo es para procesar los datos de entrada y de retorno en cualquier momento (como horas o días) de los datos procesados, la regla de oro es "el uso de la geografía si usted se siente cómodo!" (consulte "Flexibilidad/Producto" más arriba). Si no es así, compruebe reglas habituales.
NOTA: por supuesto, si tu (no habitual) la tarea es mostrar solo los datos de PostGIS a Mapserver, con la ausencia de un proceso necesario, para preservar la misma (geometría o geografía) de los datos de entrada, es la mejor decisión.
Creo que la centralización de datos es una tarea donde la geografía es mejor: en un contexto donde la diversidad de formatos de entrada y los sistemas de referencia son de costumbre, el uso de un estándar, como la que se exige por la geografía, es beneficioso... Convención sobre configuración es un buen principio de centralización y de intercambio de datos son el foco de negocio (ver Mapas de Google!).
Yo creo que la diferencia más significativa es que con el tipo geography, los cálculos están hechos sobre una esfera que representa la tierra en oposición a la superficie plana usada en los cálculos realizados en la geometría tipo de características.
Los documentos son bastante buenas: http://postgis.net/docs/manual-1.5/ch04.html#PostGIS_Geography
La geografía fue de tipo más recientemente añadidos, por lo menos funciones son compatibles/implementados.
Tal vez usted encontrar esta función - y la respuesta - es inútil, pero una de las ventajas de trabajar con geometrías es que se puede trabajar sin ningún tipo de referencia espacial (es decir, SRID valor -1).
En la actualidad estoy trabajando en una aplicación que filtra datos LiDAR aerotransportados, entre sus fuentes de datos es una base de datos PostGIS, que proporciona de primera clase de la indización espacial (RTree sobre GiST) y copes con alto volumen de datos sin problema. Desde que la aplicación no requiere la manipulación o el análisis de la geografía características no SRID es necesario, evitando así la sobrecarga que puede traer.
I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.
