Closed florisvdh closed 3 years ago
rgrass7 is only ever tested by my on the WinGRASS stand-alone. I do not use QGIS (noe Windows), so have little insight. Almost certainly OSGeo4W organises files differently from GRASS itself. If you'd like to check what is actually happening (are environment variables already set; are files in different places), I could look at this, but accessing Windows is not convenient for me, installing QGIS via OSGeo4W even less convenient.
It would help colleagues trying to use rgrass7 in Windows (the default in our organization). But indeed this would require special effort. I presume that it does not matter for GRASS and rgrass7 whether QGIS is installed alongside when using OSGeo4W (the user selects QGIS & GRASS independently during installation).
Should the standalone installer (from https://grass.osgeo.org/download/windows/) have a better chance with rgrass7? I'm willing to try out.
That is what I use when I'm obliged to test using Windows. There are number of more recent problems, because more R packages build in PROJ and GDAL, so the settings of PROJ_LIB may be overwritten - see other issues on that.
I checked in Windows and with OSGeo4W:
@veroandreo and others (https://lists.osgeo.org/pipermail/grass-dev/2018-November/090433.html, https://lists.osgeo.org/pipermail/grass-stats/2018-November/001800.html) found that you always must start R in the OSGeo4W shell in order to pick up the correct settings of the environment variables:
With R/Rgui/RStudio started outside the OSGeo4W shell:
> initGRASS("C:/OSGeo4W64/apps/grass/grass78", tempdir())
Error in if (!compatible) { : argument is of length zero
In addition: Warning messages:
1: In system(paste("g.dirseps.exe -g", shQuote(Sys.getenv("GISRC"))), :
running command 'g.dirseps.exe -g "junk"' had status 309
2: In system(paste("g.dirseps.exe -g", shQuote(gisDbase)), intern = TRUE) :
running command 'g.dirseps.exe -g "C:\Users\Roger\AppData\Local\Temp\Rtmp0cRH64"' had status 309
3: In dir.create(loc_path) :
cannot create dir 'NA\file22341d5d681a', reason 'No such file or directory'
4: In dir.create(paste(loc_path, "PERMANENT", sep = "/")) :
cannot create dir 'NA\file22341d5d681a\PERMANENT', reason 'No such file or directory'
5: In dir.create(paste(loc_path, mapset, sep = "/")) :
cannot create dir 'NA\file22341d5d681a\file2234b2491d', reason 'No such file or directory'
6: In system(paste("g.version", get("addEXE", envir = .GRASS_CACHE), :
running command 'g.version.exe' had status 309
Starting the OSGeo4W shell first, then R/Rgui/RStudio inside that:
> initGRASS("C:/OSGeo4W64/apps/grass/grass78", tempdir())
gisdbase C:/Users/Roger/AppData/Local/Temp/Rtmpeymcyp
location filedd463b7163
mapset filedd420d64b87
rows 1
columns 1
north 1
south 0
west 0
east 1
nsres 1
ewres 1
projection:
XY location (unprojected)
Warning message:
In initGRASS("C:/OSGeo4W64/apps/grass/grass78", tempdir()) :
working directory not writable, using tempfile for GISRC
Note the warning - the OSGeo4W shell starts in a directory that is not user-writable.
Thank you for helping out @rsbivand, thanks for the links! (adding here https://trac.osgeo.org/grass/ticket/3688 as a reference)
It might be useful to mention it in the rgrass7 package documentation as well (perhaps in initGRASS()
help), I doubt whether R users easily think of searching GRASS mailing lists when encountering this problem. (But at least now here it is, in the rgrass7 repo). Will try this ASAP, I'm not booting Windows by default.
With this commit, running against OSGeo4W but not through the OSGeo4W shell adds a warning to the error messages:
> initGRASS("C:/OSGeo4W64/apps/grass/grass78", tempdir())
Error in if (!compatible) { : argument is of length zero
In addition: Warning messages:
1: In initGRASS("C:/OSGeo4W64/apps/grass/grass78", tempdir()) :
NOTE: If using OSGeo4W GRASS, start R in the OSGeo4W shell
2: In system(paste("g.dirseps.exe -g", shQuote(Sys.getenv("GISRC"))), :
running command 'g.dirseps.exe -g "junk"' had status 309
3: In system(paste("g.dirseps.exe -g", shQuote(gisDbase)), intern = TRUE) :
running command 'g.dirseps.exe -g "C:\Users\Roger\AppData\Local\Temp\RtmpMHBRxB"' had status 309
4: In dir.create(loc_path) :
cannot create dir 'NA\file244863b85e5', reason 'No such file or directory'
5: In dir.create(paste(loc_path, "PERMANENT", sep = "/")) :
cannot create dir 'NA\file244863b85e5\PERMANENT', reason 'No such file or directory'
6: In dir.create(paste(loc_path, mapset, sep = "/")) :
cannot create dir 'NA\file244863b85e5\file24487b892b76', reason 'No such file or directory'
7: In system(paste("g.version", get("addEXE", envir = .GRASS_CACHE), :
running command 'g.version.exe' had status 309
However, I'm not sure that users read any messages - should this trigger an error itself? It checks whether OSGEO4W_ROOT
is defined; if it is not defined, but the gisBase=
argument includes toupper(...)
giving OSGEO4W
, the warning is thrown. Should this be an error?
The next commit/push now gives:
> initGRASS("C:/OSGeo4W64/apps/grass/grass78", tempdir())
Error in initGRASS("C:/OSGeo4W64/apps/grass/grass78", tempdir()) :
NOTE: If using OSGeo4W GRASS, start R in the OSGeo4W shell
but not tested other than raising the error when not in the OSGeo4W shell, and not raising it when in the shell understood as possessing the OSGEO4W_ROOT
environment variable. A comment has been added to the initGRASS()
help page. I attach a Windows binary build for testing:
rgrass7_0.2-3.zip
I much like the current, simple error message, thanks a lot! I confirm this behaves as expected.
library(rgrass7)
#> Loading required package: XML
#> GRASS GIS interface loaded with GRASS version: (GRASS not running)
initGRASS(gisBase = "C:/OSGeo4W64/apps/grass/grass78",
home = tempdir())
#> Error in initGRASS(gisBase = "C:/OSGeo4W64/apps/grass/grass78", home = tempdir(), : NOTE: If using OSGeo4W GRASS, start R in the OSGeo4W shell
Created on 2020-12-04 by the reprex package (v0.3.0)
Started from RStudio in OSGeo4W shell works :smile: :
library(rgrass7)
#> Loading required package: XML
#> GRASS GIS interface loaded with GRASS version: (GRASS not running)
getwd()
#> [1] "C:/Users/floris_vanderhaeghe/AppData/Local/Temp/RtmpEtYLCH/reprex4f8481f70e1"
initGRASS(gisBase = "C:/OSGeo4W64/apps/grass/grass78",
home = tempdir())
#> gisdbase C:/Users/FLORIS~1/AppData/Local/Temp/RtmpiUYrg8
#> location file74c751f27ab
#> mapset file74c26d73ee7
#> rows 1
#> columns 1
#> north 1
#> south 0
#> west 0
#> east 1
#> nsres 1
#> ewres 1
#> projection:
#> XY location (unprojected)
Created on 2020-12-04 by the reprex package (v0.3.0)
rgrass7 is only ever tested by my on the WinGRASS stand-alone. I do not use QGIS (noe Windows), so have little insight. Almost certainly OSGeo4W organises files differently from GRASS itself. If you'd like to check what is actually happening (are environment variables already set; are files in different places), I could look at this, but accessing Windows is not convenient for me, installing QGIS via OSGeo4W even less convenient.
For completeness, I can confirm that GRASS indeed works when installed as standalone from grass GIS for Windows via: https://grass.osgeo.org/download/
I have it running on my laptop with Windows 7.
library(rgrass7)
#> Loading required package: XML
#> GRASS GIS interface loaded with GRASS version: (GRASS not running)
initGRASS(gisBase = "C:/Program Files/GRASS GIS 7.8")
#> gisdbase C:/Users/HANS_V~1/AppData/Local/Temp/Rtmpgv9Pi5
#> location file23684ed2678d
#> mapset file2368796a5ac1
#> rows 1
#> columns 1
#> north 1
#> south 0
#> west 0
#> east 1
#> nsres 1
#> ewres 1
#> projection NA
Created on 2020-12-04 by the reprex package (v0.3.0)
I've added in extra protection (32/64 bit), but we cannot protect against OSGeo4W being installed in directories not using the standard names.
I'll post to R-sig-geo and grass-stats with a link to a Windows binary package and ask for comments; if OK, I'll submit to CRAN.
Splendid. Thanks for documenting it so well and for further extending the error message.
rgrass7 is only ever tested by my on the WinGRASS stand-alone. [...] Almost certainly OSGeo4W organises files differently from GRASS itself.
winGRASS standalone and OSGeo4W winGRASS use the same mechanism to integrate and provide access to R via the OSGeo4W shell.
the mechanism is provided by
https://github.com/OSGeo/grass/tree/master/mswindows/external/rbatch
@hellik thanks, but this isn't the problem here. The problem here is that when rgrass7::initGRASS() is pointed at WinGRASS from RGui/RStudio/console-R, it works. The same approach pointed at OSGEO4W/apps/grass (or 64) doesn't work, unless RGui/RStudio/console-R are started from the OSGEO4W shell.
Doing below test on Windows (in the context of https://github.com/r-spatial/link2GI/issues/48) with a fresh (yesterday's) OSGeo4W installation of QGIS + GRASS 7.8.4, the below behaviour was observed. I.e. 6 warnings and an error:
Error in if (!compatible) {: argument is of length zero
.Am I doing a correct implementation of the
initGRASS()
function in Windows?Created on 2020-12-02 by the reprex package (v0.3.0)
Session info
``` r devtools::session_info() #> - Session info --------------------------------------------------------------- #> setting value #> version R version 3.6.1 (2019-07-05) #> os Windows 7 x64 SP 1 #> system i386, mingw32 #> ui RTerm #> language (EN) #> collate Dutch_Belgium.1252 #> ctype Dutch_Belgium.1252 #> tz Europe/Paris #> date 2020-12-02 #> #> - Packages ------------------------------------------------------------------- #> package * version date lib source #> assertthat 0.2.1 2019-03-21 [1] CRAN (R 3.6.1) #> callr 3.5.1 2020-10-13 [1] CRAN (R 3.6.3) #> cli 2.2.0 2020-11-20 [1] CRAN (R 3.6.3) #> crayon 1.3.4 2017-09-16 [1] CRAN (R 3.6.1) #> desc 1.2.0 2018-05-01 [1] CRAN (R 3.6.1) #> devtools 2.3.2 2020-09-18 [1] CRAN (R 3.6.3) #> digest 0.6.27 2020-10-24 [1] CRAN (R 3.6.3) #> ellipsis 0.3.1 2020-05-15 [1] CRAN (R 3.6.3) #> evaluate 0.14 2019-05-28 [1] CRAN (R 3.6.1) #> fansi 0.4.1 2020-01-08 [1] CRAN (R 3.6.3) #> fs 1.5.0 2020-07-31 [1] CRAN (R 3.6.3) #> glue 1.4.2 2020-08-27 [1] CRAN (R 3.6.3) #> highr 0.8 2019-03-20 [1] CRAN (R 3.6.1) #> htmltools 0.5.0 2020-06-16 [1] CRAN (R 3.6.3) #> knitr 1.30 2020-09-22 [1] CRAN (R 3.6.3) #> magrittr 2.0.1 2020-11-17 [1] CRAN (R 3.6.3) #> memoise 1.1.0 2017-04-21 [1] CRAN (R 3.6.1) #> pkgbuild 1.1.0 2020-07-13 [1] CRAN (R 3.6.3) #> pkgload 1.1.0 2020-05-29 [1] CRAN (R 3.6.3) #> prettyunits 1.1.1 2020-01-24 [1] CRAN (R 3.6.3) #> processx 3.4.4 2020-09-03 [1] CRAN (R 3.6.3) #> ps 1.4.0 2020-10-07 [1] CRAN (R 3.6.3) #> R6 2.5.0 2020-10-28 [1] CRAN (R 3.6.3) #> remotes 2.2.0 2020-07-21 [1] CRAN (R 3.6.3) #> rgrass7 * 0.2-1 2019-08-06 [1] CRAN (R 3.6.3) #> rlang 0.4.9 2020-11-26 [1] CRAN (R 3.6.3) #> rmarkdown 2.5 2020-10-21 [1] CRAN (R 3.6.3) #> rprojroot 2.0.2 2020-11-15 [1] CRAN (R 3.6.3) #> sessioninfo 1.1.1 2018-11-05 [1] CRAN (R 3.6.1) #> stringi 1.4.6 2020-02-17 [1] CRAN (R 3.6.2) #> stringr 1.4.0 2019-02-10 [1] CRAN (R 3.6.1) #> testthat 3.0.0 2020-10-31 [1] CRAN (R 3.6.3) #> usethis 1.6.3 2020-09-17 [1] CRAN (R 3.6.3) #> withr 2.3.0 2020-09-22 [1] CRAN (R 3.6.3) #> xfun 0.19 2020-10-30 [1] CRAN (R 3.6.3) #> XML * 3.99-0.3 2020-01-20 [1] CRAN (R 3.6.3) #> yaml 2.2.1 2020-02-01 [1] CRAN (R 3.6.2) #> #> [1] C:/R/library #> [2] C:/Program Files/R/R-3.6.1/library ```Some extracts from my attempts to debug (which I did not proceed to the end). I ran these statements at or directly after the code line where below objects were made or used: