Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add native point cloud Processing provider #263

Open
alexbruy opened this issue Feb 20, 2023 · 2 comments
Open

Add native point cloud Processing provider #263

alexbruy opened this issue Feb 20, 2023 · 2 comments

Comments

@alexbruy
Copy link
Contributor

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 to laz
  • 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.

@nyalldawson
Copy link
Contributor

Looks good to me!

@roya0045
Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants