Route Distance Calculator

Comparing car, foot and bike on the same pair

One origin, one destination, three answers. This tool runs the same two places through the driving, walking and cycling routing models and presents distance and time side by side, making the trade-offs between modes immediately visible. Driving is fastest but park-bound; walking is shortest in dense grids thanks to pedestrian cut-throughs; cycling often beats both on mid-range urban trips — and now you can see it with real network routing rather than intuition.

Each mode follows its own legal network through the Valhalla engine, so differences are genuine network effects, not rounding noise. Times are free-flow estimates and are labelled that way; add your local congestion buffer for car legs. The comparison is perfect for commute decisions, school-run planning, carbon conversations and feasibility checks ('is it realistically bikeable?'). When one mode wins your heart, the dedicated planners for driving, walking and cycling add stops, optimisation and GPX export for the full workflow.

Worked examples

• 10 km urban drive — at a 40 km/h free-flow average takes about 15 minutes before congestion; add 20–40% at peak and the labelled estimate becomes a plan.
• 15-minute cycling isochrone — typically stretches 5–7 km along continuous cycleways but shrinks to ~3 km across a river with one bridge — the anisotropy circles can't show.
• Ten-stop optimisation — regularly saves 15–30% of the distance of a 'logical' typed order, because human intuition underweights cross-town backtracking.

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.

Tips & common mistakes

Add a congestion buffer to any free-flow travel time: 20–40% in peak urban areas is a sane rule of thumb, and the interface labels its times as free-flow for exactly this reason. For appointments, plan with the buffer; for physics, trust the raw number.

Place route endpoints on roads, not rooftops. Routing engines snap points to the nearest drivable way, and a point in a river or a courtyard can snap somewhere surprising — nudging the pin to the nearest street makes results stable and explainable.

When optimising many stops, keep the true origin first and let the engine order the rest; then sanity-check the result visually. Optimizers minimise distance, not your time windows — hard appointments still belong in manual order.

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.

How professionals use this

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

Step-by-step masterclass

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

Related questions people ask

Quick glossary

Isochrone

The reachable-area polygon for a given travel time from a start point.

Costing model

The routing engine's mode profile (auto, pedestrian, bicycle) with its speeds and rules.

Free-flow time

Travel time from speed limits and road classes, without congestion.

Travelling-salesman ordering

Reordering stops to minimise total route distance.

Snap

The engine's move of your pin to the nearest routable way.

Contour

One time band in an isochrone set (e.g. the 30-minute ring).

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.

Data & methodology note

Routes and isochrones come from the FOSSGIS Valhalla engine on OpenStreetMap data (OSRM fallback for driving). Durations are free-flow estimates and are labelled as such on every result.

Category context: Routing & Travel Time — Real road routes, travel times, multi-stop planning and drive-time areas. This page is one of the routing & travel time tools on MapForge; the related-tools links below and the header's Tools menu connect every sibling instrument.