read_RAST() fails when specifying mapset via "@"

[TillF]

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     
>

[rsbivand]

@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.

[TillF]

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.

[TillF]

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.

[rsbivand]

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 https://github.com/rsbivand/rgrass/commit/d405eabf64ea618c5e261dcf73043bedd46a2325 to try to address this. Please let me know if it is sufficient; do you need a Windows build of the package?

[TillF]

I installed 0.4-2 via install_github(). It works as expected for me. Issue can be closed. Thanks a lot!

[rsbivand]

@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?

[TillF]

No sweat, I don't need any immediate release. Thanks, though.