njtierney / geotargets

Targets extensions for geospatial data
https://njtierney.github.io/geotargets/
Other
49 stars 4 forks source link

create `tar_terra_sds()` #59

Open Aariq opened 2 months ago

Aariq commented 2 months ago

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.

brownag commented 2 months ago

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.