How does gdalraster make use of gdal?

[wiesehahn]

I have some dummy questions related to how gdalraster makes use of gdal.

If I install from CRAN, I expected it to look for a previously installed gdal version on the system?

But this might be wrong, or what exactly does this mean?

CRAN provides pre-compiled binary packages for Windows and macOS. These do not require any separate installation of external libraries for GDAL.

If I understand correctly then RTools' gdal is used if we install from source on windows?

RTools since version 4.2 includes GDAL and all other dependent libraries that are needed to compile gdalraster.

Can we configure gdalraster also to use a custom gdal version installed on the system?

Basically I ask because I wanted to test capabilities of JXL compression for COG, which

is only available when using internal libtiff and building GDAL against https://github.com/libjxl/libjxl

and while I have a version installed which supports this (via osgeo4w), the gdal version which is used by gdalraster (I think from RTools) seems not to support JXL.

[ctoney]

Good questions.

If I install from CRAN, I expected it to look for a previously installed gdal version on the system?

It will not look for libraries installed on the system in that case. Pre-compiled binaries basically mean that the library code is already "compiled in" by CRAN (or by R-universe which does this automatically for development versions from the GitHub repo).

If I understand correctly then RTools' gdal is used if we install from source on windows?

Yes, RTools provides the toolchain (compilers and related software needed to build R and packages), bundled with many of the external libraries required by R packages that use compiled code with such libraries. Since RTools 4.2, this has included comprehensive support for geospatial libraries like GDAL, PROJ and their dependencies.

Can we configure gdalraster also to use a custom gdal version installed on the system?

Maybe but it would not be easy and requires that GDAL development files are present (the header files) and that the custom GDAL libraries are built with the same compiler used to build R and gdalraster (i.e., the RTools toolchain). I develop primarily on Linux and don't have the Windows expertise to accomplish this. More likely, the approach to add a custom GDAL build with JXL enabled on Windows would be to add libjxl in RTools, and customize its GDAL build configuration to use it. Tomas Kalibera has an excellent and very thorough Howto: Building R 4.5 and packages on Windows that describes this (e.g., see the section "Adding/updating an MXE package"). I'm not sure how difficult it would be to add an MXE package for libjxl, and then modify the existing GDAL package (https://svn.r-project.org/R-dev-web/trunk/WindowsBuilds/winutf8/ucrt3/toolchain_libs/mxe/src/gdal.mk) to include -DGDAL_USE_JXL:BOOL=ON.

Basically I ask because I wanted to test capabilities of JXL compression for COG

If using Docker is an option, that could be a straightforward way to test things like that. In that case, the thread in #703 may be helpful. The initial code I posted there shows how to set up a docker container manually, starting with a GDAL-provided image (e.g., GDAL 3.11) and installing R and gdalraster with its dependencies. That code is sort of a light tutorial if you have basic familiarity with docker, but you may want to skip down the thread and check out the more sophisticated automated builds that @mdsumner has been curating. For example, ghcr.io/mdsumner/gdal-builds:r-gdalraster already has latest GDAL development version with R and gdalraster installed. In a container started from that image we can run R and have:

library(gdalraster)
#> GDAL 3.12.0dev-ce5f0f192b46eb67243a037a241e0ad010a2e378 (released 2025-05-06), GEOS 3.12.1, PROJ 9.7.0

getCreationOptions("COG", "COMPRESS") 
#> $COMPRESS
#> $COMPRESS$type
#> [1] "string-select"

#> $COMPRESS$description
#> [1] NA

#> $COMPRESS$default
#> [1] "LZW"

#> $COMPRESS$values
#> [1] "NONE"         "LZW"          "JPEG"         "DEFLATE"      "LZMA"        
#>  [6] "ZSTD"         "WEBP"         "LERC"         "LERC_DEFLATE" "LERC_ZSTD"   
#> [11] "JXL"         

#> $COMPRESS$min
#> [1] NA

#> $COMPRESS$max
#> [1] NA

[wiesehahn]

Thanks for the detailed answer.
Actually it was just out of curiosity and at the moment its not super important to me, but if I find some time I might check out the docker solution, which looks great.

[wiesehahn]

haha, just had the same question again and found my own dicussion question here. So it seems I have not learned anything.
so the only option to run gdalraster with recent gdal versions is via docker?

how is decided which version is build in the CRAN or R-universe version and when is this updated?

from CRAN

> install.packages("gdalraster")
> packageVersion("gdalraster")
[1] ‘2.2.1’
> library(gdalraster)
GDAL 3.10.1 (released 2025-01-08), GEOS 3.13.0, PROJ 9.5.1

from Github an R-Universe

> remotes::install_github("USDAForestService/gdalraster")
> packageVersion("gdalraster")
[1] ‘2.2.1.9055’
> library(gdalraster)
GDAL 3.9.3 (released 2024-10-07), GEOS 3.12.2, PROJ 9.4.1

Is this older cause its using RTools gdal version (I havent updated RTools)?

[ctoney]

Yes, for Windows, RTools provides the build tool chain (used on both CRAN and r-universe) but is also bundled with a fairly large number of external libraries used by R packages (which are statically linked and must be built with the same tool chain). For spatial packages this includes GDAL, PROJ, GEOS and their dependencies. A given version of R has a corresponding version of RTools that must be used, e.g., RTools45 for R 4.5.x. But over the lifetime of a given R minor version release (e.g., R 4.5.x), there will be multiple RTools releases. E.g., RTools45 has releases 6536, 6608 and 6691 so far. These RTools releases generally include updated versions of the external libraries.

Support for geospatial libraries in RTools is quite good and versions are updated regularly. A changelog of updates is maintained at
https://cran.r-project.org/bin/windows/Rtools/rtools45/news.html.

[wiesehahn]

thanks, this explains something.