-
Notifications
You must be signed in to change notification settings - Fork 4
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
create tar_terra_sds()
#59
Comments
As you point out the write function approach using subdatasets from .read_terra_rasters_sprc_sds <- if (is.null(sds) || !sds) {
function(path) terra::sprc(path)
} else {
function(path) terra::sds(path)
} I like the idea of having a 1:1 relationship between user-facing methods for creating formats and object types from supported packages, because it is explicit--but the user has already chosen an object type if they are using this method, so having to pair that type with a geotargets format method is essentially a restatement of that choice. These cases where there is a lot of overlap in backend functionality makes me want to handle it internally via arguments with defaults determined from users input object type. I have provided arguments like this ( Also a note for all format methods that rely on creating subdatasets in target file-- From https://gdal.org/user/raster_data_model.html#subdatasets-domain
|
SpatRasterDataset
s are similar toSpatRasterCollection
s (implemented in #50) but all datasets must have the same extent (and projection?). They are a bit easier to work with though, as they appear to be coercible to lists andpurrr::map()
works onSpatRasterDataset
but notSpatRasterCollection
. I'm guessing we can borrow much if not all of the write function fromtar_terra_sprc()
for this.The text was updated successfully, but these errors were encountered: