[GRASS-dev] Re: [GRASS-user] LiDAR LAS import

[Hamish]

Markus Metz 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 guess a v.transform step would be needed, with another hit of
rebuilding the topology.

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

roughly/quickly:
 echo "1|2|3||5|6" | v.in.ascii in=- out=gaptest
 v.db.select gaptest

GRASS 6.4.0+42329    bug
GRASS 6.5.svn45825M  no bug
GRASS 7.0.svn45737M  no bug

I'll try with latest svn in the morning.

perhaps this was fixed by the v.in.ascii last-row-is-empty bugfix
some months ago?


> v.in.lidar is a notch faster than las2txt | v.in.ascii. And
> easier to use...

I'm not too surprised the speed difference is not so huge, as
unix pipes are very efficient. but the easier to use thing is
very important.. both las2txt and v.in.ascii are a bundle of
command line switches to get right.


> Speed comparisons:
> 
> # sample las file with 1,287,775 points
> 
> # with table and topology
...
> real    6m34.430s
...
> real    6m13.823s
...
> # without table, with topology
...
> real    1m53.578s
...
> real    1m44.876s


I take it that without topology it runs in just seconds?
my RAID runs at ~300mb/sec. 1.3m points isn't pushing memory
limits into swap space. there's no real tough math happening
here, just moving bits around... me thinks it's time to break
out the profiling tools. aka why shouldn't this take less than
5 sec to run, even with no-op points topology + dbf creation?


Hamish