[pdal] Point cloud viewer in QGIS

[Luigi Pirelli]

Another possible critical aspect is lack of OSGeo4W packaging moved to
Conda in a Win environment. AFAIR OSGeo4W packaging was abandoned due to
lack of resources to maintain it, not for technical limitations. Is it
right Howard?

Luigi Pirelli

**************************************************************************************************
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Book: Mastering QGIS3 - 3rd Edition
<https://www.packtpub.com/eu/application-development/mastering-geospatial-development-qgis-3x-third-edition>
* Hire a team: http://www.qcooperative.net
**************************************************************************************************


On Mon, 6 Jul 2020 at 18:22, Howard Butler <howard at hobu.co> wrote:

>
>
> On Jul 6, 2020, at 9:01 AM, Martin Dobias <wonder.sk at gmail.com> wrote:
>
>
> While the existing tools such as CloudCompare or
> Potree are great to visualize point clouds, we are IMHO still missing
> integration with a proper GIS, which would open many new possibilities
> and make point cloud data more accessible to ordinary GIS users.
>
>
> Point cloud visualization in QGIS would be an excellent addition, but as
> you discuss, it would be a heavy lift.
>
> 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.
>
> The next thing is
> how to deal with rendering. From what I understand, CloudCompare reads
> the whole point cloud file into memory and builds an in-memory octree
> which is then used for data access. Potree needs the data to be
> pre-processed beforehand with PotreeConverter tool into an octree, its
> nodes are then stored in files and requested as needed. Entwine does
> similar indexing, with a different file format. So it seems that it
> would be nice to cover both cases:
>
>
> Everyone that renders data pre-processes it into something more suitable
> for visualization. Entwine supports keeping all attributes, to full depth,
> with the option of preserving original data ordering. The encoding of the
> data can be LAZ or Zstd-compressed blobs, but other encodings could be
> trivially added. Entwine also supports "addons"
> https://pdal.io/stages/writers.ept_addon.html that can be used to enrich
> per-point attributes without disrupting the existing tree. This is needed
> for situations where the original data is remote (say usgs.entwine.io for
> USGS 3DEP holdings), but you want to locally process/classify/enhance data.
>
> It will probably be a long run to make the point cloud visualization
> look good - splatting, dynamic point sizing, eye-dome lighting and
> possibly more features already supported by Potree / CloudCompare.
>
>
> It has been my observation that point cloud rendering features radiate
> most quickly out of Potree into the other softwares. This includes
> implementations of EDL, dynamic sizing and fill approaches, and the frustum
> culling approach.
>
>
> I don't want to make this mail too long - at some point I will try to
> prepare a QGIS Enhancement Proposal (QEP) with more details. I would
> be very grateful for any comments and suggestions, where do you see
> possible issues, where else to look for some inspiration etc.
>
>
> I'm excited to see movement toward PDAL's usage in QGIS. As you embark on
> the process of its development, don't hesitate to ask questions and for
> things you might need. 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.
>
> Howard
>
> _______________________________________________
> pdal mailing list
> pdal at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/pdal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20200706/6ce70fac/attachment.html>