weatherfeeder/docs/roadmap/future.md

Future Work

Purpose

This document is the catch-all roadmap for planned, deferred, aspirational, experimental, or unimplemented weatherfeeder work. Current behavior belongs in the canonical docs outside docs/roadmap/.

SPC Convective Outlook Follow-Ups

Weatherapi Outlook Endpoints

Expose persisted SPC convective outlooks through weatherapi after the weatherfeeder storage contract is stable.

Likely endpoints:

• GET /outlooks/convective
• GET /outlooks/convective/active
• GET /outlooks/convective/location

Recommended behavior:

• Return the latest outlook run by default.
• Support active outlook filtering by current time and containsLocation=true.
• Consider optional query filters for day, outlookType, and containsLocation.
• Preserve canonical outlook geometry for downstream display and audit use.

SPC Day 4-8 Outlooks

Add SPC Day 4-8 convective outlook support as a schema-compatible extension only after Day 1-3 operation is proven.

Notes:

• Day 4-8 products have different semantics from Day 1-3 categorical/tornado/hail/wind products.
• Avoid forcing Day 4-8 assumptions into the current Day 1-3 model until the source shapes and consumer needs are reviewed.
• Prefer reusing weather.outlook.v1 if the fields remain accurate; otherwise write a separate roadmap before changing the canonical contract.

Degraded SPC Bundle Mode

Evaluate whether the SPC source should support degraded partial bundles when one required upstream product fails.

Current behavior should remain atomic: if a required GeoJSON or print-page fetch fails, emit no event for that poll.

Future degraded mode would need a clear contract for:

• distinguishing "no risk polygon" from "product missing";
• exposing per-product fetch errors without leaking raw provider internals into canonical events;
• deciding whether downstream sinks and APIs should store or serve partial snapshots.

Richer SPC Page Assets And Tables

Evaluate whether to parse additional SPC print-page metadata beyond the current discussion text.

Possible additions:

• archive GeoJSON/shapefile/KML links;
• image URLs;
• page risk tables;
• city tables;
• richer discussion section metadata.

Keep GeoJSON products authoritative for polygons, validity windows, and point matching unless a future roadmap explicitly changes that contract.