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

Benjamin Ducke benjamin.ducke at ufg.uni-kiel.de
Tue Apr 11 03:59:47 EDT 2006


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.

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.

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.

5. For power users: provide an R console

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

-- 
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeo-Information Science)
Institut für Ur- und Frühgeschichte
(Institute of Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg




More information about the grass-user mailing list