[GRASS-dev] adding lib_arraystats

Dylan Beaudette dylan.beaudette at gmail.com
Tue Feb 12 20:19:35 EST 2008


On Tuesday 12 February 2008, Glynn Clements wrote:
> Dylan Beaudette wrote:
> > However-- this is starting to get into the realm of feature bloat...
> > As neat as it would be to have R routines which could work directly on
> > GRASS data structures, it might be overkill considering the possible
> > amount of work. I'll keep checking around and post back other ideas.
> >
> > On the other hand-- R has so many great plotting / analysis routines,
> > it would be a shame to re-implement these in GRASS if they could be
> > easily "plugged-into" via some kind of share library / SWIG
> > interface.

Thanks for the follow-up Glynn.;

> Another concern is that it could discourage development of new
> functionality in GRASS itself. In the worst case, GRASS could end up
> of little use unless you are familiar with R, and your map fits into
> memory.
>
> This is similar to my concerns regarding the use of high-level Python
> libraries in the GUI suppressing development of more widely-applicable
> display modules.
>
> External tools should be used to augment GRASS functionality, not to
> replace it.

I agree completely-- just as long as we don't go overboard re-inventing the 
wheel.

> That isn't to say that we shouldn't facilitate integration with tools
> such as R. Certainly, I would prefer R integration to adding our own
> half-baked statistics package. But we also need to avoid delegating
> "core" functionality to external packages.
>
> What would be particularly useful is if it's possible for GRASS to use
> R functions on small amounts of data. E.g. r.series and r.resamp.stats
> both compute aggregates over relatively small amounts of data.

This is essentially what I had in mind when I first posted the suggestion-- 
using R code on simple arrays of data.

> If it was practical to have e.g. "r.series method=R expression=...",
> that would be much more useful than having to start R and load
> potentially hundreds of rasters into memory.

Right-- the "not-in-memory" features of GRASS are extremely valuble.

> r.resamp.stats only works on a single map, but as it's essentially a
> down-sampling tool, it's not unreasonable to use it on very large
> input maps.

I like this idea. Use of a trimmed mean or other such R specialty would be 
very nice here.

Dylan


-- 
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341


More information about the grass-dev mailing list