Engineering Route Planning Algorithmsalgo2.iti.kit.edu/sanders/courses/bergen/routePlanning.pdfSanders/Schultes: Route Planning 2 Shortest Path Problem given a weighted, directed graph

Sanders/Schultes: Route Planning 1

EngineeringRoute PlanningAlgorithms

Peter Sanders Dominik Schultes

Institut für Theoretische Informatik – Algorithmik II

Universität Karlsruhe (TH)

in cooperation with

Holger Bast, Daniel Delling, Stefan Funke, Sebastian Knopp, Domagoj Matijevic,

Jens Maue, Frank Schulz, Dorothea Wagner

http://algo2.iti.uka.de/schultes/hwy/

Algorithm Engineering 2007

?


Shortest Path Problem

� given a weighted, directed graph G = (V,E) with

– n = |V | nodes,

– m = |E| edges, and

– edge weights w : E→ N

� given a source node s ∈V and target node t ∈V

� Definition: the length w(P) of a path P = 〈u1,u2, . . . ,uk〉 is

∑ki=2w(ui−1,ui)

� task: determine the shortest path from s to t in G

(if there is any path from s to t)


Shortest Path Problem

� fundamental problem from graph theory

� intuitive / very natural problem

� very active field of research

� required as subroutine by other algorithms

� many real-world applications

e.g., “Routenplaner” most frequently used search term on google.de

for the last years (according to the official statistics)


DIJKSTRA ’s Algorithm

the classic solution[1959]

O(n logn+m) (with Fibonacci heaps)

tsDijkstra

tsbidirectionalDijkstra

not practicable

for large graphs

(e.g. European road network:

≈ 18 000 000 nodes)

improves the running time,

but still too slow


Speedup Techniques

that are faster than Dijkstra’s algorithm

� require additional data (e.g., node coordinates)

not always available!

AND / OR

� preprocess the graph and generate auxiliary data (e.g., ‘signposts’)

can take a lot of time; assume static graph and many queries!

AND / OR

� exploit special properties of G (e.g., planar, hierarchical)

fail when the given graph has not the desired properties!

not a general solution,

but can be very efficient for many practically relevant cases


Road Networks

We concentrate on road networks.

� several useful properties that can be exploitet

� many real-world applications

� some techniques: already applied to railway networks

� most techniques: open question if they can be applied to other graph types


Road Networks

Properties

� large, e.g. n =18 000 000 nodes for Western Europe

� sparse, i.e., m = Θ(n) edges

� almost planar, i.e., few edges cross

� inherent hierarchy, quickest paths use important streets

� changes are slow/few (only partly true!)


Road Networks

Applications

� route planning systems

in the internet

(e.g. www.map24.de)

� car navigation systems

� logistics planning

� traffic simulation


Outline

1. short introduction of basic approaches

� Dijkstra’s algorithm / bidirectional search

2. detailed presentation of speedup techniques after Oct 2005

� highway hierarchies fast queries

� transit-node routing very fast queries

� highway-node routing handles dynamic scenarios

� contraction hierarchies simplification


1. ApproachHighway Hierarchies

[SS 05–]

ts


Naive Route Planning

1. Look for the next reasonable motorway




2. Drive on motorways to a location close to the target




2. Drive on motorways to a location close to the target

3. Search the target starting from the motorway exit


Commercial Approach

Heuristic Highway Hierarchy s t

ts

� complete search in local area

� search in (sparser) highway network

� iterate highway hierarchy

Defining the highway network:

use road category (highway, federal highway, motorway,. . . )

+ manual rectifications

� delicate compromise

� speed⇔ accuracy


Our Approach

Exact Highway Hierarchy s t

ts




Defining the highway network:

minimal network that preserves all shortest paths

� fully automatic (just fix neighborhood size)

� uncompromisingly fast


Our Approach

Exact Highway Hierarchy s t

ts



� contract network, e.g.,



A Meaning of “Local”

� choose neighbourhood radius r(s)

e.g. distance to the H-closest node for a fixed parameter H

� define neighbourhood of s:

N (s) := {v ∈V | d(s,v)≤ r(s)}

� example for H = 5

6

520

1

3

4

8

9

7

s

N (s)ranks =


Highway Network

N (s) N (t)

s t

Highway

Edge (u,v) belongs to highway network iff there are nodes s and t s.t.

� (u,v) is on some shortest path from s to tand

� v 6∈ N (s)and

� u 6∈ N (t)


Contraction

highway nodes and edges


Contraction

bypass node


Contraction

shortcuts


Contraction

bypass node


Contraction


Contraction

(of bypassed nodes)

leaves

component

component

enterscomponent


Contraction

core


Contraction

Which nodes should be bypassed?

Use some heuristic taking into account

� the number of shortcuts that would be created and

� the degree of the node.


Example: Karlsruhe

Level 0–1

Level 2

Level 3

Level 4


Shrinking of the Highway Networks

107

106

105

104

1000

100

10

1 0 2 4 6 8 10 12 14 16

#edg

es

level

Europe

H = 40H = 60H = 80


Fast Construction

ChallengeAvoid all-pairs shortest-path precomputation.

SolutionFor each node:

perform only a local search.


Query

Bidirectional version of Dijkstra’s Algorithm

Restrictions:

� Do not leave the neighbourhood of the

entrance point to the current level.

Instead: switch to the next level.

� Do not enter a component of

bypassed nodes.

level 0

level 1

N (v)

N (s)

entrance point to level 1



sv


Query

Example: from Karlsruhe, Am Fasanengarten 5

to Palma de Mallorca


Bounding Box: 20 km Level 0 Search Space


















Level 8 Search Space


Level 10 Search Space


Optimisation: Distance Table

Construction:

� Construct fewer levels. e.g. 4 instead of 9

� Compute an all-pairs distance table

for the topmost level L. 13 465× 13 465 entries


Distance Table Query:

s t

� Abort the search when all entrance points in the

core of level L have been encountered. ≈ 55 for each direction

� Use the distance table to bridge the gap. ≈ 55× 55 entries


Distance Table: Search Space Example


Experiments: Methodology

� s-t-pairs uniformly at random←→ queries in real applications

� average value←→ variance?

Transit Node Routing (economic variant)

Que

ry T

ime

[µs]

510

2040

100

300

1000

510

2040

100

300

1000



� consider different localities!

� average value←→ variance?


Dijkstra Rank

Que

ry T

ime

[µs]

25 26 27 28 29 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224

510

2040

100

300

1000

510

2040

100

300

1000




� plot complete spectrum!


Dijkstra Rank

Que

ry T

ime

[µs]

25 26 27 28 29 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224

510

2040

100

300

1000

510

2040

100

300

1000


InstancesW. Europe (PTV) USA/CAN (PTV)

18 029 721 #nodes 18 741 705

42 199 587 #directed edges 47 244 849

13 #road categories 13

10–130 average speeds [km/h] 16–112


Local Queries (Highway Hierarchies)

211 212 213 214 215 216 217 218 219 220 221 222 223 224

01

2

01

2

Dijkstra Rank

Que

ry T

ime

[ms]

Europe (15 min., 68 B/node)USA/CAN (20 min., 69 B/node)


Combination Goal DirectedSearch (landmarks)

[with D. Delling, D. Wagner]

� About 20 % faster than HHs + distance tables

� Significant speedup for approximate queries


Many-to-Many Routing

[with S. Knopp, F. Schulz (PTV AG), D. Wagner]

Given:

� graph G = (V,E)

� set of source nodes S⊆V

� set of target nodes T ⊆V

Task: compute |S|× |T | distance table

containing the shortest path distances S

T


Applications

� Logistics

– vehicle routing problem

– input for traveling salesman solver

� Traffic Simulation

� Preprocessing for Point-to-Point Techniques

– precomputed cluster distances [MaueSandersMatijevic2006]

– transit node routing


Simple Solutions

Example: 10 000× 10 000 table

in Western Europe

� apply SSSP algorithm︸︷︷︸

|S| times

(e.g. DIJKSTRA)≈ 10 000× 10 s≈ one day

� apply P2P algorithm︸︷︷︸

|S|× |T | times

(e.g. highway hierarchies1)≈ 10 0002× 1 ms≈ one day

1requires about 15 minutes preprocessing time


2. ApproachTransit-Node Routing

[with H. Bast and S. Funke]

s t


X XX XExample:Karlsruhe→ Copenhagen


X XX XExample:Karlsruhe→ Berlin


X XX XExample:Karlsruhe→ Vienna


X XX XExample:Karlsruhe→ Munich


X XX XExample:Karlsruhe→ Rome


X XX XExample:Karlsruhe→ Paris


X XX XExample:Karlsruhe→ London


X XX XExample:Karlsruhe→ Brussels


X XX XExample:Karlsruhe→ Copenhagen




X XX XExample:Karlsruhe→ Vienna


X XX XExample:Karlsruhe→ Munich


X XX XExample:Karlsruhe→ Rome


X XX XExample:Karlsruhe→ Paris


X XX XExample:Karlsruhe→ London


X XX XExample:Karlsruhe→ Brussels


First Observation

For long-distancetravel: leave current location

via one of only a few ‘important’ traffic junctions,

called access points

( we can afford to store all access points for each node)

[in Europe: about 10 access points per node on average]








Second Observation

Each access point is relevant for several nodes.

union of the access points of all nodes is small,

called transit node set

( we can afford to store the distances between all transit node pairs)

[in Europe: about 10 000 transit nodes]


Transit-Node Routing

Preprocessing:

� identify transit-node set T ⊆V

� compute complete |T |× |T | distance table

� for each node: identify its access points (mapping A : V → 2T ),

store the distances

Query (source s and target t given): compute

dtop(s, t) := min{d(s,u)+d(u,v)+d(v, t) : u ∈ A(s),v ∈ A(t)}


Transit-Node Routing

Locality Filter :

local cases must be filtered ( special treatment)

L : V ×V →{true, false}

¬L(s, t) implies d(s, t) = dtop(s, t)


Example


Related Work

� separator-basedimplementation [Müller et al. 2006]

– determine separator nodes (= transit nodes)

– partition the graph into small components

– access points of node u: border nodes of u’s component

– locality filter: “same component?”

� grid-based implementation [Bast, Funke, Matijevic 2006]

– compute geometric subdivision of the network into cells

– access points: border nodes needed for ‘long-distance’ travel

– transit nodes: union of all access points

– locality filter: “less than a certain number of grid cells apart?”


HH + Distance Table


for the core of the topmost level ℓ. 13 465× 13 465 entries

transit node set T


core of level ℓ have been encountered. ≈ 55 for each direction

do not ‘search’, just perform look-ups



HH-based Transit Node Routing


for the core of the topmost level ℓ︸︷︷︸

. 13 465× 13 465 entries

transit node set T


core of level ℓ have been encountered. ≈ 55 for each direction

do not ‘search’, just perform look-ups



Missing Pieces

1. locality filter : use geometric disks

su

t

d(s, t) = du(s, t) < dtop(s, t)

L(s, t) := “disks of s and t overlap”


Missing Pieces

2. too many ‘entrance points’ (55)

solution: fall back on comparatively few ‘access points’ (10)

(motivated by the observations from [Bast, Funke, Matijevic 2006])

topmost level

access points

entrance points


Missing Pieces

3. compute top distance table in the original graph

solution: many-to-many shortest paths

(based on highway hierarchies)

S

T


Second Layer

(to deal with medium range queries)

� secondary transit node set T2⊃ T

� secondary access mapping A2 : V → 2T2

� secondary dist. table{

d(u,v) : u,v ∈ T2∧d(u,v) 6= dtop(u,v)}

� secondary locality filter L2

¬L2(s, t) implies

d(s, t) = dtop(s, t)

OR

d(s, t) = min{d(s,u)+d(u,v)+d(v, t) : u ∈ A2(s),v ∈ A2(t)}

Level Layer

L2L1

14

22

1

0

generous

(3)

Level Layer15

23

1

0 L2

L1

economical


Two Concrete Variants


Preprocessing

� for each secondary transit node t ∈ T2:

– perform backward highway search

– stop at primary transit nodes ( set of backward access points)

– store search space entries (t,u,d(u, t))

� arrange search spaces


Preprocessing

� for each secondary transit node s ∈ T2:

– perform forward highway search

– stop at primary transit nodes ( set of forward access points)

– at each node u and for each search space entry (t,u,d(u, t)):

∗ compute distance du(s, t) := d(s,u)+d(u, t) via u

∗ compute distance dtop(s, t) via top layer

∗ if du(s, t) < dtop(s, t) then

· add entry du(s, t) to the secondary distance table

· ensure that the disks around s and t contain u

(use similar procedure for lower layers)


Local Queries (Transit-Node Routing, Europe)

Dijkstra Rank

Que

ry T

ime

[µs]

25 26 27 28 29 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224

1010

010

00

1010

010

00

eco: 46 min, 110 B/nodegen:164 min, 251 B/node


3. ApproachHighway-Node Routing

[SS 07–]

?


Static Route Planning in Road Networks

Task: determine quickest route from source to target location

Problem: for large networks, simple algorithms are too slow

Assumption: road network does not change

Conclusion:use preprocessed data to accelerate source-target-queries

(research focus during the last years [→ everything told so far])

correctness relies on the above assumption


Dynamic Scenarios

� change entire cost function

(e.g., use different speed profile)

� change a few edge weights

(e.g., due to a traffic jam)


Constancy of Structure

Weaker Assumption:

� structure of road network does not change

(no new roads, road removal = set weight to ∞)

not a significant restriction

� classification of nodes by ‘importance’ might be slightly perturbed,

but not completely changed

(e.g., a sports car and a truck both prefer motorways)

performance of our approach relies on that

(not the correctness)


Overlay Graph

[Holzer, Schulz, Wagner, Weihe, Zaroliagis 2000–2007]

� graph G = (V,E) is given

� select node subset S ⊆V


Overlay Graph

[Holzer, Schulz, Wagner, Weihe, Zaroliagis 2000–2007]

� graph G = (V,E) is given

� select node subset S ⊆V

� overlay graph G′ := (S,E ′) where

E ′ := {(s, t) ∈ S×S | no inner node of the shortest s-t-path belongs to S}


Covering Nodes

Definitions:

� covered branch: contains a node from S

� covered tree: all branches covered

� covering nodes: on each branch, the node u ∈ S closest to the root s

s


Query

� bidirectional

� perform search in G till search trees are covered by nodes in S

s

t


Query

� bidirectional

� perform search in G till search trees are covered by nodes in S

� continue search only in G′

s

t


Covering Nodes

Conservative Approach:

� stop searching in G when all branches are covered

s

big city

long−distance ferry

� can be very inefficient


Covering Nodes

Aggressive Approach:

� do not continue the search in G on covered branches

s

fast road

slow road

v

u

� can be very inefficient


Covering Nodes

Stall-on-Demand:

� do not continue the search in G on covered branches

� a node v can ‘wake’ a node u on a covered branch

� u can ‘stall’ v (if δ(u)+w(u,v) < δ(v))

i.e., search is not continued from v

s

fast road

slow road

v

u


Static Highway-Node Routing

� extend ideas from

– multi-level overlay graphs [HolzerSchulzWagnerWeiheZaroliagis00–07]

– highway hierarchies [SS05–06]

– transit node routing [BastFunkeMatijevicSS06–07]

� use highway hierarchies to classify nodes by ‘importance’

i.e., select node sets S1⊇ S2⊇ S3 . . .

(crucial distinction from previous separator-based approach)

� construct multi-level overlay graph

� perform query with stall-on-demand technique


Static Highway-Node Routing

� extend ideas from

– multi-level overlay graphs [HolzerSchulzWagnerWeiheZaroliagis00–07]

