<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Apr 15, 2016 at 12:01 PM, César Martínez Izquierdo <span dir="ltr"><<a href="mailto:cesar.izq@gmail.com" target="_blank">cesar.izq@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div><div><div></div>Regarding our needs, the library would be used on a desktop GIS software (gvSIG), so the use cases are quite diverse. We would implement a LAS data provider for our own framework, this provider would be internally based on PDAL.<br><br></div>Therefore, typical usages could be:<br></div>- To access all the LAS points on a sequential way (to draw the layer) </div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div></div>- To access all the LAS points on an area (when zooming to the layer)<br></div></div></div></div></blockquote><div><br></div><div>This just isn't possible.  The LAS format doesn't provide a spatial index.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div></div>- To access a single LAS point (info by point)<br></div></div></div></blockquote><div><br></div><div>This is an unusual requirement for point clouds.  There isn't usually much information in a single point.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div></div><div>- To write a new LAS file, the input of which could be any other point layer loaded on our GIS software (including another LAS/LAZ file but it could also be Shapefiles for instance). Note that because we have our own abstraction layers, we will not be able to directly use a PDAL reader as the input of a pipeline in this case (although we might create a custom reader that wraps our gvSIG data providers)<br></div></div></div></blockquote><div><br></div><div>You just need to put your data into a PDAL PointTable (usually using a PDAL PointView) and then PDAL can write the data.  There are fancier things that can be done that require more code on your part.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>As LAS files can be sometimes huge, I am specially worried about PDAL reading/writing strategies. </div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div> Does a <span>las_reader</span><span>.</span><span>execute</span><span>(</span><span>table</span><span>) (as shown on the libLAS to PDAL tutorial) load the full file on-memory? Or does it load blocks on demand when you actually request one point to the ViewSet?<br></span></div></div></div></blockquote><div><br></div><div>There are no blocks in a LAS file.  Points in LAS files may be in any order whatsoever and there is no spatial index, which is why reading all points is usually the only solution.  This is a limitation of the file format and not PDAL.  Many people break large files into geographically-based subfiles, or tiles, but then you're just reading smaller LAS files and have to do your own organization and preprocess the data.  Some people use PDAL to read points from a LAS file and place them in a database that supports spatial indexing, like Postgres, SQLite or Oracle.  HOBU also has a level-of-detail indexed format readable through PDAL that can be used by visualization which you might want to consider, but it's not directly reading points from LAS.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>If everything is read on-memory, the I guess we'll need to limit the number of loaded points, but at the same time it would probably simplify the implementation of our data provider.<br></div></div></div></blockquote><div><br></div><div>You can limit memory consumption by streaming points, as mentioned earlier.  If you can use the data directly from PDAL's PointTable/View for visualization streaming won't buy you anything since you need to store the data somewhere anyway.  However, most people doing visualization software need to load the data on a graphics card so using PDAL's buffer doesn't make sense.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Our software (gvSIG) is written in Java, so using PDAL means writing 
some Java-C++ bindings, that's why we want to carefully assess if PDAL 
fits our needs before actually implementing anything. I was (probably 
wrongly) feeling that libLAS could better suit our needs, but I am aware
 PDAL is much more active nowadays.<br></div></div></div></blockquote><div><br></div><div> Let us know if you have more questions.</div></div><div><br></div>-- <br><div class="gmail_signature">Andrew Bell<br><a href="mailto:andrew.bell.ia@gmail.com" target="_blank">andrew.bell.ia@gmail.com</a></div>
</div></div>