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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
