Deal all,
the new pivot_longer and pivot_wider are not working with sf and fails with Error: Can't slice a scalar. This is due to the fact that there is not yet a dedicated wrapper for those function in sf. If you are interested, I can try to propose a pull request.
Yes, please do. Maybe gather.sf and spread.sf in file tidyverse.R can be of help.
I was optimistic... So far those functions are not s3_methods:
https://github.com/tidyverse/tidyr/issues/626
In my understanding, most of the methods in tidyverse.R do is basically:
sf class from the objectNextMethod()sfThe first step is vctrs::vec_proxy() and the last step is vctrs::vec_restore().
Since people outside tidy-core have no idea what is coming of extra backwards-incompatible innovations, maybe it is more sensible to wait until tidy-core knows what it is doing, or at least says so. Break stuff only when you really need to. Its design and development principles are unknown - many appear in a development iteration without warning as a consequence of other changes, like the fallout from the vctrs innovations. This absorbs more time than sensible trying to adapt. We need urgently a blog showing R-spatial workflows that are time consistent (do the same thing across at least two tidyverse iterations) and which show how to re-write the same workflows outside tidyverse. Many serious users need stable workflows that do not require reproducibility-breaking changes at each tidyverse iteration.
@yutannihilation that sounds simple, but when I try nothing happens:
library(sf)
# Linking to GEOS 3.7.1, GDAL 2.4.2, PROJ 5.2.0
df = data.frame(a = 1:2, b = 2:3)
p = st_sfc(st_point(0:1), st_point(1:2))
library(tidyr)
pivot_longer(df, c(a,b))
# # A tibble: 4 x 2
# name value
# <chr> <int>
# 1 a 1
# 2 b 2
# 3 a 2
# 4 b 3
df$geom = p
sf = st_as_sf(df)
pivot_longer(sf, c(a,b)) # still returns a tibble:
# [1] "vec_restore.sf is being called"
# [1] "vec_restore.sf is being called"
# [1] "vec_restore.sf is being called"
# # A tibble: 4 x 3
# geom name value
# <POINT> <chr> <int>
# 1 (0 1) a 1
# 2 (0 1) b 2
# 3 (1 2) a 2
# 4 (1 2) b 3
# Warning message:
# In val_cols[col_id] <- unname(as.list(data[cols])) :
# number of items to replace is not a multiple of replacement length
pivot_longer(sf, c(a,b)) %>% st_as_sf()
# [1] "vec_restore.sf is being called"
# [1] "vec_restore.sf is being called"
# [1] "vec_restore.sf is being called"
# Simple feature collection with 4 features and 2 fields
# geometry type: POINT
# dimension: XY
# bbox: xmin: 0 ymin: 1 xmax: 1 ymax: 2
# epsg (SRID): NA
# proj4string: NA
# # A tibble: 4 x 3
# geom name value
# <POINT> <chr> <int>
# 1 (0 1) a 1
# 2 (0 1) b 2
# 3 (1 2) a 2
# 4 (1 2) b 3
# Warning message:
# In val_cols[col_id] <- unname(as.list(data[cols])) :
# number of items to replace is not a multiple of replacement length
suggesting that the vec_* methods operate on the columns, not on the object returned. @krlmlr can you confirm this, or explain what I misunderstand?
Hmm, then I'm wrong about how vec_* works. Sorry...
Most helpful comment
Since people outside tidy-core have no idea what is coming of extra backwards-incompatible innovations, maybe it is more sensible to wait until tidy-core knows what it is doing, or at least says so. Break stuff only when you really need to. Its design and development principles are unknown - many appear in a development iteration without warning as a consequence of other changes, like the fallout from the vctrs innovations. This absorbs more time than sensible trying to adapt. We need urgently a blog showing R-spatial workflows that are time consistent (do the same thing across at least two tidyverse iterations) and which show how to re-write the same workflows outside tidyverse. Many serious users need stable workflows that do not require reproducibility-breaking changes at each tidyverse iteration.