Re: R interface to grass 7.1

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: R interface to grass 7.1

Roger Bivand
Hi,

This is:

http://trac.osgeo.org/grass/wiki/GSoC/2015#Neweasy-to-usecommandlineinterfaceforGRASSGIS

is it? Did it get accepted - I don't see this on:

http://www.google-melange.com/gsoc/org2/show/google/gsoc2015/osgeo

and think that only improved metadata got funded. Do we know what the
actual status is on this? I'd feel that this could be a variant in rgrass7
if it becomes available, but I'm not sure how it would expose the
interface description.

Best wishes,

Roger

On Thu, 4 Jun 2015, Rainer M Krug wrote:

> Hi
>
> I guess you have seen the announcement from Vaclac Petras about the new
> command line interface to R. This sounds very exciting and I would like
> to start playing with the R-GRASS 7.1 interface. What would be the best
> approach concerning git / svn? should I setup my own github for this or
> should I slot in one of the spgrass repositories?
>
> Thanks,
>
> Rainer
>
>
>
> http://permalink.gmane.org/gmane.comp.gis.grass.user/51680
>
>

--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; fax +47 55 95 91 00
e-mail: [hidden email]

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: R interface to grass 7.1

wenzeslaus

On Thu, Jun 4, 2015 at 12:43 PM, Roger Bivand <[hidden email]> wrote:
Hi,

This is:

http://trac.osgeo.org/grass/wiki/GSoC/2015#Neweasy-to-usecommandlineinterfaceforGRASSGIS

is it? Did it get accepted - I don't see this on:

http://www.google-melange.com/gsoc/org2/show/google/gsoc2015/osgeo

and think that only improved metadata got funded. Do we know what the actual status is on this?

Hi Roger,

I can answer it :) I'm doing it simply because I need it (and I'm also tired of solving the setup of environment variables over on over). However, the GSoC idea went behind what I implemented. I implemented:

grass /path/to/mapset --exec r.external input=elevation.tiff output=elevation
grass /path/to/mapset --exec r.univar map=elevation

Once conceptual questions are answered, it should be relatively simple to add the following:

grass setmapset /path/to/mapset
grass run r.external input=elevation.tiff output=elevation
grass run r.univar map=elevation

The GSoC idea went much further:

grass execute r.univar map=file://elevation.tiff

* I used `execute` in the example, I'm not comfortable with the name but the idea is to keep the names different for each interface to distinguish the interfaces (but perhaps it is a wrong idea?). From discussion with Rainer, I see that parameters won't cut it for shebang and there needs to be a separate executable something like `grassscript`.

It would love to accommodate needs of the R interface. We just need to figure out what they are.

Vaclav

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats
Reply | Threaded
Open this post in threaded view
|

Re: R interface to grass 7.1

RKrug
In reply to this post by Roger Bivand
Roger Bivand <[hidden email]> writes:

> Hi,
>
> This is:
>
> http://trac.osgeo.org/grass/wiki/GSoC/2015#Neweasy-to-usecommandlineinterfaceforGRASSGIS
>
> is it? Did it get accepted - I don't see this on:
>
> http://www.google-melange.com/gsoc/org2/show/google/gsoc2015/osgeo
>
> and think that only improved metadata got funded.
This is true as far as I know, but it seems that Vaclac took it in
his own hands to code the initial stages and he checked it into the
GRASS 7.1 source.

I installed GRASS 7.1 from source using homebrew (the formula is in a
pending pull request) and I could execute the examples fine.

> Do we know what the actual status is on this?

The

