[STATSGRASS] using R and gstat inside a C module

[Roger Bivand]

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

> Rpad is a really nice tool, I didn't know it. But do you think it could be a
> way to solve my problem? I need to do gis analysis too, it's not just about
> dealing with R code... I know client/server isn't an easy subject but it
> seems to be the only way I can consider to interface the bash scripting code
> I will produce (I'm abandoning the idea to write a C modulea!!!) in a
> platform-independent way.

That's a possibility, there are many choices you need to make, and in fact 
it might be sensible to try to prototype the system using several 
different ones, to see how they scale, and how easy it is to add 
operations that you require. 

> Look at this http://les-ejk.cz/?cat=pywps

Anything in particular - there a quite a number of good ideas?

Roger

> Giovanni
> 
> 2006/10/23, Roger Bivand <Roger.Bivand at nhh.no>:
> > 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
> >
> >
> 

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