[STATSGRASS] using R and gstat inside a C module

[Roger Bivand]

On Mon, 23 Oct 2006, G. Allegri wrote:

> Thanks Roger for the complete answer!
> I know it sounds quite strange what I'm trying to do, and maybe it
> isn't the best way to do it.
> What I meant to do is an interactive (through a GUI interface to
> develop) tool to elaborate hydrogeochemical datas about acquifer
> pollution defense. It should be used by an end-user as a Decision
> Support System tool. It will use raster and vector input data to be
> treated with mapalgebra and geostatisitcal analysis. The worst problem
> is that it should be, somehow, platform independent.

If platform-independent, then a client-server model with the client being 
a web browser looks attractive. In that case, I would look seriously at 
either MapServer (and Tyler Mitchell's book Web Mapping Illustrated) if 
most of the user interaction is in map form, or at Rpad:

http://www.rpad.org/Rpad/

Look at http://www.rpad.org/Rpad/InterruptionMap.Rpad

to see a very nice example. You'll need to look at load balancing 
carefully, but here the web server and R are running on the server, 
producing pages with Javascript for interaction for the user. A lot of the 
hard work has already been done, and because of the split between client 
and server, you can update the server-side compute engine without the user 
needing to install anything. 

I think this is as close as you can get - using embedded R will mean a lot 
more work, especially with maintenance. Note the comments on the Rpad site 
about security, you will need to run the server with care.

R can also be embedded within Apache, but I guess that Rpad is better for 
you. To be honest, it might well be worth paying someone with 
Javascript/Perl/Apache etc. experience to help, none of these are suitable 
for non-specialists if the server is to be kept secure, really, but the 
same applies to any client-server model running across the Internet.

Roger

> I'm not a professional programmer, I'm a geologist, and surely it
> would be easiar to work with scripting then C coding, but it gets
> harder to develop the "wizard" interface...
> In regard using R in an interactive way: I would like to "grep" simply
> the output (as standard output or ascii file) and  then use it for my
> purposes.
> Could you suggest me a way to implement this "stange" architecture?
> Giovanni
> 
> P.S.: I'm considering the web interface way too...
> 
> 
> 
> 2006/10/23, Roger Bivand <Roger.Bivand at nhh.no>:
> > On Mon, 23 Oct 2006, G. Allegri wrote:
> >
> > > I need to use R and gstat functionalities inside a module I'm writing.
> >
> > Why? What OS/platform? Unless you are doing something very peculiar, you
> > will waste an inordinate amount of time, where a shell script will get you
> > there simply and be several orders of magnitude easier to debug. Be aware
> > that R functions are often best used interactively because user choices
> > and error conditions do matter.
> >
> > > To embed R in a C program libRmath should be used.
> >
> > No, that is just to use the math functions. See Section 8.1 in
> >
> > http://cran.r-project.org/doc/manuals/R-exts.html
> >
> > for Unixalikes (building R as a shared library, most likely libR.so).
> >
> > > First question:
> > > Is it possible to load gstat package from the R standalone library?
> >
> > Yes, like any package, but why?
> >
> > > Second question:
> > > Is there another way to do it when working inside a GRASS module? The
> > > question raises because, with regard to spgrass6, there's no way to
> > > use it from a module (except by making a shell process call from C)...
> >
> > Well, you can use the GRASS API to populate the appropriate R object
> > structures in C (see the GRASS5 GRASS package C code).
> >
> > > am I wrong?
> >
> > Yes, because you will never (at least for a definition of never being
> > greater than the number of developer hours taken to write and maintain
> > gstat and the R/GRASS interface) be able to do this robustly, taking
> > account of all possible error conditions (identical points passed to gstat
> > for example), and track changes in the different software environments
> > (something that works only with GRASS version x.y.z, R version a.b.c,
> > gstat version d.e.f, sp version g.h.i, etc. There is simply too much being
> > patched for a welded-hood C solution to be worth the development and
> > maintenance cost.
> >
> > By the way, you didn't say what you want to do that needs this level of
> > automation; if you had, it might be easier to understand your very strange
> > design choices and resource commitments.
> >
> > > Thanks,
> > > Giovanni
> > >
> > > _______________________________________________
> > > statsgrass mailing list
> > > statsgrass at grass.itc.it
> > > http://grass.itc.it/mailman/listinfo/statsgrass
> > >
> >
> > --
> > 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
> >
> >
> 

-- 
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