Mark wrote:
> The points are about 5 million per tile, and there are 23 tiles (about
> 115 million total). I'm not sure if this is considered a large amount
> of mass input points.
Yes, it's a lot. The current vector engine allocates a small amount of
memory per feature for topology. With the DBF as database and default
v.in.ascii settings I've only ever managed to import about 3 million
points before running out of memory. I am interested to hear that you
could load 5 million into a SQLite DB, maybe that is more efficient.
With the v.in.ascii -t and -b flags you should be able to load 25million+
points into a single vector map, but there is a limited number of modules
that will be able to use a vector map without topology. (importantly
v.surf.rst still works)
If you are willing to abandon your "code" data column, you can strip off
that column and import the rest as a 3D vector (-z z=), in which case no
table is created (or just ignore it with -t -z). If you are just
interested in the 3D coordinate, then a DB table is unneeded overhead and
is best skipped.
Question: what do you want to do with the data? Simply create a raster
DEM or do more fancy cleaning with v.lidar.*? If just creating a raster
DEM you might skip v.in.ascii altogether and use the r.in.xyz module.
Hamish
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
