[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