sf 1.0 will switch to using S2 geometry for ellipsoidal coordinates

[edzer]

As announced here in June last year, and also in the NEWS file around the same time, it is planned that where possible sf will use the spherical geometry operators of package s2 instead of the GEOS routines that assume projected coordinates. I've now run reverse dependency checks and found regressions in the following packages ("check" means: pkg maintainer informed):

• csodata
• eSDM
• geomultistar
• jpmesh
• mapping
• mapsf
• MODIS
• nhdplusTools
• nhdR
• osmextract
• redist
• rerddapXtracto (false positive: url timeout?)
• rmapzen
• sen2r
• sfnetworks
• slga
• tmap
• tmaptools

I have opened issues / written emails to all packages affected (issues mentioned below).

Testing your package while sf uses s2 can be done by setting

sf::sf_use_s2(TRUE)

or by specifying the environment variable _SF_USE_S2 to the value true (case sensitive); the latter can be done from within R with

Sys.setenv("_SF_USE_S2", "true")

but that needs to be done before sf is loaded.

[edzer]

Dear package author,

while checking reverse dependency's against the sf 1.0 candidate which uses s2 as a geometry back-end when using ellipsoidal coordinates, we found a regression. Please verify that this is not a false positive, and update your package on CRAN in a timely fashion before sf is released (which is not earlier than May 1st).

See #1649 for details.

[edzer]

For those interested in a low-res world map valid on S2, created by @paleolimbot :

library(sf)
# Linking to GEOS 3.9.0, GDAL 3.2.1, PROJ 7.2.1
library(s2)
st_as_sf(s2_data_tbl_countries)
# Simple feature collection with 177 features and 2 fields
# Geometry type: MULTIPOLYGON
# Dimension:     XY
# Bounding box:  xmin: -180 ymin: -85.60904 xmax: 180 ymax: 83.64513
# CRS:           NA
# First 10 features:
#                                   name               continent
# 1                          Afghanistan                    Asia
# 2                               Angola                  Africa
# 3                              Albania                  Europe
# 4                 United Arab Emirates                    Asia
# 5                            Argentina           South America
# 6                              Armenia                    Asia
# 7                           Antarctica              Antarctica
# 8  French Southern and Antarctic Lands Seven seas (open ocean)
# 9                            Australia                 Oceania
# 10                             Austria                  Europe
#                          geometry
# 1  MULTIPOLYGON (((61.21082 35...
# 2  MULTIPOLYGON (((16.32653 -5...
# 3  MULTIPOLYGON (((20.59025 41...
# 4  MULTIPOLYGON (((51.57952 24...
# 5  MULTIPOLYGON (((-65.5 -55.2...
# 6  MULTIPOLYGON (((43.58275 41...
# 7  MULTIPOLYGON (((-59.57209 -...
# 8  MULTIPOLYGON (((68.935 -48....
# 9  MULTIPOLYGON (((145.398 -40...
# 10 MULTIPOLYGON (((16.97967 48...

[paleolimbot]

For those getting errors involving redundant, invalid, or crossing edges, it is likely because s2 assumes the shortest distance on the sphere between two points (not along a constant latitude or longitude as would appear in a standard cartesian plot with points connected). A few things worth trying are:

• st_segmentize() in cartesian space before converting to s2. I don't know if there's an easy way to do this with st_use_s2(TRUE)...maybe there should be?
• Use s2_rebuild(), which is like st_make_valid() but for the sphere. I wonder it st_as_s2() should have a rebuild argument because right now it's a little hard to access (right now I think you need to do st_as_sf(s2_rebuild(s2_geog_from_wkb(st_as_binary(x), check = FALSE)))))
• Use s2_snap_to_grid() (under the hood this us just s2_rebuild() with a snap function). It would probably be helpful if we made this easy to do as well.

I'm certainly happy to PR some of this in (but @edzer should decide how/if it's done since he's spent more time in sf!)

