[GRASS-dev] Re: [GRASS-user] updating kriging modules for grass 62

[Roger Bivand]

On Wed, 29 Nov 2006, Moritz Lennert wrote:

> On 28/11/06 09:32, Benjamin Ducke wrote:
> > I would also expect a lot of statistical modules in the
> > future to depend on R, seeing how powerful the R
> > spatial analysis stuff is.
> > There are so many useless dependencies in GRASS (Motif,
> > BLAS, LAPACK,...), so why not add one that is actually very
> > useful for a lot of people?
> 
> Are you thinking about using the Mathlib of R within GRASS C-code, or of 
> calling R commands from within GRASS modules or scripts ?
> 
> How easy is it to call fonctions from R libraries in non-R code ?
> 
> > Or even better: why not include an up-to-date R shell and
> > the best spatial stat libraries in the GRASS base
> > distribution to make it easier for everyone to add
> > powerful spatial statistics modules to GRASS and use them
> > out-of-the-box?

It isn't obvious how to do this in a clean and easily maintainable way. R 
and the associated spatial packages are quite large, and perhaps ought to 
be installed by users themselves when needed (understood as for use 
running the R command line within GRASS and with the interface as an R 
package). 

On the other hand, an optional GRASS "module" might involve downloading 
and installing R components in GRASS (under scripts, share, whatever), 
where the R command line is not visible, and R is a compute engine behind 
GRASS front-end(s). Now we have scripts in the Wiki, but the suggestion 
that started this thread was to formalise them. In a medium-term future, 
I'd see a place for the R engine being available as an *.so or *.DLL, 
probably accessed from Python on the GRASS side through Rpy, although C 
could also be used to pass in commands.

The maintenance aspect is important - the R engine "steps" twice a year, 
and contributed packages - where the functionality is - can be updated 
very frequently, sometimes with incompatibilities in function argument 
names and types, updates triggered by bug reports and enhancement 
requests. In making choices, getting the maintenance/update mode right 
would be very important. 

The Lausanne LiveCD worked very nicely because of a lot of hard work done 
by the team who put it together, including R and its packages in 
predictable places. It can be done, but I think the alternatives need 
thinking through. I'm a bit reserved about having GRASS depend on R, and 
until there is more experience with shell scripts handing computation off 
to R would prefer not to "weld down the hood/bonnet".

Best wishes,

Roger

> 
> Well you can run an R shell within GRASS, so what exactly do you mean by 
> including one ?
> 
> > 
> > I think R is excellent quality code that runs on all major
> > OS's and has no dependencies itself.
> 
> I agree and as we are working on a C-version of d.vect.thematic, and 
> Roger referred me to R for potential relevant code, actually including R
> in the dependencies might makes things easier. At this stage I just 
> don't know enough of R internals to know what the best approach would be.
> 
> Moritz
> 

-- 
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand at nhh.no