[STATSGRASS] using R and gstat inside a C module

[G. Allegri]

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