<div dir="ltr">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?<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>Luigi Pirelli<br><br>**************************************************************************************************<br>* LinkedIn: <a href="https://www.linkedin.com/in/luigipirelli" target="_blank">https://www.linkedin.com/in/luigipirelli</a><br>* Stackexchange: <a href="http://gis.stackexchange.com/users/19667/luigi-pirelli" target="_blank">http://gis.stackexchange.com/users/19667/luigi-pirelli</a><br>* GitHub: <a href="https://github.com/luipir" target="_blank">https://github.com/luipir</a><br>* Book: <a href="https://www.packtpub.com/eu/application-development/mastering-geospatial-development-qgis-3x-third-edition" target="_blank">Mastering QGIS3 - 3rd Edition</a></div><div>* Hire a team: <a href="http://www.qcooperative.net" target="_blank">http://www.qcooperative.net</a><br>**************************************************************************************************</div></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 6 Jul 2020 at 18:22, Howard Butler <<a href="mailto:howard@hobu.co">howard@hobu.co</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Jul 6, 2020, at 9:01 AM, Martin Dobias <<a href="mailto:wonder.sk@gmail.com" target="_blank">wonder.sk@gmail.com</a>> wrote:</div></blockquote><br><blockquote type="cite"><div><div>While the existing tools such as CloudCompare or<br>Potree are great to visualize point clouds, we are IMHO still missing<br>integration with a proper GIS, which would open many new possibilities<br>and make point cloud data more accessible to ordinary GIS users.<br></div></div></blockquote><div><br></div><div>Point cloud visualization in QGIS would be an excellent addition, but as you discuss, it would be a heavy lift.</div><br><blockquote type="cite"><div><div>So far it looks like it would be a good idea to use the PDAL library<br>for I/O - it supports a variety of formats through a common<br>abstraction which would make our life much easier. </div></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div><div>The next thing is<br>how to deal with rendering. From what I understand, CloudCompare reads<br>the whole point cloud file into memory and builds an in-memory octree<br>which is then used for data access. Potree needs the data to be<br>pre-processed beforehand with PotreeConverter tool into an octree, its<br>nodes are then stored in files and requested as needed. Entwine does<br>similar indexing, with a different file format. So it seems that it<br>would be nice to cover both cases:<br></div></div></blockquote><div><br></div><div>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" <a href="https://pdal.io/stages/writers.ept_addon.html" target="_blank">https://pdal.io/stages/writers.ept_addon.html</a> 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 <a href="http://usgs.entwine.io" target="_blank">usgs.entwine.io</a> for USGS 3DEP holdings), but you want to locally process/classify/enhance data.</div><br><blockquote type="cite"><div><div>It will probably be a long run to make the point cloud visualization<br>look good - splatting, dynamic point sizing, eye-dome lighting and<br>possibly more features already supported by Potree / CloudCompare.<br></div></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><br>I don't want to make this mail too long - at some point I will try to<br>prepare a QGIS Enhancement Proposal (QEP) with more details. I would<br>be very grateful for any comments and suggestions, where do you see<br>possible issues, where else to look for some inspiration etc.<br><br></blockquote><br></div><div>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. </div><div><br></div><div>Howard</div><br></div>_______________________________________________<br>
pdal mailing list<br>
<a href="mailto:pdal@lists.osgeo.org" target="_blank">pdal@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/pdal" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/pdal</a></blockquote></div>