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

Distinguishing links to STAC / OGC API - Records? #276

Closed
m-mohr opened this issue May 30, 2023 · 5 comments · Fixed by #305
Closed

Distinguishing links to STAC / OGC API - Records? #276

m-mohr opened this issue May 30, 2023 · 5 comments · Fixed by #305
Assignees

Comments

@m-mohr
Copy link
Contributor

m-mohr commented May 30, 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?

@pvretano
Copy link
Contributor

pvretano commented Jun 6, 2023

@m-mohr that did not occur to me but now that you mention it, it might be a good idea. I was thinking of defining specific MIME types for each of the OARec file types ...

  • application/ogc-record+json for an OARec record
  • application/ogc-folder+json for an OARec folder
  • application/ogc-catalogue+json for an OARec record collection (aka catalogue)

I think that would help the link issue ... no?

@pvretano pvretano added this to Backlog in Part 1: Core via automation Jun 6, 2023
@pvretano pvretano self-assigned this Jun 6, 2023
@pvretano pvretano moved this from Backlog to Waiting for Input/feedback in Part 1: Core Jun 6, 2023
@m-mohr
Copy link
Contributor Author

m-mohr commented Jun 6, 2023

Yes, that would be a good solution, indeed.

@pvretano
Copy link
Contributor

pvretano commented Jun 6, 2023

@m-mohr OK ... I'll create a PR to add these MIME types

@pvretano pvretano moved this from Waiting for Input/feedback to To be drafted in Part 1: Core Jun 6, 2023
@m-mohr
Copy link
Contributor Author

m-mohr commented Jun 7, 2023

@pvretano There's a relevant line of comments in the corresponding STAC issue, which you might want to consider:
radiantearth/stac-spec#1235 (comment)

Maybe something like application/geo+json; application=ogc-record is better to keep compliance with existing media types? I'm pretty sure it can't be registered though... (practice vs. bureaucracy, as for COG)

@pvretano
Copy link
Contributor

pvretano commented Jun 7, 2023

@m-mohr yeah, I realized that about the record media type last night when I was thinking about this some more. application/geo+json; application=ogc-record sound find to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Part 1: Core
  
Done
Development

Successfully merging a pull request may close this issue.

2 participants