[GRASS-dev] R and GRASS integration

Wed Jan 6 01:27:28 PST 2016

Paulo van Breugel <p.vanbreugel at gmail.com> writes:

> I by any stretch of imagination a developer, but I did use the
> combination of shell or pythons script with R, basically following the
> approach you described, having a python or shell script write a R
> script to a text file and run it. I think it can work well, and not
> that much harder to maintain. But I also would be very interested to
> learn how to do this better. I also would be interested to see the
> randomForest scripts you mentioned Steven, are you already sharing it
> somewhere?
>
> As you mentioned, there are probably many people using / writing R
> scripts that interact with GRASS. For some it will be easier, or it
> may be more logical for them, to turn these into R packages rather
> than writing a GRASS addon.

I am one of those. I have thought about making a GRASS (or QGIS) addon /
plugin, but I stayed with the R package. I have a complete simulation
written in R which uses spatial data from GRASS, does simulations, and
returns the results to GRASS.

To run the simulations in itself is a three liner in R.

> It would be nice if there would be some kind of repository where
> people share such code (github perhaps?). I am sure there are existing
> ones on e.g., github, so perhaps just a GRASS-wiki page listing
> existing repositories would be enough. I know there is
> https://grasswiki.osgeo.org/wiki/R_statistics, but I don't think there
> is an place on the GRASS website, wiki or trac to share/list R code?
> Would this be of interest to create such page (on the Wiki perhaps?).

Different people use different repos (I use e.g. github and gitlab) so
creating another place where I should publish my code would be not
really an option. What would be an idea to make it easy (probably even
easier even than editing a wiki page?) to add a repo to a list of
projects which integrate R in GRASS or GRASS in R, and which could
indicate the last commit to aser if the repos are current or just
archives from e.g. papers or finished projects.

My repo is private at the moment, but I plan to make it open in the next
few weeks.

A brief presentation about a very similar simulation model can be
found at

https://github.com/rkrug/INTECOL_2013_Optimizing

My gitlab repos (most or all private at the moment) are at

https://gitlab.com/rkrug/asm

and the simulation is at (also still private but it will change soon)

https://gitlab.com/rkrug/asm

For reference, my github page is at

https://github.com/rkrug

Cheers,

Rainer

>
> Paulo
>
>
> On 04-01-16 16:14, Steven Pawley wrote:
>> Thank you Moritz,
>>
>> Yes I have also had difficulties with Rpy2 apart from on
>> Linux. Also, Rpy2 is quite onerous in terms of effort required to
>> integrate R scripts into Python. Your solution certainly works, but
>> as you mentioned it makes the R script harder to maintain. PypeR is
>> another alternative and is straightforward to install and is simpler
>> from a user perspective.
>>
>> I would also be interested in hearing opinions from 'true'
>> developers who have much greater expertise than myself in this area.
>>
>> Kind regards,
>>
>> Steve
>>
>>> On Jan 4, 2016, at 2:31 AM, Moritz Lennert <mlennert at club.worldonline.be> wrote:
>>>
>>>> On 04/01/16 10:28, Moritz Lennert wrote:
>>>>> On 03/01/16 23:54, Steven Pawley wrote:
>>>>> Like many R-GRASS users, I have a collection of R scripts that
>>>>> interact with GRASS to perform various workflows. I have debated
>>>>> about converting these to Python using Rpy2, although this package
>>>>> can be a difficult to install on all platforms and depends on
>>>>> specific versions of R and Python. I noticed that Moritz Lennert
>>>>> recently developed a GRASS add on which consists of simply writing
>>>>> out the R commands to a temporary script for R to run.
>>>> [...]
>>>>> Does this represent a desirable or even acceptable approach for
>>>>> embedding R scripts into grass add ons, or is Rpy2 the 'official'
>>>>> approach.
>>>> I wouldn't consider my approach in any way official, but AFAIK, rpy2
>>>> does not have any "official" status in GRASS either. In my particular
>>>> case (v.class.mlR) this was a quick and dirty hack for a course I had to
>>>> teach. The difficulty of getting rpy2 installed on the lab machines on
>>>> short notice was one of the motivations not to use it. I also agree that
>>>> dependency on rpy2 can be a nuisance and has caused me some headaches
>>>> with other modules, before. However, the approach I used (and others
>>>> have used before) is a bit unwieldy and makes maintaining such modules a
>>>> bit of a pain.
>>>>
>>>> So, I'm curious to hear the opinions of others...
>>> See [1] for a related issue.
>>>
>>> Moritz
>>>
>>> [1] https://trac.osgeo.org/grass/ticket/1290
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev

-- 
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 454 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20160106/0d5e21bd/attachment.sig>