[edzer]

We can't call s2_rebuild when the error already happens in s2_geog_from_wkb:

library(tmap)
library(sf)
# Linking to GEOS 3.9.0, GDAL 3.2.1, PROJ 7.2.1
library(s2)
data(World)
x = st_transform(World, 4326)
# qtm(x) # -->> fails
w = s2_geog_from_wkb(st_as_binary(st_geometry(x)))
# Error in s2_geography_from_wkb(wkb_bytes, oriented = oriented, check = check) : 
#   Loop 7 is not valid: Edge 171 crosses edge 174
# Calls: s2_geog_from_wkb -> new_s2_xptr -> s2_geography_from_wkb
# Execution halted

[edzer]

And the following also didn't help:

w = s2_geog_from_wkb(st_as_binary(st_segmentize(st_geometry(x), units::set_units(10, km))))
w = s2_geog_from_wkb(st_as_binary(st_segmentize(st_geometry(x), units::set_units(1, km))))
w = s2_geog_from_wkb(st_as_binary(st_segmentize(st_geometry(x), units::set_units(.1, km))))
g = st_geometry(x)
st_crs(g) = NA # so we segmentize in "degrees"
w = s2_geog_from_wkb(st_as_binary(st_segmentize(g, .01)))
w = s2_geog_from_wkb(st_as_binary(st_segmentize(g, .1)))
w = s2_geog_from_wkb(st_as_binary(st_segmentize(g, .001)))
w = s2_geog_from_wkb(st_as_binary(st_segmentize(g, .0001)))

[paleolimbot]

I think the key is check = FALSE:

library(tmap)
#> Warning: package 'tmap' was built under R version 4.0.3
library(sf)
#> Linking to GEOS 3.8.0, GDAL 3.0.4, PROJ 6.3.1
# Linking to GEOS 3.9.0, GDAL 3.2.1, PROJ 7.2.1
library(s2)
#> Warning: package 's2' was built under R version 4.0.5
data(World)
x = st_transform(World, 4326)
# qtm(x) # -->> fails
w = s2_geog_from_wkb(st_as_binary(st_geometry(x)), check = FALSE)

library(s2plot) # remotes::install_github("paleolimbot/s2plot")
s2plot(s2_rebuild(w))

^{Created on 2021-04-19 by the reprex package (v2.0.0)}

[edzer]

Bingo! This makes tmap and tmaptools pass check, and possibly a number of others. I will run an entire revdep check with this change, and report back. Out of interest: is s2_rebuild an expensive operation?

[paleolimbot]

I think so - it's something like a Union. I think it might be worth exposing check as an argument to st_as_s2() so that when a user gets this error they have recourse (rather than turning this on by default).

As a note, when I was testing with BigQuery, I did notice that they do this operation when taking any foreign input (wkt, wkb). I think they also round coordinates on input to snap level 30.

[edzer]

I think it might be worth exposing check as an argument to st_as_s2() so that when a user gets this error they have recourse (rather than turning this on by default).

That might be a bit hard: you'd have to pass it e.g. in every st_intersects(a, b), as that converts to s2, calls s2's intersection, and returns.

Are there any risks on the way back: S2 geometries converted to wkt, then to sf, then e.g. projected to whatever?

[jthurner]

just to confirm – 6de3420 fixes all errors with polygons from rnaturalearth::ne_countries, across any types and scales, both CRAN and github versions. I wrote a little test to identify which polygons were failing, but you got ahead of me ;)

[paleolimbot]

The "risk" is mostly that it's slow and shouldn't have to be. I think that any operation that returns a gemoetry (intersection, etc.) will probably be unaffected but I forget the details and I'm worried that it could do things like change the direction of a line (I guess that a GEOS overlay operation might do this too though).

The overlay ops might be much faster than GEOS though so users might not notice?

Two ways to provide an escape hatch here without running all input through s2_rebuild() would be

