Enormes datos de láser de nube de puntos en PostGIS: almacenamiento y procesamiento

Me pregunto cómo es posible almacenar grandes 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 Pointen PostGIS. Pero hasta donde yo sé, guarda cada punto en una nueva tupel, lo que puede hacer que la búsqueda de cualquier punto sea un proceso muy lento, si se almacenan algunos millones o más de ellos.

Encontré un artículo de HSR Universtiy of Applied Sciences Rapperswill, discutiendo este tema. Se sugiere tres formas de almacenar tales datos: Whole data in one tupel, Each point in one tupelo Splitting Data into Blockslos que hacen referencia los info-mesas, sosteniendo la extiende de cada bloque. Como la tercera forma parece ser la más útil para localizar puntos almacenados, me pregunto si alguien ya ha hecho algunas experiencias con ella.

El documento se puede encontrar aquí: http://wiki.hsr.ch/Datenbanken/files/pgsql_point_cloud.pdf

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 él? ¿Es utilizable para tales fines?

El proyecto se puede encontrar aquí: https://github.com/pramsey/pointcloud

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

postgis postgresql lidar

— Knutella
fuente

¿Podría dar una idea aproximada de lo que quiere decir con enorme, y qué tipo de información de la nube de puntos necesita? Es decir, solo XYZ e intensidad, que podrían almacenarse, por ejemplo, en MultipointZM bloqueado o también en otros datos de atributos que probablemente requieran que Point obtenga valores únicos para cada medición de punto por separado.

— Torsti

Almacene lidar en multipuntos de 10x10 metros por clasificación. Usamos solo valores de Z base

— simplexio

@AndreSilva El objetivo es generar perfiles de superficie de carreteras a partir de los datos. Por ahora transformamos los puntos en cuadrículas DEM y usamos PostGIS para almacenarlos como bloques de trama y SAGA para crear finalmente los perfiles a partir de él. Se ejecuta con fines de prueba, pero también significa una pérdida de precisión al rasterizar los datos antes de la importación de db. También la exportación de las celdas de la cuadrícula, cortada por las líneas de perfil dadas, va muy lentamente en PostGIS (gracias a ST_Union). Sería bueno si pudieras recomendar herramientas para tareas similares.

— knutella

@til_b: Bueno, esto es exactamente de lo que estaba hablando ... Buen descubrimiento :)

— knutella

Me hice la misma pregunta y junté algunas piezas para obtener un prototipo funcional. Hasta ahora funciona muy bien , sin problemas de escalabilidad desde varios millones hasta cientos de millones de puntos con alrededor de 20 atributos cada uno. Con tantos puntos, encontrar puntos dentro de un área lleva unos pocos cientos de milis . Toma aproximadamente el mismo tiempo filtrar por marca de tiempo (tiempo preciso de adquisición para mí). En general, el rendimiento es igual o mejor que en "Canal de gestión de datos LiDAR; desde la población de bases de datos espaciales hasta la visualización de aplicaciones web" Los datos se comprimen en DB (aproximadamente 1: 2

Respuestas:

Hay mucho en tu pregunta. La respuesta corta es sí, es completamente posible almacenar enormes datos de nubes 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 el back-end y con un front-end web que permite la visualización y descarga de datos en 3D. https://vimeo.com/39053196

Realmente se trata de cómo elige almacenar los datos en PostGIS y cómo va a acceder a ellos. Una buena solución para los datos aéreos podría ser cuadricular los datos de alguna manera y usar multipuntos para mayor 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 mirar su hardware y la cantidad de usuarios concurrentes que espera. Los detalles sobre esto se pueden encontrar en algunos de nuestros documentos http://www.mendeley.com/profiles/conor-mc-elhinney/

— Conor
fuente

Hola, gracias por tanta información detallada. ¡Las ideas / pruebas ofrecidas en sus documentos parecen realmente útiles! Me llevará un tiempo verlo todo, pero como vi en una primera lectura, ya proporcionan soluciones completas. Muchas gracias por la adición! ¡Además, el video y el visor de su PC basado en navegador son bastante interesantes y parecen funcionar muy bien y sin problemas! Lamentablemente tuve mis manos a corto plazo en otras cosas. Sin embargo, espero continuar con pc-data en breve.

— knutella

El proyecto Glimpse tiene una demostración realmente genial aquí: ncg.nuim.ie/glimpse/auth/login.php

— Kozuch

(La respuesta se basa en los comentarios anteriores y míos; realmente no lo he probado)

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

También podría 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 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 termina teniendo que almacenar los datos como PointZM por separado, entonces una clave externa en la tabla de cuadrícula + índice B-Tree haría que cargar solo los puntos específicos (probablemente) sea mucho más rápido que simplemente consultar la tabla directamente, incluso con un espacio índice.

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

— Torsti
fuente

Creo que su "resumen" es bastante bueno como conclusión de las propuestas discutidas anteriormente. Como dijiste, la forma "correcta" de cargar dichos datos debe determinarse dentro de las necesidades y soluciones propuestas. Resultó que no es imposible gracias a tantas ideas. Me inspiró mucho para seguir trabajando en este tema. ¡Muchas gracias!

— knutella