[pdal] Migrating from libLAS

[Vaclav Petras]

On Tue, Sep 1, 2015 at 11:28 PM, Andrew Bell <andrew.bell.ia at gmail.com>
wrote:
>
> On Tue, Sep 1, 2015 at 9:53 PM, Vaclav Petras <wenzeslaus at gmail.com>
wrote:
> > Hi all,
> >
> > 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.
> >
> > 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.
>
> The short answer is yes, this is what you're doing.  There is a
> callback in some readers that handle point-at-a-time semantics, but
> it's much easier to do what you're doing.

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.

> >  It also seems that all points are loaded in the memory, should I then
check some limitations or
> > add some error handling?

> Note that PDAL's design is different than libLAS because it's not just
> a LAS reader.

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.

> You can use the callback mechanism (setReadCb) along
> with a custom PointTable (derived from BasePointTable) to do your own
> thing if that's what you want.  We built this to allow people to read
> the data without actually storing it in PDAL-allocated memory.

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).

>
> On your transition guide:
>
> Point validity: there is no such concept
>
> hasColor: determines whether the LAS dataformat_id supports RGB
> hasDim(Id::Red): determines whether the dimension Red was registered
> with PDAL.  If all you're doing is reading LAS, hasColor() should be
> true when hasDim(Id::Red) is true.
>
> Memory management: PDAL generally takes care of itself.  In your
> example you allocate a reader on the heap, but it can be stuck on the
> stack just as well.  There are no hard requirements on this.

Thanks, I'll make some improvements and pull request hopefully soon.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20150902/7b32bd35/attachment.html>