• Use the st_precision() of a sfc to decide (i.e., if a precision is defined, export to WKB without rounding, read into s2 with check = FALSE, and call s2_snap_to_grid(), which is rebuild with some defaults). Then if a user gets errors they can do e.g. st_union(st_set_precision(x)).
• Use s2_rebuild() in st_make_valid(), whose input is always passed to s2 with check = FALSE

I think these are along the same lines as how users currently have to handle invalid input. In the meantime s2 should provide an equivalent to st_is_valid() so that users like @jthurner don't have write their own tests for which polygons are invalid!

[rsbivand]

Re: st_make_valid() - the underlying GEOS is being looked at in relation to a new planar geometry fixer: https://lists.osgeo.org/pipermail/geos-devel/2021-April/010205.html.

[jthurner]

FWIW, here are the failing polygons from the most recent rnaturalearth package versions. None of the approaches I had seen before today were able to make them convert (code).

#> Simple feature collection with 6 features and 6 fields
#> Geometry type: MULTIPOLYGON
#> Dimension:     XY
#> Bounding box:  xmin: -180 ymin: 8.229188 xmax: 180 ymax: 81.2504
#> CRS:           +proj=longlat +datum=WGS84 +no_defs +ellps=WGS84 +towgs84=0,0,0
#>              dataset   name st_valid fixed_prec fixed_prep_script fixed_lwgeom
#> 1   ne_countries_110  Sudan     TRUE      FALSE             FALSE        FALSE
#> 2   ne_countries_110 Russia     TRUE      FALSE              TRUE        FALSE
#> 3   ne_map_units_110  Sudan     TRUE      FALSE             FALSE        FALSE
#> 4   ne_map_units_110 Russia     TRUE      FALSE              TRUE        FALSE
#> 5 ne_sovereignty_110  Sudan     TRUE      FALSE             FALSE        FALSE
#> 6 ne_sovereignty_110 Russia     TRUE      FALSE              TRUE        FALSE

For rnaturalearth on CRAN, there are a lot more errors, in both low and medium scale. Some go away with st_set_precision(1e7) but the majority still fails with the methods tried.

[rsbivand]

Note that Centos 7 runs very old PROJ/GDAL/GEOS, so you need also to handle those. The CRAN Solaris instance runs moderately old PROJ (5.2.0), GDAL (2.2.4) and GEOS I think 3.7, but may be 3.6. It is very useful in detecting packages that do not condition for PROJ versions.

[jlacko]

I have good experience with world dataset from giscoR::gisco_get_countries() - it is in EPSG:4326 and seems to be valid.

It comes from the Eurostat / via GISCO and seems to be on a NC license, don't know if that is an issue...

[mtennekes]

Thanks @jlacko That is a good source indeed. I work in official statistics, so Eurostat has my sympathy vote. I'll continue with sharing details on the 'new world' dataset in tmap in https://github.com/mtennekes/tmap/issues/564

[jlacko]

Glad to be of service! Eurostat are good guys, even though the giscoR package is not officially endorsed by them and just kind of sort of hijacks their API, but more importantly (against current sf / s2 versions):

giscoR::gisco_get_countries() |>
  sf::st_is_valid() |>
  all()
[1] TRUE

[edzer]

Clever:

> giscoR::gisco_get_countries() |> st_bbox()
      xmin       ymin       xmax       ymax 
-180.00000  -89.90000  179.99999   83.65187 

they created a small gap at the antimeridean.

[Nowosad]

I have pondered how to update the world object from spData without changing it drastically. My current idea is:

library(sf)
#> Linking to GEOS 3.9.0, GDAL 3.2.2, PROJ 7.2.1
library(spData)
library(giscoR)

sf_use_s2(FALSE)
#> Spherical geometry (s2) switched off

