D'énormes données laser en nuage de points dans PostGIS - Stockage et traitement

Je me demande comment il est possible de stocker d'énormes ensembles de données de nuages de points numérisés au laser dans PostGIS, en gardant à l'esprit le temps de traitement. Je sais, il existe un objet géométrique Pointdans PostGIS. Mais pour autant que je sache, il enregistre chaque point dans un nouveau tupel, ce qui peut rendre la recherche d'un certain point un processus très lent, si quelques millions ou plus d'entre eux sont stockés.

J'ai trouvé un article de HSR Universtiy of Applied Sciences Rapperswill, discutant de ce sujet. Il propose trois façons de stocker ces données: Whole data in one tupel, Each point in one tupelou Splitting Data into Blocksqui sont référencés par info-tables, tenant extends de chaque bloc. Comme la troisième voie semble la plus utile pour localiser des points stockés, je me demande si quelqu'un a déjà fait des expériences avec?

Le document peut être trouvé ici: http://wiki.hsr.ch/Datenbanken/files/pgsql_point_cloud.pdf

Enfin et surtout, je suis tombé sur un projet sur github, qui semble traiter des manières de nuage de points dans PostgeSQL. Malheureusement, pas beaucoup d'informations à ce sujet sur le net. Donc la même question ici: quelqu'un a-t-il déjà fait des expériences avec? Est-il utilisable à de telles fins?

Le projet peut être trouvé ici: https://github.com/pramsey/pointcloud

Je serais également heureux d'entendre d'autres suggestions, idées ou expériences, s'il y en a. Mais je dois admettre que les solutions non commerciales sont préférées.

postgis postgresql lidar

— knutella
source

Pourriez-vous donner une idée approximative de ce que vous entendez par énorme, et de quel type d'informations du nuage de points avez-vous besoin? C'est-à-dire uniquement XYZ et l'intensité, qui pourraient par exemple être stockés dans MultipointZM bloqué ou également d'autres données d'attribut qui nécessitent probablement que Point obtienne des valeurs uniques pour chaque mesure de point séparée?

— Torsti

Je stocke le lidar dans des multipoints de 10x10 mètres par classification. Nous n'utilisons que des valeurs Z au sol

— simplexio

@AndreSilva L'objectif est de générer des profils de surface des routes à partir des données. Pour l'instant, nous avons transformé les points en grilles DEM et utilisé PostGIS pour les stocker sous forme de blocs raster et SAGA pour enfin créer les profils à partir de celui-ci. Il s'exécute à des fins de test, mais cela signifie également une perte de précision lors du tramage des données avant l'importation de la base de données. De plus, l'exportation des mailles, coupées par les lignes de profil données, se fait très lentement dans PostGIS (grâce à ST_Union). Ce serait bien si vous pouviez recommander des outils pour des tâches similaires.

— knutella

@til_b: Eh bien, c'est exactement ce dont je parlais ... Bonne trouvaille :)

— knutella

Je me suis posé la même question et j'ai assemblé quelques pièces pour obtenir un prototype fonctionnel. Jusqu'à présent, cela fonctionne très bien , sans problèmes d'évolutivité de plusieurs millions à des centaines de millions de points avec environ 20 attributs chacun. Avec autant de points, trouver des points à l'intérieur d'une zone prend quelques centaines de millis . Il faut environ le même temps pour filtrer par horodatage (heure précise d'acquisition pour moi). Dans l'ensemble, les performances sont identiques ou meilleures que dans "LiDAR Data Management Pipeline; from Spatial Database Population to Web-Application Visualization" Les données sont compressées dans la base de données (environ 1: 2

Réponses:

Il y a beaucoup dans votre question. La réponse courte est oui, il est tout à fait possible de stocker d'énormes données de nuages de points dans PostGIS et de les utiliser pour le traitement. Nous avons construit un tel système complet qui fait cela.

Cette vidéo est un peu dépassée avec ses chiffres, mais nous avions des To de données mobiles / terrestres et aériennes dans des postgis accessibles via python pour le traitement en back-end et avec un front web permettant la visualisation 3D et le téléchargement des données. https://vimeo.com/39053196

Cela dépend vraiment de la façon dont vous choisissez de stocker les données dans PostGIS et de la façon dont vous allez y accéder. Une bonne solution pour les données aériennes pourrait bien être de mettre en réseau les données d'une certaine manière et d'utiliser des multipoints pour plus d'efficacité. Cependant, si vous travaillez avec des données mobiles ou terrestres où la densité de points peut être comprise entre 500-30000 + points par mètre carré, cette approche ne fonctionne pas. Il s'agit ensuite d'examiner votre matériel et le nombre d'utilisateurs simultanés que vous attendez. Des détails à ce sujet peuvent être trouvés dans certains de nos articles http://www.mendeley.com/profiles/conor-mc-elhinney/

— Conor
source

Salut, merci pour tant d'informations détaillées. Les ides / tests proposés dans vos articles semblent vraiment utiles! Il me faudra un certain temps pour tout voir, mais comme je l'ai vu lors d'une première lecture, ils fournissent déjà des solutions de contournement entières. Merci beaucoup pour l'ajout! De plus, la vidéo et la visionneuse de votre navigateur sont très intéressantes et semblent fonctionner très bien et en douceur! Malheureusement, j'ai mis la main à court terme sur d'autres choses. J'espère cependant continuer avec pc-data sous peu.

— knutella

Le projet Glimpse a une démo vraiment cool ici: ncg.nuim.ie/glimpse/auth/login.php

— Kozuch

(La réponse est basée sur mes commentaires et ceux des autres ci-dessus; je ne l'ai pas vraiment testée)

Stockez les points sous MultiPointZM. La meilleure taille de grille dépendrait probablement des modèles d'accès et vous devez faire des tests à ce sujet. Une grille régulière avec un index spatial devrait rendre les requêtes assez rapides. Si l'accès 3D est important, MultiPointZM peut être basé sur des blocs 3D (1) au lieu d'une grille plane 2D, alors (si vous avez PostGIS> = 2.0), vous pourrez utiliser &&& pour des requêtes 3D rapides.

Vous pouvez également stocker le modèle de grille dans une table séparée, ce qui peut être utile, par exemple lors de la mise à jour des données et de la validation du fait que les blocs MultiPointZM restent dans leurs limites après les modifications, etc.

Le stockage d'horodatages ou d'autres données ne serait possible que pour un bloc à la fois, mais certaines données binaires / catégories pourraient être stockées en désagrégeant chaque bloc par attribut s'il n'y a pas trop de catégories et / ou d'attributs.

Si vous finissez par devoir stocker les données en tant que PointZM séparé, une clé étrangère sur la table de la grille + un index B-Tree rendrait le chargement des points spécifiques (probablement) beaucoup plus rapide que la simple recherche directe de la table, même avec un espace indice.

(1) Si la plage de valeurs Z est petite (c'est une route, après tout), cela n'a probablement aucun sens.

— Torsti
source

Je pense que votre «résumé» est plutôt une conclusion des anciennes propositions discutées. Comme vous l'avez dit, la «bonne» façon de charger de telles données doit être trouvée dans les besoins et les solutions proposées. Il s'est avéré que ce n'était pas impossible grâce à tant d'idées. Cela m'a donné beaucoup d'inspiration pour mes travaux ultérieurs sur cette question. Merci beaucoup!

— knutella du