sf 1.0 will switch to using S2 geometry for ellipsoidal coordinates

[edzer]

As announced here in June last year, and also in the NEWS file around the same time, it is planned that where possible sf will use the spherical geometry operators of package s2 instead of the GEOS routines that assume projected coordinates. I've now run reverse dependency checks and found regressions in the following packages ("check" means: pkg maintainer informed):

• csodata
• eSDM
• geomultistar
• jpmesh
• mapping
• mapsf
• MODIS
• nhdplusTools
• nhdR
• osmextract
• redist
• rerddapXtracto (false positive: url timeout?)
• rmapzen
• sen2r
• sfnetworks
• slga
• tmap
• tmaptools

I have opened issues / written emails to all packages affected (issues mentioned below).

Testing your package while sf uses s2 can be done by setting

sf::sf_use_s2(TRUE)

or by specifying the environment variable _SF_USE_S2 to the value true (case sensitive); the latter can be done from within R with

Sys.setenv("_SF_USE_S2", "true")

but that needs to be done before sf is loaded.

[edzer]

Dear package author,

while checking reverse dependency's against the sf 1.0 candidate which uses s2 as a geometry back-end when using ellipsoidal coordinates, we found a regression. Please verify that this is not a false positive, and update your package on CRAN in a timely fashion before sf is released (which is not earlier than May 1st).

See #1649 for details.