[STATSGRASS] using R and gstat inside a C module

[G. Allegri]

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.
Look at this http://les-ejk.cz/?cat=pywps
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-stats/attachments/20061023/a51a5e1d/attachment.html