Dijkstra with live traffic

· the same streets of Cascavel, weighted by minutes instead of metres

/signatures/trafficbuilt on Dijkstra on the real map

EXPANDED

—

intersections closed

FASTEST ROUTE

—

minutes, by time

SHORTEST ROUTE

—

minutes, by distance

SAVED

—

minutes by trusting traffic

JAMMED

—

of the named streets

jammed streetexploredshortest by distancefastest by time

Click the map: first the start, then the goalLoading the street map…

step 0 / 0

Traffic30%

THE MODEL

free flow40 km/h on every street

a jammed street1.6× to 3.5× slower, whole street

edge weightmetres × slowdown

searchDijkstra, the same one as the algorithm page

CURRENT STEP

Loading the street map…

// how it works

Dijkstra with live traffic

A navigation app does not minimise distance, it minimises expected time: every street segment carries a live speed, and the edge weight is length divided by that speed. Dijkstra does not care what the weights mean, so the same search that found the shortest route finds the fastest one once the weights change.

This page jams a share of the named streets with a slowdown factor between 1.6× and 3.5× and runs two searches from the same start: one on metres, one on minutes. The violet route is the shortest; the green one is the fastest; the difference is the minutes a driver saves by trusting the traffic layer.

// dijkstra

What to notice

With no jams the two routes coincide; slide the traffic up and they split where a jammed avenue used to be the obvious choice.

The fastest route is usually longer in metres: the KPI row shows both.

The search expands more intersections under traffic because the cheap frontier spreads along the free streets first.

Open the algorithm page: Dijkstra on the real mapPathfinding · Back to /pathfinding/real-map-dijkstra