I am going to suggest that we follow what the backend package's write function uses until we can identify how many unique "GDAL option" types we have to deal with across read and write, then choose a consistent name for each of them.
We currently only provide ability to set "creation options" via terra gdal/optionsargs--but for some GDAL vector drivers there is the ability to set both dataset and layer creation options for write.
I note that {sf} write has these option types separately via sf::st_write(..., layer_options=foo, dataset_options=bar). It appears terra::writeVector() does not currently support "dataset" creation options. For all packages we also have the "read" options (GDAL "open options"), which also use the argument name options in most cases.
```r
x <- sf::st_read(system.file("ex", "lux.shp", package = "terra"))
#> Reading layer `lux' from data source `/home/andrew/R/x86_64-pc-linux-gnu-library/4.3/terra/ex/lux.shp' using driver `ESRI Shapefile'
#> Simple feature collection with 12 features and 6 fields
#> Geometry type: POLYGON
#> Dimension: XY
#> Bounding box: xmin: 5.74414 ymin: 49.44781 xmax: 6.528252 ymax: 50.18162
#> Geodetic CRS: WGS 84
sf::st_write(x, "test.gpkg", append=F, dataset_options="METADATA_TABLES=YES")
#> options: METADATA_TABLES=YES
#> Writing layer `test' to data source `test.gpkg' using driver `GPKG'
#> Writing 12 features with 6 fields and geometry type Polygon.
terra::writeVector(terra::vect(x), "test2.gpkg", options = "METADATA_TABLES=YES")
#> Warning message:
#> In x@ptr$write(filename, layer, filetype, insert[1], overwrite[1], :
#> GDAL Message 6: dataset test2.gpkg does not support layer creation option METADATA_TABLES
## install.packages("gpkg")
gpkg::gpkg_list_tables("test.gpkg")
#> [1] "gpkg_contents" "gpkg_extensions" "gpkg_geometry_columns" "gpkg_metadata"
#> [5] "gpkg_metadata_reference" "gpkg_ogr_contents" "gpkg_spatial_ref_sys" "gpkg_tile_matrix"
#> [9] "gpkg_tile_matrix_set" "rtree_test_geom" "rtree_test_geom_node" "rtree_test_geom_parent"
#> [13] "rtree_test_geom_rowid" "sqlite_sequence" "test"
gpkg::gpkg_list_tables("test2.gpkg")
#> [1] "gpkg_contents" "gpkg_extensions" "gpkg_geometry_columns" "gpkg_ogr_contents"
#> [5] "gpkg_spatial_ref_sys" "gpkg_tile_matrix" "gpkg_tile_matrix_set" "rtree_test2_geom"
#> [9] "rtree_test2_geom_node" "rtree_test2_geom_parent" "rtree_test2_geom_rowid" "sqlite_sequence"
#> [13] "test2"
```
Note that in the above, test.gpkg has two additional metadata tables after write.
Originally raised by @Aariq
Just noticing that sometimes this arg is called options and sometimes it is called gdal. We should decide whether we want to be consistent throughout geotargets or if we want to be consistent with whatever function the arg is being passed to (or split the difference and call it gdal_options)
This is a good idea. I was sortof leaning towards emulating whatever the "write" function uses for each particular spatial backend being used... But that won't cover everything. I definitely see the value of choosing something consistent across geotargets.
I am going to suggest that we follow what the backend package's write function uses until we can identify how many unique "GDAL option" types we have to deal with across read and write, then choose a consistent name for each of them.
We currently only provide ability to set "creation options" via terra
gdal/optionsargs--but for some GDAL vector drivers there is the ability to set both dataset and layer creation options for write.I note that {sf} write has these option types separately via
sf::st_write(..., layer_options=foo, dataset_options=bar). It appearsterra::writeVector()does not currently support "dataset" creation options. For all packages we also have the "read" options (GDAL "open options"), which also use the argument nameoptionsin most cases.Originally raised by @Aariq
This is a good idea. I was sortof leaning towards emulating whatever the "write" function uses for each particular spatial backend being used... But that won't cover everything. I definitely see the value of choosing something consistent across geotargets.
_Originally posted by @brownag in https://github.com/njtierney/geotargets/pull/33#discussion_r1531465015_