[GRASS-dev] adding lib_arraystats

[Glynn Clements]

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.

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.

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.

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.

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.

-- 
Glynn Clements <glynn at gclements.plus.com>