bb = st_bbox(giscoR::gisco_get_countries())
world2 = st_intersection(world, st_as_sfc(bb))
#> although coordinates are longitude/latitude, st_intersection assumes that they are planar
#> Warning: attribute variables are assumed to be spatially constant throughout all
#> geometries

sf_use_s2(TRUE)
#> Spherical geometry (s2) switched on

isv = sf::st_is_valid(world2)
world2$name_long[!isv]
#> [1] "Sudan"

world3 = st_make_valid(world2)
plot(world3[,1])

^{Created on 2021-06-13 by the reprex package (v2.0.0)}

@edzer @paleolimbot is that make any sense? Can I update the spData package with world3?

[paleolimbot]

Almost there! I get that Sudan is not valid in world3. You could try a rebuild with split_crossing_edges = TRUE...I forget how to do this in sf, but in s2 you can get there like this:

library(sf)
#> Linking to GEOS 3.8.1, GDAL 3.2.1, PROJ 7.2.1
library(spData)
#> To access larger datasets in this package, install the spDataLarge
#> package with: `install.packages('spDataLarge',
#> repos='https://nowosad.github.io/drat/', type='source')`
library(giscoR)

sf_use_s2(FALSE)
#> Spherical geometry (s2) switched off

bb = st_bbox(giscoR::gisco_get_countries())
world2 = st_intersection(world, st_as_sfc(bb))
#> although coordinates are longitude/latitude, st_intersection assumes that they are planar
#> Warning: attribute variables are assumed to be spatially constant throughout all
#> geometries

sf_use_s2(TRUE)
#> Spherical geometry (s2) switched on

isv = sf::st_is_valid(world2)
world2$name_long[!isv]
#> [1] "Sudan"

world3 <- world2
world3$geom <- world3$geom %>% 
  s2::as_s2_geography(check = F) %>%
  s2::s2_union() %>% 
  s2::s2_rebuild(s2::s2_options(split_crossing_edges = TRUE)) %>% 
  st_as_sfc()
plot(world3[,1])

isv = sf::st_is_valid(world3)
world2$name_long[!isv]
#> character(0)

# experimental pkg, I just use it to check s2 objects
s2plot::s2plot(world3, col = "grey90", projection = s2plot::s2plot_projection_orthographic("POINT (0 0)"))

s2plot::s2plot(world3, col = "grey90", projection = s2plot::s2plot_projection_orthographic("POINT (180 0)"))

s2plot::s2plot(world3, col = "grey90", projection = s2plot::s2plot_projection_orthographic("POINT (0 90)"))

s2plot::s2plot(world3, col = "grey90", projection = s2plot::s2plot_projection_orthographic("POINT (0 -90)"))

^{Created on 2021-06-13 by the reprex package (v0.3.0)}

[Nowosad]

Thank you a lot @paleolimbot ! I have already added the changes to the dev version of spData (Nowosad/spData@957c1db) and plan to update it on CRAN sometimes this week.

[mtennekes]

Thanks @paleolimbot and @Nowosad! I've healed tmap's World dataset in a similar way as you can see below. I also tested the orthogonal projects using the old approach: with an orthogonal crs ("+proj=ortho"). However, it doesn't always work (see below). Any idea how to create orthogonal views of the earth? Of course s2plot works, but (surprise surprise) my goal is to embed these plots into tmap.

library(sf)
#> Linking to GEOS 3.8.0, GDAL 3.0.4, PROJ 6.3.1
library(spData)
#> To access larger datasets in this package, install the spDataLarge
#> package with: `install.packages('spDataLarge',
#> repos='https://nowosad.github.io/drat/', type='source')`
library(giscoR)
library(tmap)
    
sf_use_s2(FALSE)
#> Spherical geometry (s2) switched off

# load 'broken' World dataset from tmap
data(World)

bb = st_bbox(giscoR::gisco_get_countries())
W2 = World |>
    st_transform(crs = 4326) |>
    st_intersection(st_as_sfc(bb))
