-
Notifications
You must be signed in to change notification settings - Fork 17
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
load_stac: band order remark #488
Comments
cc @bossie |
FYI, my interpretation was that this "metadata" refers to the list of bands in an Item's |
Yeah, this needs clarification. Proposal:
For categorical, non-band dimensions (i.e. type |
See also #489 for a related issue. |
To be devils advocate: that proposal looks quite complicated (lot of ifs and branches) which on its own is not very user friendly, and it also practically means that effective band order (and even band names) might suddenly change if the data provider changes/improves their STAC metadata (e.g. add I wonder if it wouldn't be better to keep it simpler (including allowing the actual band order and names to be undefined if metadata is missing) and just add a strong recommendation for users to explicitly specify |
That would be another, more simple option, indeed. The list above only applies if the bands array is not specified anyway. |
Let's try to simplify and still give the user something to work with:
For load_collection it's simpler, there only 1 and 2 apply. |
Based on #491, I guess you mean with "values" the "values" field from "cube:dimensions" from the datacube STAC extension?
I'm not completely sure what you mean with "file" or "the file" in this context, but as I mentioned in #491 I think this might not be as trivial as is sounds: there might be multiple "files" in play with inconsistent band sets or band order; the "file" aspect of the data to load might be an implementation detail of the data provider and subject to change |
Yes.
Source data, whatever that might be. Usually COGs, netCDF, ... For me this is a fall back and as such a best effort thing to give at least some clue, e.g. how GDAL does it maybe. I assume consistent STAC catalogs here. If this doesn't work we are back to "undefined" anyway, so I'm not sure whether having the file reference really hurts. |
dev telco:
|
openeo-processes/proposals/load_stac.json
Line 4 in ad8a2f3
has this remark:
What does "ordered as specified in the metadata" mean practically?
Also, doesn't this heavily depends on STAC extensions in play (if any)?
For example, take a STAC Item like this (using the eo STAC extension):
I assume the spirit of the remark above is to take band order ["B04", "B05"], but this comes from the "assets" mapping, which technically does not imply an order.
The text was updated successfully, but these errors were encountered: