[GRASS-dev] Re: [GRASS-user] updating kriging modules for grass 62
Roger.Bivand at nhh.no
Wed Nov 29 05:51:48 EST 2006
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
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".
> 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.
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
More information about the grass-dev