read_RAST() fails when specifying mapset via "@"
TillF opened this issue · 7 comments
read_RAST() successfully reads an existing raster map when only specified by its "first name", but fails when its "surname", i.e. its mapset is also supplied via "@...":
execGRASS("r.info", map="svc")
and
execGRASS("r.info", map="svc@PERMANENT")
work as expected:
+----------------------------------------------------------------------------+
| Map: svc@PERMANENT Date: Mon Jan 22 11:44:08 2024 |
| Mapset: PERMANENT Login of Creator: alban |
Specifying only the simple name works:
tt = read_RAST("svc")
Checking GDAL data type and nodata value...
100%
Using GDAL data type <UInt32>
Exporting raster data to RRASTER format...
100%
ROUTGD~1 komplett. File
<C:\Users\francke\AppData\Local\Temp\RtmpGMJelV\filef905301692a.grd>
created.
Using @-notation fails:
tt = read_RAST("svc@PERMANENT")
Fehler in read_RAST("svc@PERMANENT") : svc@PERMANENT not found
Tested with GRASS 8.3.1, standalone installer.
> sessionInfo()
R version 4.2.2 (2022-10-31 ucrt)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19045)
Matrix products: default
locale:
[1] LC_COLLATE=German_Germany.utf8 LC_CTYPE=German_Germany.utf8 LC_MONETARY=German_Germany.utf8
[4] LC_NUMERIC=C LC_TIME=German_Germany.utf8
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] rgrass_0.4-1 remotes_2.4.2 pryr_0.1.6 panelaggregation_0.1.1
[5] data.table_1.14.8 curl_5.0.0 gWidgets_0.0-54 rpart_4.1.19
[9] devtools_2.4.5 usethis_2.2.2 lumpR_3.1.11 sf_1.0-9
[13] terra_1.7-55 rgeos_0.6-1 rgdal_1.6-7 RODBC_1.3-23
[17] foreach_1.5.2 xts_0.12.2 zoo_1.8-11 maptools_1.1-8
[21] cluster_2.1.4 raster_3.6-26 sp_2.1-2
loaded via a namespace (and not attached):
[1] Rcpp_1.0.11 lattice_0.20-45 prettyunits_1.1.1 class_7.3-20 ps_1.7.2
[6] digest_0.6.31 utf8_1.2.2 mime_0.12 R6_2.5.1 e1071_1.7-12
[11] pillar_1.9.0 rlang_1.1.2 rstudioapi_0.14 miniUI_0.1.1.1 urlchecker_1.0.1
[16] callr_3.7.3 stringr_1.5.0 foreign_0.8-83 htmlwidgets_1.6.0 proxy_0.4-27
[21] shiny_1.8.0 compiler_4.2.2 httpuv_1.6.9 pkgconfig_2.0.3 pkgbuild_1.4.0
[26] htmltools_0.5.4 tidyselect_1.2.0 tibble_3.2.1 codetools_0.2-18 fansi_1.0.3
[31] crayon_1.5.2 dplyr_1.1.4 later_1.3.0 grid_4.2.2 xtable_1.8-4
[36] lifecycle_1.0.3 DBI_1.2.0 magrittr_2.0.3 units_0.8-1 KernSmooth_2.23-20
[41] cli_3.6.2 stringi_1.7.8 cachem_1.0.6 fs_1.5.2 promises_1.2.0.1
[46] xml2_1.3.6 ellipsis_0.3.2 generics_0.1.3 vctrs_0.6.5 iterators_1.0.14
[51] tools_4.2.2 glue_1.6.2 purrr_1.0.1 processx_3.8.0 pkgload_1.3.2
[56] fastmap_1.1.1 sessioninfo_1.2.2 classInt_0.4-8 memoise_2.0.1 profvis_0.3.7
>
@TillF Do you ever use the same raster name in different mapsets? I'm trying to disentangle the way g.list handles names and mapsets through its pattern argument, which does not use the full path.
In the example case there is only mapset PERMANENT and, consequently, only one raster with this name.
However, I have other locations with rasters of this name, but I guess this should be of no influence.
side note: According to my old script, in prior versions of both GRASS and rGRASS7, the name resolution seemed to work, except that "...@mapsetname" always had to be supplied whenever rasters of the same name existed in parallel mapsets, even when trying to access only the current mapset.
The reason for the tightening was to try to trap non-existing raster names causing problems at r.info later in the process. I've committed and pushed d405eab to try to address this. Please let me know if it is sufficient; do you need a Windows build of the package?
I installed 0.4-2 via install_github(). It works as expected for me. Issue can be closed.
Thanks a lot!
@TillF do you need a submission to CRAN in the very near future, or is it OK to wait a little to see whether the 0.4-1 release caused other difficulties first?
No sweat, I don't need any immediate release. Thanks, though.