Add datetime summary at collection level for `item_assets`

[kyle-lesinger]

Summary

Currently item_assets are not filterable at the collection level which poses an issue when trying to find assets for a specific date.

Fix

Add new properties to the collection level item_assets showing available summary datetimes.

Current spec

"item_assets": {
   "cog_default": {
        "type": "image/tiff; application=geotiff; profile=cloud-optimized",
         "roles": [
        "data",
        "layer"
       ],
"title": "Default COG Layer",
       "description": "Cloud optimized default layer to display on map"
      }
}

Proposed spec

"item_assets": {
   "cog_default": {
        "type": "image/tiff; application=geotiff; profile=cloud-optimized",
         "roles": [
        "data",
        "layer"
       ],
"title": "Default COG Layer",
       "description": "Cloud optimized default layer to display on map"
      },
"datetimes": [ 2019-01-01, 2019-02-01, 2019-03-01]
}

[kyle-lesinger]

@slesaad @BhattaraiSijan @sandesh-sp please provide any more info that you think would be useful. I did my best to provide an example, but you may have a better method.

[anayeaye]

@kyle-lesinger @slesaad @BhattaraiSijan @sandesh-sp can we do a quick sync (<30 mins) up on this need? I am wondering if there is already something in the stac-api spec that might cover the use case? I think I understand the request but I am concerned that it will be brittle addition that could be hard to maintain if outside standard usage (extra fields are allowed in the spec for Collection item_assets but these are not searchable using the stac API collection search extension.

[bitner]

Does this need to be at the level of a range for each asset type in item_assets? There are already triggers and settings (by default they are off) that allow you to keep the extents object at the root of a collection (datetime and spatial) updated automatically tracking changes to the items tables. This is the spec-compliant place for where extents should live in a collection.

[emmalu]

To follow-up on @bitner's note, these are the updates that CSDA made recently within our STAC:

• the STAC changes to set the update_collection_extent_setting to true: https://github.com/NASA-IMPACT/csdap-stac-api/pull/354/changes
• resulting in collections including the extent.temporal property : https://csdap.earthdata.nasa.gov/stac/collections/desis
• which we are now integrating into the SDX frontend: https://github.com/NASA-IMPACT/csdap-frontend/blob/3d4db3b3e696eab20515bcde1d71558c3124fb7b/components/explore/utils.ts#L258

(I hope this is helpful!)

[anayeaye]

@bitner, @emmalu we are using the inbuilt PgStac extent updates by default but this issue is about a special case collection in which stakeholders wanted to include several different kinds of products as individual items. So on one date one you may match a veg index, on another date there may be an anomaly detection, in another location perhaps a third derived product. This makes programmatic of summaries different products (assets) at the collection level a little difficult. The collection is very small (I think <50 items) and has detailed item properties so I am wondering if a simple item search would be enough for the custom tool.

[anayeaye]

Update: had a sync today with @BhattaraiSijan @kyle-lesinger @slesaad @botanical today and we determined that this will be addressed by separating aggregated OPERA collection(s) that contain varied assets and do not have filterable properties into standardized/flattened collections.

This is the standard to follow: For STAC Collections, the datetime:* properties represent all discoverable item assets in the collection (including extent, periodicity, etc). Multiple assets are acceptable but the collection level datetime metadata needs to represent all assets.