<div dir="ltr"><div><br><br>On Tue, Sep 1, 2015 at 11:28 PM, Andrew Bell <<a href="mailto:andrew.bell.ia@gmail.com">andrew.bell.ia@gmail.com</a>> wrote:<br>><br>> On Tue, Sep 1, 2015 at 9:53 PM, Vaclav Petras <<a href="mailto:wenzeslaus@gmail.com">wenzeslaus@gmail.com</a>> wrote:<br>> > Hi all,<br>> ><br>> > I'm porting GRASS GIS's r.in.lidar module [1] (which is using libLAS) to<br>> > PDAL and I think I can write a migration guide. Do you think it should go to<br>> > the docs? If yes, where? You can view the current state in my fork [2].<br>> > Unfortunately, it is transitioning from libLAS's C API to PDAL C++ API since<br>> > r.in.lidar is using the C API.<br>> ><br>> > I have several questions/TODOs in file [2] (feel free to review them).<br>> > However, now I would like to ask about iterating over the points in the<br>> > dataset. I do it in the way that I call execute on the reader and then I<br>> > iterate over points in PointView.  It seems to me that I'm going over the<br>> > dataset two times, one reading and then my writing instead of just reading<br>> > and writing at the same time as in case of libLAS API.<br>><br>> The short answer is yes, this is what you're doing.  There is a<br>> callback in some readers that handle point-at-a-time semantics, but<br>> it's much easier to do what you're doing.<br><br></div>It's easier but apart from the potential memory limits, it also seems that it is slower. I don't have a exact benchmark yet but it seems that the libLAS-based v.in.lidar is faster than the PDAL-based one. It makes sense as they does the same but in addition to it PDAL allocates the memory and we iterate over points two times.<br><div><br>> >  It also seems that all points are loaded in the memory, should I then check some limitations or<br>> > add some error handling?<br><br>> Note that PDAL's design is different than libLAS because it's not just<br>> a LAS reader.<br><br></div><div>I know that and I hope to use the advanced PDAL functions but the first step is to be able to use PDAL instead of libLAS in GRASS GIS without loosing any current features.<br></div><div><br>> You can use the callback mechanism (setReadCb) along<br>> with a custom PointTable (derived from BasePointTable) to do your own<br>> thing if that's what you want.  We built this to allow people to read<br>> the data without actually storing it in PDAL-allocated memory.<br><br></div><div>I will look at that. This looks like the thing we need for simple import to GRASS GIS (v.in.lidar) or binning (r.in.lidar).<br></div><div><br>><br>> On your transition guide:<br>><br>> Point validity: there is no such concept<br>><br>> hasColor: determines whether the LAS dataformat_id supports RGB<br>> hasDim(Id::Red): determines whether the dimension Red was registered<br>> with PDAL.  If all you're doing is reading LAS, hasColor() should be<br>> true when hasDim(Id::Red) is true.<br>><br>> Memory management: PDAL generally takes care of itself.  In your<br>> example you allocate a reader on the heap, but it can be stuck on the<br>> stack just as well.  There are no hard requirements on this.<br><br></div><div>Thanks, I'll make some improvements and pull request hopefully soon.<br></div></div>