Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make GDAL option argument names consistent across geotargets #44

Open
brownag opened this issue Mar 20, 2024 · 0 comments
Open

Make GDAL option argument names consistent across geotargets #44

brownag opened this issue Mar 20, 2024 · 0 comments

Comments

@brownag
Copy link
Contributor

brownag commented Mar 20, 2024

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 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.

Originally posted by @brownag in #33 (comment)

@brownag brownag mentioned this issue Mar 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant