[GRASS-dev] s.cellstats replacement for GRASS 6

Hamish hamish_nospam at yahoo.com
Sat May 27 02:09:20 EDT 2006


Hi,


LIDAR & swath bathymetry people [3million+ input points]: I have an
idea for a s.cellstats replacement. Will call it r.in.xyz (name is from
a 2001 wish by Roy Sanderson). Output map options will be the same as
r.univar.

The module will be quite memory intensive - for most stats binning into
a 10000x10000 region will take ~800mb RAM for a CELL,FCELL map & 1.6gb
for a DCELL. Simple stats (min,max,n,sum) would take half that amount.

A low memory option could cut complex stats memory requirements in half
(e.g. for parameter=mean do in two passes, first write "n" .tmp map to
disk before populating "sum" in a second pass). Another idea to save
memory is to cut the region up into segments and process the data in
multiple passes. I blindly guess that the second method is more
efficient.

There'll be a test for z-range so the module can be used iteratively to
build 3D raster slices (for r.to.rast3). Same memory/segment stratagem
could be employed to populate a 3D raster in multiple passes of a single
call to the module.

The gist is to read in a line, test if the point is in the region
bounds, then use column = int((input_x - west) / ew_res), row=same; to
figure which cell to increment. Finally write out raster as f(a[,b]),
row by row.

Maybe the existing s.cellstats code is more efficient than my brute
force way of keeping whole output map components in memory? The old
sites format isn't too far from ascii x,y,z, so if s.cellstats is
clearly a better method, maybe it is better to adapt that instead?
No idea.


Hamish




More information about the grass-dev mailing list