– highway hierarchies [SS05–06]

– transit node routing [BastFunkeMatijevicSS06–07]

� use highway hierarchies to classify nodes by ‘importance’

i.e., select node sets S1⊇ S2⊇ S3 . . . 16 min

(crucial distinction from previous separator-based approach)

� construct multi-level overlay graph 3 min, 8 bytes/node

� perform query with stall-on-demand technique 1.1 ms

(experiments with a European road network with≈ 18 million nodes)


Static Highway-Node Routing(Europe)

Dijkstra Rank

Que

ry T

ime

[ms]

211 212 213 214 215 216 217 218 219 220 221 222 223 224

01

2

01

2

Highway Hierarchies Star (22 min., 76 B/node)Highway−Node Routing (19 min., 8 B/node)


Dynamic Highway-Node Routing

change entirecost function

� keep the node sets S1⊇ S2⊇ S3 . . .

� recompute the overlay graphs

speed profile default fast car slow car slow truck distance

constr. [min] 1:40 1:41 1:39 1:36 3:56

query [ms] 1.17 1.20 1.28 1.50 35.62

#settled nodes 1 414 1 444 1 507 1 667 7 057



change afew edge weights

� server scenario:if something changes,

– update the preprocessed data structures

– answer many subsequent queries very fast

� mobile scenario:if something changes,

– it does not pay to update the data structures

– perform single ‘prudent’ query that

takes changed situation into account



change afew edge weights, server scenario


� recompute only possibly affected parts of the overlay graphs

– the computation of the level-ℓ overlay graph consists of

|Sℓ| local searches to determine the respective covering nodes

– if the initial local search from v ∈ Sℓ has not touched a now

modified edge (u,x), that local search need not be repeated

– we manage sets Aℓu = {v ∈ Sℓ | v’s level-ℓ preprocessing

might be affected when an edge (u,x) changes}



change afew edge weights, server scenario

Road Type

Upd

ate

Tim

e [m

s]

0.1

110

100

0.1

110

100

any motorway national regional urban

add traffic jamcancel traffic jamblock road



change afew edge weights, mobile scenario


� keep the overlay graphs

� use the sets Aℓu to determine for each node u a reliable level r(u)

� during a query, at node u

– do not use edges that have been created in some level > r(u)

– instead, downgrade the search to level r(u)


Level 0Level 1Level 2Level 3Level 4Level 5Level 6Level 7



change afew edge weights, mobile scenario

single pass iterative

|change set| affected query time query time #iterations

(motorway edges) queries [ms] [ms] avg max

1 0.4 % 2.3 1.5 1.0 2

10 5.8 % 8.5 1.7 1.1 3

100 40.0 % 47.1 3.6 1.4 5

1 000 83.7 % 246.3 25.3 2.7 9


Summary

Highway Hierarchies: Fast routing, fast preprocessing, low space, few

tuning parameters, basis for many-to-many, transit-node routing,

highway-node routing.

Many-to-Many: Huge distance tables are tractable.

Subroutine for transit-node routing.

Transit-Node Routing: Fastest routing so far.

Highway-Node Routing: “Simpler” HHs, fast routing, very low space,

efficiently dynamizable.


Summary: A Horse-Race Perspectivemethod first date size space preproc. speedup

pub. mm/yy n/106 Byte/n [min]

separator multi-level [SWW99] 04/99 0.1 ? > 5 400 52

edge flags (basic) [Lau04] 03/04 6 13 299 523

landmark A∗ [GolHar05] 07/04 (18) 72 13 28

edge flags [KMS05] 01/05 1 141 2 163 1 470

HHs (basic) [SS05] 04/05 18 29 161 2 645

adv. reach[GKW06] 10/05 18 82 1 625 1 559

[GKW06] 08/06 18 32 144 3 830

adv. HHs [DSSW06] 08/06 18 76 22 11 496

high-perf. multi-level [Mul06] 06/06 18 181 11 520 401 109

transit nodes (gen) [BFMSS07] 10/06 18 251 164 1 129 143

