Broken CRS in fortcoming/newest PROJ/GDAL

[rsbivand]

You are using "proj=utm" with no zone number, which has never been valid. This invalidity causes errors in the most recent PROJ/GDAL. I think (as in PredictiveEcology/NetLogoR#43) this may be an attempt to trick raster into seeing the positional data as planar/projected. You should always use an appropriate declaration of coordinate reference systems. The package will fail CRAN checks and break for users as the newest (and best) PROJ/GDAL software propagates.

testthat.Rout.fail.zip
00check.log

Note that rgdal, rgeos and maptools will not be developed further, and will be withdrawn by 2024-01-01 at the latest. This means that you should transition to sf and either stars or terra (raster uses rgdal and rgeos).

[scbrown86]

@seanhaythorne in tests/testthat/test_region.R you could replace the crs settings with
crs = "+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs" which is a proj4 string for an equirectangular projection. As Roger mentioned, it is just a check to see if an error is thrown with some planar/projected data so it doesn't need to be too specific.

e.g. line 38-40, would become

raster3 <- raster::raster(vals = c(NA, NA, 4, 6, NA, 2, NA, 7, NA, NA, 5, NA, 1, 3, NA, NA),
                          nrows = 4, ncol = 4, xmn = 0, xmx = 4000, ymn = 0, ymx = 4000,
                          crs = "+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs")

We could also replace with

raster3 <- raster::raster(vals = c(NA, NA, 4, 6, NA, 2, NA, 7, NA, NA, 5, NA, 1, 3, NA, NA),
                          nrows = 4, ncol = 4, xmn = 0, xmx = 4000, ymn = 0, ymx = 4000,
                          crs = "EPSG:32663")

which is equivalent.

From a very quick check, this issue only occurs in the testthat/test_region.R file.

I do agree that transitioning to terra for handling rasters is probably a good move, although it would require a significant rewrite and checks of some code.

[rsbivand]

Yes, this is also equivalently EPSG:4087, but unlike +proj=utm without a zone, is valid. I don't see any difference between 4087 and 32663. It is possible that "EPSG:32663" is for newer GDAL/PROJ only, unchecked.

[seanhaythorne]

Hi Roger,
Thanks for notifying us, and further suggestions on a valid CRS value.

Thanks for the suggested solution Stuart.

[rsbivand]

The +proj=utm" problem is caused by OSGeo/PROJ#2672 from OSGeo/PROJ#2671 and applies in PROJ >= 8, probably backported to 8.0.1 and applies in 8.1.*. Previously a non-existing zone 0 was generated.

[rsbivand]

This serious vulnerability remains. As soon as any of the CRAN test platforms starts using PROJ >= 8, you'll see failures there. I advise updating this quickly.

[seanhaythorne]

Hi Roger,
We've uploaded the changes (as above) to CRAN.
Cheers,
Sean