-
Notifications
You must be signed in to change notification settings - Fork 15
feat: add docs for DPS STAC metadata #550
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
base: develop
Are you sure you want to change the base?
Conversation
|
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
| @@ -0,0 +1,4059 @@ | |||
| { | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When we run rio_stac.create_stac_item(...), it may populate the asset href as an absolute local filesystem path (e.g., /tmp/output/demo.tif). That can look fine inside the notebook, but once DPS uploads outputs to S3 and the STAC is ingested, that local path doesn’t exist anymore, so STAC API/tiler clients can’t resolve the asset.maybe we can write asset hrefs to be relative to the STAC JSON location set assets.*.href to something like demo.tif (or ./demo.tif) before writing item.json / catalog.json. This can keeps the STAC portable after upload. (not sure)
Reply via ReviewNB
| @@ -0,0 +1,4059 @@ | |||
| { | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Avoid setting self_href to /tmp/output/.... Keep it relative (e.g., item.json) or let normalize_and_save(...) set it, so the STAC stays portable
Reply via ReviewNB
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is ok to define asset + item hrefs as absolute paths at this point. After we have created the entire catalog we convert the hrefs to relative paths before writing the STAC metadata to json files.
| @@ -0,0 +1,4059 @@ | |||
| { | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Line #9. "grade": "A+", # you can add any relevant attributes/tags here!
maybe setting properties={"grade": "A+"} works, but it’s safer to namespace custom fields so they don’t clash with future STAC extensions.
Reply via ReviewNB
| @@ -0,0 +1,4059 @@ | |||
| { | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The roles assignments for a STAC asset just refer to the type of asset so it's ok for multiple assets to share the data tag. Alternatives include metadata to describe non-data files.
|
@hrodmn I finished the review. I left a few minor suggestions. Nothing blocking, so feel free to ignore any of them if they don’t fit your intended flow. |
This notebook shows how to generate a STAC item and associated catalog.json in a DPS algorithm and how to use the resulting STAC metadata via the DPS STAC API and the attached titiler instance.