Sf: New pivot_longer and pivot_wider from tidyr are not working with sf

Created on 14 Sep 2019  路  6Comments  路  Source: r-spatial/sf

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.

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.

All 6 comments

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:

  1. Remove sf class from the object
  2. Apply the NextMethod()
  3. Restore the object to sf

The 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...

Was this page helpful?
0 / 5 - 0 ratings

Related issues

faridcher picture faridcher  路  4Comments

tiernanmartin picture tiernanmartin  路  3Comments

Nosferican picture Nosferican  路  3Comments

kendonB picture kendonB  路  4Comments

happyshows picture happyshows  路  3Comments