[GRASS-user] LiDAR LAS import

[Markus Metz]

Rebecca Bennett wrote:
> Hello,
> Just trying to install GRASS 7 on Ubuntu 10.04 to try out the las import
> functions but I'm getting error messages during the configure that it is
> unable to find the liblas library, however the liblas library is installed
> in usr/bin/lib/ so I'm a bit puzzled...

Can you post the exact error message? Also, liblas support will only
be available if liblas-config exists.

Markus M

> Did anyone else get stuck here or am I missing something obvious?
> Thanks for reading,
> Rebecca
>
> ________________________________
> From: Markus Metz <markus.metz.giswork at googlemail.com>
> To: Hamish <hamish_b at yahoo.com>
> Cc: grass-user <grass-user at lists.osgeo.org>; GRASS developers list
> <grass-dev at lists.osgeo.org>
> Sent: Wednesday, 25 May 2011, 12:48
> Subject: Re: [GRASS-user] LiDAR LAS import
>
> On Wed, May 25, 2011 at 12:16 PM, Hamish <hamish_b at yahoo.com> wrote:
>> Markus Metz wrote:
>>> Hi all,
>>>
>>> GRASS 7 has a new module v.in.lidar for importing LiDAR LAS files
>>> (*.las or *.laz). The LAS file format is commonly used for storing
>>> LiDAR point clouds, but is unfortunately not supported by OGR.
>>> v.in.lidar uses the libLAS library [0] and is only compiled if the
>>> libLAS library is present.
>>>
>>> I chose to use the library instead of writing a custom LAS reading
>>> interface because the current LAS library version 1.6.1 is stable,
>>> 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. The
>>> user and the interface do not need to know the file version and point
>>> format of a given file, all that is conveniently handled by the libLAS
>>> library in the background. The library has Large File Support (LFS)
>>> and is well tested on different platforms, also with different
>>> endian-ness. This functionality is not that easy to replicate.
>>>
>>> You will need to get the libLAS library and configure GRASS 7 with
>>> --with-liblas in order to have the module available. Please test!
>>>
>>> Markus M
>>>
>>> [0] http://www.liblas.org
>>
>>
>> neat! any time trials to say how much faster it is than piping
>>  las2txt | v.in.ascii
>> ?
>
> 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 discovered a bug in v.in.ascii: from a point file with | as field
> separator like
>
> 1|2|3||5|6
>
> only the first 3 columns will be imported because column 4 is empty
> which means that columns 5 and 6 are skipped.
>
> v.in.lidar is a notch faster than las2txt | v.in.ascii. And easier to use...
> Speed comparisons:
>
> # sample las file with 1,287,775 points
>
> # 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
>
> real    6m34.430s
> user    4m57.530s
> sys    2m3.693s
>
> time v.in.lidar in=points.las out=points_las -o --o
>
> real    6m13.823s
> user    4m32.061s
> sys    2m1.068s
>
>
> # without table, with topology
> time las2txt -i points.las --stdout --parse xyz --delimiter "|" |
> v.in.ascii in=- out=points_ascii -zt x=1 y=2 z=3 --o
>
> real    1m53.578s
> user    1m47.032s
> sys    0m9.238s
>
> time v.in.lidar in=points.las out=points_las -ot --o
>
> real    1m44.876s
> user    1m34.450s
> sys    0m8.488s
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>
>
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>