Basemap serveces not working correctly

[dominicroye]

I am not sure since when I run into this issue, but the outputs aren't correct anymore. Maybe related to some updates in other packages or dependencies.

library(basemaps)
library(mapSpain)
library(terra)

prov_gal <- esp_get_prov(prov = "Ourense")

set_defaults(map_service = "esri", map_type = "world_terrain_base")

bg <- basemap_geotif(prov_gal, map_res = 1) %>% rast() 

plotRGB(bg)

Even using other services, they are not correct outputs:

data(ext)
set_defaults(map_service = "osm", map_type = "topographic")
bg <- basemap_geotif(ext, map_res = 1) %>% rast() 

plotRGB(bg)

My info session is

> sessionInfo()
R version 4.3.0 (2023-04-21 ucrt)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 11 x64 (build 22621)

Matrix products: default

locale:
[1] LC_COLLATE=Spanish_Spain.utf8  LC_CTYPE=Spanish_Spain.utf8    LC_MONETARY=Spanish_Spain.utf8 LC_NUMERIC=C                  
[5] LC_TIME=Spanish_Spain.utf8    

time zone: Europe/Madrid
tzcode source: internal

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
 [1] basemaps_0.0.5     ggspatial_1.1.8    mapSpain_0.7.0     systemfonts_1.0.4  ggtext_0.1.2       terra_1.7-39       rmapshaper_0.5.0  
 [8] giscoR_0.3.5       RColorBrewer_1.1-3 sf_1.0-13          gtExtras_0.4.5     gt_0.9.0           scales_1.2.1       ggiraph_0.8.7     
[15] ggthemes_4.2.4     readxl_1.4.2       countrycode_1.5.0  lubridate_1.9.2    forcats_1.0.0      stringr_1.5.0      dplyr_1.1.2       
[22] purrr_1.0.1        readr_2.1.4        tidyr_1.3.0        tibble_3.2.1       ggplot2_3.4.2      tidyverse_2.0.0   

loaded via a namespace (and not attached):
  [1] rstudioapi_0.14         jsonlite_1.8.7          wk_0.7.3                magrittr_2.0.3          magick_2.7.4            farver_2.1.1           
  [7] rmarkdown_2.23          ragg_1.2.5              vctrs_0.6.3             paletteer_1.5.0         base64enc_0.1-3         webshot_0.5.5          
 [13] tinytex_0.45            htmltools_0.5.5         curl_5.0.1              raster_3.6-20           cellranger_1.1.0        s2_1.1.4               
 [19] sass_0.4.6              slippymath_0.3.1        KernSmooth_2.23-20      htmlwidgets_1.6.2       fontawesome_0.5.1       plyr_1.8.8             
 [25] zoo_1.8-12              stars_0.6-1             uuid_1.1-0              lifecycle_1.0.3         pkgconfig_2.0.3         R6_2.5.1               
 [31] fastmap_1.1.1           digest_0.6.32           colorspace_2.1-0        mapview_2.11.0          rematch2_2.1.2          leafem_0.2.0           
 [37] textshaping_0.3.6       crosstalk_1.2.0         rosm_0.2.6              reactR_0.4.4            labeling_0.4.2          lwgeom_0.2-13          
 [43] fansi_1.0.4             timechange_0.2.0        httr_1.4.6              abind_1.4-5             compiler_4.3.0          proxy_0.4-27           
 [49] bit64_4.0.5             withr_2.5.0             DBI_1.1.3               rgdal_1.6-7             maps_3.4.1              rappdirs_0.3.3         
 [55] leaflet_2.1.2           classInt_0.4-9          tools_4.3.0             units_0.8-2             reactable_0.4.4         glue_1.6.2             
 [61] satellite_1.0.4         gridtext_0.1.5          grid_4.3.0              generics_0.1.3          leaflet.providers_1.9.0 gtable_0.3.3           
 [67] tzdb_0.4.0              class_7.3-22            prettymapr_0.2.4        hms_1.1.3               sp_2.0-0                xml2_1.3.4             
 [73] utf8_1.2.3              pillar_1.9.0            vroom_1.6.3             pals_1.7                lattice_0.21-8          bit_4.0.5              
 [79] tidyselect_1.2.0        pbapply_1.7-2           knitr_1.43              V8_4.3.2                stats4_4.3.0            xfun_0.39              
 [85] stringi_1.7.12          yaml_2.3.7              geojsonsf_2.0.3         evaluate_0.21           codetools_0.2-19        cli_3.6.1              
 [91] munsell_0.5.0           dichromat_2.0-0.1       Rcpp_1.0.10             mapproj_1.2.11          png_0.1-8               parallel_4.3.0         
 [97] ellipsis_0.3.2          viridisLite_0.4.2       plotwidgets_0.5.1       e1071_1.7-13            crayon_1.5.2            rlang_1.1.1  

