Traffic-Aware Navigation in Road Networks

This project compares three graph search approaches for the task of traffic-aware navigation in Kingston’s road network. These approaches include a single-run multi-query preprocessing algorithm (Floyd-Warshall-Ingerman), continuous single-query real-time search (Dijkstra’s and A*), and an algorithm combining both approaches to balance between their trade-offs by first finding the top K shortest paths then iterating over them in real time (Yen’s). Dijkstra’s and A* resulted in the most traffic-aware optimal solutions with minimal preprocessing required. Floyd-Warshall-Ingerman was the fastest in real time but provided distance based paths with no traffic awareness. Yen’s algorithm required significant preprocessing but balanced between the other two approaches in terms of runtime speed and optimality. Each approach presents advantages and disadvantages that need to be weighed depending on the circumstances of specific deployment contexts to select the best custom solution. *This project was completed as part of ELEC 844 (Search and Planning Algorithms for Robotics) in the Fall 2025 term.

💡 Research Summary

This paper presents a systematic comparison of three graph‑search strategies for traffic‑aware navigation on the road network of Kingston, Ontario. The authors first construct a directed graph from OpenStreetMap data using the OSMnx library, yielding 3,305 vertices (intersections) and 8,467 edges (road segments). Because many speed‑limit attributes are missing, they impute values based on road type (50 km/h for residential and similar categories, 80 km/h for secondary/tertiary, 100 km/h for motorways) and average multiple limits when present. Parallel edges are collapsed by keeping the cheaper one according to the cost metric used in each experiment.

Three algorithmic families are evaluated:

1. Multi‑Query Lookup (Floyd‑Warshall‑Ingerman) – a classic all‑pairs shortest‑path algorithm that pre‑computes distances using pure Euclidean length as edge cost. Preprocessing takes 273 minutes (≈4.5 h) but yields instantaneous query times (≈40 µs). Because it ignores real‑time traffic weights, the resulting routes can be sub‑optimal in congested conditions.

2. Single‑Query Search (Dijkstra and A*) – each navigation request triggers a fresh search. Dijkstra requires no preprocessing and averages 2.38 s per query. A* uses heuristics (Euclidean or great‑circle distance) and achieves similar runtimes (2.12–2.38 s) after a modest preprocessing step (≈15 min) to build heuristic lookup tables. Inflated‑heuristic variants (α = 10, 100) dramatically reduce runtime (≈0.18 s) but produce routes with 23–25 km traffic‑weighted distance, far worse than optimal.

3. K‑Shortest‑Paths (Yen’s algorithm, K = 5) – the top‑5 loopless shortest paths (by pure distance) are pre‑computed for each origin‑destination pair. This step is extremely expensive: 3,946 minutes (≈66 h) for the 1,000 experimental pairs, and would scale to roughly 45 days for the full graph. At runtime, the algorithm evaluates the traffic‑weighted cost of each of the five candidates and selects the cheapest, resulting in a query time of 0.043 s. The average traffic‑weighted distance is 21.36 km, only slightly higher than the optimal 19.31 km achieved by Dijkstra/A*.

The experimental protocol consists of 1,000 random start‑goal pairs (all vertices appear exactly once) and four traffic scenarios (no traffic, light, moderate, heavy) each with 250 trials. Traffic weights are 1 (low), 3 (medium), and 5 (high). Five trials had no feasible path and were excluded.

Key metrics (averaged over the 995 solvable trials):

(*Only partial preprocessing for the 1,000 query pairs was performed.)

Additional analyses report average path length, estimated arrival time (traffic‑weighted distance divided by speed limit), and violin plots of cost distributions. Dijkstra and both A* variants (with admissible heuristics) achieve identical optimal costs, confirming that the heuristic does not degrade optimality when it is admissible. Inflated A* variants deviate significantly, confirming the trade‑off between speed and solution quality.

Statistical significance is established via ANOVA (p < 0.05) and pairwise two‑tailed t‑tests (77 of 81 comparisons significant). Non‑parametric Wilcoxon tests corroborate these findings.

A second set of experiments incorporates speed limits into the edge cost (traffic × distance / speed). This changes the units from distance to time. The heuristic for A* is adjusted accordingly (distance divided by average speed), but becomes non‑admissible, leading to slightly higher average costs than Dijkstra. Nevertheless, the overall ranking of algorithms remains unchanged.

Discussion emphasizes the practical implications:

• Dijkstra/A* require no or minimal preprocessing and deliver the most traffic‑aware optimal routes, but each request incurs a few seconds of computation—acceptable for low‑volume services but potentially problematic for high‑throughput platforms.
• Floyd‑Warshall‑Ingerman offers near‑zero query latency after a heavy one‑time preprocessing, making it suitable for scenarios where traffic does not change rapidly or where distance‑only routing suffices.
• Yen’s K‑Shortest‑Paths provides a middle ground: massive upfront cost but sub‑second query times and routes that are close to optimal. It is attractive for centralized routing servers that can afford periodic batch preprocessing (e.g., nightly) and then serve many users with low latency.
• Inflated A* demonstrates that aggressive heuristic inflation can reduce runtime dramatically but at the expense of unacceptable route quality, underscoring the need to balance speed and optimality.

The authors conclude that the choice of algorithm depends on deployment constraints such as frequency of traffic updates, request volume, and available computational resources. Future work is suggested in the direction of incremental all‑pairs updates, hierarchical A* (e.g., contraction hierarchies), and parallelized Yen’s preprocessing to mitigate the steep preprocessing burden.

Overall, the study provides a thorough empirical foundation for selecting graph‑search techniques in traffic‑aware navigation systems, highlighting the trade‑offs between preprocessing effort, real‑time performance, and route optimality.