[STATSGRASS] using R and gstat inside a C module

[Roger Bivand]

On Tue, 24 Oct 2006, G. Allegri wrote:

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

Yes, data analysis can be automated, but then the insight of the analyst 
has to be hard-coded into the interface, which is OK for very repetetive 
tasks but less so for one-off analyses (the exceptions crowd out the 
regular situations). Curiously, naive users are experts at generating 
exceptions that the coder didn't anticipate!

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

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