terra targets: pass additional arguments via ... to writeRaster/writeVector

[brownag]

This is a possible fix for #132 (issues with datatype and additional arguments to writeRaster()) originally raised by @hansvancalster in #127. With this PR, additional arguments (...) passed to tar_terra_rast() and tar_terra_vect() are substituted into writeRaster/writeVector calls.

For example, with tar_terra_rast(datatype= ):

# write as FLT8S
targets::tar_script({
    library(targets)
    library(geotargets)
    list(
        
        tar_terra_rast(x, terra::rast(
            system.file("ex", "elev.tif", package = "terra")
        ), datatype = "FLT8S")
    
    )
})

targets::tar_make()
#> ▶ dispatched target x
#> ● completed target x [0.013 seconds, 13.106 kilobytes]
#> ▶ ended pipeline [0.174 seconds]
targets::tar_load(x)
terra::datatype(x)
#> [1] "FLT8S"

targets::tar_make()
#> ✔ skipped target x
#> ✔ skipped pipeline [0.088 seconds]
targets::tar_load(x)
terra::datatype(x)
#> [1] "FLT8S"

# changing datatype to INT2U invalidates the target
targets::tar_script({
    library(targets)
    library(geotargets)
    list(
        
        tar_terra_rast(x, terra::rast(
            system.file("ex", "elev.tif", package = "terra")
        ), datatype = "INT2U")
        
    )
})

targets::tar_make()
#> ▶ dispatched target x
#> ● completed target x [0.01 seconds, 8.4 kilobytes]
#> ▶ ended pipeline [0.221 seconds]
targets::tar_load(x)
terra::datatype(x)
#> [1] "INT2U"

[Aariq]

Nice! I tried to figure out a way to get this to work without do.call() using rlang::list2(...) and !!!args instead (just for slightly easier readability), but that doesn't seem to play nicely with tar_format(). Should we keep gdal as an argument for tar_terra_*() or deprecate it (and the associated option) now that it gets passed via ...? Maybe fine to keep it since gdal seems like something you might want to set for an entire pipeline?

[brownag]

Should we keep gdal as an argument for tar_terra_*() or deprecate it (and the associated option) now that it gets passed via ...? Maybe fine to keep it since gdal seems like something you might want to set for an entire pipeline?

I agree that the GDAL options and drivers may be more likely to be properties that we want to set for all or part of a pipeline, whereas datatype and friends can be more dataset/target specific. There will be cases where folks need specific option values for individual targets, and pipelines where folks want to handle all targets with the same specific settings, so we should make both easier if possible.

IMO it makes sense to have ... be passed to the "write" functions for targets, so I think this is a good use of the currently-unused ... in geotargets functions.

I think it is fine to keep gdal and options as explicit arguments. As devil's advocate I would suggest datatype could be an explicit option because it affects target data size and precision, and also interacts with options such as those for compression. Other writeRaster() arguments are mostly used less frequently and have lower impact on the raster data itself.

The ergonomics of substitute argument to tar_format() are pretty nice and do make me wonder whether we need all the extra options infrastructure that we developed before all these great additions to targets. But I think it is valuable to provide the option to use the options, as long as it doesn't get in the way of functionality or reproducibility.