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

Collection Metadata #62

Merged
merged 15 commits into from
Nov 21, 2024
Merged

Collection Metadata #62

merged 15 commits into from
Nov 21, 2024

Conversation

mpiannucci
Copy link
Contributor

We do not have nested collections but this PR moves us closer, making a new route on /edr/ that returns json formatted metadata attempting to match the reference spec (https://docs.ogc.org/is/19-086r6/19-086r6.html#_5d07dde9-231a-4652-a1f3-dd036c337bdc) as close as possible without going overboard.

xpublish_edr/plugin.py Outdated Show resolved Hide resolved
xpublish_edr/plugin.py Outdated Show resolved Hide resolved
xpublish_edr/plugin.py Outdated Show resolved Hide resolved
@mpiannucci mpiannucci marked this pull request as ready for review November 21, 2024 15:31
Copy link
Member

@abkfenris abkfenris left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this looks pretty good in itself, but I had a few questions about goals for this endpoint and others, so Matt and I chatted over Slack. This takes us from building a handful OGC EDR compatible endpoints to making a more custom but non-compliant version of the overall OGC API spec (dataset/collection metadata at a different relative path in relation to the EDR endpoints).

We have the hooks already in Xpublish (even before we incorporate datatrees) that we could build an xpublish-ogc-compliance plugin, so before we go too far down the road of fully custom endpoints, we can plan ahead on how to get to a OGC complaint future.

xpublish_edr/plugin.py Outdated Show resolved Hide resolved
@mpiannucci
Copy link
Contributor Author

mpiannucci commented Nov 21, 2024

This takes us from building a handful OGC EDR compatible endpoints to making a more custom but non-compliant version of the overall OGC API spec (dataset/collection metadata at a different relative path in relation to the EDR endpoints).

@abkfenris I dont think I follow this. In the spec the routes look like this:

/edr/collections/
/edr/collections/{collection_id}/
/edr/collections/{collection_id}/position
/edr/collections/{collection_id}/area

But with this PR ours is now this:

/{dataset_id}/edr/ # THIS PR
/{dataset_id}/edr/position
/{dataset_id}/edr/area

So we are not changing the routes any more than how they exist now

We have the hooks already in Xpublish (even before we incorporate datatrees) that we could build an xpublish-ogc-compliance plugin, so before we go too far down the road of fully custom endpoints, we can plan ahead on how to get to a OGC complaint future

I fully think we should do this. To support this, before merging I will breakout the collections metadata to its own function so when we refactor into collections it is just plug and play for that. I do not want to do those plugins in this PR tho

@abkfenris
Copy link
Member

The spec doesn't have a leading /edr.

/collections/
/collections/{collection_id}/
/collections/{collection_id}/position
/collections/{collection_id}/area

/collections/ and /collections/{collection_id} is part of the common OGC API spec, and is extended by the various additional specs, so multiple specs get merged together under it's namespace

/collections/{collection_id}/position
/collections/{collection_id}/items - for features/records
/collections/{collection_id}/map/tiles - for map tiles
/collections/{collection_id}/coverages - for coverage downloads in other formats (some of what we've implemented by extending EDR formats)

@mpiannucci
Copy link
Contributor Author

Gotcha. Their spec has /edr/ all over it but youre right that its not really in the spec, just in their reference urls.

@abkfenris
Copy link
Member

Ya, they don't explain the fact that the spec is just part of a greater union of specs and then throw those mistakes in there doesn't help.

@mpiannucci
Copy link
Contributor Author

Okay I think this is as far as it should go in this PR for now.

I moved all the metadata to its own module and typed the entire collection metadata with pydantic.

@mpiannucci mpiannucci requested a review from abkfenris November 21, 2024 21:18
Copy link

codecov bot commented Nov 21, 2024

Codecov Report

Attention: Patch coverage is 92.04545% with 14 lines in your changes missing coverage. Please review.

Project coverage is 89.64%. Comparing base (434d6b9) to head (9c8c808).
Report is 14 commits behind head on main.

Files with missing lines Patch % Lines
xpublish_edr/metadata.py 94.28% 8 Missing ⚠️
xpublish_edr/geometry/common.py 76.92% 6 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff             @@
##             main      #62       +/-   ##
===========================================
+ Coverage   79.02%   89.64%   +10.61%     
===========================================
  Files           6       12        +6     
  Lines         205      560      +355     
===========================================
+ Hits          162      502      +340     
- Misses         43       58       +15     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.


🚨 Try these New Features:

@mpiannucci mpiannucci merged commit 7a75087 into main Nov 21, 2024
23 checks passed
@mpiannucci mpiannucci deleted the metadata branch November 21, 2024 21:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants