[GRASS-user] Re: LiDAR LAS import

[Markus Metz]

On Thu, Jun 2, 2011 at 3:06 PM, isenburg <martin.isenburg at gmail.com> wrote:
>
>> Note that las2txt does NOT apply scale and offset to x,y,z, this would
>> need to be done afterwards in order to obtain correct coordinates.
>> Therefore the output of las2txt | v.in.ascii with the sample las file
>> I used is incorrect.
>
> I don't think this is true. Obviously you are using the las2txt version from
> libLAS but when libLAS branched off LAStools the scaling and offsetting was
> already correctly supported. If not, you could maybe compare the outputs of
> LAStools txt2las and libLAS txt2las and let Howard know if there is
> something wrong.
>
Found it, the libLAS documentation is wrong:
-->
LAS_DLL double LASPoint_GetX(const LASPointH hPoint)  	

Returns the X value for the point.

This value is not scaled or offset by any header values and stands on
its own. If you need points to have a scale and/or offset applied,
this must be done in conjunction with the header values after the
value is read.
<--

This not true, scale and offset are applied, I checked the libLAS
source code. I will fix v.in.lidar asap.

>> # with table and topology
>> time las2txt -i points.las --stdout --parse xyztinrcCpedRGBau
>> --delimiter "|" | v.in.ascii in=- out=points_ascii -z x=1 y=2 z=3 --o
>
> Why did you use this elaborate parse string when all you need is xyz? The
> temporary ASCII representation that goes through the pipe with parse string
> "xyztinrcCpedRGBau" will be several multiples the size of a parse string
> "xyz".

Because v.in.ascii will import all the other fields into an attribute
table, and I wanted to test that.

>
> I would have expected that the libLAS import module would be several times
> faster than piping route via temporary ASCII conversion. Is the reason that
> the ASCII translation costs are not bigger because you are running of a
> multi-core machine? Or maybe the built-in routines that I am using are much
> slower than yours. How do you do ASCII conversion?

It was a quadcore 64bit machine, and linux pipes are really fast. The
time goes into creating an attribute table and creating a spatial
index, not so much in reading the las (or laz) file.

Markus M