,----
| grass71 MAPSET --exec THE GRASS COMAND WITH WHATEVER COMES NOW
`----

is working, but I don't know if it has been tested a lot. For testing,
the sp collection could help as there are already examples which one
could run.

Otherwise - no idea - but it seems to be going forward.

> I'd feel that this could be a variant in rgrass7 if it becomes
> available,

Yes - some changes and getting rid of the initialisation of the GRASS
session, and only provide the path to the grass71 executable.

> but I'm not sure how it would expose the interface description.

--8<---------------cut here---------------start------------->8---
grass71 --exec g.list --interface-description
--8<---------------cut here---------------end--------------->8---

I just tried it out.

or, maybe safer,

--8<---------------cut here---------------start------------->8---
grass71 PATH/TO/MAPSET --exec g.list --interface-description
--8<---------------cut here---------------end--------------->8---

This is only the first stage, and Vaclac seems to be very much open to
suggestions and discussion on which direction this should go.

The discussion is on grass-user.

It seems that you are planning to move the sp packages to github - is
this true?

Cheers,

Rainer

>
> Best wishes,
>
> Roger
>
> On Thu, 4 Jun 2015, Rainer M Krug wrote:
>
>> Hi
>>
>> I guess you have seen the announcement from Vaclac Petras about the new
>> command line interface to R. This sounds very exciting and I would like
>> to start playing with the R-GRASS 7.1 interface. What would be the best
>> approach concerning git / svn? should I setup my own github for this or
>> should I slot in one of the spgrass repositories?
>>
>> Thanks,
>>
>> Rainer
>>
>>
>>
>> http://permalink.gmane.org/gmane.comp.gis.grass.user/51680
>>
>>
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      [hidden email]

Skype:      RMkrug

PGP: 0x0F52F982

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

signature.asc (504 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: R interface to grass 7.1

Roger Bivand
On Thu, 4 Jun 2015, Rainer M Krug wrote:

> Roger Bivand <[hidden email]> writes:
>
>> Hi,
>>
>> This is:
>>
>> http://trac.osgeo.org/grass/wiki/GSoC/2015#Neweasy-to-usecommandlineinterfaceforGRASSGIS
>>
>> is it? Did it get accepted - I don't see this on:
>>
>> http://www.google-melange.com/gsoc/org2/show/google/gsoc2015/osgeo
>>
>> and think that only improved metadata got funded.
>
> This is true as far as I know, but it seems that Vaclac took it in
> his own hands to code the initial stages and he checked it into the
> GRASS 7.1 source.
>
> I installed GRASS 7.1 from source using homebrew (the formula is in a
> pending pull request) and I could execute the examples fine.
>
>> Do we know what the actual status is on this?
>
> The
>
> ,----
> | grass71 MAPSET --exec THE GRASS COMAND WITH WHATEVER COMES NOW
> `----
>
> is working, but I don't know if it has been tested a lot. For testing,
> the sp collection could help as there are already examples which one
> could run.
>
> Otherwise - no idea - but it seems to be going forward.
>
>> I'd feel that this could be a variant in rgrass7 if it becomes
>> available,
>
> Yes - some changes and getting rid of the initialisation of the GRASS
> session, and only provide the path to the grass71 executable.
>
>> but I'm not sure how it would expose the interface description.
>
> --8<---------------cut here---------------start------------->8---
> grass71 --exec g.list --interface-description
> --8<---------------cut here---------------end--------------->8---
>
> I just tried it out.
>
> or, maybe safer,
>
> --8<---------------cut here---------------start------------->8---
> grass71 PATH/TO/MAPSET --exec g.list --interface-description
> --8<---------------cut here---------------end--------------->8---
>
> This is only the first stage, and Vaclac seems to be very much open to
> suggestions and discussion on which direction this should go.
>
> The discussion is on grass-user.
>
> It seems that you are planning to move the sp packages to github - is
> this true?

