SWMPrExtension vulnerable to forthcoming changes in sp and rgdal

[rsbivand]

Running revdep checks for current rgdal on R-Forge - see:

https://stat.ethz.ch/pipermail/r-sig-geo/2019-November/027801.html

shows the errors in the attached check log, related to use of PROJ&/GDAL3 and required changes to sp and rgdal. If useful find a regerence to a docker image in this thread:

https://github.com/r-spatial/discuss/issues/28

Changes will occur quite fast, and packages need to be prepared.

* checking examples ... ERROR
Running examples in ‘SWMPrExtension-Ex.R’ failed
The error most likely occurred in:

> ### Name: national_sk_map
> ### Title: Reserve National Map with Seasonal Kendall Results
> ### Aliases: national_sk_map
> 
> ### ** Examples
> 
> ##National map highlighting west coast states and NERRS (including AK)
> nerr_states_west <- c('02', '06', '41', '53')
> 
> nerrs_codes <- c('pdb', 'sos', 'sfb', 'elk', 'tjr', 'kac')
> nerrs_sk_results <- c('inc', 'inc', 'dec', 'insig', 'insuff', 'dec')
> 
> national_sk_map(sk_reserve = nerrs_codes, sk_results = nerrs_sk_results)
Warning in showSRID(uprojargs, format = "PROJ", multiline = "NO") :
  Discarded datum unknown in CRS definition
Error in spRbind(as(obj, "SpatialPolygons"), as(x, "SpatialPolygons")) : 
  coordinate reference systems differ
Calls: national_sk_map -> <Anonymous> -> <Anonymous> -> spRbind -> spRbind
Execution halted

[rsbivand]

Problem still present

[DaveEslinger]

Roger, I am using the docker image mentioned and testing against gdal 3.02 and proj 6.2.1, but do not get them same error. Can you provide further information on how the test you ran to produce it? Sorry for my ignorance, but I can't seem to reproduce it, so can't fix it.

library(sf) Linking to GEOS 3.8.0, GDAL 3.0.2, PROJ 6.2.1

[DaveEslinger]

Here is output from the national_sk_map function you showed with the error:

library(sf) Linking to GEOS 3.8.0, GDAL 3.0.2, PROJ 6.2.1 ?national_sk_map

National map highlighting west coast states and NERRS (including AK)

nerr_states_west <- c('02', '06', '41', '53')

nerrs_codes <- c('pdb', 'sos', 'sfb', 'elk', 'tjr', 'kac') nerrs_sk_results <- c('inc', 'inc', 'dec', 'insig', 'insuff', 'dec')

national_sk_map(sk_reserve = nerrs_codes, sk_results = nerrs_sk_results) Joining, by = "NERR.Site.ID" Warning: Ignoring unknown aesthetics: x, y

With a successful conclusion and a map generated.

Thanks again for what help yo9u can provide.

--

--

[DaveEslinger]

Nevermind. Docker image did not have dev versions of sp and rgdal. Now I get the error.

[DaveEslinger]

The current set of issues have been resolved with merge e21dac13fde. Please open a new issue if you find additional problems with the package working with the dev versions of {rgdal} and {sp}. It passed all the tests I tried.

Thanks!

[rsbivand]

Thanks, this will be checked in my workflows when it is on CRAN. However, sp::proj4string() only returns the PROJ string, which may very well have lost their +datum=, +towgs84= or +nadgrids= keys. If an offset of 125m (4-5 landsat pixels) doesn't matter, OK. So far I haven't changed sp::proj4string() or sp::proj4string<-(), but will add warnings if a WKT comment is dropped.

[DaveEslinger]

Thanks, this is working its way through the CRAN process as I write. We do not do any conversions in the current setup, so shouldn't run afoul of any datum translation issues. In fact, our proj string has no towgs84 keys.

I have an alternate workflow using {sf} instead of {sp}, but I can't seem to find an EPSG code for particular projection we are using. Spatial-org knows it as a custom projection, with only a proj4 or WKT description. If I use those (assuming I can) with the {sf} workflow, should that address any future issues?

Thanks again!

[rsbivand]

I don't think the current CRAN errors are related to spatial packages.

If you can provide custom WKT, that may work, but will be fragile, in that there will be no authority support and interpretations may drift. The new sf as described in https://www.r-spatial.org/r/2020/03/17/wkt.html may help clarify.