highway nodes (mem) [SS07] 01/07 18 2 24 4 079

realisticmodels

design

implementation

librariesalgorithm−

perf.−guarantees

app

lication

sdeduction

falsifiable

inductionhypothesesanalysis experiments

algorithmengineering real

Inputs


Conclusion


ModelsApplication:

� structure of a road network is (‘almost’) static

allow preprocessing

� edge weights may change unexpectedly

� time-dependent edge weights

� point-to-point, many-to-many

� multi-objective

Machine:

� memory hierarchy

� parallel


Analysis

Correctness:

� for TNR and HNR: not very too difficult

� for HH: surprisingly difficult (ambigious shortest paths)

Worst-Case Bounds:

� performance relies on ‘certain’ graph properties: specify them

� derive worst-case bounds for graphs with the specified properties


Analysis

Per-Instance Worst-Case Guarantees:

1014

1012

1010

108

106

104

100

0 500 1000 1500 2000 2500 3000

Fre

quen

cy

Search Space

Europe

histogram of (upper bounds on︸︷︷︸

) the search space sizes of all possible n2 queries

can be computed using a linear number of queries


Implementation

[covers all mentioned route planning techniques]

� quite complex (≈ 18 000 lines of code (w/o tools))

� C++ template mechanism

(currently, 23 different instantiations of our Dijkstra template class)

� standard template library and ‘home-made’ data structures

– provide only the required functionality

– can efficiently handle large data sets

� thorough checking: asserts, naive reference implementations

� visualisation


Experiments


� plot complete spectrum!


Dijkstra Rank

Que

ry T

ime

[µs]

25 26 27 28 29 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224

510

2040

100

300

1000

510

2040

100

300

1000


Instances

� before 2005: only very small road networks

publicly and readily available

≈ 200 000 nodes, but only

≈ 1 000 ‘degree > 2’ nodes


Instances

� in 2005: US and Western European road networks obtained

– composed from a public source (US Census Bureau)

– provided by a company (PTV AG) for scientific use

� now: widely spread (e.g., DIMACS Implementation Challenge)

≈ 18 million nodes

≈ 16 million ‘degree > 2’ nodes


Instances

Open Issues:

� turn penalties

� real source-target pairs

(we have some many-to-many instances)

� real traffic reports (edge weight changes)

� time-dependent edge weights (not only for motorways!)

� other graph types


Applications

� single point-to-point queries

– mobile navigation system (built-in, PDA, mobile phone, . . .)

– internet route planning service

� massive amount of point-to-point queries

– traffic simulations

� many-to-many queries

– logistics optimisation

– ride sharing

promising contacts to various companies—more to come?


Appendix


Summary: An Application Perspective

HH= highway hierarchy; HNR= highway-node routing

Static low-cost mobile route planning: low space HHs or static HNR

Dynamic mobile route planning: dynamic HNR (single-shot)

Static server-based: transit-node routing

Dynamic server-based: dynamic HNR (with updates)

Logistics: Many-to-many HHs (HNR when edge weight change often)

Microscopic Traffic Simulation: transit-node routing ?

Macroscopic Traffic Simulation: Many-to-many HHs or HNR


Future Work I: More on Static Routing

� Better choices for transit-node sets or highway-node sets.

(use centrality measures, separators, explicit optimization,. . . )

� A hierarchical routing scheme that allows stopping bidirectional

search earlier ? (competetive with HHs, HNR)

� Better integration with goal directed methods.

(PCDs, A∗, edge flags, geometric containers)

� Experiments with other networks.

(communication networks, VLSI, social networks, computer

games, geometric problems, . . . )

� Specialized preprocessing for one batch of (many-to-many) queries


Future Work II: Theory Revisited

� Correctness proofs

� Stronger impossibility results (worst case)

� Analyze speedup techniques for model graphs

� Characterize graphs for which a particular (new?) speedup

technique works well

� A method with low worst-case query time,

but preprocessing might become quadratic ?


Future Work III: Towards Applications

� Turn penalties (implicitly represented)

Just bigger but more sparse graphs ?

