[pdal] Reading only specific fields from LAS files to improve performance.

[Andrew Bell]

On Mon, Mar 22, 2021 at 9:22 AM Leona Swift <leonaswift80 at gmail.com> wrote:

> Thanks,
>
> Is it true to say that the code is still trivial when supporting up to,
> e.g. LAS/LAZ 1.4 with all the compression variants commonly seen? I see
> many examples of simple LAS 1.2, uncompressed file reading (and have one
> here which works fine, and as you say the code is trivial.) I'm worried
> about the number of variants of LAZ a production system will encounter in
> practical use when consuming data from many vendors, which is the current
> reason for using PDAL.
>

My comment about the triviality of reading XYZ from a LAS file applies only
to LAS, not LAZ.


> I agree that theoretically, code to rapidly pull XYZ points out of a
> binary file sounds trivial, but am a little scared about going that route
> in case it ends up taking 3 months to test all the variants of file
> encoding, and it's tricky when looking at a general binary file spec to
> know how rigidly all data will adhere to that spec in practice. Is there a
> good example of such code somewhere else on the internet that we can look
> at?
>

To read XYZ from a LAS file, you need to know only the offset to the first
point and the point data size. It really is trivial. If data doesn't
conform, it's unreadable.

If you need to read LAZ, and don't want to use PDAL, you can use lastools
or lazperf directly.  Lazperf will soon be released with support for point
types 6-8. lastools supports the ability to decode only XYZ for point
formats 6-10. lazperf should support the same before long.

If you're having performance issues with PDAL, I'd be interested to know
what you're trying to do. Most of the time incurred when reading LAS data
with PDAL is copying the data into memory. With LAZ, the decompression is
quite expensive, as well and there's no getting around that.

Best,

-- 
Andrew Bell
andrew.bell.ia at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20210322/28823b64/attachment.html>