Drive Time Map vs Radius Circle: Which One Should You Use?

The toolkit behind this post, in depth

How routing engines turn streets into answers

A routing engine ingests the road and path network as a graph — intersections as nodes, street segments as edges, each with speed, access rules and geometry — then searches it for the cheapest path under a costing model. Driving, walking and cycling are genuinely different networks: pedestrians slip through footways and cut-throughs cars cannot use, cyclists avoid motorways and steep grades, cars ignore steps entirely. That is why the same two points produce three different routes and three different times, and why comparing them is often the most informative thing you can do with a trip.

Isochrones invert the question from 'how long to get there' to 'everywhere reachable in this time'. A proper isochrone is not a circle: it grows along fast corridors, pinches at bridges and rivers, and holes around barriers. When the shape looks jagged, that is the network telling the truth. These polygons make honest service-area and catchment maps — the circle version always over-promises across the river and under-promises along the motorway.

One caveat belongs on every routing result: free public engines report free-flow times derived from speed limits and road classes, not live congestion. Treat a 25-minute result as the physics of the network; your city's rush hour adds the sociology. Multi-stop optimisation adds a second layer of honesty: reordering stops to minimise distance is the travelling-salesman problem, and engine heuristics solve it beautifully at driver scale — the difference between a sensible morning and a wasteful one is frequently twenty percent of the kilometres.

Reading routes like a dispatcher

A route result is a claim about a network, and networks have personalities. Motorway cities produce long fast fingers in their isochrones; river cities show comb shapes; border towns pinch. Learning to read those shapes turns a pretty polygon into diagnostic information: a missing finger is a missing interchange, a hole is a barrier, a lopsided blob is a one-way system. The same literacy applies to stop ordering — an optimized route that criss-crosses itself is either a data error or a constraint you forgot to state, because distance-minimising engines don't voluntarily draw bows on their own paths.

Time estimates deserve the same reading discipline. Free-flow times are the network's physics; your city adds sociology on top. Dispatchers handle this with explicit buffers by area and hour, and you can too: keep the engine's number as the reproducible baseline, store your buffer as policy, and present the sum. When someone asks 'how long will it take', the honest answer has two numbers and a reason — which is precisely what a good tool's labels should invite you to give.

• Snap endpoints to visible roads before calculating; stable inputs, stable results, explainable diffs.
• Keep the engine's free-flow figure and your congestion buffer as separate fields; policies change, physics doesn't.
• Export isochrones with their mode and contours in properties; a polygon without its parameters is unverifiable.
• After auto-optimising stops, scan the drawn path for self-intersection — the cheapest QA in logistics.

Honest limits & when to escalate

Routing's limits live in three places: data vintage, access reality and time modelling. The network is OpenStreetMap's current picture — new interchanges lag, private gates may be missing, seasonal ferries keep their own calendars. Access rules reflect mapped law, not today's roadworks. And durations are free-flow physics: speed limits and road classes without your city's sociology, so peak hours, weather and parking belong in your buffer, not in the engine's promise. The tools label all three limits on every result, because an unlabelled estimate is a trap.

What the stack does brilliantly is the reproducible core: the same stops, mode and engine give the same route to everyone, everywhere, which makes it a superb baseline for comparison, screening and planning. Escalation is domain-specific and well understood — professional dispatch adds live traffic and driver hours; logistics tenders add contracted networks; navigation products add certified maps. A free browser tool that hands you a clean, exportable baseline with its assumptions printed is not competing with those; it is feeding them.

• Live congestion and ETAs → traffic-aware commercial routing.
• Driver-hours and windows → transport-management systems.
• Certified navigation → licensed map products with update guarantees.
• Accessibility-critical walks → ground truth; curb data is still emerging everywhere.

Step-by-step masterclass

1. Pin endpoints on roads — Drag each pin to a visible street before calculating; snapping surprises are the top cause of 'weird' routes, and road-pinned inputs make results stable and explainable.
2. Pick the mode that matches reality — Driving, walking and cycling follow different legal networks; comparing all three is often more informative than any single answer.
3. Read the shape, not just the total — Isochrone fingers follow fast corridors and holes mark barriers; a route that criss-crosses itself after optimisation is a cue to re-check your stop list.
4. Separate physics from policy — Keep the engine's free-flow figure and your congestion buffer as distinct numbers; present the sum with its parts and your estimate becomes defensible.
5. Export for the next step — GPX for navigation apps, GeoJSON for reports; embed mode and contours in properties so the file is auditable without archaeology.

Routing quality follows OpenStreetMap's coverage: excellent across Europe, North America and most of East Asia, good in South America's cities, patchier in remote regions — and access rules (one-ways, pedestrian zones) reflect local mapper knowledge, which is why the engine sometimes knows a shortcut your satnav doesn't.