� Parallelization (server scenarios, logistics, traffic simulation)

easy (construction, many-to-many, many queries)

� Mobile platforms

adapt to memory hierarchy (RAM↔ flash)

data compression


Industral Contacts


Future Work IV: Beyond Static Routing

� More dynamic routing (e.g. for transit-node routing)

� Time-dependent networks

(public transportation, traffic-dependent travel time)

� Preprocessing for an entire spectrum of objective functions

� Multi-criteria optimization

(time, distance, fuel, toll, driver preferences,. . . )

� Approximate traffic flows

(Nash-equilibria, (fair) social optima)

� Traffic steering (road pricing, . . . )

� Stochastic optimization


An Algorithm Engineering Perspective

Models: Preprocessing, point-to-point, dynamic, many-to-many

parallel, memory hierarchy, time dependent, multi-objective,. . .

Design: HHs, HNR, transit nodes,. . . wide open

Analysis: Correctness, per instance. big gap

Implementation: tuned, modular, thorough checking, visualization.

Experiments: Dijkstra ranks, worst case, cross method. . . .

Instances: Large real world road networks.

turn penalties, queries, updates, other network types

Algorithm Libraries: ???

Applications: Promising contacts, hiring. more should come.


Goal-Directed Search

s t

A∗ [Hart, Nilsson, Raphael 68]: not effective for travel time

Geometric Containers [Wagner et al. 99–05]:

high speedup but quadratic preprocessing time

Landmark A∗ [Goldberg et al. 05–]: precompute distances to≈ 20

landmarks moderate speedups, preprocessing time, space

Precomputed Cluster Distances [S, Maue 06]:

more space-efficient alternative to landmarks


Hierarchical Methods

Planar graph (theory) [Fakcharoenphol, Rao, Klein 01–06]: O(n log2n)

space and preprocessing time; O(√

n logn) query time

Planar approximate (theory) [Thorup 01]: O((n logn)/ε) space and

preprocessing time; almost constant query time

Separator-based multilevel [Wagner et al. 99–]:

works, but does not capitalize on importance induced hierarchy

Reach based routing [Gutman 04]:

elegant, but initially not so successful

Highway hierarchies [SS 05–]: stay tuned

Advanced reach [Goldberg et al. 06–]: combinable with landmark A∗

Transit-node routing [Bast, Funke, Matijevic, S, S 07–]: stay tuned


Highway-node routing [SS 07–]: stay tuned


Goals

� bridge gaps between theory and practice

� accelerate transfer of algorithmic results into applications

� keep the advantages of theoretical treatment:

generality of solutions and

reliabiltiy, predictabilty from performance guarantees


Canonical Shortest Paths

S P : Set of shortest paths

S P canonical⇔

∀P = 〈s, . . . ,s′, . . . , t ′, . . . , t〉 ∈ S P : 〈s′→ t ′〉 ∈ S P


A Meaning of “Local”

� choose neighbourhood radius r(s)

e.g. distance to the H-closest node for a fixed parameter H

� define neighbourhood of s:

N (s) := {v ∈V | d(s,v)≤ r(s)}

� example for H = 5

6

520

1

3

4

8

9

7

s

N (s)ranks =


Highway Network

N (s) N (t)

s t

Highway

Edge (u,v) belongs to highway network iff there are nodes s and t s.t.

� (u,v) is on the “canonical” shortest path from s to t

and

� (u,v) is not entirely within N (s) or N (t)


Canonical Shortest Paths

s0

0

0

0 0

0

0u′

u v

t0s1 t1

v′

N (s1) N (t1)

N (v′)N (s0)

1 2

2 2

2221

1

1

1

11

1

(a) Construction, started from s0.

0

0

0 0

0

0

u

v′

v

t1 t0s0 s1

u′

N (s1)N (t0)N (u′)

N (v)

1 2

2 2

2221

1

1

1

11

1

(b) Construction, started from s1.


0

0

0 0

0

0

u

v′t1s0 t0

v

s1

u′

1 2

2 2

2221

1

1

1

