<div dir="ltr">Thanks much, Roger!! (sorry for the delay in reacting ;))<br></div><br><div class="gmail_quote"><div dir="ltr">El vie., 28 sept. 2018 a las 10:25, Roger Bivand (<<a href="mailto:Roger.Bivand@nhh.no" target="_blank">Roger.Bivand@nhh.no</a>>) escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Package rgrass7_0.1-12.tar.gz is on its way to CRAN, with work-around for <br>
OSGeo4W no write access console startup directory.<br>
<br>
Roger<br>
<br>
On Tue, 25 Sep 2018, Roger Bivand wrote:<br>
<br>
> On Tue, 25 Sep 2018, Veronica Andreo wrote:<br>
><br>
>>  Hi Roger,<br>
>><br>
>>  [...]<br>
>><br>
>>>  It should work even in a directory without write permission - now it<br>
>>>  tests<br>
>>>  first rather than failing. Probably the default should be to use a<br>
>>>  temporary file for GISRC anyway, but ten years ago that seemed<br>
>>>  challenging.<br>
>>>><br>
>>>>>  I also corrected the PROJ shared files location for GRASS (I hope). I<br>
>>>  can<br>
>>>>>  provide a Windows binary package<br>
>>>>>  off-list if need be.<br>
>>>>><br>
>>>>  How to find/test for the location of PROJ shared files?<br>
>>>><br>
>>>  You don't need to, it's just to do with correcting a carry-over from file<br>
>>>  organization in GRASS 6 that had not been correct for GRASS 7 when<br>
>>>  setting up environment variables for GRASS.<br>
>>><br>
>>>>>  Please let me know if this gets things working.<br>
>>>>><br>
>>>>>  I'm also concerned to know how rgrass7 should be maintained going<br>
>>>  forward?<br>
>>>>>  Should it be on github/r-spatial ? Should it migrate to sf/raster<br>
>>>  classes?<br>
>>>>> <br>
>>>><br>
>>>>  IMHO, moving to sf/raster classes seems reasonable. However, if it is<br>
>>>>  too<br>
>>>>  much of a hassle or there's no consensus, going from sp to sf is just<br>
>>>>  one<br>
>>>>  line in R once a GRASS vector has been read in and, for the raster data,<br>
>>>  as<br>
>>>>  well.<br>
>>><br>
>>>  I already have a trial sf/raster github repo, but the recent edits are<br>
>>>  not<br>
>>>  present there. It only uses sf for vector, but is stuck with sp/raster<br>
>>>  for<br>
>>>  raster, so was waiting for stars or similar to provide something newer.<br>
>>> <br>
>><br>
>>  star given :)<br>
>>  Didn't know about this repo. I think github/r-spatial is also probably the<br>
>>  better place to hold the official rgrass7 in the (near?) future<br>
><br>
> Yes, but until we know whether getClass("Raster") in the raster Package is a <br>
> stable target match for GRASS raster layers (as sp::SpatialGridDataFrame has <br>
> been), we don't know how to drop the sp dependency. raster still depends on <br>
> sp and suggests rgdal; it now also suggests sf, so maybe in a little while an <br>
> R/GRASS interface could be just sf/rgdal-based. To support existing <br>
> workflows, a legacy mode would be needed, I think. So rgrass7 would load in <br>
> legacy mode, but pivot to sf/raster if legacy mode was set FALSE? The <br>
> r-spatial/stars project is making some progress as Edzer described in <br>
> Pruchonice, but is split between local arrays and/or cloud-based <br>
> representations. When stars reaches a sweet spot, rgrass7 can follow it for <br>
> the R-side representation.<br>
><br>
> Best wishes,<br>
><br>
> Roger<br>
><br>
>><br>
>>  Cheers,<br>
>>  Vero<br>
>> <br>
><br>
><br>
<br>
-- <br>
Roger Bivand<br>
Department of Economics, Norwegian School of Economics,<br>
Helleveien 30, N-5045 Bergen, Norway.<br>
voice: +47 55 95 93 55; e-mail: <a href="mailto:Roger.Bivand@nhh.no" target="_blank">Roger.Bivand@nhh.no</a><br>
<a href="http://orcid.org/0000-0003-2392-6140" rel="noreferrer" target="_blank">http://orcid.org/0000-0003-2392-6140</a><br>
<a href="https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en" rel="noreferrer" target="_blank">https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en</a><br>
</blockquote></div>