upcoming sf breaks hereR on CRAN

[edzer]

See

• https://www.r-spatial.org/r/2020/03/17/wkt.html
• https://win-builder.r-project.org/incoming_pretest/sf_0.9-0_20200319_213604/reverseDependencies/summary.txt

Package hereR has one or more sf objects stored that use the old represenation of crs objects. This breaks downstream code (here: in mapview, through your vignettes). Please update these objects, or consider using dynamic construction with the sf api (using e.g. st_set_crs()), so you no longer get bitten by issues of this kind.

[munterfi]

Hi Edzer, many thanks for reporting.

The sf objects in the package data are now updated with the new CRS format of sf version 0.9-0 (97cc882):

library(sf)
#> Linking to GEOS 3.8.0, GDAL 3.0.4, PROJ 6.3.1
library(hereR)
data(poi)
poi %>% st_crs()
#> Coordinate Reference System:
#>   User input: WGS 84
#>   wkt:
#> GEOGCRS["WGS 84",
#>     DATUM["World Geodetic System 1984",
#>         ELLIPSOID["WGS 84",6378137,298.257223563,
#>             LENGTHUNIT["metre",1]]],
#>     PRIMEM["Greenwich",0,
#>         ANGLEUNIT["degree",0.0174532925199433]],
#>     CS[ellipsoidal,2],
#>         AXIS["geodetic latitude (Lat)",north,
#>             ORDER[1],
#>             ANGLEUNIT["degree",0.0174532925199433]],
#>         AXIS["geodetic longitude (Lon)",east,
#>             ORDER[2],
#>             ANGLEUNIT["degree",0.0174532925199433]],
#>     ID["EPSG",4326]]

As you mentioned, the problem bites me again because previous sf versions are now having trouble reading them:

library(sf)
#> Linking to GEOS 3.7.2, GDAL 2.4.2, PROJ 5.2.0
library(hereR)
data(poi)
poi %>% st_crs()
#> Coordinate Reference System:Error: C stack usage  7971648 is too close to the limit

Do you have a suggestion for the dynamic creation of the sf objects with the sf API?

My approach would be to save them first as data.frame objects to the package data, then convert into sf objects in .onLoad <- function(libname, pkgname){...} and finally export the sf objects to <environment: R_GlobalEnv>. However, I am not sure if this is the right way to deal with it.

The errors in the vignettes seem to be related to the mapview package r-spatial/mapview#271, in which the getProjection() function has already been fixed. Thanks!

Session info

