Closed brownag closed 6 months ago
A semi-related issue is that it may sometimes be desirable to transfer between OGR sources without reading them into memory. Minimal support for querying and writing a SpatVectorProxy for an arbitrary source was added in https://github.com/brownag/gpkg/commit/8f3cae479dec4d0f8166ab51926893fe3b4658f0... but a more general solution would use an ogr2ogr-like interface, rather than going through a SpatVector/R intermediate object.
This could probably be resolved using {vapour}!
system.file("ex","lux.shp",package="terra") |>
vapour::vapour_driver()
Currently just a small number of file path extensions for raster and vector data are used to identify paths to possible spatial data sources.
Nobody has complained, and I guess it has worked fine for me, but I should have generalized this a long time ago...
I am now thinking perhaps the functionality to support and classify arbitrary file paths in the same call to
gpkg_write()
might be too general. The main reason using file extensions is necessary is because eitherterra::rast()
orterra::vect()
, or a non-spatial table function, needs to be called based on whether a file input is determined to be is a raster, vector, or attribute.Can I create a lookup table of file extensions from file based sources found in
terra::gdal(drivers=TRUE)
?Could I pass an argument so that user needs to specify whether they are writing raster, vector, or attributes? Meaning 1 type per call, or a vector of equal length to the input list denoting data type? Both of these alternate options seem rather cumbersome in comparison to how it works now.