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

Separate media type for STAC? #1235

Open
m-mohr opened this issue Jun 7, 2023 · 10 comments
Open

Separate media type for STAC? #1235

m-mohr opened this issue Jun 7, 2023 · 10 comments
Milestone

Comments

@m-mohr
Copy link
Collaborator

m-mohr commented Jun 7, 2023

Do we need a way to distinguish links to STAC and OGC API - Records somehow?

A link to a STAC JSON file with relation type child looks exactly like a link to OGC API - Records, although they are not fully compatible. They both would look as follows:

{
  "href": "./catalog.json",
  "rel": "child",
  "type": "application/json"
}

I could see a world where STAC and Record JSON files will be mixed in one catalog (actually, I'm currently working on a project that would benefit from it).

The only way I could distinguish them right now consistently, is probably to load the files and check whether stac_version is present (STAC) or not (=> likely Records, but could also be something else).

Thoughts?

Records is adding explicit media types: opengeospatial/ogcapi-records#276
Should we also add explicit media types that could be used? application/stac+json?

@gadomski
Copy link
Collaborator

gadomski commented Jun 7, 2023

How would this work for Items, which are currently application/geo+json? Changing that type (which is auto-detected by tooling e.g. for display) would remove functionality we currently get for free.

@m-mohr
Copy link
Collaborator Author

m-mohr commented Jun 7, 2023

Not sure, the same applies for Records. We can also all live under the the same media type, but then you may not know whether you actually get a STAC or not. You may also only use it if it's mixed content. Maybe this really is just an optional addition in case you start to mix things? Not sure. I really just raised it in both specs to discuss and collect thoughts.

@m-mohr
Copy link
Collaborator Author

m-mohr commented Jun 7, 2023

Maybe the better way is application/geo+json; application=stac-item and application/json; application=stac-collection etc? That at least keeps the main media type (although I'm sure many implementations don't parse media types and only compare strings for equallity).

@gadomski
Copy link
Collaborator

gadomski commented Jun 7, 2023

(although I'm sure many implementations don't parse media types and only compare strings for equallity). [sic]

Yeah this is a downside, I usually just see == in tooling when checking media types.

One benefit of application/json; application=stac-collection is you can actually know (probably) whether you're getting a collection or catalog when you're resolving a child.

@PowerChell
Copy link

We want to have a discussion about this so we can close and have some sort of clear statement regarding our stance on this.

@matthewhanson
Copy link
Collaborator

Should mention somewhere (best practices) that if you mix OGC API Records and STAC that clients cannot tell from the type alone if the target is a STAC Item or an OGC Record.

@matthewhanson
Copy link
Collaborator

Not sure where this left off in the sprint. can we arbitrarily and legitimately add a profile to a media type, e.g., application=stac-collection ?

@m-mohr
Copy link
Collaborator Author

m-mohr commented Nov 7, 2023

I think we concluded that media types are difficult to extend for us. Maybe Records gets a separate media type or we just use an additional field to indicate it? Ultimately, you'd not need it anway if STAC is a profile of Records....

@fmigneault
Copy link

Explicit types for STAC would be amazing!
Currently, many processes return application/geo+json without distinction.
For backward compatibility of servers expecting and already supporting this type, I believe application/geo+json; application=stac-item and application/json; application=stac-collection are more appropriate than application/stac+json.

@m-mohr
Copy link
Collaborator Author

m-mohr commented Jun 27, 2024

Changing the media type in 1.1 is likely breaking in a lot of implementations, as such we need to to this in 2.0.

Here's a related discussion on the do and don'ts: opengeospatial/ogc-feat-geo-json#129

@m-mohr m-mohr modified the milestones: 1.1, 2.0 Jun 27, 2024
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

5 participants