11

1

(c) Result of the construction.


Contraction

highway nodes and edges


Contraction

bypass node


Contraction

shortcuts


Contraction

bypass node


Contraction


Contraction

(of bypassed nodes)

leaves

component

component

enterscomponent


Contraction

core


Contraction

Which nodes should be bypassed?

Use some heuristic taking into account

� the number of shortcuts that would be created and

� the degree of the node.


Fast Construction of the Highway Network

Look for HH-edges only in (modified) local SSSP search trees.

� Nodes have state

active, passive, or mavericks.

� s0 is active.

� Node states are inherited

from parents in the SSSP tree.

� abort condition(p)−→ p becomes passive.

� d(s0, p) > f · r(s0)−→ p becomes maverick.

� all nodes maverick?−→ stop searching from passive nodes

� all nodes passive or maverick?−→ stop

Result: superset of highway network

s0

mavericks

f · r(s0)

pas-sive

active


Local Queries (Highway Hierarchies Star, Europe)

Dijkstra Rank

Que

ry T

ime

[ms]

211 212 213 214 215 216 217 218 219 220 221 222 223 224

01

01

exact (22 min., 76 B/node)approx (22 min., 76 B/node)


Simple Solutions


in Western Europe

� apply SSSP algorithm︸︷︷︸

|S| times

(e.g. DIJKSTRA)≈ 10 000× 10 s≈ one day

� apply P2P algorithm︸︷︷︸

|S|× |T | times

(e.g. highway hierarchies1)≈ 10 0002× 1 ms≈ one day



pOur Solution


in Western Europe

� many-to-many algorithm

based on highway hierarchies1≈ one minute

ts


S

T


Main Idea

� instead of |S|×|T | bidirectional highway queries

� perform |S|+ |T | unidirectional highway queries

Algorithm

� maintain an |S|× |T | table D of tentative distances

(initialize all entries to ∞)


� for each t ∈ T , perform backward search

store search space entries (t,u,d(u, t))

� arrange search spaces: create a bucket for each u

� for each s ∈ S, perform forward search

at each node u, scan all entries (t,u,d(u, t)) and

compute d(s,u)+d(u, t), update D[s, t]


Different Combinations

Europe

metric /0 DistTab ALT both

time

preproc. time [min] 17 19 20 22

total disk space [MB] 886 1 273 1 326 1 714

#settled nodes 1 662 916 916 686 (176)

query time [ms] 1.16 0.65 0.80 0.55 (0.18)

dist

preproc. time [min] 47 47 50 49

total disk space [MB] 894 1 506 1 337 1 948

#settled nodes 10 284 5 067 3 347 2 138 (177)

query time [ms] 8.21 4.89 3.16 1.95 (0.25)


Neighbourhood Size

15

16

17

18

19

20

21

22

23

24

25

40 50 60 70 80 90

Pre

proc

essi

ng T

ime

[min

]

20

40

60

80

100

120

140

40 50 60 70 80 90

Mem

ory

Ove

rhea

d pe

r N

ode

[byt

e] EuropeUSA/CAN

USA

0.6

0.7

0.8

0.9

1

1.1

1.2

40 50 60 70 80 90

Que

ry T

ime

[ms]


Number of Levels

0

10

20

30

40

50

60

70

5 6 7 8 9 10 11 0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

Mem

ory

Ove

rhea

d pe

r N

ode

[byt

e]

Que

ry T

ime

[ms]

Number of Levels

Europe

Memory OverheadQuery Time


Contraction Rate

1600

1700

1800

1900

2000

2100

2200

2300

2400

1 1.5 2 7900

8000

8100

8200

8300

8400

8500

8600

8700

8800

8900

9000

# S

ettle

d N

odes

# R

elax

ed E

dges

Contraction Rate

Europe

Settled NodesRelaxed Edges

Documents

Engineering Route Planning Algorithmsalgo2.iti.kit.edu/sanders/courses/bergen/routePlanning.pdfSanders/Schultes: Route Planning 2 Shortest Path Problem given a weighted, directed graph