Adrian wrote:
I have LiDAR data in ASCII txt files with only X, Y and Z
coordinates, which I want to import and create DEM models
from in GRASS. I'm new to this kind of data processing.
--> see http://grass.osgeo.org/wiki/LIDAR
r.in.xyz + r.surf.nnbathy is my favorite combo for this, but
then, I'm biased. 3.5M points should run in a few seconds.
(r.surf.nnbathy from the wiki AddOns page)
The choice between v.in.ascii and r.in.xyz really depends on if
you want to do full analysis on the point cloud or just make a
fast DEM from an already cleaned x,y,z set.
3.5M points is on the limit of the number of vector points you
can work with in GRASS 6 with full topology and database tables
unless you have a computer with lots of RAM. (thus options to
disable first database creation and second topology)
Hamish
Le 2013-05-02 23:57, Hamish a écrit :
3.5M points is on the limit of the number of vector points you
can work with in GRASS 6 with full topology and database tables
unless you have a computer with lots of RAM. (thus options to
disable first database creation and second topology)
Hi Hamish,
Then what would be the limit for grass7 with 4gb of ram, no topology/database ? Can it handle billions of points ?
jr.morreale wrote:
Then what would be the limit for grass7 with 4gb of ram, no
topology/database ? Can it handle billions of points ?
I don't really know to be honest. Try the experimental approach
and keep an eye on `top`, and let us know the results. 
See the
grass wiki FAQ for a hint on adding temporary swap space on Linux
if you need it.
r.in.xyz can handle many billions of points without trouble for
non-exotic statistical aggregations; memory use there is more a
matter of raster region size and you can do multi-pass if memory
is an issue on a really really huge region.
Hamish
On 05/03/2013 01:18 PM, Hamish wrote:
jr.morreale wrote:
Then what would be the limit for grass7 with 4gb of ram, no
topology/database ? Can it handle billions of points ?
In my experience, it can (even GRASS 6), if:
a) you rasterize the input data directly (r.in.xyz,
as suggested by Hamish).
b) your file system supports files > 4GB (which really
just about anything except a VFAT formatted USB drive
should these days)
and
c) (in case you want to export the results for use
with another GIS) your GDAL has a GeoTIFF driver
that has 64 bit BigTIFF support enabled.
To save storage space, use single precision
floating point data if you can.
Best,
Ben
I don't really know to be honest. Try the experimental approach
and keep an eye on `top`, and let us know the results. See the
grass wiki FAQ for a hint on adding temporary swap space on Linux
if you need it.
r.in.xyz can handle many billions of points without trouble for
non-exotic statistical aggregations; memory use there is more a
matter of raster region size and you can do multi-pass if memory
is an issue on a really really huge region.
Hamish
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
benducke@fastmail.fm
On Fri, May 3, 2013 at 1:18 PM, Hamish <hamish_b@yahoo.com> wrote:
jr.morreale wrote:
Then what would be the limit for grass7 with 4gb of ram, no
topology/database ? Can it handle billions of points ?
Yes:
http://grasswiki.osgeo.org/wiki/GRASS_GIS_Performance#Vector_geometry
"In all GRASS GIS versions,
* with topology the feature limit is at time 2^31 - 1 (about 2
billion) features per vector map.
"
But you can disable topology to be build when importing:
v.in.ascii -b
Do not build topology in points mode
See for more details: http://grass.osgeo.org/grass70/manuals/v.in.ascii.html
TODO: understand the limit when using the -b flag.
Markus
Hello Hamish and Mark,
This way is a lot more easy! Probably it would take me a lot of time to find it myself
Thank you for the help and keep doing the good job for GRASS and the community!
Greetings,
Adrian Kirilov
···
On Thu, May 2, 2013 at 11:57 PM, Hamish <hamish_b@yahoo.com> wrote:
Adrian wrote:
I have LiDAR data in ASCII txt files with only X, Y and Z
coordinates, which I want to import and create DEM models
from in GRASS. I’m new to this kind of data processing.
→ see http://grass.osgeo.org/wiki/LIDAR
r.in.xyz + r.surf.nnbathy is my favorite combo for this, but
then, I’m biased. 3.5M points should run in a few seconds.
(r.surf.nnbathy from the wiki AddOns page)
The choice between v.in.ascii and r.in.xyz really depends on if
you want to do full analysis on the point cloud or just make a
fast DEM from an already cleaned x,y,z set.
3.5M points is on the limit of the number of vector points you
can work with in GRASS 6 with full topology and database tables
unless you have a computer with lots of RAM. (thus options to
disable first database creation and second topology)
Hamish