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

[Markus Metz]

On Wed, May 25, 2011 at 4:02 PM, Hamish <hamish_b at yahoo.com> wrote:
> 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.
>
Yes.

>> 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?
>
Weird. My local copy is a few hours old, my quick test case
"1|2|3||5|6" works, but not the stream coming from las2txt.
>
>> 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.
>
I would like to add more options, e.g. what columns to import, but
v.in.lidar works just fine with v.in.lidar in=in.las out=out_grass
>
[...]
>
>
> I take it that without topology it runs in just seconds?
Yes.
> 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?

I used sqlite, no idea how long it will take with dbf. And it is still
nearly 1.3 million points with attributes, las2txt produces a 94MB
ascii file. Reading can be done in 5sec, especially if the system has
already cached the file, but writing takes a bit longer.

For GRASS 7, I want to slim down vector topology some more, I guess
the import time could be reduced by half. There is a reason to have
some topology even for points: a spatial index which would make
spatial queries and selections much faster.

Markus M