[GRASS-dev] Re: [GRASS-user] LiDAR LAS import
Hamish
hamish_b at yahoo.com
Wed May 25 10:02:30 EDT 2011
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
More information about the grass-dev
mailing list