New PROJ/GDAL break `.projNowhere`

[rsbivand]

See also r-spatial/sf#1776,

.projNowhere was always a dreadful idea for spatial data in the real world. +proj=utm is invalid, and now fails because PROJ/GDAL enforce a zone number requirement. So the package will not even install with current .projNowhere for PROJ 8.1.1 and GDAL 3.3.2. As a guess, you might kludge this by:

#.projNowhere <- CRS("+proj=utm")
.projNowhere <- {nm <- "CRS"; attr(nm, "package") <- "sp"; new(nm, projargs = "+proj=utm")}

in R/NetLogo-package.R - the package now installs, but fails in sp::over() when testing CRS equality, which you would also need to fix anyway.
00check.log
test-all.Rout.fail.zip

Further note that the development version of sp caches "CRS" objects, so package authors who instantiate the same object repeatedly do not have to go out to PROJ/GDAL each time (and your note in ?.projNowhere is incorrect).

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).

[eliotmcintire]

Thank you @rsbivand. We appreciate your time.

[eliotmcintire]

@SarahBauduin @achubaty Since this .projNowhere is used as a place holder for "no place in particular", we can just as easily pick a place. I am suggesting CRS("EPSG:32632"), which is in central Europe, utm zone 32U: https://epsg.io/32632

Are you OK with this? Obviously, we will run all tests.

[achubaty]

that sound fine, and we need to make users aware of this change

[eliotmcintire]

I am closing. It looks like the only places .projNowhere is used is when calculating distances (and angles). Since worlds are not in a specific unit (e.g., "meters"), the distances are in units of "cells". All we need is for these distances to be on a square surface, not a curved surface. Any UTM zone is fine for this, as it doesn't actually place the agents on the Earth. It is just calculating distances (and angles).

[rsbivand]

Please note that CRS("EPSG:32632") only works for GDAL >= 3 && PROJ >= 6, so it may fail on Solaris/CentOS and LTS Debian which are on much older versions of external software. Please also note that you actually need a planar NA CRS because if a user exports the results, they will be in the wrong CRS, no? There is discussion on an sf issue about instantiating such a planar NA to get around raster assuming that an an empty CRS is a GEOGCRS (so spherical/ellipsoidal).

[eliotmcintire]

Thank you for this. I am converting to the string, which I believe works on both legacy and current versions of GDAL and PROJ. As this is UTM, it is a planar projection, I believe.

.projNowhere <- CRS("+proj=utm +zone=32 +datum=WGS84 +units=m +no_defs")

This is non-exported, so users will not be using this, and it is never attached to an returned object. The only purpose for this function is to put arbitrary units on the WorldMatrix (which is a 2-D data class similar to a matrix), so that a buffer of a given distance (in "cells") can be determined. The purpose here is to calculate the buffer using raster::buffer, which needs a CRS, and then convert it back to the WorldMatrix. So, a user will never see this or know about it.

[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.

[SarahBauduin]

Ok for me!
Yes the UTM zone is not important as there is no coordinate system associated with the worlds or the turtles and the resolution/unit is the "cell".