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
Stackstac.stack outputs an xarray with coordinates that can be either along band or time dimension but not both.
In the case where an asset has properties which is fluctuates based on the timestamp, stackstac supposedly drops that variable (I've seen cases where it actually picks only one of the values and associates it to the band dimension - but that's not my issue's topic).
However, coordinates typically like landsat 8/9 L1 radiance_mult etc. are very common and are supposed to be different per band and time.
I've already deep-dived into the accumulate_metadata.py and it doesn't seem suited for such cases. I've tried to integrate it by making minimal changes but I'm afraid the full accumulate_metadata.py would better be rewritten from scratch.
Would you be open to such by changes? Would you have a prefered way of proceeding? Should I just open a PR with my suggestion?
The text was updated successfully, but these errors were encountered:
f"Assets must have exactly 1 band, but file {self.url!r} has {nr_of_bands}. "
"We can't currently handle multi-band rasters (each band has to be "
"a separate STAC asset), so you'll need to exclude this asset from your analysis."
)
This prevents, e.g. reading most netcdf files in from stac, despite the fact that GDAL has good support for them, eg like so. (sorry I'm coming from the R language where we our 'stackstac'-like package, gdalcubes, is used like this all the time, and still learning my way around in python)
Stackstac.stack outputs an xarray with coordinates that can be either along band or time dimension but not both.
In the case where an asset has properties which is fluctuates based on the timestamp, stackstac supposedly drops that variable (I've seen cases where it actually picks only one of the values and associates it to the band dimension - but that's not my issue's topic).
However, coordinates typically like landsat 8/9 L1 radiance_mult etc. are very common and are supposed to be different per band and time.
I've already deep-dived into the accumulate_metadata.py and it doesn't seem suited for such cases. I've tried to integrate it by making minimal changes but I'm afraid the full accumulate_metadata.py would better be rewritten from scratch.
Would you be open to such by changes? Would you have a prefered way of proceeding? Should I just open a PR with my suggestion?
The text was updated successfully, but these errors were encountered: