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

Add ADR for CO2 stac api entry #147

Open
wants to merge 1 commit into
base: feature/adrs
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions adrs/co2-stac-metadata.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
# STAC metadata design for CO2 dataset

## Status

Proposed

## Context

The decision to use a STAC API as the backend for the climate dashboard arose the need to design STAC metadata for the model data and thematic data. This ADR deals with the design for one of the thematic data - CO2.

## Decision

Each of the thematic dataset (in this case, CO2) will be a STAC item.

Depending on the usability, it might make sense to make some custom STAC extensions for some of the metadata like legend, swatch, etc.

The proposed CO2 stac metadata is linked [here](co2.json).

## Consequences

Relative to the current implementation of frontend, there will be a few changes to how we access each of the dataset metadata since the keys/values have been rearranged to better align with the STAC spec.

However, this alignment with the STAC API will improve interoperatibility and extensibiliy.
123 changes: 123 additions & 0 deletions adrs/co2.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,123 @@
{
"stac_version": "1.0.0",
"stac_extensions": [],
"type": "Feature",

Choose a reason for hiding this comment

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

I think there should be an STAC example both for the collection (co2) and for specific items (s3://covid-eo-data/xco2-base/xco2_16day_base.2022-01-07.tif, not sure if that's a valid date just an example, but items I think should refer to a single tif asset). I think this example might be trying to do both is that right?

Copy link
Collaborator

Choose a reason for hiding this comment

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

I second this, I think we need an example of a stac collection document and an item document. I'd be into a working session if we wanted to hash things out over an individual dataset.

"id": "co2",
"name": "CO\u2082 (Avg)",
"info": "This layer shows the average background concentration of carbon dioxide (CO₂) in our atmosphere for 2020. Redder colors indicate more CO₂. Bluer colors indicate less CO₂.",
"bbox": [
-180,
-90,
180,
90
],
"geometry": {
"type": "Polygon",
"coordinates": [
[
[
-180,
-90
],
[
180,
-90
],
[
180,
90
],
[
180,
-90
],
[
-180,
-90
]
]
]
},
"properties": {

Choose a reason for hiding this comment

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

I think the values which are data the dashboard front end is currently dependent on for rendering tiles should either be omitted for now or part of a custom extension, i.e. https:/NASA-IMPACT/covid-api/blob/adrs/stac-co2/adrs/co2.json#L42-L64 and https:/NASA-IMPACT/covid-api/blob/adrs/stac-co2/adrs/co2.json#L93-L122 should be omitted or use a key indicating a custom extension like "frontend:s3_location"

Copy link
Collaborator

Choose a reason for hiding this comment

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

We now have the delta-config to keep in mind as well. It might help if there is metadata that just doesn't fit into any of the predefined attributes in the stac specification.

If I understand correctly, delta config will have more ui-specific metadata about thematic areas and groupings of datasets but it seems like it could also house information like the legend colormap. I'm sure we will need to define at least one custom extension along the way, though, so you may end up needing to mock a custom extension for item properties anyway.

"s3_location": "xco2-mean",
"is_periodic": true,
"time_unit": "day",
"type": "raster-timeseries",
"exclusive_with": [
"agriculture",
"no2",
"co2-diff",
"fb-population-density",
"gibs-population",
"car-count",
"nightlights-viirs",
"nightlights-hd",
"detection-multi",
"water-chlorophyll",
"water-spm",
"water-pzd",
"detections-ship",
"detections-plane",
"detections-contrail",
"detections-vehicles"
],
"enabled": false
},
"collection": "collection",
"links": [
{
"rel": "collection",
"href": "./collection.json",
"type": "application/json",
"title": "Collection"
},
{
"rel": "root",
"href": "./collection.json",
"type": "application/json",
"title": "Collection"
},
{
"rel": "parent",
"href": "./collection.json",
"type": "application/json",
"title": "Collection"
}
],
"source": {
"type": "raster",
"tiles": [
"{api_url}/{z}/{x}/{y}@1x?url=s3://covid-eo-data/xco2-mean/xco2_16day_mean.{date}.tif&resampling_method=bilinear&bidx=1&rescale=0.0003908%2C0.0004225&color_map=rdylbu_r&color_formula=gamma r {gamma}"
]
},
"compare": {
"enabled": true,
"help": "Compare with baseline",
"year_diff": 0,
"map_label": "{date}: Base vs Mean",
"source": {
"type": "raster",
"tiles": [
"{api_url}/{z}/{x}/{y}@1x?url=s3://covid-eo-data/xco2-base/xco2_16day_base.{date}.tif&resampling_method=bilinear&bidx=1&rescale=0.000408%2C0.000419&color_map=rdylbu_r&color_formula=gamma r {gamma}"
]
}
},
"legend": {
"type": "gradient-adjustable",
"min": "< 391 ppm",
"max": "> 423 ppm",
"stops": [
"#313695",
"#588cbf",
"#a3d2e5",
"#e8f6e8",
"#fee89c",
"#fba55c",
"#e24932"
]
},
"swatch": {
"color": "#189C54",
"name": "Dark Green"
}
}