-
Notifications
You must be signed in to change notification settings - Fork 179
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
eo:bands array #247
eo:bands array #247
Conversation
trying to get all of the examples as well.
I realized the eo extension didn't discuss the band indexes in the assets. So I added a section describing that as well. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for making this PR. Overall I'm fine with these changes, but I was fine with bands as objects, too. To me personally, there not so much difference in both approaches for bands.
I suggest some changes regarding the chapter "Associating assets with bands" and the type definition of eo:bands.
I don't like that we are mixing in some other changes here regarding collections/metadata inheritance. That should be a separate PR that others can discuss separately.
extensions/examples/L1T-catalog.json
Outdated
"rel": "self" | ||
} | ||
], | ||
"properties": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wouldn't change to the new catalog.json inherited metadata model in this PR as this is not the topic of this PR. That should be separated.
extensions/examples/README.md
Outdated
@@ -1,8 +1,8 @@ | |||
## Landsat Example with EO and Collection extension | |||
## Landsat Example with EO and common metadata extension |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is it now a "common metadata extension"? Did I miss something yesterday?
extensions/stac-eo-spec.md
Outdated
@@ -21,7 +21,7 @@ It is not necessary, but recommended to use the [Collections extension](stac-col | |||
| eo:platform | string | **REQUIRED.** Unique name of the specific platform the instrument is attached to. For satellites this would be the name of the satellite (e.g., landsat-8, sentinel-2A), whereas for drones this would be a unique name for the drone. | | |||
| eo:constellation | string | **REQUIRED.** Name of the group or constellation that the platform belongs to. Example: The Sentinel-2 group has S2A and S2B, this field allows users to search for Sentinel-2 data without needing to specify which specific platform the data came from. | | |||
| eo:instrument | string | **REQUIRED.** Name of instrument or sensor used (e.g., MODIS, ASTER, OLI, Canon F-1). | | |||
| eo:bands | Map<string, Band Object> | **REQUIRED.** This is a dictionary of band information where each key in the dictionary is an identifier for the band (e.g., "B01", "B02", "B1", "B5", "QA"). | | |||
| eo:bands | List<Band Object> | **REQUIRED.** This is a list of the available bands where each item is a Band Object. | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We usually list arrays as [Band Object]
in the other spec files.
extensions/stac-eo-spec.md
Outdated
@@ -82,13 +84,104 @@ numbers of several popular instruments. | |||
| lwir11 | 10.5 - 11.5 | | | 10 | | 31 | | |||
| lwir12 | 11.5 - 12.5 | | | 11 | | 32 | | |||
|
|||
|
|||
#### Associating assets with bands |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added that in #245 as well. I'd suggest mixing both approaches, I have the format description, you have the more human-readable description.
So, I'd suggest changing this a little to:
## Associating assets with bands
Asset definitions that contain band data should reference the band index. Each asset should provide a "eo:bands" property that is an array of 0 based indexes to the correct Band Objects.
### Item `Asset Object` fields
| Field Name | Type | Description |
| ---------- | -------- | -------------------------------------------- |
| eo:bands | [number] | Lists the band names available in the asset. |
See [landsat8-merged.json](examples/landsat8-merged.json) for a full example.
...
What I also didn't thought of yesterday, that we wanted to add additional values to this field (for example offset and scale, see #245). So this would change the structure of this field a bit, but shouldn't be a big problem.
@m-mohr I got a little carried away trying to see what the new catalog format would look like. I agree that it should be done separately, so those parts have been reverted. |
Thank you for fixing the issues. I think there's one left (see comment). Other than that it's ready for approval. |
@m-mohr I think I addressed them all. Was there a specific comment you are referring too? |
@hgs-truthe01 Yes, a new one added after your commits. There is still a band objects in the properties object, which imho is not allowed. See the Planet example... |
@m-mohr I didn't notice that I had done that in the example snippets. It should be corrected now. As a side note, I don't think we should be putting any extensions outside of the properties, but this is not the right place to discuss that! |
extensions/stac-eo-spec.md
Outdated
"type": "Feature", | ||
"properties": { | ||
... | ||
"eo:bands":[ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't that be outside of the properties?
Thanks. => Approved.
I fully agree with that, but there were these concerns that objects/arrays could not be viewed correctly in legacy(?) GIS systems?! |
After discussion, we are now proposing that eo:bands be represented as an array.
This will be particularly helpful when searching for items with band definitions that don't have well known names.
I also updated the extension example to use the new catalog.json inherited metadata model instead of the collections extension.