Repository navigation
Explain traffic source freshness and verified route influence #402
Description
Activity
Implemented the first bounded presentation pass in #426, commit be82d9b. It distinguishes applied road-condition evidence from unverified congestion ETA influence, expires held claims at the proof lease, and explains owned/TomTom map sources without inventing freshness or coverage. Includes six direct PR screenshots, regression-first tests, fresh independent review, documentation updates and the final full suite (17,695 tests passed; 138 opt-in tests skipped). This issue stays open: a public publication metadata contract and navigation/EV-wide presentation remain follow-ups. No producer or route algorithm changes.
PR #426 was merged as 3c80939 after final review and green CI. It delivers compact duration/delay colors, optional route evidence details, and separate owned/TomTom map disclosures. Missing evidence uses the ordinary duration color without a visible unavailable row.
This issue remains open: trustworthy route-specific congestion coverage is still needed from routing providers before the green low-delay state can occur in production. Public overlay publication/source-age metadata also needs a bounded contract; current legends honestly report unknown update time/coverage. Existing request-bound road-update proof remains separate from congestion estimates. These remaining items are documented in the merged directions and map-layers guides.
Before you start
What problem does this solve?
A coloured traffic layer does not establish that its data affected a route or ETA. OpenMapX has separate overlay, graph/update and request-bound routing proof paths; users need a coherent explanation of which source/state applies to the displayed map and chosen route.
Proposed solution
Use existing traffic publication evidence and Valhalla proof to present overlay source/release age and route-specific traffic influence separately. Provide understandable fresh/stale/unavailable/unknown/degraded states with source context, including local versus hosted paths. Keep missing evidence honest and route-specific; preserve the existing proof rules. Start with the owned traffic-flow and Valhalla path plus a contrasting hosted overlay fixture. Out of scope: new traffic provider, graph matching/speed algorithm, replacing ETA computation or asserting live coverage from enabled integrations. Resolve available metadata, freshness thresholds and first UI placement during triage.
Verified current state
Rechecked against
mainata8e03bc3efc49207d91f7c1855402c6cf149b8fdon October 7, 2026.Acceptance criteria
Verification approach
Extend current traffic-proof tests with UI-consumer scenarios for verified/missing/stale/mismatched evidence and reroute/provider changes. Use controlled publication timestamps and existing traffic-evidence fixtures. Run root lint/types/test, relevant provider/coverage tests and docs build; publish rendered map-only versus route-applied examples without claiming broad regional coverage.
Dependencies and decisions
Baseline #393 is complete. Related #303 covers source-update lifecycle rather than presentation. No new source/engine is a blocker. The source-age contract and supported proof-to-UI mapping must be agreed before implementation; preserve request-bound validation.
Alternatives considered
Labeling every enabled traffic integration as live/ETA-aware would confuse rendering with routing. A graph/data rewrite is unnecessary to explain the evidence already available.
Area
Other / cross-cutting
Would you like to work on this?
Maybe, with some guidance. Maintainer-owned backlog; implementation has not started. Resolve the named decisions during triage before scheduling work.