Links per asset

[m-mohr]

Recently, some people approached me asking to provide related links to individual assets.

Usecases:

• add more processing:expression examples for python, docker and generic URI stac-extensions/processing#33
• Provide a visualization (flat style file) for each asset
• ...

I'm wondering what the best solution for this is:

1. Individual properties that just contains a URL
2. Have a links arrays as defined in STAC also in Assets
3. Add it to the global links array and have a property that identifies which asset it belongs to via the asset key

Looking for opinions and feedback.

Example 1

Drawback is, you can't really provide additional information about the link, e.g. media type.

{
   "assets":{
      "href":"features.geojson",
      "type":"application/geo+json",
      "style":"style.cfg"
   }
}

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.

{
   "assets":{
      "example":{
         "href":"features.geojson",
         "type":"application/geo+json",
         "links":[
            {
               "href":"style.cfg",
               "type":"text/vector-styles",
               "rel":"style"
            }
         ]
      }
   }
}

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.

{
   "assets":{
      "example":{
         "href":"features.geojson",
         "type":"application/geo+json"
      }
   },
   "links":[
      {
         "href":"style.cfg",
         "type":"text/vector-styles",
         "rel":"style",
         "asset":"example"
      }
   ]
}

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:

{
   "assets":{
      "example":{
         "href":"features.geojson",
         "type":"application/geo+json"
      },
      "example2":{
         "href":"features2.geojson",
         "type":"application/geo+json"
      },
      "example3":{
         "href":"features2.tif",
         "type":"image/tiff"
      }
   },
   "links":[
      {
         "href":"style.cfg",
         "type":"text/vector-styles",
         "rel":"style",
         "asset:keys": ["example", "example2"]
      }
   ]
}

[emmanuelmathot]

I had the same request multiple times. I actually already implement solution 3. So I vote 3B

[emmanuelmathot]

similar to stac-extensions/render#6 for renders

[m-mohr]

fyi: I just split 3 into 3A and 3B.

How is your asset reference field in the links defined, @emmanuelmathot ?

[santilland]

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?

[m-mohr]

It would be a new extension

[fmigneault]

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 stac-extensions/processing#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.

[m-mohr]

Two additional notes here:

• I also saw others discussion links per band for example. So this might not just be an asset thing.
• We already have links in contacts.