Chap 3. Tmap in a Nutshell (Fig. 3.2) fails on macOS / R 4.6 due to missing terra proj.db

[markjaypearson]

I had some difficulties with replicating the map of Slovenia (fig 3.2) and hoped that the suggestion below (with the help of Claude) may be helpful to future readers.

• What I tried: Ran the Slovenia map example in section 3.x verbatim with slo_elev, slo_borders, slo_railroads, slo_cities from spDataLarge.
• What happened: tm_shape(slo_elev) + tm_raster(...) failed with OGRCreateCoordinateTransformation(): transformation not available and Cannot find coordinate operations from EPSG:3035 to ENGCRS["ETRS89-extended / LAEA Europe", EDATUM["Unknown engineering datum"]…].
• Diagnosis: terra's PROJ runtime couldn't find proj.db (PROJ: proj_create_from_database: Cannot find proj.db (GDAL error 1)). On macOS with the CRAN binary of terra for R 4.6, no proj.db is bundled inside the terra package directory, while sf ships its own copy at /proj/proj.db. As a result, terra::crs(slo_elev) returned all NA and any attempt to assign a CRS via terra::crs(slo_elev) <- "EPSG:3035" failed silently with Cannot set raster SRS: empty srs. sf was unaffected — sf::st_crs(3035) resolved correctly.
• Workaround: Setting PROJ_DATA to sf's directory before loading terra:
• After that, terra::crs(slo_elev) <- "EPSG:3035" succeeded and the example rendered.
• Suggestion: A short sidebar in the Setup or Chapter 3 introduction warning macOS readers about this, with the workaround, would save a lot of head-scratching. The issue is independent of the book's content but blocks readers immediately at the first raster example.
• Environment:
• `> sessionInfo()
  R version 4.6.0 (2026-04-24)
  Platform: aarch64-apple-darwin23
  Running under: macOS Tahoe 26.3.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.6/Resources/lib/libRlapack.dylib; LAPACK version 3.12.1

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: Australia/Brisbane
tzcode source: internal

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

other attached packages:
[1] sf_1.1-0 tmap_4.3 spDataLarge_2.2.0 terra_1.9-11

loaded via a namespace (and not attached):
[1] s2_1.1.9 class_7.3-23 lwgeom_0.2-15
[4] KernSmooth_2.23-26 lattice_0.22-9 digest_0.6.39
[7] magrittr_2.0.5 grid_4.6.0 fastmap_1.2.0
[10] e1071_1.7-17 leafsync_0.1.0 DBI_1.3.0
[13] crosstalk_1.2.2 cols4all_0.10 XML_3.99-0.23
[16] codetools_0.2-20 abind_1.4-8 cli_3.6.6
[19] rlang_1.2.0 units_1.0-1 tmaptools_3.3
[22] base64enc_0.1-6 otel_0.2.0 leaflegend_1.2.1
[25] tools_4.6.0 raster_3.6-32 parallel_4.6.0
[28] maptiles_0.11.0 colorspace_2.1-2 spacesXYZ_1.6-0
[31] vctrs_0.7.3 logger_0.4.1 R6_2.6.1
[34] png_0.1-9 proxy_0.4-29 lifecycle_1.0.5
[37] classInt_0.4-11 leaflet_2.2.3 htmlwidgets_1.6.4
[40] pkgconfig_2.0.3 pillar_1.11.1 data.table_1.18.2.1
[43] glue_1.8.1 Rcpp_1.1.1-1.1 tibble_3.3.1
[46] rstudioapi_0.18.0 htmltools_0.5.9 leafem_0.2.5
[49] wk_0.9.5 compiler_4.6.0 sp_2.2-1
[52] stars_0.7-2

sf::sf_extSoftVersion()
GEOS GDAL proj.4 GDAL_with_GEOS USE_PROJ_H
"3.14.1" "3.8.5" "9.5.1" "true" "true"
PROJ
"9.5.1"
`

[Nowosad]

Thanks a lot for the detailed explanation, @markjaypearson. Have you tried to mention this problem at https://github.com/rspatial/terra/issues? It seems to be that this problem should be fixed upstream.