<div dir="ltr">Does this mean that with the new version of r.in.lidar using pdal that the file size that can be read in will be limited by the amount of memory on my computer?<div><br></div><div> I currently use r.in.lidar with liblas and can process aggregated las files with up to 4.2 billion points with memory usage limited by the amount of map in memory parameter. ( The type of the analysis cell size and extent also affect memory usage)  </div><div><br></div><div>The current lidar data sets I have for eastern North Carolina have a point density of 2 points / meter  ( USGS QL2) , or about 6-10 billion points per county.  The next phase of data collection for North Carolina ( foothills) will be delivered at 8 points per meter ( USGS QL 1) .  The technology can deliver up to 100 points per meter.  </div><div><br></div><div>Would continuing to keep all the points for a file in memory lead to smaller and smaller physical tile sizes as point densities increase?</div><div><br></div><div>I was hoping that the move to pdal would allow a move to las 1.4 format with more points per file than 4.2 billion to reduce having to deal with tile edge effects.</div><div><br></div><div>Or is it  too early in the morning and my caffeine hasn't kicked in yet and I'm not seeing something obvious?</div><div><br></div><div>Doug </div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 1, 2015 at 10:53 PM, Vaclav Petras <span dir="ltr"><<a href="mailto:wenzeslaus@gmail.com" target="_blank">wenzeslaus@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>Hi all,<br><br></div>I'm porting GRASS GIS's r.in.lidar module [1] (which is using libLAS) to PDAL and I think I can write a migration guide. Do you think it should go to the docs? If yes, where? You can view the current state in my fork [2]. Unfortunately, it is transitioning from libLAS's C API to PDAL C++ API since r.in.lidar is using the C API.<br><br>I have several questions/TODOs in file [2] (feel free to review them). However, now I would like to ask about iterating over the points in the dataset. I do it in the way that I call execute on the reader and then I iterate over points in PointView. It seems to me that I'm going over the dataset two times, one reading and then my writing instead of just reading and writing at the same time as in case of libLAS API. It also seems that all points are loaded in the memory, should I then check some limitations or add some error handling?<br><br></div><div>Thanks,<br></div><div>Valcav<br></div><div><br></div><div>PS: I'm also working on extending FAQs on that topic [3].</div><div><div><div><br>[1] <a href="https://trac.osgeo.org/grass/browser/grass/trunk/vector/v.in.lidar/main.c" target="_blank">https://trac.osgeo.org/grass/browser/grass/trunk/vector/v.in.lidar/main.c</a><br>[2] <a href="https://github.com/wenzeslaus/PDAL/blob/liblas-to-pdal-transition/doc/tutorial/liblas_to_pdal.rst" target="_blank">https://github.com/wenzeslaus/PDAL/blob/liblas-to-pdal-transition/doc/tutorial/liblas_to_pdal.rst</a><br>[3] <a href="https://github.com/wenzeslaus/PDAL/blob/liblas-to-pdal-transition/doc/faq.rst" target="_blank">https://github.com/wenzeslaus/PDAL/blob/liblas-to-pdal-transition/doc/faq.rst</a><br></div></div></div></div>
<br>_______________________________________________<br>
pdal mailing list<br>
<a href="mailto:pdal@lists.osgeo.org">pdal@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/pdal" rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/pdal</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Doug Newcomb</div><div>USFWS</div><div>Raleigh, NC</div><div>919-856-4520 ext. 14 <a href="mailto:doug_newcomb@fws.gov" target="_blank">doug_newcomb@fws.gov</a></div><div>---------------------------------------------------------------------------------------------------------</div><div>The opinions I express are my own and are not representative of the official policy of the U.S.Fish and Wildlife Service or Dept. of the Interior.   Life is too short for undocumented, proprietary data formats.</div></div>
</div>