PROJ initialization issues

[brownag]

This issue is a continuation of discussion in #1996, going beyond the "Cannot find proj.db" errors to three other possible issues with terra PROJ configuration. While these are distinct issues, I think that they all broadly fall under the "terra PROJ initialization"

While proj_ok() (terra >=1.8-91) allows for us to defensively program around particularly aberrant PROJ installations, which is probably generally a good practice, similar to how we should handle web-based requests in R packages "gracefully"... I had a feeling there were some bigger issues affecting the specific cases I have seen failing on Windows and macOS. In particular the warning GDAL WARNING 3: Cannot find tms_NZTM2000.json (GDAL_DATA is not defined) piqued my curiosity. Also I noticed that while many terra dependencies--including several packages I maintain--are failing on CRAN (Windows old-release) or in GHA CI (using CRAN macOS latest binaries), I am not seeing the same issues with sf-dependent packages.

I downloaded the terra 1.8-86 (macOS release) and 1.8-80 (Windows old-release) binary packages from CRAN and they looked "valid" to me (in terms of bundled proj/ and gdal/ folders and their contents), so I dug into how terra is setting paths, and compared against sf.

These are the issues I have identified:

1. Bundled binary PROJ paths on non-Windows platforms

   • The current mechanism for setting PROJ search paths in terra (.set_proj_search_paths) effectively only runs on Windows
   • macOS issues seem to be avoided in the current terra GHA CI as the system dependencies are installed with homebrew, as opposed to using the CRAN-bundled binary; in contrast downstream CIs of packages dependent on terra commonly default to using the CRAN binary

2. Syncing GDAL and PROJ paths

   • terra should ensure that both proj_context_set_search_paths() and OSRSetPROJSearchPaths() (GDAL >=3) are synchronized so both libraries look at the same set of paths

3. Network behavior and SSL

• terra currently lacks user-facing controls for PROJ CDN access (similar to sf::sf_proj_network()). This causes two "problems":
  • Unintentional network requests when local grids are missing
  • Environments with SSL inspection, custom SSL certificates, or strict firewalls can throw errors and messages when terra attempts to fetch remote assets from PROJ CDN

I have drafted a PR (#2000) to potentially address all 3 of the above issues