[Qgis-developer] Lidar data into QGIS

[Howard Butler]

On Jan 29, 2014, at 1:19 PM, Stefan Keller <sfkeller at gmail.com> wrote:

> Hi,
> 
> Since LIDAR data 1. has a special data structure 2. is huge and 3.
> needs index, using a database with QGIS as client seems to me a
> natural architectural decision.
> As you may know, PostgreSQL has a pointcloud extension made by the
> "father" of PostGIS, Paul.
> See e.g. my wiki notes and presentation here: http://giswiki.hsr.ch/PointCloud
> 
> -- Stefan
> 
> 
> 2014/1/29 Paolo Cavallini <cavallini at faunalia.it>:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> Il 29/01/2014 19:04, Larry Shaffer ha scritto:
>> 
>>> I contacted Howard Butler, one of the developers of PDAL, about possibly providing
>>> some input on questions we have in this thread, and believe he is now subscribed to
>>> the list.
>>> 
>>> Howard, any ideas on a strategy for using PDAL in QGIS, e.g. via proposed GDAL
>>> support, as a separate data provider, and/or utilizing its command line utilities via
>>> a Processing plugin provider?
>> 
>> IMVHO we need a data provider rather (before) than processing tools.
>> I believe this would be easier with a dedicated provider rather than through GDAL,
>> but I leave the question to Howard or others.
>> All the best.

Here's a little background on PDAL, where it is today, and where it hopes to go. First, PDAL was started due to the fact that I was doing lots of not-related-to-LAS point cloud processing for my work in point cloud data management. Specifically, we were using Oracle Point Cloud [1] to store and extract massive holdings of point cloud data for the US Army Corps of Engineers. At the time, Oracle was the only game in town for such an activity, but the tools around it to get data in and out of the system were deficient, and PDAL grew out of the need to fortify these. PDAL, as its namesake that it apes, aims to be a data translation and light duty processing library for point cloud data. Its initial niche is the same that GDAL fills -- providing an abstract API for translating disparate point cloud data formats. It also has some processing capabilities, but these are very much in the GIS rather than visualization or exploitation domain. 

libLAS was indeed the precursor to my work in PDAL, and it was focused explicitly on ASPRS LAS manipulation. libLAS came into existence due to the fact that Martin Isenburg's LASlib was unavailable at the time under an open source license. Now that LASlib (and many of LAStools) are available under a straight LGPL license, the reason for existence for libLAS is mostly gone. About the only feature it provides that LASlib doesn't is more complete SRS handling through its use of GDAL utilities and color overlay using a GDAL datasource. Both of these could be fixed with a few pull requests to LASlib. These features do exist in PDAL, however.  The difference between PDAL and LAStools is both mindset and features. PDAL right now at least focuses on data access with chain-able filtering. LAStools focuses on exploitation and leverage of features of the ASPRS LAS format (of which there are many).

PDAL defines a processing pipeline which on one end defines a datasource and on the other defines a data consumer. It has driver capabilities that are similar in concept, if not implementation, to GDAL's, including features like dynamically loaded plugins. My history, admiration, and familiarity with GDAL informs many concepts in PDAL although the API is a bit more C++'ish. PDAL also contains a command line application http://www.pdal.io/apps.html for manipulating and translating data via invocation, and a VRT-like XML pipeline language http://www.pdal.io/pipeline.html that allows you to define operations and filtering steps and execute them without having to write C++ to do it. 

As was mentioned, it's not really feasible to treat all the points in a point cloud as OGC simple features-style points. The quantity of data is simply too much. Are you going to render them in 3D? If you are looking to do 3D rendering, you might look to CloudCompare. CC is QT-based. Maybe there's opportunity to embed CloudCompare in some way inside of QGIS as its 3D renderer/plugin. Then both can be used together but evolve separately. The approach could easily be a goose chase too, but developing a satisfactory point cloud rendering capability is likely to be a significant effort. I do know that I hope to someday provide some patches to CloudCompare so it can consume PDAL datasources (it currently only consumes LAS data through libLAS). Having a capable cross-platform viewer handy is important for all kinds of tasks.

Are you going to simply generate a DEM? https://github.com/CRREL/points2grid points2grid provides a simple DEM generation capability. It can currently be used at the endpoint of a PDAL pipeline to generate ascii grids. With some development, this could be updated to output any GDAL-writeable raster type. I think this is where talk about the GDAL provider is aiming, but I'm not so sure. LAStools also provides DEM-generation capabilities, though I'm not sure if these are commercial or open source.

I think the first question to answer for a QGIS point cloud capability is to define what it will do. Is it a renderer/viewer? Product processing pipeline? Everything? I think it is important to keep the scope limited for the first few attempts to feel out the problem. 

I am currently in the process of finishing up the first official release of PDAL, 1.0.0. There have been a number of folks following along and contributing to PDAL as it has matured, and it is used in production for a number of our point cloud warehousing activities, but I have been hesitant to call it "done" enough to invite company to come over and see it. I suppose that feeling is true of all software. Anyway, I plan to do some push on packaging efforts, including Homebrew, OSGeo4W64, and UbuntuGIS, after the 1.0.0 release to make it easy for folks to utilize the capabilities. If anyone with experience in those environments is interested in chipping in, I'd be happy to help guide the effort. 

Howard
http://pdal.io


[1] http://docs.oracle.com/cd/B28359_01/appdev.111/b28400/sdo_pc_pkg_ref.htm#SPATL172



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140129/ed770f7a/attachment.pgp>