Eric Rakestraw
9b88be4dd2
All checks were successful
ci/woodpecker/manual/build-image Pipeline was successful
100 lines
4.2 KiB
Markdown
100 lines
4.2 KiB
Markdown
# 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/`.
|
|
|
|
## NWS AFD Parsing Resilience
|
|
|
|
The current parser handles the concrete RAH, LWX, and MFR variants that
|
|
motivated these ideas. Future work should keep those extension points
|
|
maintainable as additional evidence appears.
|
|
|
|
### Generalize Wrapper-Scoped Embedded Sections
|
|
|
|
The scanner currently permits undotted nested headings only inside `PREV
|
|
DISCUSSION`. If other wrapper identities are observed, replace the single
|
|
wrapper check with a small explicit provider-local registry and add a fixture
|
|
for each wrapper family. Do not make the leading dot globally optional: wrapper
|
|
scope is the safeguard against classifying uppercase prose as a section.
|
|
|
|
### Extend Conservative Preamble Classification
|
|
|
|
Leading key-message metadata currently supports validated `Issued at`, `Updated
|
|
at`, and `As of <clock> <weekday>...` forms. Add future wording variants as
|
|
small, ordered classifiers with strict label boundaries and value grammars.
|
|
Every addition should include collision tests proving that similar message prose
|
|
and malformed metadata remain canonical content.
|
|
|
|
### Keep List-Marker Recognition Extensible
|
|
|
|
The marker parser currently supports hyphens, asterisks, `N)`, `N.`, `(N)`, and
|
|
composite forms such as `- (N)`. If new decorators appear, evolve the helper
|
|
toward an explicit marker grammar or typed classification result rather than a
|
|
broad punctuation heuristic. Preserve positive-number and whitespace-boundary
|
|
checks so ordinary prose is not stripped.
|
|
|
|
### Maintain a Cross-Office Fixture Corpus
|
|
|
|
The compact RAH, LWX, and current MFR fixtures seed regression coverage for the
|
|
observed layouts. Future parser changes should add concise, deterministic HTML
|
|
fixtures for materially distinct office formats and exercise them through both
|
|
the provider parser and normalizer. Fixture comments should identify the format
|
|
family and state that edited prose is not an archived product; tests must remain
|
|
offline and assert both intended extraction and adjacent-section isolation.
|
|
|
|
## 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.v2` 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.
|