You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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():
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"?
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: