Datos de láser de nubes de puntos enormes en PostGIS: almacenamiento y procesamiento

14

Me pregunto, cómo es posible almacenar enormes conjuntos de datos de nube de puntos escaneados con láser en PostGIS, teniendo en cuenta el aspecto temporal para procesarlos. Lo sé, existe un objeto de geometría Point en PostGIS. Pero por lo que sé, guarda cada punto en un nuevo tupel, lo que puede hacer que la búsqueda de un punto determinado sea un proceso muy lento, si se almacenan unos cuantos millones o más de ellos.

Encontré un artículo de HSR Universtiy of Applied Sciences Rappers, que tratará este tema. Sugiere tres formas de almacenar dichos datos: Whole data in one tupel , Each point in one tupel o Splitting Data into Blocks a los que se hace referencia en las tablas de información, manteniendo las extensiones de cada bloque. Como la tercera forma parece ser la más útil para localizar puntos almacenados, me pregunto si alguien ya ha tenido alguna experiencia con ellos.

El documento se puede encontrar aquí: enlace

Por último, pero no menos importante, me topé con un proyecto en github, que parece tratar con los modales de la nube de puntos en PostgeSQL. Lamentablemente no hay mucha información al respecto en la red. Entonces la misma pregunta aquí: ¿Alguien ya ha hecho algunas experiencias con esto? ¿Es utilizable para tales fines?

El proyecto se puede encontrar aquí: enlace

También me gustaría escuchar sobre otras sugerencias, ideas o experiencias, si las hubiera. Pero debo admitir que se prefieren las soluciones no comerciales.

    
pregunta knutella 03.04.2013 - 11:15

2 respuestas

5

Hay mucho en tu pregunta. La respuesta corta es sí, es completamente posible almacenar enormes datos de nube de puntos en PostGIS y usarlos para el procesamiento. Hemos construido un sistema tan completo que hace esto.

Este video está un poco desactualizado con sus números, pero teníamos TB de datos móviles / terrestres y aéreos en Postgis accesibles a través de Python para su procesamiento en la parte posterior y con un front-end web que permite la visualización y descarga de datos en 3D. . enlace

Realmente se reduce a cómo elige almacenar los datos en PostGIS y cómo va a acceder a ellos. Una buena solución para datos aéreos podría ser cuadrar los datos de alguna manera y usar multipuntos para la eficiencia. Sin embargo, si está trabajando con datos móviles o terrestres donde la densidad de puntos puede estar entre 500-30000 puntos por metro cuadrado, este enfoque no funciona. Luego se reduce a analizar su hardware y la cantidad de usuarios concurrentes que espera. Los detalles sobre esto se pueden encontrar en algunos de nuestros documentos. enlace

    
respondido por el Conor 09.04.2013 - 19:17
7

(La respuesta se basa en mis comentarios y en los de otros; no lo he probado)

Almacena los puntos como MultiPointZM. El mejor tamaño de la cuadrícula probablemente dependerá de los patrones de acceso y necesita hacer algunas pruebas al respecto. Una cuadrícula regular con un índice espacial debería hacer las consultas bastante rápido. Si el acceso 3D es importante, MultiPointZM podría estar basado en bloques 3D (1) en lugar de una cuadrícula de planos 2D, entonces (si tiene PostGIS > = 2.0) podrá usar & & & para consultas 3D rápidas.

También puede almacenar el patrón de cuadrícula en una tabla separada, lo que podría ser útil, por ejemplo. al actualizar los datos y validar que los bloques MultiPointZM permanecen dentro de sus límites después de las ediciones, etc.

El almacenamiento de las marcas de tiempo u otros datos solo sería posible para un bloque a la vez, pero algunos datos binarios / de categoría podrían almacenarse desagregando cada bloque por atributo si no hay demasiadas categorías y / o atributos.

Si terminas teniendo que almacenar los datos como PointZM por separado, entonces una clave foránea en la tabla de la cuadrícula + el índice B-Tree haría que la carga de los puntos específicos (probablemente) sea mucho más rápida que solo hacer que la tabla se haga directamente, incluso con un índice espacial.

(1) Si el rango de valores Z es pequeño (después de todo, es un camino), probablemente no tenga sentido.

    
respondido por el Torsti 03.04.2013 - 13:54

Lea otras preguntas en las etiquetas