I think you can stick
remotes::install_github("r-spatial/sf")
Before or after this (I forget which is more likely to work): https://github.com/dcooley/sfheaders/blob/master/.github/workflows/R-CMD-check.yaml#L68 ...in a copy of your R-CMD-check.yaml file.
If you're going return an object of class sf or sfc_*, you should probably expect_identical() your output with that of sf...they're sf's objects.
If there is an in-memory structure that's faster to create (from a data frame or otherwise), you could give it another class ("sfheaders"?) and implement st_as_sfc()/st_as_sf() using sf's constructors. You can dynamically register those methods to avoid requiring sf in Imports (see here: https://github.com/paleolimbot/geovctrs/blob/master/R/zzz.R#L21 ).
Originally posted by @paleolimbot in #49 (comment)
I think you can stick
Before or after this (I forget which is more likely to work): https://github.com/dcooley/sfheaders/blob/master/.github/workflows/R-CMD-check.yaml#L68 ...in a copy of your R-CMD-check.yaml file.
If you're going return an object of class
sforsfc_*, you should probablyexpect_identical()your output with that of sf...they're sf's objects.If there is an in-memory structure that's faster to create (from a data frame or otherwise), you could give it another class ("sfheaders"?) and implement
st_as_sfc()/st_as_sf()using sf's constructors. You can dynamically register those methods to avoid requiring sf inImports(see here: https://github.com/paleolimbot/geovctrs/blob/master/R/zzz.R#L21 ).Originally posted by @paleolimbot in #49 (comment)