[pdal] Point cloud viewer in QGIS

[Howard Butler]

> On Jul 6, 2020, at 2:00 PM, Martin Dobias <wonder.sk at gmail.com> wrote:
> 
> Hi Howard
> 
> On Mon, Jul 6, 2020 at 6:22 PM Howard Butler <howard at hobu.co> wrote:
>> 
>>> So far it looks like it would be a good idea to use the PDAL library
>>> for I/O - it supports a variety of formats through a common
>>> abstraction which would make our life much easier.
>> 
>> I agree. You could also give users the ability to load PDAL Pipelines (search for the PipelineExecutor C++ class) that would enable them to directly load and process PDAL data much like a GDAL VRT. Another point that QGIS should worry about is streamable or bulk data processing with PDAL. Both are supported.
> 
> Good point - support for pipelines would add a lot of flexibility.
> 
> I have seen that some PDAL modules support streaming, but I have not
> played with streamed reading of data yet.

Pipelines can be streamable or not streamable depending on their stage composition as well.

> 
>> PDAL was not developed with support for a dynamic live GUI as a primary use case, and you are likely to run into a few friction points (Progress reporting is one thing I immediately know about. Threading situations would be another). We'll see what we can do.
> 
> Right, progress reporting and user-initiated cancellation of data I/O
> would be important, and if not supported by PDAL yet, those would be
> high on our wish list of features. If you have some thoughts on how
> that should be architected, I would be interested in learning more -
> and possibly I would try to work on that.

user-initiated cancelation of i/o in stream mode should not be a challenge. You would be able hook that together yourself. There's no facility for that in standard mode, however. Maybe Andrew has some ideas here.

> 
> Regarding threading, what can be expected - is the library reentrant
> (multiple threads may call PDAL at once, but not using the same data)
> or are there some bits of code that would prohibit any parallel calls
> (e.g. having a global library state (caches / error messages)
> unprotected by mutexes) ?

Entwine provides a good example of what can be done in regard to threading and PDAL. Not all of the readers have been exercised with Entwine, however. Some liberal locking should be enough. We're not purposely thread unsafe, but the typical PDAL usage scenario is to construct parallelism using processes, not threads.

> One more question that comes to my mind is how PDAL deals with API /
> ABI stability - is there any promise that the C++ API will not change
> between versions? Or are there any plans for a stable C API like
> provided in GDAL or GEOS?

No plan for a PDAL C API. Just extra stuff to manage for little benefit. PDAL's C++ API has been quite stable since about 1.6 or 1.7 release. More specifically, if you use higher level APIs like the PipelineManager or PipelineExecutor, they will insulate you from API changes. We have done our best to preserve pipeline behavior and syntax throughout releases, as this is the real definition of PDAL activity. This also conveniently gives other language implementors (Python, Java, Julia, Matlab) a mechanism to drive PDAL without having to deeply implement a large API surface.

Howard