[GRASS-stats] Error when starting grass from R (grass installed thru osgeo4w)

[Roger Bivand]

On Mon, 24 Sep 2018, Veronica Andreo wrote:

> El lun., 24 sep. 2018 6:24, Roger Bivand <Roger.Bivand at nhh.no> escribió:
>
>> On Sun, 23 Sep 2018, Helmut Kudrnovsky wrote:
>>
>>>> I could reproduce the problem after starting the OSGeo4W console from
>> the
>>>> desktop shortcut icon.
>>>>
>>>> The problem seems to be that OSGeo4W's console starts in a directory for
>>>> which the user does not have write access (for me from a desktop
>> shortcut
>>>> C:\Users\Public\Desktop\OSGeo4W). Because rgrass7::initGRASS() needs to
>>>> write a GISRC file in the working directory, it needs write access.
>> When I
>>>> changed working directory to one to which I did have write access, the
>>>> current CRAN binary rgrass7 loaded correctly under OSGeo4W for a
>>>> throw-away location. I haven't yet tried with a pre-existing location.
>>>>
>>>> Could you check and see whether this seems reasonable?
>>>>
>>>> If so, I'll add a check for write access in the working directory to
>> give
>>>> a more sensible error message.
>>>
>>
>> Committed in r65 on https://r-forge.r-project.org/projects/spgrass/; the
>> change tests whether the working directory is writable, and if not puts
>> the temporary GISRC in an R temporary file. I checked Vero's scenario of
>> using initGRASS under OSGeo4W with an existing location (screenshot
>> attached) from the OSGeo4W console.
>
>
> This is great! I could only test now, and after changing to a folder with
> writing permission, all works perfectly!
> Thanks so much, Roger and Helli :)

It should work even in a directory without write permission - now it tests 
first rather than failing. Probably the default should be to use a 
temporary file for GISRC anyway, but ten years ago that seemed 
challenging.

>
>
>> I also corrected the PROJ shared files location for GRASS (I hope). I can
>> provide a Windows binary package
>> off-list if need be.
>>
>
> How to find/test for the location of PROJ shared files?
>

You don't need to, it's just to do with correcting a carry-over from file 
organization in GRASS 6 that had not been correct for GRASS 7 when 
setting up environment variables for GRASS.

>
>> Please let me know if this gets things working.
>>
>> I'm also concerned to know how rgrass7 should be maintained going forward?
>> Should it be on github/r-spatial ? Should it migrate to sf/raster classes?
>>
>
> IMHO, moving to sf/raster classes seems reasonable. However, if it is too
> much of a hassle or there's no consensus, going from sp to sf is just one
> line in R once a GRASS vector has been read in and, for the raster data, as
> well.
>

I already have a trial sf/raster github repo, but the recent edits are not 
present there. It only uses sf for vector, but is stuck with sp/raster for 
raster, so was waiting for stars or similar to provide something newer. 
I'll try to combine the two at some stage, but not soon.

Best wishes,

Roger

> Thanks again!
>
> Best,
> Vero
>

-- 
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: Roger.Bivand at nhh.no
http://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en