Open m-mohr opened 4 months ago
I had the same request multiple times. I actually already implement solution 3. So I vote 3B
similar to https://github.com/stac-extensions/render/pull/6 for renders
fyi: I just split 3 into 3A and 3B.
How is your asset reference field in the links defined, @emmanuelmathot ?
3B seems like the most flexible option to me too. Would this mean adding a new rel type to the best practices? https://github.com/radiantearth/stac-spec/blob/master/best-practices.md#using-relation-types Or would the idea more to have a dedicated extension?
It would be a new extension
I agree that 3B would be the best to limit introducing too many new functionalities. 3B allows preserving the current STAC structure, and one can apply a filter by matching asset:keys
if needed.
Note however that I do not consider this to be a solution for https://github.com/stac-extensions/processing/pull/33. This links
+asset:keys
would work for the format: uri
case, but does not make sense for all other format: docker
, format: python
, etc. that are not an HTTP link.
Recently, some people approached me asking to provide related links to individual assets.
Usecases:
I'm wondering what the best solution for this is:
Looking for opinions and feedback.
Example 1
Drawback is, you can't really provide additional information about the link, e.g. media type.
Example 2
Note: File format, media type an rel type are examples and probably don't exist.
Existing tooling may not understand this, but it re-uses an existing structure and the links are close to the assets.
Example 3A
Note: File format, media type an rel type are examples and probably don't exist.
This works the best with existing tooling, but the information are not close together. It's a little harder to implement as you need to filter the links for each asset.
Example 3B
Potentially this could allow assigning a link to multiple assets if we slightly change it. This could allow a bit of de-duplication: