[STATSGRASS] using R and gstat inside a C module

[G. Allegri]

Thanks everyone for this very interesting discussion. I think I will have a
look to the swig interface and the wxpython solutions.
I already looked to the "earthquake php" code, but I'm not sure it could be
an "operative" solution, it's a nice thing but it becomes a heavy workload
for the system having to run php system calls to bash scripting and then to
R... and come back to php? It sounds that efficiency and memory issues would
be the main problems, dont'you think?
As a result:
 - use R from shell scripitng
 - call, eventually, external programs using R system() function
 - make gis analysis through shell scripting
 - create a GUI with these solutions to be studied: the web way: pywps (HOPE
MARKUS CAN GIVE ME SOME NEWS about it, I can't find the page anymore!!!),
java(swig), php; wxpythn.
I think the web solutions are the only one suitable to run my tool from any
platform... that's why I was trying to avoid using scripting!!!
Anyway, Roger, I will keep into account your tips about the difficulties to
automate R; I will find a way to break the whole elaboration into multiple
small operations to keep control over each of theme.
Giovanni


2006/10/24, Roger Bivand <Roger.Bivand at nhh.no>:
>
> On Tue, 24 Oct 2006, Hamish wrote:
>
> > G. Allegri wrote:
> > > 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...
> >
> >
> > just a hint about what the next multi-platform GUI for GRASS will use.
> >
> > Currently grass uses tcl/tk as a multi-platform GUI frontend.
> >
> > You can use the g.parser module to create a (static) GUI frontend to a
> > shell script. (see any of the grass 6 scripts and g.parser help page for
> > an example)
> >
> > After some deliberation the next GRASS GUI will be based on WxPython, so
> > that may be an obvious choice for you. Some initial infrastructure &
> > examples have been added to the GRASS 6.3 source code, see
> > gui/wxpython/.
> >
> > Also, perhaps the new SWIG interface is useful for you, that's in swig/
> > in the grass source code. Right now it has some perl and python
> > bindings, but that can be extended to Java, etc as well. Roger: could
> > this be a better way to code the GRASS<->R interface? (or is it fine
> > as-is?)
>
>
> The interface is "R-in-front-of-GRASS", using whatever UI R is using, with
> GRASS just being the database. R cannot assume the presence of any of
> these other components, but more complicated setups can be built with
> "R-in-the-middle" or "R-as-a-backend-compute-server", such as R embedded
> in PostgreSQL as a PL (which would be "GRASS-in-front-of-PostgreSQL"
> "-in-front-of-R"). But prototyping any actual data analysis in that
> setting is bluesky^2, ie. not having the data analysis tool in front runs
> the strong risk of garbage in, garbage out, unless there is very detailed
> control of data entering the system and analyses are kept really simple.
>
> Just things like missing values can trip things up so easily, that
> anything beyond a shell script running R as a script engine is foolhardy.
> Just in the last month there have been several reports of the GRASS wiki
> v.krige failing (shell script of R running gstat on spgrass6), all caused
> by data points at the same locations (which lead to singularity within
> gstat).
>
> Since the number of possible error conditions is largely unknown, and
> grows in proportion with the level of complication of the analysis (and
> one does use data analysis tools mainly to do more complicated things), I
> really don't think putting R behind a GIS GUI is a sensible step unless
> there is a lot of coding and maintenance support (UK vet services were
> doing something like this for point pattern analysis, but I think ran into
> software roll-out issues, needing local ArcGIS/R/splancs/glue, which
> became too heavy. A client-server setup would also have been better there,
> I believe.
>
> By the way, I don't use GRASS in anything other than -text anyway, except
> for digitising and visualisation, though this is a minority view. Most of
> the interfacing of R and SWIG is dormant. Rpy does run, as now does JRI
> and rJava (but not SJava), Perl get used on development platforms but not
> by regular users. For people needing GUI/GRASS-in-fornt-of-R, I guess Rpy
> provides for using R from Python, but how this would handle larger data
> volumes is open.
>
> My personal preference is arT using Terralib, or myR (same place). My
> guess is that many GRASS modules could be rewritten to use Terralib
> instead of libgis etc., and that these interfaces are cleaner, but this is
> aesthetic, I haven't used it in earnest.
>
> Roger
>
> >
> > I don't know enough about either to tell you what's the best or easiest
> > path (or not), but fyi those are two available methods under active
> > development (better support) and perhaps warrant some investigation.
> > Note it's still early days for both SWIG and WxPython in GRASS.
> >
> >
> > > Look at this http://les-ejk.cz/?cat=pywps
> >
> > another to check out is Markus's PHP earthquake map:
> >   http://grass.itc.it/spearfish/php_grass_earthquakes.php
> >
> >
> > good luck - it sounds like a neat project and I think all the
> > ingredients to the recipe are here, just need the right glue.
> >
> >
> > Hamish
> >
>
> --
> 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/20061024/ff00d482/attachment.html