Just on this, no, I will give up maintaining if anyone moves the main sp
repository to git, and especially github, which is a proprietory
corporation. Git is a bad choice going forward, as the important
"responsibility" element is pulverised (good for projects with very strong
brands, so someone will be responsible, probably bad for projects without
strong brands with few active developers and lots of users sitting on
their hands). Git is usable, and can be used like svn or similar
centralised repositories, but is several steps backward IMO. It's got
popular through github because projects avoid having to host their own
repos. We'll see whether PROJ.4 falls apart after migration to github
(it's very weak already). Github mostly attracts on coolness, which is
often orthogonal to productive work.

Roger

>
> Cheers,
>
> Rainer
>
>>
>> Best wishes,
>>
>> Roger
>>
>> On Thu, 4 Jun 2015, Rainer M Krug wrote:
>>
>>> Hi
>>>
>>> I guess you have seen the announcement from Vaclac Petras about the new
>>> command line interface to R. This sounds very exciting and I would like
>>> to start playing with the R-GRASS 7.1 interface. What would be the best
>>> approach concerning git / svn? should I setup my own github for this or
>>> should I slot in one of the spgrass repositories?
>>>
>>> Thanks,
>>>
>>> Rainer
>>>
>>>
>>>
>>> http://permalink.gmane.org/gmane.comp.gis.grass.user/51680
>>>
>>>
>
>

--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; fax +47 55 95 91 00
e-mail: [hidden email]

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: R interface to grass 7.1

Edzer Pebesma-2


On 06/04/2015 09:44 PM, Roger Bivand wrote:

> On Thu, 4 Jun 2015, Rainer M Krug wrote:
>
>> Roger Bivand <[hidden email]> writes:
>>
>>> Hi,
>>>
>>> This is:
>>>
>>> http://trac.osgeo.org/grass/wiki/GSoC/2015#Neweasy-to-usecommandlineinterfaceforGRASSGIS
>>>
>>>
>>> is it? Did it get accepted - I don't see this on:
>>>
>>> http://www.google-melange.com/gsoc/org2/show/google/gsoc2015/osgeo
>>>
>>> and think that only improved metadata got funded.
>>
>> This is true as far as I know, but it seems that Vaclac took it in
>> his own hands to code the initial stages and he checked it into the
>> GRASS 7.1 source.
>>
>> I installed GRASS 7.1 from source using homebrew (the formula is in a
>> pending pull request) and I could execute the examples fine.
>>
>>> Do we know what the actual status is on this?
>>
>> The
>>
>> ,----
>> | grass71 MAPSET --exec THE GRASS COMAND WITH WHATEVER COMES NOW
>> `----
>>
>> is working, but I don't know if it has been tested a lot. For testing,
>> the sp collection could help as there are already examples which one
>> could run.
>>
>> Otherwise - no idea - but it seems to be going forward.
>>
>>> I'd feel that this could be a variant in rgrass7 if it becomes
>>> available,
>>
>> Yes - some changes and getting rid of the initialisation of the GRASS
>> session, and only provide the path to the grass71 executable.
>>
>>> but I'm not sure how it would expose the interface description.
>>
>> --8<---------------cut here---------------start------------->8---
>> grass71 --exec g.list --interface-description
>> --8<---------------cut here---------------end--------------->8---
>>
>> I just tried it out.
>>
>> or, maybe safer,
>>
>> --8<---------------cut here---------------start------------->8---
>> grass71 PATH/TO/MAPSET --exec g.list --interface-description
>> --8<---------------cut here---------------end--------------->8---
>>
>> This is only the first stage, and Vaclac seems to be very much open to
>> suggestions and discussion on which direction this should go.
>>
>> The discussion is on grass-user.
>>
>> It seems that you are planning to move the sp packages to github - is
>> this true?
>
> Just on this, no, I will give up maintaining if anyone moves the main sp
> repository to git, and especially github, which is a proprietory
> corporation. Git is a bad choice going forward, as the important
> "responsibility" element is pulverised (good for projects with very
> strong brands, so someone will be responsible, probably bad for projects
> without strong brands with few active developers and lots of users
> sitting on their hands). Git is usable, and can be used like svn or
> similar centralised repositories, but is several steps backward IMO.
> It's got popular through github because projects avoid having to host
> their own repos. We'll see whether PROJ.4 falls apart after migration to
> github (it's very weak already). Github mostly attracts on coolness,
> which is often orthogonal to productive work.
>
> Roger
I have less problems with github, and so sp might migrate one day. Right
now, Roger and I do the majority of the work on sp, so svn on r-forge
makes most sense. Contributors send patches, or code snippets in email.

Once I see an easy way to use travis-ci for the full check on all of
sp's reverse dependencies I will adopt that, at the cost of having to
keep git and svn synced. Right now this check [*] takes me an absurd
amount of time.

[*] I now use:

library(sp)
demo(depend)

>
>>
>> Cheers,
>>
>> Rainer
>>
>>>
>>> Best wishes,
>>>
>>> Roger
>>>
>>> On Thu, 4 Jun 2015, Rainer M Krug wrote:
>>>
>>>> Hi
>>>>
>>>> I guess you have seen the announcement from Vaclac Petras about the new
>>>> command line interface to R. This sounds very exciting and I would like
>>>> to start playing with the R-GRASS 7.1 interface. What would be the best
>>>> approach concerning git / svn? should I setup my own github for this or
>>>> should I slot in one of the spgrass repositories?
>>>>
>>>> Thanks,
>>>>
>>>> Rainer
>>>>
>>>>
>>>>
>>>> http://permalink.gmane.org/gmane.comp.gis.grass.user/51680
>>>>
>>>>
>>
>>
>
--
Edzer Pebesma
Institute for Geoinformatics (ifgi),  University of Münster,
Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
Journal of Statistical Software:   http://www.jstatsoft.org/
Computers & Geosciences:   http://elsevier.com/locate/cageo/
Spatial Statistics Society http://www.spatialstatistics.info


_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

signature.asc (501 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: R interface to grass 7.1

RKrug
In reply to this post by Roger Bivand
Roger Bivand <[hidden email]> writes:

> On Thu, 4 Jun 2015, Rainer M Krug wrote:
>
>> Roger Bivand <[hidden email]> writes:
>>
>>> Hi,
>>>
>>> This is:
>>>
>>> http://trac.osgeo.org/grass/wiki/GSoC/2015#Neweasy-to-usecommandlineinterfaceforGRASSGIS
>>>
>>> is it? Did it get accepted - I don't see this on:
>>>
>>> http://www.google-melange.com/gsoc/org2/show/google/gsoc2015/osgeo
>>>
>>> and think that only improved metadata got funded.
>>
>> This is true as far as I know, but it seems that Vaclac took it in
>> his own hands to code the initial stages and he checked it into the
>> GRASS 7.1 source.
>>
>> I installed GRASS 7.1 from source using homebrew (the formula is in a
>> pending pull request) and I could execute the examples fine.
>>
>>> Do we know what the actual status is on this?
>>
>> The
>>
>> ,----
>> | grass71 MAPSET --exec THE GRASS COMAND WITH WHATEVER COMES NOW
>> `----
>>
>> is working, but I don't know if it has been tested a lot. For testing,
>> the sp collection could help as there are already examples which one
>> could run.
>>
>> Otherwise - no idea - but it seems to be going forward.
>>
>>> I'd feel that this could be a variant in rgrass7 if it becomes
>>> available,
>>
>> Yes - some changes and getting rid of the initialisation of the GRASS
>> session, and only provide the path to the grass71 executable.
>>
>>> but I'm not sure how it would expose the interface description.
>>
>> --8<---------------cut here---------------start------------->8---
>> grass71 --exec g.list --interface-description
>> --8<---------------cut here---------------end--------------->8---
>>
>> I just tried it out.
>>
>> or, maybe safer,
>>
>> --8<---------------cut here---------------start------------->8---
>> grass71 PATH/TO/MAPSET --exec g.list --interface-description
>> --8<---------------cut here---------------end--------------->8---
>>
>> This is only the first stage, and Vaclac seems to be very much open to
>> suggestions and discussion on which direction this should go.
>>
>> The discussion is on grass-user.
>>
>> It seems that you are planning to move the sp packages to github - is
>> this true?
>
> Just on this, no, I will give up maintaining if anyone moves the main
> sp repository to git, and especially github, which is a proprietory
> corporation. Git is a bad choice going forward, as the important
> "responsibility" element is pulverised (good for projects with very
> strong brands, so someone will be responsible, probably bad for
> projects without strong brands with few active developers and lots of
> users sitting on their hands). Git is usable, and can be used like svn
> or similar centralised repositories, but is several steps backward
> IMO. It's got popular through github because projects avoid having to
> host their own repos. We'll see whether PROJ.4 falls apart after
> migration to github (it's very weak already). Github mostly attracts
> on coolness, which is often orthogonal to productive work.
I just thought that there was a discussion about this on the mailing
list, but I must have mixed them up (probably with PROJ.4 ?).

No need to change anything at the moment.

Cheers,

Rainer

>
> Roger
>
>>
>> Cheers,
>>
>> Rainer
>>
>>>
>>> Best wishes,
>>>
>>> Roger
>>>
>>> On Thu, 4 Jun 2015, Rainer M Krug wrote:
>>>
>>>> Hi
>>>>
>>>> I guess you have seen the announcement from Vaclac Petras about the new
>>>> command line interface to R. This sounds very exciting and I would like
>>>> to start playing with the R-GRASS 7.1 interface. What would be the best
>>>> approach concerning git / svn? should I setup my own github for this or
>>>> should I slot in one of the spgrass repositories?
>>>>
>>>> Thanks,
>>>>
>>>> Rainer
>>>>
>>>>
>>>>
>>>> http://permalink.gmane.org/gmane.comp.gis.grass.user/51680
>>>>
>>>>
>>
>>
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      [hidden email]

Skype:      RMkrug

PGP: 0x0F52F982

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

signature.asc (504 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: R interface to grass 7.1

Roger Bivand
In reply to this post by Edzer Pebesma-2
On Thu, 4 Jun 2015, Edzer Pebesma wrote:

>
>
> On 06/04/2015 09:44 PM, Roger Bivand wrote:
>> On Thu, 4 Jun 2015, Rainer M Krug wrote:
>>
>>> Roger Bivand <[hidden email]> writes:
>>>
>>>> Hi,
>>>>
>>>> This is:
>>>>
>>>> http://trac.osgeo.org/grass/wiki/GSoC/2015#Neweasy-to-usecommandlineinterfaceforGRASSGIS
>>>>
>>>>
>>>> is it? Did it get accepted - I don't see this on:
>>>>
>>>> http://www.google-melange.com/gsoc/org2/show/google/gsoc2015/osgeo
>>>>
>>>> and think that only improved metadata got funded.
>>>
>>> This is true as far as I know, but it seems that Vaclac took it in
>>> his own hands to code the initial stages and he checked it into the
>>> GRASS 7.1 source.
>>>
>>> I installed GRASS 7.1 from source using homebrew (the formula is in a
>>> pending pull request) and I could execute the examples fine.
>>>
>>>> Do we know what the actual status is on this?
>>>
>>> The
>>>
>>> ,----
>>> | grass71 MAPSET --exec THE GRASS COMAND WITH WHATEVER COMES NOW
>>> `----
>>>
>>> is working, but I don't know if it has been tested a lot. For testing,
>>> the sp collection could help as there are already examples which one
>>> could run.
>>>
>>> Otherwise - no idea - but it seems to be going forward.
>>>
>>>> I'd feel that this could be a variant in rgrass7 if it becomes
>>>> available,
>>>
>>> Yes - some changes and getting rid of the initialisation of the GRASS
>>> session, and only provide the path to the grass71 executable.
>>>
>>>> but I'm not sure how it would expose the interface description.
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> grass71 --exec g.list --interface-description
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> I just tried it out.
>>>
>>> or, maybe safer,
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> grass71 PATH/TO/MAPSET --exec g.list --interface-description
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> This is only the first stage, and Vaclac seems to be very much open to
>>> suggestions and discussion on which direction this should go.
>>>
>>> The discussion is on grass-user.
>>>
>>> It seems that you are planning to move the sp packages to github - is
>>> this true?
>>
>> Just on this, no, I will give up maintaining if anyone moves the main sp
>> repository to git, and especially github, which is a proprietory
>> corporation. Git is a bad choice going forward, as the important
>> "responsibility" element is pulverised (good for projects with very
>> strong brands, so someone will be responsible, probably bad for projects
>> without strong brands with few active developers and lots of users
>> sitting on their hands). Git is usable, and can be used like svn or
>> similar centralised repositories, but is several steps backward IMO.
>> It's got popular through github because projects avoid having to host
>> their own repos. We'll see whether PROJ.4 falls apart after migration to
>> github (it's very weak already). Github mostly attracts on coolness,
>> which is often orthogonal to productive work.
>>
>> Roger
>
> I have less problems with github, and so sp might migrate one day. Right
> now, Roger and I do the majority of the work on sp, so svn on r-forge
> makes most sense. Contributors send patches, or code snippets in email.
>
> Once I see an easy way to use travis-ci for the full check on all of
> sp's reverse dependencies I will adopt that, at the cost of having to
> keep git and svn synced. Right now this check [*] takes me an absurd
> amount of time.
>
> [*] I now use:
>
> library(sp)
> demo(depend)

Using _R_CHECK_FORCE_SUGGESTS_=FALSE helps. I update/install the packages
to check first (which draws in their c("Depends", "Imports",
"LinkingTo")), and in checking rgeos and rgdal have reduced run times
greatly. I also fell into the trap of setting recursive=TRUE, but that is
not needed, as only packages referring to the target arguably need to be
tested (if a package suggesting a package that suggests sp itself doesn't
declare its relying on sp say for plotting something, it is in error).
Almost all the errors turn out to be errors in the packages that are not
caused by changes in the target, but rather careless coding or examples
(typically unprotected library/require).

Should we set up a docker instance (or just a shell script) to run sp (and
other) dependency checks nightly? I think the hard part is summarizing the
findings. Project for Avignon?

Roger

>
>>
>>>
>>> Cheers,
>>>
>>> Rainer
>>>
>>>>
>>>> Best wishes,
>>>>
>>>> Roger
>>>>
>>>> On Thu, 4 Jun 2015, Rainer M Krug wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I guess you have seen the announcement from Vaclac Petras about the new
>>>>> command line interface to R. This sounds very exciting and I would like
>>>>> to start playing with the R-GRASS 7.1 interface. What would be the best
>>>>> approach concerning git / svn? should I setup my own github for this or
>>>>> should I slot in one of the spgrass repositories?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Rainer
>>>>>
>>>>>
>>>>>
>>>>> http://permalink.gmane.org/gmane.comp.gis.grass.user/51680
>>>>>
>>>>>
>>>
>>>
>>
>
>

--
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; fax +47 55 95 91 00
e-mail: [hidden email]

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats
Roger Bivand
NHH Norwegian School of Economics, Bergen, Norway
Reply | Threaded
Open this post in threaded view
|

Re: R interface to grass 7.1

RKrug
In reply to this post by Edzer Pebesma-2
Edzer Pebesma <[hidden email]> writes:

> On 06/04/2015 09:44 PM, Roger Bivand wrote:
>> On Thu, 4 Jun 2015, Rainer M Krug wrote:
>>
>>> Roger Bivand <[hidden email]> writes:
>>>
>>>> Hi,
>>>>
>>>> This is:
>>>>
>>>> http://trac.osgeo.org/grass/wiki/GSoC/2015#Neweasy-to-usecommandlineinterfaceforGRASSGIS
>>>>
>>>>
>>>> is it? Did it get accepted - I don't see this on:
>>>>
>>>> http://www.google-melange.com/gsoc/org2/show/google/gsoc2015/osgeo
>>>>
>>>> and think that only improved metadata got funded.
>>>
>>> This is true as far as I know, but it seems that Vaclac took it in
>>> his own hands to code the initial stages and he checked it into the
>>> GRASS 7.1 source.
>>>
>>> I installed GRASS 7.1 from source using homebrew (the formula is in a
>>> pending pull request) and I could execute the examples fine.
>>>
>>>> Do we know what the actual status is on this?
>>>
>>> The
>>>
>>> ,----
>>> | grass71 MAPSET --exec THE GRASS COMAND WITH WHATEVER COMES NOW
>>> `----
>>>
>>> is working, but I don't know if it has been tested a lot. For testing,
>>> the sp collection could help as there are already examples which one
>>> could run.
>>>
>>> Otherwise - no idea - but it seems to be going forward.
>>>
>>>> I'd feel that this could be a variant in rgrass7 if it becomes
>>>> available,
>>>
>>> Yes - some changes and getting rid of the initialisation of the GRASS
>>> session, and only provide the path to the grass71 executable.
>>>
>>>> but I'm not sure how it would expose the interface description.
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> grass71 --exec g.list --interface-description
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> I just tried it out.
>>>
>>> or, maybe safer,
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> grass71 PATH/TO/MAPSET --exec g.list --interface-description
>>> --8<---------------cut here---------------end--------------->8---
>>>
>>> This is only the first stage, and Vaclac seems to be very much open to
>>> suggestions and discussion on which direction this should go.
>>>
>>> The discussion is on grass-user.
>>>
>>> It seems that you are planning to move the sp packages to github - is
>>> this true?
>>
>> Just on this, no, I will give up maintaining if anyone moves the main sp
>> repository to git, and especially github, which is a proprietory
>> corporation. Git is a bad choice going forward, as the important
>> "responsibility" element is pulverised (good for projects with very
>> strong brands, so someone will be responsible, probably bad for projects
>> without strong brands with few active developers and lots of users
>> sitting on their hands). Git is usable, and can be used like svn or
>> similar centralised repositories, but is several steps backward IMO.
>> It's got popular through github because projects avoid having to host
>> their own repos. We'll see whether PROJ.4 falls apart after migration to
>> github (it's very weak already). Github mostly attracts on coolness,
>> which is often orthogonal to productive work.
>>
>> Roger
>
> I have less problems with github, and so sp might migrate one day. Right
> now, Roger and I do the majority of the work on sp, so svn on r-forge
> makes most sense. Contributors send patches, or code snippets in email.
I am fine with this.

>
> Once I see an easy way to use travis-ci for the full check on all of
> sp's reverse dependencies I will adopt that, at the cost of having to
> keep git and svn synced. Right now this check [*] takes me an absurd
> amount of time.

I just looked at travis-ci for the first time, and it looks really
interesting.

A mirror might be quite interesting in light of travis-ci - I just found
this on a quick google:

http://danielpocock.com/automatically-mirroring-svn-repositories-to-git-and-github

which *sounds* easy enough.

Cheers,

Rainer

>
> [*] I now use:
>
> library(sp)
> demo(depend)
>
>>
>>>
>>> Cheers,
>>>
>>> Rainer
>>>
>>>>
>>>> Best wishes,
>>>>
>>>> Roger
>>>>
>>>> On Thu, 4 Jun 2015, Rainer M Krug wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I guess you have seen the announcement from Vaclac Petras about the new
>>>>> command line interface to R. This sounds very exciting and I would like
>>>>> to start playing with the R-GRASS 7.1 interface. What would be the best
>>>>> approach concerning git / svn? should I setup my own github for this or
>>>>> should I slot in one of the spgrass repositories?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Rainer
>>>>>
>>>>>
>>>>>
>>>>> http://permalink.gmane.org/gmane.comp.gis.grass.user/51680
>>>>>
>>>>>
>>>
>>>
>>
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      [hidden email]

Skype:      RMkrug

PGP: 0x0F52F982

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

signature.asc (504 bytes) Download Attachment