[STATSGRASS] using R and gstat inside a C module
Markus Neteler
neteler at itc.it
Mon Oct 23 14:35:18 EDT 2006
On Mon, Oct 23, 2006 at 07:38:51PM +0200, 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.
> Look at this [1]http://les-ejk.cz/?cat=pywps
As far as I know, pywps has been recently integrated with R.
I cc the author (who may be offline for a week) to give
further details.
Markus
> Giovanni
>
> 2006/10/23, Roger Bivand <[2]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:
> >
> > [3]http://www.rpad.org/Rpad/
> >
> > Look at [4]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 <[5]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
> > > >
> > > > [6]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
> > > > > [7]statsgrass at grass.itc.it
> > > > > [8]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: [9]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: [10]Roger.Bivand at nhh.no
> >
> >
>
>
> References
>
> Visible links
> 1. http://les-ejk.cz/?cat=pywps
> 2. mailto:Roger.Bivand at nhh.no
> 3. http://www.rpad.org/Rpad/
> 4. http://www.rpad.org/Rpad/InterruptionMap.Rpad
> 5. mailto:Roger.Bivand at nhh.no
> 6. http://cran.r-project.org/doc/manuals/R-exts.html
> 7. mailto:statsgrass at grass.itc.it
> 8. http://grass.itc.it/mailman/listinfo/statsgrass
> 9. mailto:Roger.Bivand at nhh.no
> 10. mailto:Roger.Bivand at nhh.no
> _______________________________________________
> statsgrass mailing list
> statsgrass at grass.itc.it
> http://grass.itc.it/mailman/listinfo/statsgrass
--
Markus Neteler <neteler itc it> http://mpa.itc.it/markus/
ITC-irst - Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18 - 38050 Povo (Trento), Italy
More information about the grass-stats
mailing list