[STATSGRASS] using R and gstat inside a C module

[Roger Bivand]

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