<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)<br></div>- To access all the LAS points on an area (when zooming to the layer)<br></div>- To access a single LAS point (info by point)<br></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><br>As LAS files can be sometimes huge, I am specially worried about PDAL reading/writing strategies. Does a <span class="">las_reader</span><span class="">.</span><span class="">execute</span><span class="">(</span><span class="">table</span><span class="">) (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><br></span></div><div><span class="">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></span><br>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><br>Thank you very much for the documentation pointers and ideas, the "libLAS C API to PDAL transition guide" is very useful.<br><br></div><div>César Martínez<br></div></div><div><div><div><br><div><div><div><br></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 15 April 2016 at 18:14, Andrew Bell <span dir="ltr"><<a href="mailto:andrew.bell.ia@gmail.com" target="_blank">andrew.bell.ia@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 class="gmail_extra"><div class="gmail_quote"><span class="">On Fri, Apr 15, 2016 at 4:06 AM, 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></span><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>Dear list,<br><br></div></div></div></div></div><span class=""><div>The "Writing with PDAL" tutorial [<a href="http://www.pdal.io/tutorial/writing.html" target="_blank">http://www.pdal.io/tutorial/writing.html</a>] gives me some light on the writing part, but I still don't see if it really matches our use case. If I correctly understand the tutorial, you have to first create a PointTable and a PointView, which I guess are created on-memory.<br><br>Is there a way to "stream" the points to the writer? Otherwise I believe this approach is not feasible for writing big LAS files. Would be possible to create the writer on "append" mode and to feed it with several PointViews on a loop for instance?. Will this approach perform well or is there a better way to do it?<br></div></span></div></blockquote><div><br></div><div>As was mentioned, you can stream points to the writer with LAS depending on what other processing you might want to do. When you call execute(), just pass a FixedPointTable instead of a PointTable. Unless you are memory-limited, it's not likely to amount to a huge performance improvement, though.</div><div><br></div><div>You really need to be specific about your needs to allow us to provide you good information. It's best to write a little code and not make to make too many assumptions about problems before you start.</div><div><br></div><div>Best,</div><div><br></div><div>--</div></div><div>Andrew Bell<br><a href="mailto:andrew.bell.ia@gmail.com" target="_blank">andrew.bell.ia@gmail.com</a></div>
</div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -<br> César Martínez Izquierdo<br> GIS developer<br> - - - - - - - - - - - - - - - - - - - -<br></div><div> SCOLAB: <a href="http://www.scolab.es" target="_blank">http://www.scolab.es</a><br></div><div>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -</div></div></div></div>
</div>