--- name: vaisala-xweather-road-weather-route-check description: Assess weather risk along a planned road journey using Xweather road weather and route tools, flagging the road segments and time windows where conditions could affect safe travel and turning them into a clear go, delay or reroute recommendation. Use when the user asks whether a drive, delivery run or fleet route is safe, wants to know where on a route the weather gets bad, or asks about road conditions, icing, visibility or timing for a trip. --- # Check weather risk along a road route This job answers one question: **where on this route, and at what time, will the road weather make travel unsafe or slower, and should the trip go ahead, be retimed or be rerouted?** It is about a journey, not a single place. A forecast that is fine at the origin says nothing about a mountain pass two hours in. Work segment by segment and time by time. ## 1. Pin down the route and the departure time first Before calling anything, confirm three things with the user, and ask if any is missing: - **Origin and destination**, plus any stops or waypoints that matter. - **Departure time** and whether the user can leave earlier or later. A time window is more useful than one departure. - **Vehicle or load context** if they mention it (high-sided van, loaded trailer, cyclists, refrigerated cargo). Use it to weight the risk, not to invent thresholds. Use `xweather_get_roadweather_routes` to retrieve the route geometry and segments for the journey. Confirm the segments returned cover the whole route. If coverage stops partway, say which stretch is unassessed rather than assuming it is clear. If the user only has a rough description ("the A-road over the moors"), say you need the endpoints to pull the real route, and do not guess a corridor. ## 2. Pull road conditions for the segments Use `xweather_get_roadweather` for the segments along the route. Read the conditions per segment and per time step, not as a single summary for the trip. Note for each segment and time step: - Surface state and any icing or snow risk. - Visibility. - Precipitation type and intensity. - Wind, especially crosswind exposure on bridges, open moorland and coast. Work from the segment nearest the origin outward, and record where each condition first appears. Recording the point where a problem starts matters more than its peak value, because that is where the driver needs to act. ## 3. Layer the active alerts and the near-term forecast Road conditions describe now and the next few hours. Extend the picture with: - `xweather_get_current_active_weather_alerts` for the corridor, to catch warnings already issued that the segment data may not yet show clearly. An official alert on the route outranks an inferred risk. - `xweather_get_forecast_precipitation_timing` to find when precipitation arrives at each part of the route. Matching the arrival time against the driver's segment-by-segment timing is what turns a weather map into a journey plan. - `xweather_get_forecast_weather` for temperature and wind across the window, especially for the freezing-point crossings that cause icing on otherwise wet roads. Where the forecast and the road-weather reading disagree, say so and prefer the more conservative reading for safety, and state that the two sources differ. ## 4. Time the risk windows Build a single timeline of risk windows: for each segment, the start and end of any period above the safe-travel line you have applied. Then ask the decision question directly: - Is there a departure time within the user's window where the **whole route** is clear? - If not, which segments remain the problem at each candidate time? - Would a short delay clear the worst segment before the vehicle reaches it, or does the risk move along the route with the vehicle? A risk that reaches a segment later in the journey than the vehicle does is less urgent than one that is already present at the start. Make the timing relationship explicit. ## 5. Recommend, do not decide Give one of three outcomes and the evidence behind it: - **Go as planned**: no segment above the risk line at the vehicle's arrival time, with the margin stated. - **Retime**: a specific earlier or later departure that clears the risk windows, with the windows it avoids. - **Reroute or defer**: the problem segment cannot be cleared by timing alone; name the alternative only if you have verified its conditions with the same tools. Never propose an alternative route you have not checked. The user decides. Your job is to make the consequences of each option visible. ## Common patterns and traps - **Reading the origin only.** The most common failure is a clean forecast at departure followed by a hazard on a high or exposed section. Always check the whole route. - **Averaging a route.** A trip that is mostly fine with one icy stretch is not a fine trip. Report the worst segment, not the average. - **Wet road versus icy road.** A wet surface above freezing and a surface at or below freezing can share the same forecast precipitation. The temperature crossing decides the risk, so check the freezing point along the route. - **Visibility is often the real hazard.** Fog and blowing snow on open ground can close a route while the road surface looks acceptable. Do not let a good surface reading hide poor visibility. - **Crosswind on exposed sections.** Bridges, ridgelines and coastal stretches are riskier than their wind speed at the origin suggests. Flag them by name where the segment data allows. - **Timing drift.** A long drive can carry the vehicle into the storm it was meant to avoid. Compare arrival times at each segment against the risk windows rather than assuming the trip is uniform. - **Stale or partial coverage.** If road-weather data is missing for part of the route, say which part. Do not present an unassessed stretch as safe. - **Alert versus absence of alert.** No active warning on a segment is not the same as a clear road. Say what was checked. ## Output ``` Route: to , departure window Coverage: of ; unassessed: Risk windows - : from