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

Roger Bivand Roger.Bivand at nhh.no
Fri Sep 28 01:25:02 PDT 2018


Package rgrass7_0.1-12.tar.gz is on its way to CRAN, with work-around for 
OSGeo4W no write access console startup directory.

Roger

On Tue, 25 Sep 2018, Roger Bivand wrote:

> On Tue, 25 Sep 2018, Veronica Andreo wrote:
>
>>  Hi Roger,
>>
>>  [...]
>>
>>>  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.
>>> 
>>
>>  star given :)
>>  Didn't know about this repo. I think github/r-spatial is also probably the
>>  better place to hold the official rgrass7 in the (near?) future
>
> Yes, but until we know whether getClass("Raster") in the raster Package is a 
> stable target match for GRASS raster layers (as sp::SpatialGridDataFrame has 
> been), we don't know how to drop the sp dependency. raster still depends on 
> sp and suggests rgdal; it now also suggests sf, so maybe in a little while an 
> R/GRASS interface could be just sf/rgdal-based. To support existing 
> workflows, a legacy mode would be needed, I think. So rgrass7 would load in 
> legacy mode, but pivot to sf/raster if legacy mode was set FALSE? The 
> r-spatial/stars project is making some progress as Edzer described in 
> Pruchonice, but is split between local arrays and/or cloud-based 
> representations. When stars reaches a sweet spot, rgrass7 can follow it for 
> the R-side representation.
>
> Best wishes,
>
> Roger
>
>>
>>  Cheers,
>>  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


More information about the grass-stats mailing list