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

David Finlayson david.p.finlayson at gmail.com
Sat May 27 02:51:23 EDT 2006


FYI. GMT implements several important filters for XYZ data that GRASS
lacks, for example binning data into a raster (be various means) grid
prior to actually importing the data. In some cases these can
substantially decrease the processing time of griding operations as
well as remove aliasing problems associated with some data set/griding
algorithm combinations.

A module like you suggest might benefit from some of these prefilters.
See the manual pages for GMT for FILTERING OF 1-D AND 2-D DATA at the
top of the GMT man pages:

http://gmt.soest.hawaii.edu/gmt/gmt_man.html



On 5/26/06, Hamish <hamish_nospam at yahoo.com> wrote:
> 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
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>


-- 
David Finlayson




More information about the grass-dev mailing list