sf and PROJ problem?

I just updated packages on my Mac  (apple silicon,  R 4.5.2) and the package ?sf? was updated.  After the update,  anything using ?sf? was throwing errors that:

proj_create: Cannot find proj.db
proj_create: no database context specified

This did not occur before the update.  When I compiled sf from source,  the problem went away.

To be host-independent, sf needed to be installed using something like

--configure-args='--with-data-copy --with-proj-data=/opt/R/arm64/share/proj

so the proj auxiliary files are copied into the package (as directory 
proj). (Analogously for gdal files.)  This may not be needed if you have 
an installation of PROJ (the software, not the R package), as presumably 
you do if you installed sf from source.

This applies also to packages terra and vapour.

Brian D. Ripley,                  ripleybd at icloud.com
Emeritus Professor of Applied Statistics, University of Oxford

Roy,

I think you may have misidentified the package, because sf *does* include proj.db:

$ tar fvtz big-sur-arm64/bin/4.5/sf_1.0-24.tgz | grep proj.db
-rw-rw-r--  0 root   admin  9261056 13 Jan 15:13 sf/proj/proj.db

(that's why reproducible examples are so crucial!) because the flags Brian mentioned are used for sf:

https://svn.r-project.org/R-dev-web/trunk/QA/Simon/packages/flags.inst/sf

However, you are onto something, because it looks like due to a bug in SVN where softlinks are incorrectly resolved the other packages in flags.inst that were linking to the same (soft-linked) sf flags could not use them:
apcf
gdalcubes
gdalraster
rgdal
terra
uFTIR
vapour
vol2birdR
I'm still not too happy about the fact that they don't just simply use the db from sf and thus all require overrides and private copies, but at least I have replaced the softlinks with copies which should fix the problem (albeit they all still duplicate everything).

I think the reason that re-install from source worked for you (even though you re-installed the one package that already worked!) is that if you install *any* of the above packages (+sf) from source they will copy those files into your system location so then all of them will be able to find it. (Binary packages are not allowed to write into your system that's why we can't do it).

Cheers,
Simon

On 14/01/2026, at 07:22, Roy Mendelssohn - NOAA Federal via R-SIG-Mac <r-sig-mac at r-project.org> wrote:

I just updated packages on my Mac  (apple silicon,  R 4.5.2) and the package ?sf? was updated.  After the update,  anything using ?sf? was throwing errors that:

proj_create: Cannot find proj.db
proj_create: no database context specified

This did not occur before the update.  When I compiled sf from source,  the problem went away.

Thanks,

-Roy

_______________________________________________
R-SIG-Mac mailing list
R-SIG-Mac at r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

On Wed, Jan 14, 2026 at 2:00?AM Simon Urbanek <simon.urbanek at r-project.org>
wrote:

Roy,

I think you may have misidentified the package, because sf *does* include
proj.db:

$ tar fvtz big-sur-arm64/bin/4.5/sf_1.0-24.tgz | grep proj.db
-rw-rw-r--  0 root   admin  9261056 13 Jan 15:13 sf/proj/proj.db

(that's why reproducible examples are so crucial!) because the flags Brian
mentioned are used for sf:

https://svn.r-project.org/R-dev-web/trunk/QA/Simon/packages/flags.inst/sf

However, you are onto something, because it looks like due to a bug in SVN
where softlinks are incorrectly resolved the other packages in flags.inst
that were linking to the same (soft-linked) sf flags could not use them:

Instead of special casing these builds, you can set environment
variables PROJ_GDAL_DATA_COPY and PROJ_LIB on your server to the same
effect.