You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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 84sf::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.
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
/options
args--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 nameoptions
in most cases.Note that in the above, test.gpkg has two additional metadata tables after write.
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 #33 (comment)
The text was updated successfully, but these errors were encountered: