Thanks much, Roger!! (sorry for the delay in reacting ;))
El vie., 28 sept. 2018 a las 10:25, Roger Bivand (<roger.biv...@nhh.no>)
escribió:
> 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.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
