[GRASSLIST:658] Re: [GRASS5] Re: Re: running r.topmodel

[Roger Bivand]

On Tue, 11 Apr 2006, Benjamin Ducke wrote:

In response to Hamish:


Short answer is section 13.2.3 in Neteler/Mitasova (section number for
first edition), which shows how to set up the R script and data in a shell
script, passing variable values through environmental variables.

This is interesting, because different users see things from different   
ends, and may need a different application "on top". Another example using
Terralib is here:

http://www.est.ufpr.br/aRT/
  
> A few basic things, I would think, none of them too hard:
> 
> 1. Implement decent attribute management GUI for vector data via a
> tcl/tk table widget incl. SQL queries, data sorting and filtering, just
> like e.g. ArcMap does
> 
> 2. Ship GRASS with a version of R and all relevant spatial packages
> included so the user does not need to worry about installing R in
> addition to GRASS.

Probably not a good idea, because the R package management and updating - 
especially the updating - works very well online, and installation is not 
a big problem. Supporting cross-platform portability is much more of a 
problem. On the other hand, documenting installation routes might be a 
sensible idea, or linking to such documentation.

> 
> 3. Make a simple wrapper function available to C and shell programmers
> to pipe data back and forth between GRASS and the included R system and
> call R functions to work on that data.

Loose coupling is all that is available now (GRASS6 data is written out to 
temporary files and read into R), but for GRASS5 it was tighter - this is 
with R running "on top" reading from the GRASS database(s) and running 
GRASS commands through system().

However, R as a shared library can be put inside a GRASS module (GRASS "on 
top"):

http://cran.r-project.org/doc/manuals/R-exts.html#Linking-GUIs-and-other-front_002dends-to-R

in addition to using sockets, or other interprocess communication. These 
steps were used in aRT. 

The main issues so far have been that with R "on top", it runs 
continuously for each interactive session than the GRASS programmes, and 
that libgis typically caused problems, because it doesn't expect internal 
arrays (like mapsets) to exist for more than one program execution. The 
interface code for GRASS5 tried to handle that, but my present view is 
that data transfer (metadata and data) should not rely on GRASS libraries 
being linked to the interface package in R. A middle way is the GDAL/OGR 
plugin, which rgdal in R will respect for reading from GRASS, but here, 
for example, the GDAL plugin doesn't respect the region settings.

> 
> 4. Provide some GRASS modules as front-ends (wrappers) to most popular
> used R functionality (e.g. multivariate statistics, kriging)
> Results from the R calls should be saved in attributes of GRASS vector
> maps or as GRASS raster maps.
> 

Like ArcRstats:

http://www.nicholas.duke.edu/geospatial/software/

or GRASPER:

http://www.cscf.ch/grasp/grasp-r/index.html

For someone with a little time on their hands, write a shell/R script to 
prototype a GRASS/Mondrian interface for dynamic linked graphics for 
polygon vector layers:

http://stats.math.uni-augsburg.de/Mondrian/Mondrian.html

library(maptools)
my_SPDF <- readShapePoly(Sys.getenv("GRASS_INFILE"))
sp2Mondrian(my_SPDF, Sys.getenv("MOND_OUTFILE"))
q(n)

but I'm not sure how to prime Mondrian with the $MOND_OUTFILE, I guess 
there's a way.

> 5. For power users: provide an R console
> 

No, data analysis is too serious to be left to the power users ...

(Seriously, getting one's fingers dirty in the data really helps learn 
about how confident one ought to be in drawing conclusions - for instance, 
ArcGISs Moran's I with row standardisation is simply not correct, but only 
a Chinese epidemiologist with a hands on attitude (and independently two 
social scientists from Cornell) spotted the issue; they trusted their 
gut feeling more than the twee graphic that said there was no 
autocorrelation, and then ran the same test in R and GeoDa, and I ran it 
in Stata)

Roger

> Benjamin
> 
> Hamish wrote:
> > Wouter:
> > 
> >>>Just to say that I'm now one of the topmodel developers at
> >>>Lancaster. We are doing a major cleanup of the code and intend to
> >>>release some new versions soon, although in R rather than in GRASS
> >>>(for several reasons...) incorporating Monte Carlo and other stuff.
> > 
> > 
> > Tom:
> > 
> >>That's excellent; the choice of going to R is pretty interesting. Does
> >>this mean the Glue algorithms will be ported there as well?
> > 
> > 
> > Wouter:
> > 
> >>I chose R primarily for uncertainty analysis: in R it is very easy to
> >>pull parameters from whatever probability distribution you want,
> >>construct a  parameter matrix and do a Monte Carlo run over the whole
> >>matrix. Similarly, you can feed the modelling results directly to
> >>whatever likelihood function that is available (or that can be
> >>programmed) in R.
> >>
> >>As a result, it should be quite straightforward to use a GLUE approach
> >>within this framework...
> > 
> > 
> > 
> > Each tool belongs where it is best suited, so if that means R or GMT or
> > Matlab, and not in GRASS, then fine with me. I think it is a good thing
> > to make GRASS easily modular with these other great softwares.
> > 
> > We now have a pretty functional way of calling up GRASS 6 data from in
> > R, I think what we need now is a good way of access R from within GRASS.
> > i.e. a GRASS shell script could be a wrapper to send data to R, tell R
> > to do something special with it, then automatically bring the final
> > product back into GRASS. This would open up a lot of the really good
> > geostat, interpolation, etc., fns already written for R to GRASS users
> > who are not R experts, and would also make it very easy to write new &
> > powerful GRASS scripts using R algorithms (eg wrapper script for new
> > topmodel).
> > 
> > What needs to happen?
> > 
> > 
> > Hamish
> > 
> > _______________________________________________
> > grass5 mailing list
> > grass5 at grass.itc.it
> > http://grass.itc.it/mailman/listinfo/grass5
> > 
> > 
> 
> 

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