Technical Overview
This page documents how Wasatch Roads works under the hood: external data sources, how we cache and normalize data, the GIS math we use to assign zones and filter cameras/stations, and the advanced bus tracking logic.
Data Sources & Fetching
The external feeds we pull from and how they reach the server.
- UDOT TrafficMessage signs, cameras, road condition statuses and travel-time routes. Fetched via official APIs and ArcGIS endpoints; normalized on the server for consistency.
- NOAA/NWSStation observations in/near the canyons. We convert units, map to canyon zones, and expose a compact DTO (temperature, wind, precip, etc.).
- Utah Avalanche CenterRegion advisories with a normalized summary and rose image.
- UTASki bus routes, stops, and live vehicle locations (WebAPI). We smooth motion and infer direction/prev/next stops for a cleaner view.
Fetching uses defensive timeouts and headers, and data is cached server‑side (Valkey/Redis) with targeted TTLs per feed to balance freshness and load.
Caching & Normalization
Turning raw feeds into stable, display‑ready shapes.
All expensive or frequently polled endpoints are cached on the server to reduce latency and rate-limit risk. The server transforms convert raw payloads into stable, display‑ready shapes with unit conversions and derived fields (e.g., travel‑time index, % of capacity, cardinal wind, elevation in feet).
GIS & Zone Mapping
The geometry behind zone filters and weather-by-area.
- Point‑in‑polygon testsUsed to determine whether a camera or observation lies within a canyon boundary polygon.
- Zone assignmentAssigns a station or camera to a descriptive area (e.g., Lower, Middle, Upper) by testing the point against named zone polygons. This powers zone filters and “weather by area”.
- Route geometry metricsFor UTA buses, we precompute per‑route polyline metrics (segment lengths, bearings, cumulative distance) to project positions and reason about direction and proximity to stops.
UTA Bus Tracking (Advanced)
Fusing API telemetry with computed route geometry.
The bus tracking pipeline fuses API telemetry with computed route geometry to make vehicle state easy to understand:
- Projection & along‑route distanceEach vehicle location is projected onto the route polyline to get a smoothed position along the path and local segment bearing. This reduces GPS jitter relative to the route line.
- Direction inferenceCombines segment bearing vs. vehicle bearing, a short history of motion along the route, and (when needed) destination text to determine forward/backward travel in ambiguous areas.
- Prev/Next stop selectionSelects candidates ahead/behind using: minimum along‑distance gap, corridor distance to the route line, a side‑of‑road check, and an approach cone to exclude stops behind sharp turns. A hysteresis window avoids flapping when dwelling near stops.
- Movement & dwellWe store a short last-position history and time of last significant movement to detect when a bus is “At stop” or “Stopped”.
These steps yield stable status without flicker, even when the source API omits hints or vehicles move slowly in congestion. Because we infer context heuristically, the displayed “previous” and “next” stops are estimates and not official.