Késako

pgPointcloud est une extension PostgreSQL permettant de stocker des nuages de points dans une base PostgreSQL. Cet article présente ses différentes caractéristiques, ses compromis et cas d’usages principaux.

Problématique

Le besoin de créer pgPointcloud est venu de l’émergence de l’acquisition de nuages de points très volumineux, pouvant contenir des centaines de millions, voire des milliards de points. Comment stocker ces points ainsi que leurs attributs tout en profitant de la puissance de PostgreSQL et de PostGIS ?

Un stockage naïf en format POINT est à déconseiller. En effet, cela implique d’avoir une ligne par point dans la table, ce qui ne passera pas à l’échelle pour les index géographiques lorsque la quantité de points sera supérieure à quelques dizaines de millions.

De plus, l’index géographique de PostGIS est peu adapté aux points. Il se base, en effet, sur une hiérarchie de boîtes englobantes. Si cette hiérarchie est toujours utile pour les points, le calcul d’une boîte englobante d’un point est… le point lui-même ! On se retrouve donc à dupliquer le stockage de la table dans l’index.

On préfère ainsi les solutions qui regroupent les points en ensembles géographiques cohérents permettant de garder une taille d’index raisonnable.

`MULTIPOINT`

Une solution possible est bien sûr d’utiliser le type géographique MULTIPOINT, en regroupant les points en suivant un découpage géographique. Cette solution permet de faire passer à l’échelle l’index géographique, mais a deux limitations :

Ce format n’est pas compressé
Il ne permet pas de stocker facilement les métadonnées liées à chaque point.

Pour ce dernier point, on peut utiliser un MultiPointM et détourner cette dimension M pour stocker un identifiant de métadonnée pouvant participer à la condition d’un JOIN par exemple.

pgPointcloud

pgPointcloud offre une autre façon de stocker les points en les groupant dans des « patchs ». Par comparaison avec le MULTIPOINT, pgpointcloud permet deux choses supplémentaires :

la compression d’un patch de point ;
la définition d’un format spécifique de points.

pgPointcloud peut donc se comparer au multipoint, tout en apportant un compromis différent en termes de stockage et de format de donnée.

La compression

pgPointcloud supporte la configuration d’une méthode de compression. Les trois possibles sont :

pas de compression ;
compression LAZ ;
compression dimensionnelle. Elle regroupe les données par dimension (X, Y, Z) car elles ont plus de chance d’être similaires, puis utilise différentes stratégies de compression.

Le site officiel de pgPointcloud détaille davantage ces méthodes. Ces compressions permettent de compresser avec un ratio entre 3:1 et 5:1.

Déclaration du format

pgPointcloud permet de déclarer un format de point. Principalement utile pour déclarer des attributs supplémentaires aux classiques X, Y et Z. Il est ainsi possible d’embarquer dans chaque point l’intensité, la classification, le nombre de retour, etc. sans recourir à des jointures. La déclaration du format se fait avec un schéma XML.

Avantages

Stocker des points en base de données avec PostGIS apporte deux principaux bénéfices :

la possibilité d’avoir des mises à jour et des modifications transactionnelles, ce qui apporte une sécurité et de meilleures garanties de cohérence ;
la possibilité de faire des croisements avec d’autres tables géographiques en utilisant les index géographiques.

Inconvénients

Ce type de stockage peut ne pas convenir à tous les cas d’usage. En effet, le fait de stocker un grand nombre de points dans une base de données va mécaniquement l’alourdir, ce qui peut complexifier les opérations de maintenance et de maintien en condition opérationnelle (sauvegarde, restauration, migration, etc.).

Par rapport à d’autres types de stockage comme le MULTIPOINT, la compression va nécessairement ralentir les opérations de lecture.

Enfin, pgPointcloud, bien que permettant un requêtage par zone efficace, n’est pas utilisable seul pour de la visualisation, car il n’implémente pas de notion de niveau de détail. Ces niveaux doivent être mis en place par ailleurs, par exemple, avec une table additionnelle. On peut alors utiliser pg_tileserv et une fonction SQL qui interrogera la table contenant les niveaux de détails pour les vues d’ensemble et la table de référence pour les vues plus détaillées.

Une table pgpointcloud branchée sur pg_tileserv et visualisée dans QGIS

Cas d’usage

pgPointcloud pourra donc être choisi si :

On souhaite absolument un stockage transactionnel
Le croisement avec des données géographiques est fréquent et nécessaire
On veut optimiser le stockage plutôt que la rapidité d’interrogation
Le format de point est spécifique

Voici un petit diagramme résumant les points clés de décision.

Diagramme de décision pour pgpointcloud

Ce diagramme résume les critères, mais le choix réel dépendra bien sûr du contexte d’utilisation. Retenons tout de même que pgPointcloud pourra être envisagé pour des cas d’usage comme un référentiel de donnée (où l’intégrité est très importante) ou comme étape pouvant débloquer des calculs géographiques complexes.

Infos pratiques

Installation

pgPointcloud est présent dans les dépôts de paquets officiels d’Ubuntu et debian (par exemple postgresql-16-pointcloud pour ubuntu 24.10). Pour avoir accès à plus de versions ou pour les dépôts rhel, centos etc., il est possible d’ajouter le dépôt de paquet du projet postgresql (pgdg) correspondant à votre distribution, qui contient un paquet pour pgpointcloud.

Pour Windows, pgPointcloud est inclus dans le bundle PostGIS officiel.

Chargement et extractions des données

Pour charger et extraire les données, PDAL reste un outil de choix, car il possède un reader et un writer pgPointcloud.

Toute la puissance SQL est également à votre disposition, en utilisant les fonctions pgPointcloud et les fonctions PostGIS.

Par exemple, voici une requête extrayant les points au format MVT sur une étendue donnée, en incluant le Z comme propriété :

WITH mvtgeom AS (
  SELECT
    pc_get(points, 'z') AS z,
    st_asmvtgeom(st_transform(points::geometry, 3857), bounds.geom) point
  FROM points,
    -- pc_explode "ouvre" le patch de points pour traiter chaque point séparement
    LATERAL pc_explode(sonde.patch) v(points)
  WHERE
    pc_intersects(patch, polygon)
)
SELECT st_asmvt(mvtgeom) FROM mvtgeom;

Conclusion

pgPointcloud présente une solution intéressante pour le stockage et le traitement de nuage de point. Profitant de la puissance de SQL, de la sécurité de PostgreSQL et des fonctionnalités de PostGIS, il offre un compromis intéressant lorsqu’on souhaite construire un référentiel ou croiser des couches entre elles.

Si cette technologie vous intéresse, n’hésitez pas à nous contacter pour évaluer si elle répond à votre cas d’usage.

Pour aller plus loin :

pgPointcloud, un compromis différent pour le stockage de nuage de points