¿El formato de almacenamiento espacial más rápido?


8

Me pregunto qué método de almacenamiento dará como resultado la lectura más rápida de los vectores de mapa para la representación. SHP? PostGres? SQLite? (No cambian a menudo y no necesito funciones espaciales para estos vectores).


1
¿De cuántas características estás hablando?
Roger D.

2
Su pregunta parece implicar que el cuello de botella es el proceso de lectura de datos. Mi experiencia es que la carga real está en el proceso de representación en sí, al menos con MapServer. Es decir, no veo que el uso de shapefiles o una base de datos espacial haga una gran diferencia.
dariapra

@Roger: no estoy seguro. Es un mapa de los EE. UU. Que utiliza la resolución más alta (estados, condados, carreteras, ríos). Obtuve los datos de naturalearthdata.com
Nate

@Nate, siendo ese el caso, ¿por qué leer la nota en OSM o Google para su mapa? Entonces superposición encima de ellos? Hacer que todo Estados Unidos viva en todo momento es un gran proceso. Entonces debe considerar el rendimiento de la red, el rendimiento del disco io, la CPU. Hay muchas cosas que pueden afectar y afectarán el rendimiento.
DEWright

Respuestas:


12

Pruebas de velocidad

Hay algunas pruebas de velocidad muy de archivos de forma frente a la base de datos (PostGIS) para MapServer en esta presentación (desde 2007).

En resumen:

  • Para un conjunto de datos de 3 millones de características ejecutando solicitudes de 30 características una tras otra, PostGIS fue más rápido que el shapefile (aunque esto puede haber cambiado desde entonces por una solución para leer el índice del shapefile)
  • Para un conjunto de datos de 10,000 características, shapefile fue un poco más rápido.
  • Para solicitudes concurrentes, shapfile fue más rápido

Y los tiempos en detalle, lo que también puede ayudar a decidir si el formato de almacenamiento es un factor importante.

                       PostGIS   Shapefile 
Start mapserv process  15ms      15ms
Load mapfile           3ms       3ms
Connect to DB          14ms      n/a
Query                  20ms      n/a
Fetch                  7ms       n/a
Draw                   11ms      28ms
Write Image            8ms       8ms
Network Delay          3ms       3ms

Utilice siempre FastCGI en MapServer si usa una base de datos, ya que las conexiones de la base de datos se pueden reutilizar; de lo contrario, se debe crear una nueva conexión en cada solicitud.

Implementaciones para lectores de archivos Shapefile

La velocidad de lectura de un archivo de forma (y datos de una base de datos) depende de la implementación de codificación específica.

El código fuente para MapServer abriendo un archivo de forma se puede ver aquí . Después de los comentarios, puede ver lo importante que es tener un índice. Normalmente solo puede leer un archivo en una dirección para obtener un registro, pero con un índice puede leer en dos direcciones.

345   /*    Read the .shx file to get the offsets to each record in             */
346   /*    the .shp file.   

Otro ejemplo de abrir un shapefile se puede ver en la fuente de Python para PyShp . Una vez más, puede ver cómo se utiliza un índice para buscar formas específicas directamente.

Otros factores a Condsider

Las limitaciones del formato DBF (límites en el tamaño del campo, sin soporte nulo, límites en el almacenamiento de texto), también deben tenerse en cuenta al decidir si usar o no una base de datos.

Una base de datos también ofrece medios para proteger los datos, unir y crear vistas más fácilmente, iniciar sesión y muchas otras funciones que no obtendrá con un archivo independiente.


10

Al contrario de lo que dice dariapra, mi experiencia en el desarrollo de Maperitive me dice que el mayor cuello de botella está en la carga real de los datos antes de la representación. Todo depende en gran medida de qué tan grande sea el conjunto de datos almacenado en general y qué tan grande sea el conjunto de datos que está tratando de procesar de una vez. Si puede cargarlo todo en la memoria, entonces los archivos de forma probablemente sean mejores que usar un motor de base de datos.


44
+1 por señalar que la forma del cuello de botella es importante y proporcionar información de la experiencia real. Buen material.
whuber

¿Dónde está el cuello de botella? Parece una pregunta interesante y abierta que depende de una serie de variables, tal vez el tipo de carga de trabajo sea importante. Recuerdo que una vez indexé algunos archivos de forma con shapetree para obtener una representación más rápida de algunas capas vectoriales con MapServer, y no obtuve una ganancia de rendimiento significativa.
dariapra

2
@dariapra Cierto, depende mucho del caso de uso. Si es capaz de cargar todos los datos de una vez, entonces el índice espacial no es realmente necesario, pero la carga de datos de un archivo de forma debería ser mucho más rápido que ejecutar consultas SQL. Por otro lado, si hay una gran cantidad de datos que necesitan ser filtrados, apostaría en una base de datos y no en archivos de forma.
Igor Brejc

4

¿Qué programa usarás para renderizar? Esto puede influir en los resultados. De todos modos, tener un shapefile con un índice espacial (p. Ej. Http://mapserver.org/utilities/shptree.html ) que se usa es a menudo la técnica más rápida. Aparte de eso: depende de su aplicación, pero el almacenamiento en caché de los resultados renderizados suele ser mucho más útil para mejorar el rendimiento.


Gracias. Estoy usando MapGuide en este momento (todavía estoy explorando nuestras opciones), y he estado mirando Mapserver.
Nate

2

Shapefile será la apuesta más rápida y probablemente la mejor. Existe una sobrecarga para cualquier base de datos SQL, luego se gestiona el retorno de grandes conjuntos de resultados (la conversión de tipos de datos de bases de datos a tipos de datos nativos también ralentizará las cosas).

Intente usar un paquete de código abierto de maptools.org para hacer sus lecturas. Las herramientas de ArcGIS, aunque están diseñadas específicamente, tienen un poco de sobrecarga para comenzar y son caras.

Espero que esto ayude

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.