PROJ 6 problems?

[rsbivand]

Running rgeos reverse dependency checks, now on a platform with PROJ 6.1.1, I'm seeing CRS mismatch problems in the tests:

testthat.Rout.fail.log

[ateucher]

Thanks for the heads up @rsbivand, I will check it out. Just to be clear, is this affecting your release of rgeos?

[rsbivand]

I was just running R CMD check rmapshaper... because I have to do that for all packages depending/importing/suggesting rgeos, and noticed the issue. The most likely cause is that I'm running on a platform with PROJ 6.1.1, so rendering of proj4 strings varies, and in general +towgs84= is deprecated going forward. Try running R CMD check on a system with PROJ 6 and see. The problem may be coming through sf (mine is built against PROJ 6), or somewhere else - I do not try to interpret testthat failures because they are almost always close to opaque, but making an exception, in test-innerlines.R, I see:

> proj4string(poly_sp)
[1] "+proj=longlat +datum=WGS84 +no_defs +ellps=WGS84 +towgs84=0,0,0"
> st_crs(poly_sfc)
Coordinate Reference System:
  EPSG: 4326 
  proj4string: "+proj=longlat +datum=WGS84 +no_defs"
> proj4string(ms_innerlines(poly_spdf))
[1] "+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs"
> proj4string(expected_sp)
[1] "+proj=longlat +datum=WGS84 +no_defs +ellps=WGS84 +towgs84=0,0,0"

So there are at least three different strings being presented to expect_equal(). Debugging ms_sp(), something odd happens in GeoJSON_to_sp():

debug: geojson <- sp_to_GeoJSON(input, file = sys)
Browse[2]> proj4string(input)
[1] "+proj=longlat +datum=WGS84 +no_defs +ellps=WGS84 +towgs84=0,0,0"
Browse[2]> 
debug: ret <- apply_mapshaper_commands(data = geojson, command = call, 
    force_FC = TRUE, sys = sys)
Browse[2]> attr(geojson, "proj4")
[1] "+proj=longlat +datum=WGS84 +no_defs +ellps=WGS84 +towgs84=0,0,0"
...
debug: ret <- GeoJSON_to_sp(ret, proj = attr(geojson, "proj4"))
Browse[2]> attr(geojson, "proj4")
[1] "+proj=longlat +datum=WGS84 +no_defs +ellps=WGS84 +towgs84=0,0,0"
Browse[2]> attr(ret, "proj4")
NULL
...
Browse[2]> proj4string(ret)
[1] "+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs"

and debugging in GeoJSON_to_sf()

Browse[3]> debug(GeoJSON_to_sf)
Browse[3]> 
debugging in: GeoJSON_to_sf(geojson, proj)
debug: {
    sf <- suppressWarnings(sf::st_read(unclass(geojson), quiet = TRUE, 
        stringsAsFactors = FALSE))
    if (!is.null(proj)) {
        suppressWarnings(sf::st_crs(sf) <- proj)
    }
    curly_brace_na(sf)
}
Browse[4]> 
debug: sf <- suppressWarnings(sf::st_read(unclass(geojson), quiet = TRUE, 
    stringsAsFactors = FALSE))
Browse[4]> 
debug: if (!is.null(proj)) {
    suppressWarnings(sf::st_crs(sf) <- proj)
}
Browse[4]> st_crs(sf)
Coordinate Reference System:
  EPSG: 4326 
  proj4string: "+proj=longlat +datum=WGS84 +no_defs"
Browse[4]> proj
[1] "+proj=longlat +datum=WGS84 +no_defs +ellps=WGS84 +towgs84=0,0,0"
Browse[4]> 
debug: suppressWarnings(sf::st_crs(sf) <- proj)
Browse[4]> 
debug: curly_brace_na(sf)
Browse[4]> st_crs(sf)
Coordinate Reference System:
  EPSG: 4326 
  proj4string: "+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs"
Browse[4]> 
exiting from: GeoJSON_to_sf(geojson, proj)
debug: as(x_sf, "Spatial")

so the change is made in sf::st_crs<-(), which goes out to GDAL and PROJ.

