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 <[email protected]> > To: Hamish <[email protected]> > Cc: grass-user <[email protected]>; GRASS developers list > <[email protected]> > Sent: Wednesday, 25 May 2011, 12:48 > Subject: Re: [GRASS-user] LiDAR LAS import > > On Wed, May 25, 2011 at 12:16 PM, Hamish <[email protected]> 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-user > > > > _______________________________________________ > grass-user mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-user > > _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
