Add native point cloud Processing provider
alexbruy opened this issue · comments
QGIS Enhancement: Add native point cloud Processing provider
Date 2023/02/20
Author Alexander Bruy (@alexbruy)
Contact alexander dot bruy at gmail dot com
Maintainer @alexbruy
Version QGIS 3.32
Summary
With acceptance of QEP #194 Point Clouds in QGIS point clouds became a first class citizen in QGIS with own layer type, data provider and renderer. However, native data management and analysis possibilities for point clouds remain quite limited, especially when compared to raster, vector and mesh layer types.
There are some 3rd party plugins offering tools for point cloud processing, however all of them require installation of additional packages, which sometimes can be platform-dependent. All this puts point cloud layers in unequal position and makes the user's life harder.
Proposed Solution
It is proposed that a new native Processing provider with the set of point cloud algorithms will be implemented.
Under the hood these algorithms will use pdal_wrench command line tool, which is build on top of PDAL pipelines and provides basic data processing and export functionality (merge, translate, thin, etc). The pdal_wrench
code will be integrated in the QGIS source code, like already done with the untwine
tool.
The new Processing provider will be build only when QGIS is build with the PDAL support. If present, provider will be enabled by default and available for use both via QGIS GUI and qgis_process
command line tool.
As a first step the following tools will be implemented:
- information: outputs a basic metadata of the point cloud (number of points, extent, crs, etc)
- translate: convert point cloud to a different format, e.g.
las
tolaz
- reproject: reproject point cloud to a different CRS
- assign CRS: fix (assign) CRS of a point cloud file
- clip: clip point cloud by clipping polygon(s)
- merge: merge multiple point clouds in a single file
- tile: create tiles from input data
- thin: create a thinned version of the point cloud
- extract boundary: export vector layer containing point cloud boundaries
- density: export a raster file where each cell contains number of points that are in that cell's area
- export as raster: export point cloud data to a 2D raster grid
- export as vector: export point cloud data to a vector layer with 3D points
- export as raster TIN: export point cloud data to a 2D raster grid using a triangulation of points
Why pdal_wrench
?
There are several reasons to use pdal_wrench
instead of using PDAL API and building pipelines:
- ease of use:
pdal_wrench
provides a set of ready to use algorithms and hides complexity of the pipeline creation from
the user, making it much easier for non tech-savvy people to use LiDAR data - parallel execution: PDAL runs pipelines in a single thread, while
pdal_wrench
supports multithreaded processing either
on a spatial or per-file basis. - virtual point clouds support: this is similar to GDAL's virtual raster (VRT) — a single file references multiple other
files and represent them as a single dataset.
Affected Files
Most of the development will be done in new files, e.g. src/analysis/processing/pdal/*.h|cpp
Further Considerations/Improvements
When more tools will be added to pdal_wrench
, they can be exposed via Processing provider as well.
Once QGIS gets Virtual Point Clouds (VPC) support, provider can be updated to read/write VPC files.
Looks good to me!
Does the proposal integrates/considers the changes that will be needed to have everything in the modeler or will this be a distinct proposal?
Out of curiosity, once it comes to the modeler, would it be a good idea to convert the alg into a PDAL pipelien or would it be better to use wrench and generate outputs sequentially?