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