#> although coordinates are longitude/latitude, st_intersection assumes that they are planar
#> Warning: attribute variables are assumed to be spatially constant throughout all
#> geometries

sf_use_s2(TRUE)
#> Spherical geometry (s2) switched on

isv = sf::st_is_valid(W2)
W2$name[!isv]
#> factor(0)
#> 177 Levels: Afghanistan Albania Algeria Angola Antarctica Argentina ... Zimbabwe

tm_shape(W2) + tm_polygons()

tm_shape(W2, projection = "+proj=eck4") + tm_polygons() # old default CRS for World

# round earth tests:
tm_shape(W2, projection = "+proj=ortho +lon_0=0 +lat_0=0") + tm_polygons() 

tm_shape(W2, projection = "+proj=ortho +lon_0=0 +lat_0=90") + tm_polygons()

tm_shape(W2, projection = "+proj=ortho +lon_0=0 +lat_0=45") + tm_polygons()
#> Error: Shape contains invalid polygons. Please fix it or set tmap_options(check.and.fix = TRUE) and rerun the plot

# valid? 
W2_ortho_0_0 = st_transform(W2, "+proj=ortho +lon_0=0 +lat_0=0")
st_is_valid(W2_ortho_0_0)
#>   [1]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#>  [13]  TRUE  TRUE  TRUE FALSE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#>  [25]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#>  [37]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#>  [49]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#>  [61]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#>  [73]  TRUE FALSE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#>  [85]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#>  [97]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE FALSE  TRUE  TRUE  TRUE  TRUE  TRUE
#> [109]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#> [121]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#> [133]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#> [145]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#> [157]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#> [169]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE

W2_ortho_0_90 = st_transform(W2, "+proj=ortho +lon_0=0 +lat_0=90")
st_is_valid(W2_ortho_0_90)
#>   [1]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#>  [13]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE FALSE  TRUE
#>  [25]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE FALSE FALSE FALSE
#>  [37]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE FALSE  TRUE
#>  [49]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#>  [61]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#>  [73]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#>  [85] FALSE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#>  [97]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#> [109]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#> [121]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#> [133]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#> [145]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE
#> [157]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE FALSE  TRUE  TRUE
#> [169]  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE  TRUE

W2_ortho_0_45 = st_transform(W2, "+proj=ortho +lon_0=0 +lat_0=45")
st_is_valid(W2_ortho_0_45)
#>   [1] NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA
#>  [26] NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA
#>  [51] NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA
#>  [76] NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA
#> [101] NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA
#> [126] NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA
#> [151] NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA NA
#> [176] NA NA

# s2plot works for 0 45:
library(s2plot)
s2plot::s2plot(W2, col = "grey90", projection = s2plot::s2plot_projection_orthographic("POINT (0 45)"))

^{Created on 2021-06-14 by the reprex package (v2.0.0)}

[edzer]

Any idea how to create orthogonal views of the earth?

Polygons that are partly out of sight (behind the globe) may come back as invalid: you need to clip them to the part(s) of the polygon that is visible before projecting. I think that is what s2plot does, the challenge is to find where / how ;-) There's also an (independent) example here.

[Saadi4469]

Any update on the invalid polygon error from tmap, or do I need to downgrade the sf package to make it work with tmap?

[donojazz]

I love tmap and have been using it constantly for the 30 Day Map Challenge. It has been working great until yesterday.

On code that ran great 2 days ago, I now get:

Error: Shape contains invalid polygons. Please fix it or set tmap_options(check.and.fix = TRUE) and rerun the plot

constantly. After playing with marmap and having it hose my R environmant, especially tidyverse. I had to delete my entire R environment along with libraries. I worked with Jenny Bryan and she helped with the tidyverse issue tidyverse/tidyverse#316 (comment) We agreed about the fresh start with R. But, now, I am getting errors with tmap. I am getting the same errors off your sample vignettes (tmap: version changes). Can you assist? Thanks. Jim

