`vrt` ignores options on Mac OS

[dramanica]

When attempting to create a vrt where multiple files are treated as separate bands, the command fails on OSX but works fine in Linux. On OSX, the problem seems to be that the options are ignored:

library(terra)
#> terra 1.7.65
r <- terra::rast(ncols=100, nrows=100)
values(r) <- 1:ncell(r)
r2 <- r*2
file_name_1 <- file.path(tempdir(),"raster1.tif")
file_name_2 <- file.path(tempdir(),"raster2.tif")
vrt_filename <- file.path(tempdir(),"test.vrt")
terra::writeRaster(r, file_name_1)
terra::writeRaster(r2, file_name_2)
terra::vrt(c(file_name_1,file_name_2), filename = vrt_filename, overwrite=TRUE,
           options="-separate")
#> class       : SpatRaster 
#> dimensions  : 100, 100, 1  (nrow, ncol, nlyr)
#> resolution  : 3.6, 1.8  (x, y)
#> extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
#> coord. ref. : lon/lat WGS 84 (EPSG:4326) 
#> source      : test.vrt 
#> name        :  test 
#> min value   :     1 
#> max value   : 20000

<sup>Created on 2024-01-26 with [reprex v2.1.0](https://reprex.tidyverse.org)</sup>

This is the same output as we get from:

terra::vrt(c(file_name_1,file_name_2), filename = vrt_filename, overwrite=TRUE)

On Ubuntu, the -separate flag gives me a raster with two layers as expected. A similar problem is seen using the example for vrt (which uses option tr), so, this is a problem with options in general and not the specific options chosen.

Using terra version 1.7-65 and gdal v 3.5.3. Also, tested on terra dev 1.7-69

[rhijmans]

terra uses the GDAL tool for that, so the variation between OSs is probably due to different versions of GDAL. Also see https://github.com/rspatial/terra/issues/1341

[dramanica]

I don't think it's a GDAL version issue. If I use:

sf::gdal_utils(
      util = "buildvrt",
      source = c(file_name_1,file_name_2),
      destination = vrt_filename,
      options = c("-separate","-overwrite")
    )

I can create the file correctly.

[rhijmans]

Maybe, but that does not really prove it, as the sf function directly uses the GDAL tool (gdalbuildvrt) whereas terra calls the C interface GDALBuildVRT. I may have made a mistake, but since it works on other platforms, I still suspect that the GDAL version plays a role. We would probably need some dockers on linux to corroborate or disprove that this would be broken in the current CRAN/windows GDAL (version 3.7.2).

[kadyb]

This seems to be reproducible on macOS 12 with GDAL 3.8.1: https://github.com/kadyb/test3/actions/runs/7712093740/job/21018843693

Repository: https://github.com/kadyb/test3

[edzer]

Maybe, but that does not really prove it, as the sf function directly uses the GDAL tool (gdalbuildvrt) whereas terra calls the C interface GDALBuildVRT.

No, see https://github.com/r-spatial/sf/blob/main/src/gdal_utils.cpp#L345