Le portail francophone de la géomatique

Hello,
J'avais fait quelques tests à l'epoque avec pg_pointcloud, qui utilise pdal pour les formats pointcloud

Nicolas

nicolas > pg_pointcloud n'utilise rien de PDAL, par contre PDAL peut lire et écrire dans pg_pointcloud.

Sur les volumes un tant soit peu conséquent, l'ingestion de données lidar dans PG n'est pas la solution la plus efficace : le stockage sous la forme PCPatch et Pcpoint a un coût prohibitif par rapport à des formats fichiers taillés pour (copc, tiledb, etc.).

Dans un monde idéal, pour exploiter ce type de données dans Postgres il faudrait une solution similaire à pgraster ou ogr_fdw qui permettent d'appeler en SQL des sources stockées en-dehors de la base.

Dans l'attente, il est plus simple d'utiliser PDAL et ses pipelines (p. ex filters.overlay gère le dialecte OGR SQL) pour croiser des données lidar et PG ou bien produire des dérivés raster ou vecteurs mobilisables dans PG.

Dernière modification par JRM (Wed 07 February 2024 15:02)

Oui pardon pour mon abus de langage: j'avais donc utilisé le writer pdal pointcloud, as per the doc (https://pgpointcloud.github.io/pointclo … start.html)

Merci pour ces explications

Nicolas

Dernière modification par Nicolas Ribot (Wed 07 February 2024 17:30)

Christophe, je te conseillerais de débuter par les tutoriels présents sur pdal.io pour prendre en main le concept des pipelines PDAL (similaires aux pipes unix) et découvrir quelques filtres.

Il ne faut pas négliger le travail initial de préparation de la donnée, si tu utilises les dalles lidarhd ign ça limite les efforts, si tu récupères celles d'un presta c'est une autre paire de manche. Et si ensuite tu veux t'attaquer à l'ensemble du GR20 c'est la gestion du calcul qui prend la relève (tuilage, buffers, parallelisation, etc.).

QGIS a intégré une grande partie des commandes PDAL, ça peut être une première approche plus sympa

Bonjour,

nous stockons des données bathymétriques en PGPOINTCLOUDS. Nous utilisons PDAL comme PIPE pour envoyer des données d'une instance Postgres à une autre et réorganiser les patch. Nous créons un fichier json via un ETL puis nous l'exécutons en gros. Voici la forme de notre JSON, je ne sais pas si cela peut aider? :
L'inconvénient de ce pipe (via les options filters.chipper est qu'il est très consommateur en RAM (les données sont stockées dans la RAM pour calcul des patch)

{
        "type":"readers.pgpointcloud",
        "connection":"host='hote' dbname='db_source' user='user' password='mdp' port='5432'",
        "table":"table_source",
        "schema":"sonde_pc",
        "column":"patch",
        "spatialreference":"EPSG:4326"
    },
    {
        "type":"filters.chipper",
        "capacity":"400"
    },
    {
        "type":"writers.pgpointcloud",
        "connection":"host='nom_hote' dbname='gb_name' user='user' password='mdp' port='5432'",
        "compression":"dimensional",
        "srid":"4326",
        "schema": "nom_schema",
        "table": "nom_table",
        "column":"patch",
        "pcid": "1",
        "post_sql": "create index if not exists patch_geom_maj_idx on schela.table gist((patch::geometry))",
        "scale_x": 0.0000001,
        "scale_y": 0.0000001,
        "scale_z": 0.001