Here is my sys info.

sessionInfo()

R version 4.2.2 (2022-10-31 ucrt)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 10 x64 (build 19044)

Matrix products: default

locale:
[1] LC_COLLATE=English_United States.utf8 LC_CTYPE=English_United States.utf8
[3] LC_MONETARY=English_United States.utf8 LC_NUMERIC=C
[5] LC_TIME=English_United States.utf8

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

other attached packages:
[1] DT_0.26 mapview_2.11.0 tigris_1.6.1 spdplyr_0.4.0 readxl_1.4.1
[6] rgdal_1.6-2 sp_1.5-1 sf_1.0-9 tmaptools_3.1-1 tmap_3.3-3
[11] leaflet_2.1.1 forcats_0.5.2 stringr_1.4.1 dplyr_1.0.10 purrr_0.3.5
[16] readr_2.1.3 tidyr_1.2.1 tibble_3.1.8 ggplot2_3.4.0 tidyverse_1.3.2

loaded via a namespace (and not attached):
[1] googledrive_2.0.0 leafem_0.2.0 colorspace_2.0-3
[4] ellipsis_0.3.2 class_7.3-20 satellite_1.0.4
[7] base64enc_0.1-3 fs_1.5.2 dichromat_2.0-0.1
[10] rstudioapi_0.14 proxy_0.4-27 bit64_4.0.5
[13] fansi_1.0.3 lubridate_1.9.0 xml2_1.3.3
[16] codetools_0.2-18 cachem_1.0.6 knitr_1.40
[19] jsonlite_1.8.3 broom_1.0.1 dbplyr_2.2.1
[22] png_0.1-7 compiler_4.2.2 httr_1.4.4
[25] backports_1.4.1 assertthat_0.2.1 fastmap_1.1.0
[28] gargle_1.2.1 cli_3.4.1 leaflet.providers_1.9.0
[31] htmltools_0.5.3 tools_4.2.2 gtable_0.3.1
[34] glue_1.6.2 rappdirs_0.3.3 Rcpp_1.0.9
[37] jquerylib_0.1.4 cellranger_1.1.0 raster_3.6-3
[40] vctrs_0.5.0 leafsync_0.1.0 crosstalk_1.2.0
[43] lwgeom_0.2-9 xfun_0.34 rvest_1.0.3
[46] timechange_0.1.1 lifecycle_1.0.3 XML_3.99-0.12
[49] googlesheets4_1.0.1 terra_1.6-17 scales_1.2.1
[52] vroom_1.6.0 hms_1.1.2 parallel_4.2.2
[55] RColorBrewer_1.1-3 curl_4.3.3 yaml_2.3.6
[58] sass_0.4.2 stringi_1.7.8 maptools_1.1-5
[61] e1071_1.7-12 rlang_1.0.6 pkgconfig_2.0.3
[64] spbabel_0.5.5 evaluate_0.18 lattice_0.20-45
[67] htmlwidgets_1.5.4 bit_4.0.4 tidyselect_1.2.0
[70] magrittr_2.0.3 R6_2.5.1 generics_0.1.3
[73] DBI_1.1.3 pillar_1.8.1 haven_2.5.1
[76] foreign_0.8-83 withr_2.5.0 units_0.8-0
[79] stars_0.5-6 abind_1.4-5 modelr_0.1.10
[82] crayon_1.5.2 uuid_1.1-0 KernSmooth_2.23-20
[85] utf8_1.2.2 tzdb_0.3.0 rmarkdown_2.18
[88] grid_4.2.2 reprex_2.0.2 digest_0.6.30
[91] classInt_0.4-8 webshot_0.5.4 stats4_4.2.2
[94] munsell_0.5.0 viridisLite_0.4.1 bslib_0.4.1

[edzer]

Well, a reprex is missing and your issue sounds like a tmap issue. @mtennekes ?