devtools::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#>  setting  value                       
#>  version  R version 3.6.3 (2020-02-29)
#>  os       Arch Linux                  
#>  system   x86_64, linux-gnu           
#>  ui       X11                         
#>  language (EN)                        
#>  collate  en_DK.UTF-8                 
#>  ctype    en_DK.UTF-8                 
#>  tz       Europe/Zurich               
#>  date     2020-03-21                  
#>
#> ─ Packages ───────────────────────────────────────────────────────────────────
#>  package     * version    date       lib source                       
#>  assertthat    0.2.1      2019-03-21 [1] CRAN (R 3.6.2)               
#>  backports     1.1.5      2019-10-02 [2] CRAN (R 3.6.3)               
#>  callr         3.4.1      2020-01-24 [1] CRAN (R 3.6.2)               
#>  class         7.3-15     2019-01-01 [2] CRAN (R 3.6.3)               
#>  classInt      0.4-2      2019-10-17 [2] CRAN (R 3.6.2)               
#>  cli           2.0.1      2020-01-08 [1] CRAN (R 3.6.2)               
#>  crayon        1.3.4      2017-09-16 [1] CRAN (R 3.6.2)               
#>  DBI           1.1.0      2019-12-15 [2] CRAN (R 3.6.2)               
#>  desc          1.2.0      2018-05-01 [2] CRAN (R 3.6.3)               
#>  devtools      2.2.2      2020-02-17 [1] CRAN (R 3.6.3)               
#>  digest        0.6.23     2019-11-23 [1] CRAN (R 3.6.2)               
#>  e1071         1.7-3      2019-11-26 [2] CRAN (R 3.6.2)               
#>  ellipsis      0.3.0      2019-09-20 [1] CRAN (R 3.6.2)               
#>  evaluate      0.14       2019-05-28 [2] CRAN (R 3.6.3)               
#>  fansi         0.4.1      2020-01-08 [1] CRAN (R 3.6.2)               
#>  fs            1.3.2      2020-03-05 [1] CRAN (R 3.6.3)               
#>  glue          1.3.2      2020-03-12 [2] CRAN (R 3.6.3)               
#>  hereR       * 0.3.1.9000 2020-03-21 [1] local                        
#>  htmltools     0.4.0      2019-10-04 [1] CRAN (R 3.6.2)               
#>  KernSmooth    2.23-16    2019-10-15 [2] CRAN (R 3.6.3)               
#>  knitr         1.28       2020-02-06 [1] CRAN (R 3.6.3)               
#>  magrittr      1.5        2014-11-22 [2] CRAN (R 3.6.2)               
#>  memoise       1.1.0      2017-04-21 [1] CRAN (R 3.6.3)               
#>  pkgbuild      1.0.6      2019-10-09 [2] CRAN (R 3.6.3)               
#>  pkgload       1.0.2      2018-10-29 [2] CRAN (R 3.6.3)               
#>  prettyunits   1.1.1      2020-01-24 [2] CRAN (R 3.6.3)               
#>  processx      3.4.2      2020-02-09 [1] CRAN (R 3.6.2)               
#>  ps            1.3.0      2018-12-21 [1] CRAN (R 3.6.2)               
#>  R6            2.4.1      2019-11-12 [1] CRAN (R 3.6.2)               
#>  Rcpp          1.0.4      2020-03-17 [2] CRAN (R 3.6.3)               
#>  remotes       2.1.1      2020-02-15 [1] CRAN (R 3.6.3)               
#>  rlang         0.4.5      2020-03-01 [2] CRAN (R 3.6.3)               
#>  rmarkdown     2.1        2020-01-20 [1] CRAN (R 3.6.3)               
#>  rprojroot     1.3-2      2018-01-03 [2] CRAN (R 3.6.3)               
#>  sessioninfo   1.1.1      2018-11-05 [1] CRAN (R 3.6.3)               
#>  sf          * 0.9-0      2020-03-20 [1] Github (r-spatial/sf@05f14dc)
#>  stringi       1.4.6      2020-02-17 [2] CRAN (R 3.6.2)               
#>  stringr       1.4.0      2019-02-10 [2] CRAN (R 3.6.2)               
#>  testthat      2.3.2      2020-03-02 [2] CRAN (R 3.6.3)               
#>  units         0.6-6      2020-03-16 [2] CRAN (R 3.6.3)               
#>  usethis       1.5.1      2019-07-04 [1] CRAN (R 3.6.3)               
#>  withr         2.1.2      2018-03-15 [1] CRAN (R 3.6.2)               
#>  xfun          0.12       2020-01-13 [1] CRAN (R 3.6.2)               
#>  yaml          2.2.1      2020-02-01 [1] CRAN (R 3.6.2)               
#>
#> [1] /home/mufix/R/x86_64-pc-linux-gnu-library/3.6
#> [2] /usr/lib/R/library

[edzer]

Storing objects in .rda files that might change in their representation over time is always vulnerable to this problem. Package sf loads the nc dataset for instance by reading from an external file:

nc = read_sf(system.file("gpkg/nc.gpkg", package="sf"))

This will always use the sf version loaded. (I think there is also a shapefile because .gpkg is SQLite and that is not present on solaris - not sure if that is still the case)

[munterfi]

Many thanks for your input. I will consider a dynamic construction of the sf objects in a minor or major release of the package.

To fix the issue for now, the sf objects stored by the hereR package are recreated with the new sf version and the dependency on the sf package is increased to version 0.9-0. The code blocks in the vignettes that cause hereR to break on CRAN are deactivated until a new version of the mapview package is released.

And finally, thank you for developing and maintaining such a great sf package.

[edzer]

Sounds sensible - thanks!