At the moment, sp uses rgdal which uses the proj_api.h PROJ interface, but I think sf uses the proj.h PROJ interface. So for the time being I think that you cannot expect verbatim proj4 strings to be equal. I'd re-write the tests to drop the proj4 strings until both sf and sp/rgdal are on the same header interface to PROJ, which for now they may not be.

I guess we need an r-spatial blog on PROJ transitions. @edzer (more for Muenster?).

[ateucher]

Interesting. I installed sf, sp, rgdal, and rgeos from source using GDAL 2.4.2, GEOS 3.7.2, and PROJ 6.1.1 and didn't get any failures:

$ R CMD check rmapshaper_0.4.1.tar.gz
* using log directory '/Users/ateucher/dev/personal/rmapshaper/rmapshaper.Rcheck'
* using R version 3.6.1 (2019-07-05)
* using platform: x86_64-apple-darwin15.6.0 (64-bit)
* using session charset: UTF-8
* checking for file 'rmapshaper/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'rmapshaper' version '0.4.1'
* checking package namespace information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking if there is a namespace ... OK
* checking for executable files ... OK
* checking for hidden files and directories ... OK
* checking for portable file names ... OK
* checking for sufficient/correct file permissions ... OK
* checking whether package 'rmapshaper' can be installed ... OK
* checking installed package size ... OK
* checking package directory ... OK
* checking 'build' directory ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking for left-over files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... OK
* checking whether the package can be loaded with stated dependencies ... OK
* checking whether the package can be unloaded cleanly ... OK
* checking whether the namespace can be loaded with stated dependencies ... OK
* checking whether the namespace can be unloaded cleanly ... OK
* checking loading without being on the library search path ... OK
* checking dependencies in R code ... OK
* checking S3 generic/method consistency ... OK
* checking replacement functions ... OK
* checking foreign function calls ... OK
* checking R code for possible problems ... OK
* checking Rd files ... OK
* checking Rd metadata ... OK
* checking Rd cross-references ... OK
* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... OK
* checking Rd \usage sections ... OK
* checking Rd contents ... OK
* checking for unstated dependencies in examples ... OK
* checking installed files from 'inst/doc' ... OK
* checking files in 'vignettes' ... OK
* checking examples ... OK
* checking for unstated dependencies in 'tests' ... OK
* checking tests ...
  Running ‘testthat.R’
 OK
* checking for unstated dependencies in vignettes ... OK
* checking package vignettes in 'inst/doc' ... OK
* checking running R code from vignettes ...
  'rmapshaper.Rmd'using 'UTF-8'... OK
 NONE
* checking re-building of vignette outputs ... OK
* checking PDF version of manual ... OK
* DONE

Status: OK

$ Rscript -e "sf::sf_extSoftVersion(); rgdal::rgdal_extSoftVersion(); rgeos::rgeos_extSoftVersion()"
          GEOS           GDAL         proj.4 GDAL_with_GEOS
       "3.7.2"        "2.4.2"        "6.1.1"         "true"
          GDAL GDAL_with_GEOS         PROJ.4             sp
       "2.4.2"         "TRUE"        "6.1.1"        "1.3-1"
   GEOS      sp
"3.7.2" "1.3-1"

However your point about testing exact proj4 strings is a good one, I will alter the tests to be more liberal in this regard

[ateucher]

And you are right, looking at the install logs from sf:

...
checking proj.h usability... yes
checking proj.h presence... yes
checking for proj.h... yes
configure: PROJ: 6.1.1
...

vs rgdal:

...
configure: PROJ version: 6.1.1
configure: Support for PROJ >= 6.0.0 not yet available, deprecated API defined
configure: proj CPP flags: -DACCEPT_USE_OF_DEPRECATED_PROJ_API_H -I/usr/local/Cellar/proj/6.1.1/include 
checking PROJ header API:... proj_api.h
checking proj_api.h presence and usability... yes
...

it looks like the former uses proj.h while the latter uses proj_api.h.

[rsbivand]

I'm using GDAL 3.0.1 built against PROJ 6; you'd need to move from GDAL 2 to GDAL 3 to reproduce the problem, I think.

[ateucher]

Thanks, and again you're right - building with GDAL 3.0.0 reproduced the test failures, and the above commits fixes them for me. Thanks again for the heads-up, I will try to update before CRAN's machines do.