Changed `sf_proj_search_paths` behaviour in 1.0-16

[rsbivand]

Please add to NEWS and to roxygen in man page:

sf_proj_search_paths from 1.0-16 returns a character vector of two strings, PROJ and GDAL, no longer split on the path separators. Up to now, the function returned a character vector of directories on the PROJ path.

This broke the evolution checks on ASDAR, as the actual path was needed for RSQLite to open proj.db. I also saw sf 1.0-16 collapse, with no proj.db found, wrong version of proj.db when looking in $HOME/.local/share/proj, which is now what GDAL points to for me, and is only used for chunk.db which is mutable, not proj.db which is not mutable.

[rsbivand]

As a guess, in src/proj.cpp,

sf/src/proj.cpp

Line 192 in 1cf6260

char **ogr_sp = OSRGetPROJSearchPaths();

returns the wrong value, that is it only returns the first path in

sf/src/proj.cpp

Line 190 in 1cf6260

ret[0] = proj_info().searchpath;

but should return both the mutable and the immutable paths. Other apps can likely stuff the wrong proj.db into $HOME/.local/share/proj, with no check for freshness on the GDAL side.

[rsbivand]

If .Platform$path.sep is present after returning from CPL_get_data_dir or CPL_set_data_dir, the object probably needs to be run through strsplit(, .Platform$path.sep) then unlist then unique to get back to where it was. I think that the $HOME/.local/share/proj directory could have been created by running ctest in either PROJ or GDAL during the GDAL 3.8 churn. Will try my fix in a branch of my fork.

[gm4]

Would this be a cause of the below warning in st_as_sf with proper lat, lon and crs passed?

Warning message:
In CPL_crs_from_input(x) :
  GDAL Error 1: PROJ: proj_create_from_database: Cannot find proj.db

While st_as_sf throws the warning, I get Error: node stack overflow from ggplot's geom_sf when trying to plot the map.

[rsbivand]

@gm4 please provide full output of sessionInfo and sf::st_extSoftVersion. This issue concerns the development version of sf, not releaded versions.

[gm4]

My apologies for posting on the development version @rsbivand. Here is the output:

> sessionInfo()
R version 4.3.2 (2023-10-31)
Platform: aarch64-apple-darwin20 (64-bit)
Running under: macOS Sonoma 14.2.1

Matrix products: default
BLAS:   /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib 
LAPACK: /Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/lib/libRlapack.dylib;  LAPACK version 3.11.0

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

time zone: America/Los_Angeles
tzcode source: internal

attached base packages:
[1] stats     graphics  grDevices datasets  utils     methods   base     

other attached packages:
[1] lubridate_1.9.3 stringr_1.5.1   sf_1.0-15       janitor_2.2.0  
[5] jsonlite_1.8.8  ggplot2_3.4.4   dplyr_1.1.4     readr_2.1.4    
[9] here_1.0.1     

loaded via a namespace (and not attached):
 [1] bit_4.0.5          gtable_0.3.4       crayon_1.5.2       compiler_4.3.2    
 [5] renv_1.0.3         tidyselect_1.2.0   Rcpp_1.0.11        parallel_4.3.2    
 [9] snakecase_0.11.1   scales_1.3.0       R6_2.5.1           generics_0.1.3    
[13] classInt_0.4-10    tibble_3.2.1       units_0.8-5        munsell_0.5.0     
[17] rprojroot_2.0.4    DBI_1.2.0          pillar_1.9.0       tzdb_0.4.0        
[21] rlang_1.1.2        utf8_1.2.4         stringi_1.8.3      bit64_4.0.5       
[25] timechange_0.2.0   cli_3.6.2          withr_2.5.2        magrittr_2.0.3    
[29] class_7.3-22       grid_4.3.2         vroom_1.6.5        rstudioapi_0.15.0 
[33] hms_1.1.3          lifecycle_1.0.4    vctrs_0.6.5        KernSmooth_2.23-22
[37] proxy_0.4-27       glue_1.6.2         e1071_1.7-14       fansi_1.0.6       
[41] colorspace_2.1-0   tools_4.3.2        pkgconfig_2.0.3   

> sf::st_extSoftVersion
Error: 'st_extSoftVersion' is not an exported object from 'namespace:sf'

[rsbivand]

Should have been sf_extSoftVersion, sorry. Since the released version, not this issue. Did you install sf as a binary from CRAN? If so, 1.0-16 may help when it is ready. Do you have other software installed that sets the environment variable PROJ_LIB?

[rsbivand]

See the whole of this issue 2298 especially this comment #2298 (comment).

[gm4]

Many thanks @rsbivand! This seemed to solve my issue.

[edzer]

@rsbivand thanks - yes this was all wrong. I suggest we revert to the old behavior of 1.0-15, e.g.

> sf_proj_search_paths()
[1] "/home/edzer/.local/share/proj" "/usr/share/proj"

and add an option to query PROJ_INFO.searchpath, for debugging purposes only, without splitting on the path separator. The main goal of the sf package is to provide the GDAL interface to coordinate transformation / conversion.

[edzer]

This also fixes some of the ambiguities setting search paths for GDAL and/or PROJ:

library(sf)
# Linking to GEOS 3.11.1, GDAL 3.6.4, PROJ 9.1.1; sf_use_s2() is TRUE
sf_proj_search_paths() # from GDAL
# [1] "/home/edzer/.local/share/proj" "/usr/share/proj"              
sf_proj_info("path") # from PROJ
# [1] "/home/edzer/.local/share/proj:/usr/share/proj"
sf_proj_search_paths(c("a", "b"), TRUE) # set for PROJ only
# setting proj path(s) to a:b
# [1] TRUE
sf_proj_search_paths() # from GDAL
# [1] "a" "b"
sf_proj_info("path") # from PROJ
# [1] "a:b"
sf_proj_search_paths(c("c", "d"), FALSE) # set for GDAL only
sf_proj_search_paths() # from GDAL
# [1] "c" "d"
sf_proj_info("path") # from PROJ
# [1] "a:b"
sf_proj_search_paths(c("e", "f")) # set for both GDAL and PROJ
# setting proj path(s) to e:f
# [1] TRUE
sf_proj_search_paths() # from GDAL
# [1] "e" "f"
sf_proj_info("path") # from PROJ
# [1] "e:f"