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

create tar_terra_sds() #59

Open
Aariq opened this issue Apr 26, 2024 · 1 comment
Open

create tar_terra_sds() #59

Aariq opened this issue Apr 26, 2024 · 1 comment
Labels
terra related to compatibility with `terra`

Comments

@Aariq
Copy link
Collaborator

Aariq commented Apr 26, 2024

SpatRasterDatasets are similar to SpatRasterCollections (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 and purrr::map() works on SpatRasterDataset but not SpatRasterCollection. I'm guessing we can borrow much if not all of the write function from tar_terra_sprc() for this.

@Aariq Aariq added the terra related to compatibility with `terra` label Apr 26, 2024
@brownag
Copy link
Contributor

brownag commented Apr 27, 2024

As you point out the write function approach using subdatasets from tar_terra_sprc() works without changes (provided filetype="GTiff") for either SpatRasterDataset or SpatRasterCollection object as the target. Basically all that is needed is a toggle to read with sds() rather than sprc(). Could define read function where sds is a logical value in the format-creating function... Something like this in tar_terra_sprc() or tar_terra_sds():

.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 (proxy, mdim, ncdf) for different read/write features in #33 for {stars}... but have not gone so far as to be detecting object types.

Also a note for all format methods that rely on creating subdatasets in target file-- APPEND_SUBDATASET=YES works for GTiff output of both SpatRasterDataset or SpatRasterCollection objects, but other formats will not necessarily work this way. Perhaps these methods should be limited to filetype="GTiff"?

From https://gdal.org/user/raster_data_model.html#subdatasets-domain

Currently, drivers which support subdatasets are: ADRG, ECRGTOC, GEORASTER, GTiff, HDF4, HDF5, netCDF, NITF, NTv2, OGDI, PDF, PostGISRaster, Rasterlite, RPFTOC, RS2, TileDB, WCS, and WMS.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
terra related to compatibility with `terra`
Projects
None yet
Development

No branches or pull requests

2 participants