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

Links per asset #1284

Open
m-mohr opened this issue May 17, 2024 · 6 comments
Open

Links per asset #1284

m-mohr opened this issue May 17, 2024 · 6 comments
Milestone

Comments

@m-mohr
Copy link
Collaborator

m-mohr commented May 17, 2024

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

Usecases:

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
Copy link
Collaborator

emmanuelmathot commented May 17, 2024

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

@emmanuelmathot
Copy link
Collaborator

similar to stac-extensions/render#6 for renders

@m-mohr
Copy link
Collaborator Author

m-mohr commented May 17, 2024

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

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

@santilland
Copy link

santilland commented May 17, 2024

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
Copy link
Collaborator Author

m-mohr commented May 17, 2024

It would be a new extension

@fmigneault
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants