proj_context_set_search_paths does not ignore PROJ_LIB

[edzer]

This is an R context: running R --vanilla < script.R with the following script

library(sf)
sf:::CPL_set_data_dir("/usr/local/share/proj") # this is the right directory
data.frame(lat = 10, lon = 0) |>
st_as_sf(crs = 4326, coords = c("lon", "lat")) |>
st_transform(crs = 32719)

works, but when PROJ_LIB is set to an illegal location (or location with older proj.db), e.g. running this by

$ PROJ_LIB=/tmp R --vanilla < script.R

gives the following output:

library(sf)
# Linking to GEOS 3.12.1, GDAL 3.8.2, PROJ 9.3.1; sf_use_s2() is TRUE
sf:::CPL_set_data_dir("/usr/local/share/proj")
# [1] TRUE
data.frame(lat = 10, lon = 0) |>
st_as_sf(crs = 4326, coords = c("lon", "lat")) |>
st_transform(crs = 32719)
# Error in st_transform.sfc(st_geometry(x), crs, ...) : 
#   cannot transform sfc object with missing crs
# Calls: st_transform ... st_transform.sf -> st_transform -> st_transform.sfc
# In addition: Warning message:
# In CPL_crs_from_input(x) :
#   GDAL Error 1: PROJ: proj_create_from_database: Cannot find proj.db
# Execution halted

This is found under PROJ 9.3.0 here and 9.3.1 (local docker image). On earlier versions (e.g. locally, ubuntu, PROJ 9.1.1) this did not create a problem. My understanding was that setting a correct search path with proj_context_set_search_paths() (which is what sf:::CPL_set_data_dir() does) should override any PROJ_LIB. (same results for PROJ_DATA instead of PROJ_LIB).

Let me know if you want me to prepare a C example.

Also reported here.

[rouault]

Seeing https://github.com/r-spatial/sf/blob/e817351702a46d32ac8869b4b4ff8d856d699254/src/proj.cpp#L227, I see CPL_set_data_dir() acts on the default PROJ context. But if this is called after GDAL has created its thread-local PROJ context, then this is not honoured by GDAL. You might want to use GDAL's OSRSetPROJSearchPaths() to be sure that GDAL honours your PROJ dir setting.

[edzer]

Thanks Even! I believe that is the second time I mix up PROJ and GDAL interfaces to proj; hopefully the third time I will think of it before posting.