-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
GTI stac-geoparquet driver support for multiple band assets #11321
Comments
Attaching the related items.parquet (as it takes quite a bit to have the setup to generate it): items.parquet.zip This ticket intersects the previous one of #11317 , so with #11319 , now it is possible to specify the LOCATION_FIELD open option to get one particular asset/band:
So with that and classic VRT, an admitedly not so ergonomic solution would be to create a VRT per band, and assemble all those VRT, like:
It would be indeed better to be able to specify maybe That said that would be tricky here because Sentinel 2 bands don't have all the same resolution, whereas in a GDAL dataset all bands must have the same resolution. So probably that internally the GTI driver would need to do the above workaround and align on the 10m resolution, or do like then Sentinel2 driver and expose one subdataset for the 10m bands, one for the 20 m ones and one for the 60m ones |
…ts.XXX.proj:transform fields in addition to top level proj:epsg and proj:transform. Also handle geotransform being a IntegerList or Integer64List. Refs OSGeo#11321 (but does no fix it)
Thanks for the work on this! The second option sounds interesting. I'd like it if there was some limited set of sensible choices for resolution for a given STAC collection that GTI could derive. My initial expectation was that resolution would be a user specified arg but that's only because I've used the opendatacube https://odc-stac.readthedocs.io/en/latest/_api/odc.stac.load.html#odc.stac.load for example
|
odc exposes a limited set of target output grid params, and heuristics to pick a UTM zone if not specified - GTI's virtualness is offering a slot to add this explicitly, but uses similar heuristics to make a choice. It's a kind of slippery user/ux area where you want maximum flexibility (specifying one thing, or the entire grid details, or anything in between including no-user input). There's all kinds of things these heuristics+rules need, like pixel alignment, and resolution-choice (good for when you know), dimension-choice (good for when you want a region for a quick look at n-pixels) - and there's no single framework to guide the user well here, and I don't this this is well understood (entirely off topic but just wanted to add a bit here). |
Feature description
I'd like to be able to load STAC items that have bands referenced as distinct geotiffs. The current GTI docs indicate it is limited to using a
location
field that points to one href per STAC Item.An example I am working with is here: stac-utils/stac-rs#528 (comment)
install
setting up the query
workaround to access the blue band and set it's href as the location field to confirm GTI works
Ideally the GTI driver would interpret the assets section of the stac-geoparquet and load all the bands, if the assets only referenced bands. But this isn't the case
I'm wondering if GTI could look for a different column that points to a list of asset keys that refer to bands that also specifies band order for assembling a multi band mosaic. then it could handle fetching the hrefs from the stac-geoparquet assets section.
Additional context
This would be a nice quality of life feature for various users, top of mind for me is the TorchGeo project which is exploring how to easily make stac queries, persist them, and create mosaics of large raster datasets for model training.
I can help by finding someone to PR if I'm not able to do this work myself and if maintainers don't want to take this on but think it would still be valuable.
The text was updated successfully, but these errors were encountered: