• UDOT Traffic — message signs, cameras, road condition statuses and travel-time routes. Fetched via official APIs and ArcGIS endpoints; normalized on the server for consistency.
• NOAA/NWS — station observations in/near the canyons. We convert units, map to canyon zones, and expose a compact DTO (temperature, wind, precip, etc.).
• Utah Avalanche Center — region advisories with a normalized summary and rose image.
• UTA — ski 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.

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).

• Point‑in‑polygon tests — used to determine whether a camera or observation lies within a canyon boundary polygon.
• Zone assignment — assigns 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 metrics — for UTA buses, we precompute per‑route polyline metrics (segment lengths, bearings, cumulative distance) to project positions and reason about direction and proximity to stops.

The bus tracking pipeline fuses API telemetry with computed route geometry to make vehicle state easy to understand:

• Projection & along‑route distance — each 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 inference — combines 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 selection — selects 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 & dwell — we 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.