Story
Mission admins add VEDA data to MMGIS by hand-assembling tile layer configs
from facts scattered across a STAC catalog — and the hardest fact is one
they cannot know: when the data ends. Most VEDA collections keep
growing; a config written today with a concrete end date is stale tomorrow.
Forecast products are worse — their whole time window moves every day.
This epic makes VEDA collections first-class layer sources:
- A layer's time range can be expressed as a policy ("ends now",
granularity-aware) instead of a fixed timestamp, so configs for growing
data never go stale.
- An admin can create a tile layer from a VEDA STAC collection: give a
collection id, see what the collection offers (its render options and
temporal coverage), make the few real choices, and the layer's fields
fill from the collection's own metadata — including the open-ended time
policy when the collection is ongoing.
- (Follow-up) Forecast collections, whose start and end both move, are
expressible with the same policy mechanism.
Sub-issues
Story
Mission admins add VEDA data to MMGIS by hand-assembling tile layer configs
from facts scattered across a STAC catalog — and the hardest fact is one
they cannot know: when the data ends. Most VEDA collections keep
growing; a config written today with a concrete end date is stale tomorrow.
Forecast products are worse — their whole time window moves every day.
This epic makes VEDA collections first-class layer sources:
granularity-aware) instead of a fixed timestamp, so configs for growing
data never go stale.
collection id, see what the collection offers (its render options and
temporal coverage), make the few real choices, and the layer's fields
fill from the collection's own metadata — including the open-ended time
policy when the collection is ongoing.
expressible with the same policy mechanism.
Sub-issues