auto_limits fails under Solaris

[MikkoVihtakari]

I am unable to solve this issue myself and will post it here to ask for help. Perhaps @rsbivand, @yreecht or someone has an idea on how to solve it.

rhub::check_on_solaris() fails and this prevents CRAN from accepting the package.

I still get the same old error when I run check_on_solaris:

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

> ### Name: auto_limits
> ### Title: Automatic limits for basemap
> ### Aliases: auto_limits
> ### Keywords: internal
> 
> ### ** Examples
> 
> if(requireNamespace("ggOceanMapsData")) {
+ auto_limits(data = expand.grid(lon = c(-120, 180, 120), 
+    lat = c(60, 60, 80)))
+ }    
Loading required namespace: ggOceanMapsData
Using lon and lat as longitude and latitude columns, respectively.
Error in h(simpleError(msg, call)) : 
  error in evaluating the argument 'CRSobj' in selecting a method for function 'spTransform': no arguments in initialization list
Calls: auto_limits -> transform_coord -> <Anonymous> -> <Anonymous>
Execution halted

Inspired by @yreecht here, I tried to add the following to auto_limits(), transform_coord() and clip_shapefile()

if(sf::sf_extSoftVersion()[["GDAL"]] < "3.0.0" | 
     sf::sf_extSoftVersion()[["PROJ"]] < "6.0.0") {
    if(is.character(proj.in) & nchar(proj.in) == 9) {
      proj.in <- paste0("+init=epsg:", select_element(strsplit(proj.in, split = ":"), 2)) 
    }
  }

This did not help. I don't know what to try next.

This issue is related to this one also.

[rsbivand]

Solaris and many systems on clusters (CentOS, older Ubuntu and Debian) are stuck on PROJ 4. and GDAL 1. or at best GDAL 2.*. This means that although +init=epsg: may work (nchar(proj.in) == 9 is fallible, as EPSG codes may have 4, 5 or I think 6 digits - esri takes 6 certainly), you are safer with a PROJ4 variant like +proj=longlat +ellps=WGS84 for work not requiring positional accuracy within about +/- 150m. You need to create a testing environment with old PROJ and old GDAL on any platform, and you should be able to re-create the Solaris error.

Maybe the problem is in assigning proj.out when seen as NULL https://github.com/MikkoVihtakari/ggOceanMaps/blob/d4378a31d1296b3332a3bcc1191c35e0e723aa00/R/transform_coord.R#L130 ? The sp and sf representations do differ.

[MikkoVihtakari]

Thanks for the clarification @rsbivand. Do you think that using sf instead of sp would cause less trouble?

[rsbivand]

Nothing to do with sp/sf, only support for much older PROJ/GDAL versions. Solaris acts as a watchdog because it still only runs older PROJ/GDAL/GEOS. Typically, older external software is used by large labs and clusters running CentOS or older Debian, where the user cannot upgrade because all software is centrally administered, and is the version frozen into long term support.

[MikkoVihtakari]

The CRSargs function by @yreecht seems to solve the issue. I suppose we'll need to rename that function something else as rgdal::CRSargs() exists already.

Perhaps too much hoped but would similar functionality within sp::CRS work @rsbivand? The function causes a dependency to rgdal (or sf) to test the PROJ/GDAL versions. Otherwise, I don't see how it would cause conflicts, but then again, I did not see this conflict coming either.

[rsbivand]

One only finds conflicts with extensive revdep checks on multiple platforms. You are wrong about rgdal, as it is simply hidden under a wrapper in sp. All the CRS and transformation in sp is done in rgdal, which in turn depends on PROJ/GDAL. Maybe move everything to sf, at least then you are future-proofed as rgdal is EOL end 2023.

[MikkoVihtakari]

This issue should be addressed here: https://github.com/MikkoVihtakari/ggOceanMaps/commit/24780292d6750d9c530f8d44dad56fefb29cc878

Thank you for help @rsbivand and @yreecht. I'll close the issue. Please reopen if the issue prevails.