[GRASS-user] LIDAR Data

GRASS GRASS user
1

Hello again,

yesterday it was the laser day:
we have obtained huge airborne laserscanner data, and want to try out the modules in GRASS.
after importing the xyz-data into vector-file we apply v.lidar.edgedetection
second step should be v.lidar growing. but it does not work

GRASS 6.3.cvs (Morbach):~ > v.lidar.growing input=morbach55156_edge@PERMANENT output=morbach55156_grow input_first=morbach55156 database=/home/seeger/Documents/GRASSDATA/Morbach/PERMANENT/dbf/ driver=dbf tj=0.2 td=0.6
dbmi: Protocol error
ERROR: It was impossible open table

well, this is the error I get. I dont know how to handle with this.

Any suggestions?

Another question. How many points can be handled with grass and these modules (or grass vector files in general)?

Manuel

(thanks for the first help with terrestrial laserscanning data, I will go deeper into this!)

--
please visit www.warela.eu
and participate:

WaReLa scientific conference on

Integrated catchment management
for hazard mitigation

September 24-26, 2007 in Trier, Germany
_______________________________________________________________________
Dr. Manuel Seeger
Wiss. Assistent Scientific Assistant
Physische Geographie Dpt. of Physical Geography
FB VI - Geographie/Geowissenschaften Geography/Geosciences
Universität Trier University of Trier
D - 54286 Trier
Tel.: +49-651-201 4557
Fax: +49-651-201 3976
Web: http://www.uni-trier.de/uni/fb6/geographie/mitarbeiter/Seeger/

2

Dr. Manuel Seeger wrote:

we have obtained huge airborne laserscanner data, and want to try out
the modules in GRASS.

..

Another question. How many points can be handled with grass and these
modules (or grass vector files in general)?

For vector point data loaded with v.in.ascii & the default settings you
can probably get up to ~1 million points before running out of memory.
(happens in the "building lines" step of building topology, watch memory
grow with `top`, M)

see the NOTES section,
http://grass.ibiblio.org/grass63/manuals/html63_user/v.in.ascii.html

The first thing you do can do to save memory is -t to skip creating a DB
table. If data is just x,y,z you don't need one, just use -z and make a
3D vector map. (no DB table is the default if no extra columns besides
xyz?) This will get you up to ~1 million(?) points before running out of
memory.

Next you could try the new (6.3 only) v.in.ascii -r flag to only import
points which are in the current region (area of interest). [g.region]

The final v.in.ascii flag to try is -b, which skips building topology
altogether. This means that the new vector can't be used for much, but
the max point limit becomes 25+ million (as high as Helena's has tested
I think). Then you start to get into LFS 2gb file size problems, ..?
While there isn't much you can do with a vector map without topology,
one important thing you can do is run v.surf.rst to make a surface.
It is hoped that v.surf.idw(2) and v.univar can be updated to work with
them as well.

The "other way" is to use r.in.xyz to create a raster directly from
the points. This is very fast and the only limit is from the LFS
issues, but I'd guess you could load 4gb of data without a problem.
It is hoped to one day update r.in.xyz to optionally read data from
stdin, in which case you can avoid and file system issues*. Then AFAIK
there would be no limit, as no file to open. LFS support is much better
for rasters than it is for vectors currently.

[*] would need to disable scan mode if input=stdin

http://grass.ibiblio.org/grass63/manuals/html63_user/r.in.xyz.html
http://hamish.bowman.googlepages.com/grassfiles#xyz

Hamish

3

Hamish wrote:

The "other way" is to use r.in.xyz to create a raster directly from
the points. This is very fast and the only limit is from the LFS
issues, but I'd guess you could load 4gb of data without a problem.
It is hoped to one day update r.in.xyz to optionally read data from
stdin, in which case you can avoid and file system issues*. Then AFAIK
there would be no limit, as no file to open. LFS support is much better
for rasters than it is for vectors currently.

[*] would need to disable scan mode if input=stdin

http://grass.ibiblio.org/grass63/manuals/html63_user/r.in.xyz.html
http://hamish.bowman.googlepages.com/grassfiles#xyz

missing tool: a future r3.in.xyz (or "r.in.xyz -3"?) to make a 3D raster
map?

Hamish