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

[Hamish]

me:
> I have an idea for a s.cellstats replacement. Will call it r.in.xyz
> [...] Output map options will be the same as r.univar.

David:
> 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.

Which is essentially s.in.ascii + s.cellstats + s.to.rast in GRASS 5.

So existing work arounds include "use GRASS 5", use GMT xyz2grd software
mentioned above & import GMT NetCDF to GRASS with r.in.gdal, and GRASS
s.to.rast2 add-on/LDART tool as mentioned by Helena. I guess there is a
solution using R-stats as well?


David:
> 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

I'll have a look, thanks.


Helena:
> s.cellstats inputs and outputs a site file,

technically, yes; but as s.cellstats output is gridded data preformed
for s.to.rast input, the s.to.rast step was implied.

> what you are proposing is supposed to read an ascii x,y,z and output a
> raster file?

yes. s.in.ascii + s.cellstats + s.to.rast in one step.


> If that is true, you may want to look also at s.to.rast2 in GRASS
> Add-ons: http://grass.itc.it/outgoing/

will do.

> (it includes an option to include data from surrounding cells, so if  
> there are small holes in data, they can be filled-in).

For r.in.xyz, I think this is best left to r.neighbors & r.fillnulls.
Will you lose data resolution that way? I have not done the algebra to
check, but guess for the simple stats you will not. I guess you could
weight result due to uneven "n" in surrounding cells for average calc.


> I have used s.to.rast a lot with lidar data or the binning option  
> that provides the on-line LDART tool (http://ekman.csc.noaa.gov/TCM/)
> and I miss it a lot in GRASS6.

A more s.cellstats-like alternative could be a v.in.xyz.grid module,
which culls vector points to a grid ready for v.to.rast. Advantage is
access to advanced stats that s.cellstats has but r.univar does not, and
each point could have full stats as 7-10 attribute columns. This could
even be a -v flag from r.in.xyz. I'd rather the solution be that
r.univar get advanced stats support (median,..) from new library fns &
we could reuse the method in r.in.xyz. Note v.in.ascii memory limit is
much smaller than r.in.xyz (single-pass) memory limit. (~ 1750^2 grid vs
~ 10000^2 grid)


> Your suggestion to go directly from ascii points to raster would get
> around the problems that the current vector support has with large
> data sets 

That is the motivation & idea.


> (otherwise I would have suggested to do v.in.ascii and add this to
> v.to.rast so that attributes can be used instead of z as well).

I don't dispute the general need, but in practice the only massive point
dataset I can think of with more than x,y,z is sonar signal strength.
If there was a need the r.in.xyz module could have xcolumn= ycolumn=
zcolumn= parameters so 4th+ column could be used as z to make the
raster. Non-numeric + non-categorical attributes for that many input
points will have to be left for the future.



Hamish