---
name: tomtom-maps-route-planning-with-traffic
description: Plan and compare routes with TomTom Maps (point-to-point, multi-stop, EV routing and reachable range) and check traffic incidents along them, the way a careful dispatcher or journey planner does. Use when the user asks for a route, a drive time, the fastest or shortest way between places, a multi-stop trip, whether an EV can make a journey, how far a car can go, or what traffic and incidents are on the way.
---

# Plan and compare routes with traffic

A route answer is only useful if the endpoints are right, the constraints match the vehicle and the trip, and the traffic picture is checked for the time of travel. Most wrong routes come from a bad start or end point, not from the routing engine. Confirm the places first, then route, then check conditions.

## 1. Pin down the endpoints and the trip shape

Before calling `tomtom-routing`, settle:

- **Origin and destination as coordinates or unambiguous addresses.** A place name like "Springfield" or a street with no city is not an endpoint. If the text is ambiguous, resolve it first with `tomtom-geocode` and confirm the match with the user. This is a separate job from route planning; use `location-search-and-enrichment` when the user has a list of addresses to clean up.
- **Stops, if any, and their order.** Ask whether the stops must be visited in the given order or whether the user wants the best order. Do not reorder stops silently; say when you have chosen an order and why.
- **Departure time or "now".** Traffic and any time-of-day restriction depend on it. If the user does not say, state that you assumed "now" and that the result will differ at other times.
- **Mode of travel.** Car, truck, EV or walking-style assumptions change the answer. Only use EV routing when the user has an EV and wants charging or energy planning.

Route options are a comparison, not one answer. Ask what matters: fastest, shortest, or avoiding tolls, highways or ferries, if the routing options support it. Check the tool's own parameters for what it accepts; do not assume a preference exists.

## 2. Choose the right routing tool by question

- **One start, one end:** `tomtom-routing`. This is the default.
- **Several stops:** `tomtom-routing` with the stops in the agreed order. Only consider reordering if the user asked for the best order.
- **EV trip, charging stops, battery state:** `tomtom-ev-routing`. A standard route is not an EV plan. If the user has not given battery level, consumption or charging need, ask before presenting energy figures as fact.
- **"How far can I get from here?":** `tomtom-reachable-range`. This answers an area question, not a route question. Do not present its output as a route.
- **"Which fuel stations, chargers or restaurants are on the way?":** `tomtom-search-along-route` once you have a route. Hand the place-finding detail to `location-search-and-enrichment` if the user wants a fuller list for each point.

## 3. Check traffic, and say when it is current

Call `tomtom-traffic` for the corridor of the route. Look for:

- **Incidents on the route itself**, not just nearby. An incident 2 km off the route is a note, not a reroute trigger.
- **Closures and long delays** are decisive. A minor slowdown is worth a mention and rarely changes the recommendation.
- **Time of travel.** Current conditions describe now. If the departure is hours away, say that the traffic picture may change and offer to recheck closer to departure.

Do not report traffic as a guarantee. The honest form is "at the time of checking, the route had X and Y".

## 4. Compare, then explain the trade-off

When there are two or more candidate routes, compare them on the same basis: duration, distance, incidents, tolls or other constraints the user asked about. State the difference in plain terms: "Route B is 6 minutes longer, avoids the closure on the A4 and adds 8 km." The user should be able to choose from that sentence alone.

## 5. Visualise only when it helps

If the client shows an interactive map, the route and incidents will appear. Use `tomtom-dynamic-map` only when the user wants a map view of a larger set of places or routes. Do not make the map the answer; the numbers and the recommendation are the answer.

## Common patterns and traps

- **Routing from a loosely named place.** The route is then calculated from the wrong town and looks plausible. Check the resolved coordinates or address against what the user meant before quoting any time.
- **Reusing a standard route for an EV trip.** Distance and time are not energy. Use `tomtom-ev-routing` and say which assumptions it used.
- **Confusing reachable range with a route.** A reachable area is a set of places you can get to; it has no single path. Present it as coverage.
- **Quoting traffic as the future.** Traffic is a snapshot. A "fastest route now" may be slower at rush hour. State the time.
- **Silent stop reordering.** Changing the user's stop order without saying so makes the route wrong for their plan.
- **Treating an incident as a closure.** Incident data can be partial. Report what the tool says and avoid stating a road is closed unless the result says so.
- **Stacking route, traffic and POI calls for a simple question.** If the user asked only for a drive time, answer that first and offer the rest.

## Output

```
Route: <origin> to <destination> [via <stops in order>]
Assumed: <departure time or "now">, <mode>, <other preferences>
Option A: <duration>, <distance>, <notable incidents or constraints>
Option B: <duration>, <distance>, <difference from A> (if compared)
Traffic at check time (<time>): <incidents on route, or "none reported on route">
Recommendation: <option and the one reason>
Not established: <e.g. departure traffic, EV energy use, unverified addresses>
```

## Rules

- Never claim a route, time or traffic state as guaranteed. State the check time and the assumptions.
- Do not present reachable-range output or a general map as a route.
- Do not change the user's stop order without saying so.
- Do not treat traffic data as a real-time closure feed unless the result states it.
- Do not state EV energy or charging figures unless the user gave the battery and vehicle inputs, or label them as assumptions.
- Do not run any tool in this skill that would create, save or send anything; the connector here is read-only for this job. If a user asks to save a route or share it externally, wait for the user's explicit yes before doing so, and check first whether a tool supports it.

## Done when

- The endpoints are confirmed as unambiguous places, with the departure assumption stated.
- The route tool that matches the question has been used, and each comparison uses the same basis.
- Traffic has been checked on the route corridor, with the check time given.
- The recommendation is stated with its reason, and anything not checked is listed under "Not established".