[GRASS-dev] R and GRASS integration
Paulo van Breugel
p.vanbreugel at gmail.com
Thu Jan 7 00:52:44 PST 2016
On 06-01-16 18:24, Rainer M Krug wrote:
> Paulo van Breugel <p.vanbreugel at gmail.com> writes:
>
>> On Wed, Jan 6, 2016 at 10:27 AM, Rainer M Krug <Rainer at krugs.de>
>> wrote:
>>
>> 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.
>>
>>
>> +1 That would be something quick to implement. However, what form did
>> you have in mind, if not a wiki page? I wouldn't mind creating such
>> page, but perhaps first some further ideas on the best form from
>> others as well.
> I thought about a field, where I just add the link to the repository and
> some info (Author, short description, possibly License type, ...) and
> this is automatically added to the page including information from the
> repo like last updated, link to the README, ... But this might be
> getting to complicated. But I know it from my side - editing a wiki page
> is often a "will do later" thing.
>
> Also a system where there is an form where one fills in the info and it
> is emailed to somebody to add it to the wiki would work.
Creating an automated form, etc wouldn't be something I could do, but I
wouldn't mind maintaining a a list on the GRASS wiki based on
information from a user form. Perhaps a Google form? Any ideas /
opinions on this from the devs?
>
>> 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
>>
>>
>>
>>
>> Thanks for sharing, interesting. Looking forwards seeing some further
>> code
> Thanks - I will keep you posted.
>
> Coming back to the initial question:
>
> What we would need in the meantime is possibly a discussion, on how R
> functions could be used in an automated way - i.e. something along the
> lines of an R package, which contains a set of defined functions like:
>
> getFunctionNames() :: which returns the function names which can be
> called from GRASS
>
> getFunctionInterface(functionName) :: which returns the arguments of the
> function functionName (similar to the interfaceDescription (I think it
> is called differently) in GRASS commands)
>
> would make it possible to just
>
> 1) load any R package which has these functions
> 2) and get all function names and arguments needed
> 3) and just call the R function in an easy way like
> g.call.R package=PACKAGENAME function=FUNCTIONNAME
> arguments="arguments for the R function)
>
> The function could than be executed by using either a relatively simple python or
> direct Rscript approach.
>
> Also, one could even dynamically load an R package and construct all the
> calls including help, so they could be called by using
> g.call.R.PACKAGENAME.FUNCTIONNAME arg1=ARG1 arg2=ARG2
>
> From the R side, this would be relatively easy to include, (there are
> the packages rgrass7 and spgrass6 to interact with GRASS 7 and 6) and it
> I think that it should not be to difficult to implement on the GRASS side.
>
> This would than be very similar to the approach which rgrass7 (and
> spgrass6) are using by querying the interface and than doing the
> checking, and if everything seems consistent, call the GRASS command.
Sounds like a good approach to me (just from a user perspective, no clue
about the implementation details).
>
> Just some thoughts,
>
> Rainer
>
>> 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
>>
>>
>>
More information about the grass-dev
mailing list