Use list-columns as alternative to `tm_mv` for multivariate variables

[MatthieuStigler]

I am getting a strange error message running a very simple call tm_shape(inter)+ tm_borders():

Error in sort.int(x, na.last = na.last, decreasing = decreasing, ...) : 'x' must be atomic

I suspect it happens whenever a sf object contains a list column? See example below, where the code will break when inter has list-column origins, but run if origins is removed?

library(sf)
#> Linking to GEOS 3.10.2, GDAL 3.4.3, PROJ 8.2.0; sf_use_s2() is TRUE

library(tmap)
#> 
#> Attaching package: 'tmap'
#> The following object is masked from 'package:datasets':
#> 
#>     rivers

packageVersion("tmap")
#> [1] '3.99.9001'

packageVersion("sf")
#> [1] '1.0.16'

col <- st_sfc(st_polygon(list(rbind(c(-1, 2), c(11, 2), c(11, 4), c(-1, 4), c(-1, 2)))),
      st_polygon(list(rbind(c(-1, 2), c(11, 2), c(11, 4), c(-1, 4), c(-1, 2))))) %>% 
  st_as_sf()

inter <- st_intersection(col)

tm_shape(inter)+
  tm_borders()
#> Error in sort.int(x, na.last = na.last, decreasing = decreasing, ...): 'x' must be atomic

## works:
# tm_shape(inter %>% select(-origins))+
#   tm_borders()

^{Created on 2024-07-07 with reprex v2.1.0}

[mtennekes]

Interesting example, thanks @MatthieuStigler

Not sure what to do with list columns. We ignore them. (Which is sufficient for your example) For the time being I'll do that.

A potential use case would be to use instead of tm_mv, to give the users more flexibility.

[mtennekes]

Done. I'll rename this issue