Skip to content
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

WIP: EO Band references proposal #523

wants to merge 2 commits into
base: dev


Copy link

commented Jun 27, 2019

This PR contains examples for a proposal to rework how EO Bands are defined and referenced from Assets, and to act as a facilitator for discussion.

There are three common use cases for Bands:

  1. I have a static Catalog, and define the Bands in the Catalog and reference this single definition from Assets.
  2. I have an API returning an Item with Assets that share no or few bands, and I want to put the band definition directly in the Asset to avoid indirection.
  3. I have a static Catalog or API with Items with Assets that share more than a few bands, and want to define them once in the Item and reference each Band from multiple Assets.

The design constraints around bands are thus:

  1. Bands may defined in an Item or its parent Collection
  2. Assets that share bands should be able to each reference a single Band definition
  3. Many Items will contain Assets that share no bands (e.g, Landsat 8 PDS), so defining Bands separately from the Asset they use them an unnecessary level of indirection.
  4. Referencing Bands by array index is prone to implementation errors, and fragile in the the face of reordering Band definitions.
  5. Semantics for when Bands are defined in the Item and in the Collection are not clearly defined (I would assume Item definition would take precedence, but this is not stated explicitly anywhere)

Overall, I fell that this proposed specification is a good balance between static catalogs that will typically define bands in the Catalog and API result Items that will need to be self-contained and can therefore have the band definitions within the Asset.

PR Checklist:

  • This PR has no breaking changes.
  • I have added my changes to the CHANGELOG or a CHANGELOG entry is not required.
  • API only: I have run npm run generate-all. to update the generated OpenAPI files.

This comment has been minimized.

Copy link

commented Jul 23, 2019

An issue worth reading on the history of bands in STAC: #142

@m-mohr m-mohr added this to the 0.9.0 milestone Aug 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.