[ltbogaard]

I am also having this issue with the newest version of R. My colleague had it running properly on an older version of R from 2022. It must be an incompatibility with R version 4.3 or higher, and/or one of the dependencies.

[grwhumphries]

@16EAGLE - This probably has something to do with all the latest changed in terra - we have systematically gone through some of the other package dependencies that would have likely led to the basemaps not rendering properly - magick, pbapply, slippymath, etc... but terra is the only one that has had some pretty major changes recently. I'd imagine this is where the problem lies. Unfortunately, there doesn't seem to be an easy to way to install an older version of terra as it gives a series of non-zero exit status warnings when you try to install an older version from source

[apsteinmetz]

Same problem here. Same code worked a month ago. Maybe this error message is useful: satview <- basemaps::basemap_png( ext = my _sf_object, map_service = "esri", map_type = "world_imagery", map_res = NULL, verbose = TRUE, browse = FALSE ) C:/Users/Apste/AppData/Local/Temp/Rtmpi8SwAu/basemaps/esri_world_imagery_603_361.png: Access window out of range in RasterIO(). Requested (0,0) of size 640x512 on raster of 256x256. (GDAL error 5)

[apsteinmetz]

I compiled terra_1.7-29, the previous release, for windows, and all is well again. The compilation did spit out a lot of undefined object warnings for things in other packages and I got a warning that a configuration file might be needed but that did not prevent success.

[mliskPSU]

Has there been any update on this issue? It maybe due to certain institutional limits placed on my workstation, but the archive versions of terra do not compile on my Mac.

Update 8/16/2023 - I was able to leverage other resources in order to get a copy of terra_1.7-29. Specifically, a custom environment was built within a Singularity/Apptainer container and it is working fine.

[BlaiseKelly]

Maybe a bit off topic, but whilst I can see some nice additional functions and speed benefits of terra, the whole system feels like going from sf to sp. With raster it was clear what each function did and the rasters could be interrogated in the environment or using @ to get nlayers, max min etc..

Almost every week there is some serious bug in terra. Does anyone know of any plans to keep raster alive? I would be a supporter.

[mliskPSU]

@BlaiseKelly I personally know of none. In fact, I have been unsuccessful with installing raster on newer versions of R - even from archived source tarballs.

In a more concerning case, there was recent need for me to rerun some of my older code ran with R 3.x, and I had verified that raster was installed with that R version. However, once the version of R had been switched in my RStudio and some other packages had been updated, raster would no longer load into the session. Double checking, the files for the raster were no longer in my libraries directory. My best guess is that one of the packages which required an update called terra, which over-writ raster.

The only way I have been successful in retaining a version of raster has been with containers, and even then it has been with installing R through Ubuntu instead of CRAN.

[zross]

Just a note that for me it was working perfectly on R 4.3.0. Then I upgraded to 4.3.1 and I started having the same issues. I downgraded to 4.3.0 but now that version is having the same issue.

[zross]

A few more notes on this.

Using the rocker/geospatial Docker container for reproducibility it seems that the issue is related to the terra::mosaic function in terra starting with version 1.7.37.

I ran the code below using the same version of basemap (0.0.5) with different versions of terra and got these results:

1. Version 1.7.29 worked (see image below)
2. Version 1.7.37 did not work (see image below)
3. Version 1.7.39, current version, did not work (same bad image)
4. Development version from GitHub, did not work (same bad image)

When I replace the do.call(terra::mosaic, r) line in internal.R in the basemaps package with do.call(terra::merge, r) the image it produces seems correct.

This does not necessarily mean it's an issue with terra -- it could be related to how basemaps feeds the images to mosaic and the use of do.call.

circle <- sf::st_as_sfc("POINT(-76.498361 42.439586)", crs = 4326) |> 
  sf::st_transform(3857) |> 
  sf::st_buffer(10000)

basemaps::flush_cache()

png("mymap.png")
basemaps::basemap(circle)
dev.off()

Bad image

Good image

[ctlamb]

Also having issues with this.

data(ext)

basemaps::basemap_raster(
  ext = ext,
  map_res = 1, map_type = "terrain_bg")

produces error: "Error: [mosaic] resolution does not match"

[TheTS]

@zross your solution worked for me (replacing terra::mosaic with terra::merge). I just installed your fork of the package. Thanks!

[16EAGLE]

Thanks to all for the heads-up, I could not work on this earlier. This should be fixed with the latest CRAN version of basemaps, 0.0.6. Please reopen the bug persists.

[zross]

@16EAGLE thanks so much!