Basemap are not correctly rendered

[Bevann]

When animating GPS collar data everything works as expected, with the exception of the base maps that are downloaded through frames_spatial. The output does not contain all tiles, and are only in black and white. This is not unique to my data, when I run the example vignette the result is also in black and white, though all the tiles are present.

Is this perhaps related to the retirement of rgdal/rgeos and the change to the move2 package? If so, what would be the necessary changes to workflow as outlined in the vignette to include basemaps in animations?

[cbreiter]

Following. I've been having the same issue. Running the same script as I did prior to April 2023, but was using basemap OSM watercolor which no longer works... Any advice or updates on this?

[smerker]

Yes I've seen this same problem.

[andrewdigby]

I'm also having the same problem with scripts which were previously fine, using several services & types (e.g. osm/topographic; mapbox/satellite).

For some service/type combinations (osm/streets, carto/voyager) I'm now also getting this new error:

Loading basemap 'streets' from map service 'osm'...
Assigning raster maps to frames...
Error in if (row1 == 1 & row2 == nrow(x) & col1 == 1 & col2 == ncol(x)) { : 
  missing value where TRUE/FALSE needed

I'm seeing similar problems with package {basemaps}.

[ingomiller]

I'm having the same error for all basemap types I tried (esri). Using the same script as before where the basemaps showed in colour. Please advise/fix

[samfranks]

I've also run into this problem. This is almost certainly caused by the same issue logged here for the basemaps package, caused by major changes in the terra package. There is a potential workaround logged in the final comment in the issue thread, if it could also be applied in moveVis - I've not personally tried. Further up the thread, this comment suggests that reverting to earlier versions of terra might not be straightforward as a workaround.

[ErikaPeirce-USDA]

I applied the work around samfranks mentioned (Thank you!) and it solved the basemaps issue. To do this I 1. uninstalled basemaps, 2. forked the repo from zross . 3. downloaded my forked repo using devtools and it worked like a charm.

[NinoPierantonio]

Hi, I am having the same issue with moveVis. I have followed the solution posted by ErikaPeirce-USDA and R does not crash anymore. However, I get the following:

Checking temporal alignment...
Processing movement data...
Approximated animation duration: ≈ 34.12s at 25 fps for 853 frames
Retrieving and compositing basemap imagery...
Loading basemap 'topographic' from map service 'osm'...
  |==============================================| 100% elapsed=01s  
Assigning raster maps to frames...
Error in if (row1 == 1 & row2 == nrow(x) & col1 == 1 & col2 == ncol(x)) { : 
  missing value where TRUE/FALSE needed

If I just run a basic example as posted on zross github, e.g.,:

data(ext)
set_defaults(map_service = "osm", map_type = "topographic")
basemap_magick(ext)

I obtain a map so I am not sure where the above error is coming from. Any advice would be great.

[agblake22]

I am having the same issues with my basemap displaying correctly; however, I am having trouble applying the workaround.

@ErikaPeirce-USDA could you please elaborate for this novice on what your 2nd and 3rd bullet points mean (e.g., what does fork the repo mean exactly?)

[Bevann]

You should be able to install his fork (duplication of a package where some of the code is modified) of the package and then use it in place of the original basemaps package

remotes::install_github("zross/basemap-fork")

[NinoPierantonio]

@agblake22, i solved my issue by:

remotes::install_github("16eagle/moveVis") #install.packages("remotes") from github

paths<-.libPaths() #list the directories where R has saved packages in your local machine

remove.packages("basemaps", paths[1]) #remove the package basemaps from each directory (in my case 2)
remove.packages("basemaps", paths[2]) 

.rs.restartR() #restart the R session

remotes::install_github("zross/basemap-fork") #install the basemap-fork from ZROSS @https://github.com/zross/basemap-fork.git

library(basemaps) #load the package

If you still have problems with basemaps, you need to install the proper version of Rtools for your computer from https://cran.r-project.org/bin/windows/Rtools/

N

[16EAGLE]

Thanks for reporting this bug. This should be resolved with the latest version of basemaps on CRAN: Please update basemaps using install.packages("basemaps") and optionally update moveVis from GitHub using remotes::install_github("16eagle/moveVis") to apply the patch.

[cshuert]

I'm not sure if this is helpful or not for this issues (if others are still having issues with it), but the maps seem to render correctly only if all the projections from the original data (e.g. locations from movement data) are at WGS 84 (EPSG: 4326). I've tried mapbox and esri basemaps which seem to render well at that projection, but not in others (e.g. EPSG: 3347).

Perhaps this might help narrow in on the parts of frames_spatial() that might not be rendering correctly with other projections?

Thanks!