Open m-mohr opened 1 year ago
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.
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.
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).
(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.
We want to have a discussion about this so we can close and have some sort of clear statement regarding our stance on this.
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.
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 ?
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....
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
.
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: https://github.com/opengeospatial/ogc-feat-geo-json/issues/129
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:
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: https://github.com/opengeospatial/ogcapi-records/issues/276 Should we also add explicit media types that could be used?
application/stac+json
?