[GRASS-user] Re: LiDAR LAS import

[isenburg]

hi mark,

great job. and thanks for supporting both LAS and LAZ.

>> supports LAS file versions 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, each of
>> which can store LiDAR points in up to 5 different point formats.

Just a minor correction. the supported LAS file versions range from 1.0 to
1.3. And yes, the 1.3 version can store LiDAR points in up to 5 different
point formats.

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

> # 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".

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?

Again, kudos for adding LAS and LAZ to GRASS. Wow ... that rhymes. (-:

Martin


--
View this message in context: http://osgeo-org.1803224.n2.nabble.com/LiDAR-LAS-import-tp6402014p6431063.html
Sent from the Grass - Users mailing list archive at Nabble.com.