On Mon, 24 Sep 2018, Veronica Andreo wrote:
El lun., 24 sep. 2018 6:24, Roger Bivand <roger.biv...@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.biv...@nhh.no
http://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
grass-stats mailing list
grass-stats@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-stats
