On Thu, Jun 2, 2011 at 3:06 PM, isenburg <[email protected]> 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 _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
