[pdal] Migrating from libLAS

Andrew Bell andrew.bell.ia at gmail.com
Wed Sep 2 07:24:05 PDT 2015


There is an example in PointViewTest.cpp called userView that shows
how you might implement a custom PointTable and callback.  It
allocates no memory other than a bit for each field.  There are lots
of options on how you might do this.

On Wed, Sep 2, 2015 at 9:15 AM, Andrew Bell <andrew.bell.ia at gmail.com> wrote:
> On Wed, Sep 2, 2015 at 8:39 AM, Vaclav Petras <wenzeslaus at gmail.com> wrote:
>>
>> On Wed, Sep 2, 2015 at 8:15 AM, Newcomb, Doug <doug_newcomb at fws.gov> wrote:
>>>
>>> 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?
>>>
>>>  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)
>>
>>
>> I meant v.in.lidar, sorry for confusion. But what you are saying applies
>> even more for v.in.lidar. It always holds in memory just one point as it
>> doesn't combines the points in any way. There might be some issues on GRASS
>> site like counting the points but that's a different story.
>
> If you're only using PDAL to read the data from LAS as in your example
> code, then using the callback mechanism and a custom PointBuffer will
> result in less memory usage and faster run times.  I thought there was
> a good example around, but I don't see it, so I'll write one.
>
> PDAL is slower than the libLAS when all you're doing is reading data.
> We've spent quite a bit of time looking at this, and have squeezed
> most of what we think we can out of it without changing the
> architecture.  PDAL isn't intended to be a super-fast LAS reader.
> It's made for doing analysis work and handling multiple types of
> input/output datasets.  Most of the the time difference you see
> between libLAS and PDAL isn't iteration, but data copying.  You can
> iterate the data very quickly on most modern computers with sufficient
> memory.
>
> Note that PDAL will do a bunch of the work that you're doing in your
> code for you.  You can filter based on geometry, do reprojection,
> perform classification filtering, etc., without writing code or
> writing much less than what you have done.  It will be somewhat slower
> than your own code if all you're doing is reading the data and
> throwing it away after doing some calculations, but you don't have to
> write the code :)
>
> --
> Andrew Bell
> andrew.bell.ia at gmail.com



-- 
Andrew Bell
andrew.bell.ia at gmail.com


More information about the pdal mailing list