stac-spec

stac-spec copied to clipboard

Related Issue(s): #1198

Proposed Changes:

1. Added method, headers, body fields in links objects

PR Checklist:

• [X] This PR is made against the dev branch (all proposed changes except releases should be against dev, not master).
• [ ] This PR has no breaking changes.
• [X] I have added my changes to the CHANGELOG or a CHANGELOG entry is not required.
• [X] This PR affects the STAC API spec, and I have opened issue https://github.com/radiantearth/stac-api-spec/issues/435 to track the change.

This looks generally good, but a couple of thoughts (for here and partially also the API):

• headers: Shouldn't this be strictly just be a Map<string, string>?
• body: Shouldn't this allow anything? Why is it only an object? Why can't it be a string or an array for example?

I used the same spec as per STAC API to be aligned since the initial issue was about being in line with STAC API.

• Should we have a central place where we define links so that it's not so repetitive?

I moved link object definitions from item, catalog and collection to common metadata page

I used the same spec as per STAC API to be aligned since the initial issue was about being in line with STAC API.

Maybe that's something we should actually bring up in the API and change there, too...

I moved link object definitions from item, catalog and collection to common metadata page

Not sure whether that's a good idea. That would need a broader change also in the schema as it implies links can now be used in Assets, Providers, Links itself, ... basically everywhere. I don't think that's intended.

Discussion in STAC meetup: use Map<string, *> that is also an object and thus not break STAC API spec

Looks solid, I just proposed two additional clarifications around the method. Happy to approve afterwards.