CH Introduction

8/12/2019 CH Introduction

1/18


2/18

TRANSPORTATION SCIENCEVol. 46, No. 3, August 2012, pp. 388-404ISSN 0041-1655 (print) | ISSN 1526-5447 (online)

infj3E]http://dx.doi.org/10.1287/trsc.1110.0401

2012 INFORMS

Exact Routing in Large Road Networks Using

Contraction Hierarchies

Robert Geisberger, Peter Sanders, Dominik Schultes, Christian VetterKarlsruhe Institute of Technology, Department of Informatics, 76128 Karlsruhe, Germany

([email protected],[email protected],[email protected],[email protected])

Contraction hierarchies are a simple approach for fast routing in road networks. Our algorithm calculatesexact shortest paths and handles road networks of whole continents. During a preprocessing step, we exploit

the inherent hierarchical structure of road networks by adding shortcut edges. A subsequent modified bidirectional Dijkstra algorithm can then find a shortest path in a fraction of a millisecond, visiting only a few hundrednodes. This small search space makes it suitable to implement it on a mobile device. We present a mobile

implementation that also handles changes in the road network, like traffic jams, and that allows instantaneousrouting without noticeable delay for the user. Also, an algorithm to calculate large distance tables is currentlythe fastest if based on contraction hierarchies.

Key words:route planning; shortest paths; algorithm engineeringHistory:Received: November 2010; revision received August 2011; accepted: August 2011. Published online in

Articles inAdvanceApril 5, 2012.

1. IntroductionFinding optimal routes in road networks is an impor

tant problem used in diverse applications, such as

car navigation systems, Internet route planners, trafficsimulation, or logistics optimization. Formally, we are

given a directed graph G = (V, ) together with an

edge weight function c: ->U+.Edges represent roads

and nodes represent junctions. In practice, c is usu

ally the travel time or some more general cost func

tion highly correlated with travel time. Because the

network does not change much over time, it makes

sense topreprocess this graph in order to speed up sub

sequent (shortest path) queriesasking for a mi nimum

weight path from a given source node to a given target

node. However, in order to scale to networks with mil

lions of nodes, preprocessing has to be fast and spaceefficient. In particular, it is not feasible to precompute

a complete distance table.

Our motivation forcontraction hierarchies(CH) was

to create an efficient routing algorithm whose sim

plicity makes it adaptable to a variety of situations.

Somewhat surprisingly, this approach also resulted in

one of the most efficient approaches available today.

Depending on the desired tradeoff between query

time, preprocessing time, and space consumption,

CHs are usually the best known approach or used

as a component of a more complex algorithm (see6.7). We exploit the observation that road networks

have an inherent hierarchy with a few important and

many unimportant roads and junctions, i.e., roads and

junctions tha t are only used for local traffic near the

source and target of a route. However, it is not neces

sary to specify road categories in advance. Our algo

rithm performs the road classification automatically

by evaluating the assigned cost of each road. To show

that our algorithm is feasible in practice, Geisberger,

Sanders, and Schultes (2008) released source code as

open source, and Vetter (2010) provided a mobile

implementation that calculates exact shortest paths

within split seconds. We also added features of cur

rent commercial systems that can cope with traffic

jams or blocked routes .

1.1. Basic App roach

The idea of our algorithm is to remove unimportant

nodes from a directed, weighted road network in a

way that preserves shortest path distances. This concept is called node contraction: deleting a node u and

adding shortcut edges (shortcuts) to preserve short

est path distances between the remaining nodes. The

shortcuts bypass node u and represent whole paths.

During the preprocessing, we contract one node at

a time until the graph is empty. All original edges

together with the shortcuts form the result of the pre

processing, acontraction hierarchy.Subsequently, nodes

removed later will be calledhigher up in the hierarchy.

A crucial figure is the number of shortcuts. If it is too

large, our algorithm will not be useful because pre

processing time, space consumption, and query time

will suffer. But because of the inherent hierarchy of

road networks, we can keep this figure small by a care

ful heuristic choice of the order in which the nodes

388
http://dx.doi.org/10.1287/trsc.1110.0401mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]://dx.doi.org/10.1287/trsc.1110.0401


3/18

Geisberger, Sanders, Schultes, and Vetter: Contraction HierarchiesTransp ortatio n Science 46(3), pp. 388-404, 2012 INFORMS 389

are contracted. Roughly, after contracting a node, the

remaining graph should be as sparse as possible.

Hence, theedgedifferencethe number of added short

cuts minus number of incident edgesof a contracted

node should be small. Further heuristics enforce a

uniform contraction everywhere in the graph and

try to limit the effort for contraction or subsequent

queries.

The concept of node contraction al lows an efficient

and simple query algorithm. We find a shortest path

from source s to target / using a variant of the bidirec

tional version of Dijkstra's algorithm: Both forward

search from s and backward search from t relax only

edges leading to nodes higher up in the hierarchy.

Because of the shortcuts, both searches will meet on

a node u that is highest in the CH on a shortest path

between s and t.

We developed two implementations of CHs: onefor personal computers and one for mobile devices.

The mobile implementation required engineering of

an external-memory graph representation to over

come the input/output operation (I/O) bandwidth

and main memory limitations of those small devices.

We also support dynamic edge weight changes.

To reestablish a correct CH on a personal computer,

we only need to update affected shortcuts , and recon-

tract nodes that are affected by the changes. On a

mobile device, we do not recontract, but we establish

a correct query by ensuring that the search can reachaffected nodes.

1.2. Related Work

Computing shortest paths in road networks is a well-

studied problem, e.g., Ahuja, Magnanti, and Orlin

(1993). Recently a plethora of faster algorithms(speed-

up techniques) has been developed, and they are sev

eral orders of magnitude faster and can handle much

larger graphs than the classic algorithm by Dijkstra

(1959). We can only give an abridged overview with

emphasis on directly related techniques beginning

with the closest kin. For a recent overview we refer tothe reader to Delling et al. (2009). Previous heuristic

approaches, e.g., Fu, Sun, and Rilett (2006), or speedup

techniques based on A*, e.g., Klunder and Post (2006),

are orders of magnitude slower than the best exact

methods known now. In addition, research in trans

portation science has continued partly unaware of the

above developments, e.g., Pijls and Post (2009).

CHs, first introduced by Geisberger et al. (2008), are

an extreme case of the hierarchies in highway-node

routing (HNR) by Schultes and Sanders (2007)every

node defines its own level of the hierarchy. CHs arenevertheless a new approach in the sense that the

node ordering and hierarchy construction algorithms

used by HNR are only efficient for a small num

ber of geometrically shrinking levels. We also give a

faster and more space efficient query algorithm and

improve their dynamization techniques.

The node ordering computed by HNR uses lev

els acquired by highway hierarchies (HHs) by Sanders

and Schultes (2005). Our original motivation for CHs

was to simplify HNR by obviating the need for

another (more complicated) speedup technique (HHs)

for node ordering. HHs are constructed by alternating

between two subroutines: Edge removal is a sophis

ticated and relatively costly routine that only keeps

edges required "in the middle" of "long-distance"

paths.Node removalcontracts nodes and uses the edge

difference to estimate the cost of contracting a node v.

Goldberg, Kaplan, and Werneck (2007) and Bauer and

Delling (2009) further refine this method using a pri

ority queue and avoiding parallel edges. All previous

approaches to contraction had in common that the

average degree of the nodes in the remaining graphwould eventually explode. So it looked like an addi

tional technique such as edge removal would be a

necessary ingredient of any high-performance hierar

chical routing method. Perhaps the most important

result of CHs is that using only (a more sophisticated)

node contraction, we achieve very good performance.

An even faster speedup technique is transit-node

routing (TNR). The basic idea of TNR is to store an

all-to-all lookup table for a set of important transit

nodes (&(^/n) many) and, for each node, the mini

mal set of transit nodes (about 10) that are needed tocover all shortest paths touching a transit node. This

essentially reduces long distance routing to a set of

table lookups (one for each pair of access nodes at

source and destination). However, TNR needs consid

erably higher preprocessing time and space; is less

amenable to dynamization; and, most importantly,

relies on another hierarchical speedup technique for

its preprocessing. We will show that using CHs for this

purpose leads to improved performance.

Recently, it was shown that using even more pre

processing time and space, one can directly use CHs

to achieve the currently fastest query times (Abrahamet al. 2011). Essentially, this is an extreme case of the

many-to-many technique described in 7. The hubla-

beling method explicitly stores the search spaces from

all nodes and intersects them for a query.

Finally, there is an entirely different family of

speedup techniques based on goal-directed routing.

In particular, ALT (A*, Landmarks, Triangle inequal

ity) by Goldberg and Harrelson (2005) yields strong

lower bounds that can direct the search toward the

target. It has fast preprocessing but considerable

space requirements. Arc flags (AF), first introducedby Lauther (2004), indicate for each edge into which

regions it leads. They give a stronger sense of goal

direction than ALT and need less space yet very

high preprocessing times. Combination of CHs with


4/18

390Geisberger, Sanders, Schultes, and Vetter: Contraction Hierarchies

Transportation Science 46(3), pp. 388-404, 2012 INFORMS

goal-directed routing have been systematically stud

ied by Bauer et al. (2010b). Their experiments suggest

that CHs also work for other sparse networks with

high locality such as some transportation networks

or sparse unit-disk graphs. For denser networks, CHs

can be used in an initial contraction phase whereas a

goal-directed technique is applied to the resulting core

network.

For mobile algorithms, only few academic imple

mentations exist. Goldberg and Werneck (2005) suc

cessfully implemented the ALT algorithm on a Pocket

PC. Our implementation, a static version, was pre

sented earlier in Sanders, Schultes, and Vetter (2008)

and is more than one magnitude faster and drasti

cally more space efficient. Also a mobile implemen

tation of the RE algorithm by Goldberg1 yields query

times of "a few seconds including path computation

and search animation" and requiring "2-3 GB forUSA/Europe." Commercial systems, to the best of our

knowledge, do not compute exact routes and require

several seconds to calculate a route.

Several aspects of routing in road networks are

more or less orthogonal. For example, turn restric

tions and turn penalties can be modeled using edge

based routing, e.g., Winter (2002), where nodes repre

sent the starting point of a road segment and edges

represent the cost of going from one starting point to

a subsequent starting point.

1.3. Outline

In 2 we describe CHs in detail and explain the prepro

cessing (2.1,2.3) and the query algorithm (2.2). Our

adaptations for mobile devices are in 3. The refined

dynamization technique is described in 4 and a vari

ant suitable for the mobile scenario in 5. Section 6

summarizes experiments regarding different variants

of CHs and comparisons with other techniques. A few

applications of CHs are introduced in 7. The conclu

sion in 8 summarizes the results and outlines fur

ther routes of study. Some important implementation

details have been moved to the appendix.

2. Contraction HierarchiesBefore proceeding with the description of contraction

hierarchies, we recall that Dijkstra's algorithm can be

used to solve the single-source shortest path problem,

i.e., to compute the shortest paths from a single source

node s to all other nodes in a given graph. Starting

with the source node s as root, Dijkstra's algorithm

grows a shortest path tree that contains shortest paths

from s to all other nodes. During this process, each

node of the graph is eitherunreached, reached,orsettled.A node that already belongs to the tree is settled. If a

node u is settled, a shortest path P* from s to u has

been found and the distance dt(u) c(P*) is known,

where c(P) denotes the sum of the costs of the edges

on a path P. A node that is adjacent to a settled node

is reached.Note that a settled node is also reached.

If a node u is reached, a path P from s to w, which

might not be the shor test one , has been found and

a tentative distance 8s(u) = c(P) is known. Nodes that

are not reached areunreached. Relaxing an edge (u,v)

means checking whether the path s-u-v improves the

tentative distance 8s(u).

As introduced in 1.1, we construct a CH by order

ing the nodes and then contracting the nodes in this

order. For convenience, we assume that after node

order ing the nodes are numbered from 1 to n, where

n := |V|, in order of ascending importance. A node u

is contracted by removing it from the network in such

a way that shortest paths in the remaining graph arepreserved. When we do not add a shortcut, then there

must exist a shortest path different from the path

(v, u, w) via the contracted node. We call such a path

awitness path.The concept of witness paths is particu

larly important for the dynamization described in 4

and 5. Figure 1 shows a completed CH.

2.1. Node Contraction

The most important part of the node contraction is to

find witness paths. A simple way to decide whether

(v, u,w) is the only shortest path is to perform for

each node v e S a forward shortest-path search only

using nodes not yet contracted until all nodes in T\{v]

are settled. Such a search to compute shortest path

distances between the neighbors is called alocalsearch.

Let 8v(w) be the shortest path distance found by this

local search. We add a shortcut if and only if 8v(w) >

c(v, u)+ c(u, w), i.e., if the shortest i>-w-path exclud

ing uwill be longer; see Figure 2. We can additionally

stop the search from a node x when it has reached

distance c(v, ) + max(c(,w) \ we T\{v}\.

Limit Local Searches. To achieve fast preprocess

ing we rely on the assumption that local searches

are fast because they visit only a tiny fraction of the

network. However, this assumption fails when long

distance edges like ferry connections are involved.

1Goldberg, A (2008). Personal Communication, September 1. Figure 1 A Completed CH; Dashed Edges Are Added Shortcuts


5/18

Geisberger, Sanders, Schultes, and Vetter: Contraction Hierarchies

Transportation Science 46(3), pp. 388-404, 2012 INFORMS 391

' - - \ ' '

2^X1O

v

Figure2 There IsNo Witness Path Between the Node Pairs v, w,and

v, x so We Need to Add Shortcuts (Dashed) for the Contrac-

tion of Node v. The Witness Path (w, y,x)Allows us to Omit

a Shortcut Between the NodePairw, x.

We therefore additionally truncate local searches that

become too large. Note that this preserves shortest

path distances because we only introduce some super

fluous shortcuts. Because additional shortcuts slow

down all further processing, the local search limit

needs to be carefully selected for maximum performance. We propose two approaches to limit the local

searches: asettled nodes limit and a hop limit that lim

its the number of edges of witness paths. Limiting

the number of settled nodes is simple but, in our

experience, leads to dense remaining graphs and does

not speed up the contraction a lot. However, if we

only use it to estimate the edge difference and per

form the real contraction without a limit, it speeds

up the node ordering and yields CHs with fast query

times. Hop limits, introduced by Schultes (2008), pro

vide a better contraction speedup and also adapt to

denser remaining graphs. To achieve further speedup,we propose staged hop limits: We start contracting

nodes with a small hop limit, e.g., one. At some point,

we switch to larger hop limits because otherwise the

remaining graph will get too dense. We use the aver

age node degree, a measure for density, to trigger

these switches. Geisberger (2008) describes further

algorithmic details on how to efficiently implement

hop limits.

On-the-Fly Edge Reduction. If the local search is

performed by a local Dijkstra search, it computed

tentative distances 8v(x) to all neighbors x > u of v.

We use them to remove superfluous edges (v, x) e E

with 8v(x) < c(v, x). This edge reduction is cache effi

cient, and will therefore cause almost no direct over

head, but brings potentially faster preprocessing and

query times.

2.2. Query

In this section we will introduce our query algorithm

and prove its correctness. Recall that we find a short

est path from source s to target t using a variant of

the bidirectional version of Dijkstra's algorithm. Thequery does not relax edges leading to nodes lower

than the current node. This property is reflected in

the upward graph Gt : (V, E t) with Et := {(u,v) e

E |u < v) and the downward graph Gi :(V, ;) with

El := {(u, v) e E | u > v}. We combine them in the

search graph G* = (V,E*) with E4 := \(v, u) \ (u,v)

e EJ and E* := E, UE t . With each e e E", we store a

forward and a backward flag such that f(e) = true iff

e e t and 1(e) = true iff e eE ;. Algorithm 1 describes

our bidirectional Dijkstra-like query on G",essentially

a forward search in G. and a backward search in G ;.

The search is stopped when both queues are empty or

the smallest priority queue entry exceeds the length

of the best path already found. This upper bound is

updated whenever the search spaces meet; i.e., both

dt[u] and dju] have finite values.

Algorithm 1 Query(s, t)

1 dt := (oo,..., oo); d t[s] := 0;d^:= (oo,..., oo);

djf] :=0, d:=oo; / / te nt at iv e distances

2 Qr = j(0,s)(;Q i = j (0 , 01 ; r : = t ;

/ / p r i o r i t y queues

3 while (Q, 0 o r Q , ^ 0 ) and

(d >minjmin QT, min Q, \) do

4 if Q^r # 0 then r:=^r;

/ / i n te r l ea ve direct ion, ->f = I and - 4 = t

5 (-,u):=Q r .deleteMin();

d:= mm{d, d^[u] + dl[u}\;

//u i s set tl ed and new candi date

6 foreach e= (u, v) eE* do

7 if r(e) and (dr[u]+c(e) < dr[v]) then

/ / sho r t e r path found

8 dr[v]:=dr[u] + c(e);/ /update tentat ive dista nc e

9 Qr.update(],v);

/ /update pr ior i ty queue

10 returnd

THEOREM 1. Algorithm 1,applied to a CH, returns the

correct shortest path distance.

PROOF. It follows from the definition of a shortcut

that the shortest path distance between sand t in the

CH is the same as in the original graph. Every short

est s-t path in the original graph still exists in the CH,but there may be additional shortest s-t paths. How

ever because we use a modified Dijkstra algorithm

that does not relax all incident edges of a settled node,

our query algorithm does only find particular ones.

It only finds shortest paths that areup-down paths (s =

uQ, UJ up,...,uq = t) with p,q eN, u, < uI+] for

i eN,i H ;+ 1 for j eN,p < j < q. We will

prove that if there exists a shortest s-t path, then there

exists one that is an up-down path.

Give a shortest s-t path P = (s = UQ, U1,..., U., ...,

uq = t)

with p, q

M, u

p = max P. Let M

P := {u

k |wfc_! > uk < uk+l\ denote the set of local minima

excluding nodes s, t. MP ^ 0 iff P is not an up-

down path, like in Figure 3(a). Let uk :=minM P and

consider the two edges (uk , uk), (uk, uM) e E. Both


6/18



(b) After

Shortcut or witness

J= Kg ,, = I

Figure3 Step of the Correctness Proof to Construct an Up-Down Path

edges already exist at the beginning of the contrac

tion of node uk. So there is either a witness path Q =

{uk_:,..., uk+l) consisting of nodes higher than uk

with c(Q)


7/18


transportation Science 46(3), pp. 388 404, I 2012 0MFORM5 393

region. We have tried several heuristics for choosing

nodes uniformly, out of which we present the three

most successful ones. For all measures used here,

a large value means that the node is contracted late.

Deleted Neighbors: Every node has a counter that

gets incremented when a neighbor is contracted.

This heuristic is very simple and can be computed

efficiently.

Original Edges Term:For each shortcut we store the

number of original edges in the represented path. The

original edges term is the sum of the number of orig

inal edges of the necessary shortcuts. This increases

the space requirements but the term is beneficial,

e.g., for path unpacking.

Voronoi Regions: Let R(v) := (w contracted |d(v, u)

< oo, for each uncontracted w: d(v, u) < d(w, u)\ be

the Voronoi-region of an uncontracted node v.We use

y|R(i>)| as term in the priority function. By arbitrary

tie breaking, we ensure that a node is in at most one

R(v). Note that in directed graphs , a contracted node

may be in no region. When v is contracted, its neigh

boring Voronoi regions will "eat up" R(v).

Cost of Contraction. The most time consuming

part of the contraction are the local searches for wit

ness paths. Because their durations vary from node to

node, we want to contract "expensive" nodes later in

a smaller remaining graph. So we include the number

of settled nodes during the local search as a prior

ity term.

Cost of Queries. We have implemented the fol

lowing simple estimate H(u) that is an upper bound

for the number of hops of a path (s,... ,u) explored

during a query: Initially, H(u) = 0. Inductively, when

H(u) is an upper bound and u is contracted, then

H(u) + 1 is an upper bound for a path from s via u

to a neighbor v, so for each neighbor v, we update

H(v):=max(H(v),H(u) + \).

Generally speaking, one can come up with many

heuristic terms, but one gets an inflation of tuningparameters. Therefore, in the experiments we try to

keep their number small, we use the same set of

parameters for different inputs, and we make some

sensitivity analyses to test their robustness.

3. Mobile ScenarioBecause of the simple query algorithm and the small

search space, see 6, CHs are perfectly suited for

mobile devices with slow processors and limited

memory. However, some modifications to the originalalgorithm are necessary to engineer a fast mobile algo

rithm. We will sketch the modifications here and refer

to Sanders, Schultes, and Vetter (2008) for details on

algorithms and data structures.

Locality. Reading data from external memory is the

bottleneck of our query application. To get a good per

formance, we want to arrange the data into blocks and

access them blockwise. Obviously, the arrangement

should be done in such a way that accessing a single

data item from one block typically implies that a lot of

data items in the same block have to be accessed in the

near future. In other words, we have to exploit local

ity properties of the data. Therefore, we need to find a

node numbering that reflects locality. We achieve this

by combining a topological numbering using depth-

first search and a hierarchical renumbering using the

CH node order.

Blockwise Representation. Our graph data struc

ture stores per block a subset of nodes together with

their incident edges. We distinguish between internal

edges leading to a node within the same block and

the remaining external edges. That way, we requireless space to store internal edges. Within each block

we use the minimal number of bits to store the node

and edge attributes.

Storing the Graph Representation. The blocks rep

resenting the graph are stored in external memory.

In main memory, we manage a cache that can hold a

subset of the blocks.

Path Unpacking Data Structures. The above data

structures are sufficient to determine the shortest-

path length. In order to generate actual driving direc

tions, it must also be possible to generate a description

of the shortest path. First of all, because we have

changed the node numbering, we need to store for

each node its original ID so that we can perform

the reverse mapping. Furthermore, we need the func

tionality to unpack shortcuts. To support a simple

recursive unpacking routine, we store the ID of the

middle node of each shortcut (see 2.2). We distin

guish between internal and external shortcuts, where

the middle node is stored in the same block as the

shortcut or not. Expanding an external shortcut might

require an additional block read. To accelerate the pathunpacking, we refine the approach of Delling et al.

(2009) to store explicit descriptions of the paths under

lying the external shortcuts. A new feature is that we

exploit that a shortcut can contain other shortcuts, and

we do not need to store its path description again.

4. Dynamic ScenarioMany applications do not deal with a mere static

graph. Small changes take place over time and the

CH needs to be updated to remain correct. In such

cases, rebuilding the complete CH is often too timeconsuming. Here, we present an approach that effi

ciently processes a small amount of changes in the

edge set, i.e., insertion and deletion of edges as well

as changes of edge weights.


8/18


Transportation Science 46(3), pp. 388^04, 2012 INFORMS

Processing the Changes. The most time-consuming

part of the CH precomputation is the node order

ing. Because we only deal with a small amount of

edge changes, we keep the original node order. Instead

of recontracting the whole graph, we update exist

ing shortcuts to comply with the changes and then

identify the subset U of nodes whose contraction has

to be repeated to add new shortcuts. Certainly, the

recontraction of the other nodes V\L7 is unnecessary

because no new shortcuts have to be added.

Updating Existing Shortcuts. For each changed

edge (u, w), we find all shortcuts containing (u, w) to

delete them or adjust their weight. Then, only valid

shortcuts remain in the graph.

We process all changed edges except new edges,

which are never part of an existing shortcut. Let

(u, w) eE* be an edge or shortcut in the search graph;

see 2.2. Because u < w, (u, w) can only become partof other shortcuts if, during the contraction of u,

a shortcut (v,u,w) is added. This shortcut may be

contained in other shortcuts so that adepth-first search

from (u, w) (Algorithm 2) will find all shortcuts (z, y)

containing (u, w). To identify the shortcuts correctly,

we must store the middle node. Also, (z,y) may be

either stored in E* with z in case z


9/18



few queries using a simple Dijkstra's algorithm. In the

mobile scenario, we are therefore interested in tech

niques that only take changes into account that affect

the queries.

Iterative Routing. The most common change in the

edge set is increasing the weight of an edge, e.g., introducing a traffic jam. Schultes (2008) observed that a

lengthened or deleted edge can only change the result

of ans-t query if it is par t of the original short est s-t

path. Therefore, this kind of update can be handled in

a way that ensures that only increments important to

the query are processed.

We repeat the query until the shortest path does

not differ from the shortest path of the previous itera

tion. Initially we only use all new or shortened edges

to determine new seed nodes. Deleted or lengthened

edges are only considered if they are on a shortest

path of any previous iteration. This can greatly reduce

the amount of lengthened and deleted edges that

have to be processed. To identify edge changes on the

shortest path, we have to unpack it after each query.

Usually very few iterations are required to compute

the correct result.

This approach is independent of the speedup tech

nique applied and can be used whenever the time to

process changes outweighs the time to perform sev

eral queries.

Handling Seed Nodes. In the mobile scenario we

cannot afford to recontract nodes. Instead, we ensure

that the backward search of the query finds all cur

rently known seed nodes on the shortest path. If the

seed nodes are found on the shortest path, no addi

tional shortcuts skipping these nodes are necessary.

To achieve this we first determine the set of nodes

reachable from the seed nodes by one or more edges

(v, u) in G* with f(i>, u) = true . We add the edge

(u, v)with \,(u, v) := true to such a node u inG*, even

though v < u. This enables the backward search to

find the shortest path to any seed node because now

every edge usable by the forward search can also beused by the backward search. Schultes (2008) used a

similar technique to make queries unidirectional.

We do not have to completely repeat the search for

reachable nodes in G* in each iteration. It suffices to

process the edge changes added in this iteration. Fur

thermore, if we keep track of all nodes reachable in

the last iteration we can prune the search for new

nodes quite early on. As a result, most of the addi

tional edges get added to G* in the first two iterations.

Data Structures: The additional data for each edge,

witness data and middle node, is directly stored

with the associated edge. We use additional volatile

data structures next to our read-only graph to store

the changed edges, affected shortcuts, and edges

inserted in G*.

6. ExperimentsOur programs were written in C+-h No libraries

except for the C++ Standard Template Library were

used to implement the algorithms. To obtain a robust

implementation, we include extensive consistency

checks using assertions and perform experiments

that are checked against reference implementations,

i.e., queries are checked against Dijkstra's algorithm.

6.1. Experimental Setting

Environment. Our experiments were done on one

core of a single AMD Opteron Processor 270 clocked

at 2.0 GHz with 8 GB main memory and 2 x 1 MB

L2 cache, running SuSE Linux 10.3 (kernel 2.6.22). For

the mobile scenario, we used a Nokia N800 Inter

net Tablet, equipped with 128 MB of RAM, and a

Texas Instruments OMAP 2420 microprocessor, which

features an ARM11 processor running at 400 MHz.

We used a SanDisk Extreme III SD flash memory

card with a capacity of 2 GB; the manufacturer states

a sequential reading speed of 20 MB/s though the

device limits this to 8 MB/s. The operating system is

the Linux-based Maemo 4.1 in the form of Internet

Tablet OS2008 4.2008.30-2. The programs were com

piled by the GNU C++ compiler 4.2.1 using opti

mization level 3.

Instances. For most practical applications, a travel

timemetric is most useful; i.e., the edge weights corre

spond to an estimate of the travel time that is needed

to traverse an edge. In order to compute the edge

weights, we assign an average speed to each road

category.

6.2. Main Instance

Most of our experiments were done on a road

network of Western Europe having 18,029,721 nodes

and 42,199,587 directed edges. The countries

Austria, Belgium, Denmark, France, Germany, Italy,

Luxembourg, the Netherlands, Norway, Portugal,

Spain, Sweden, Switzerland, and the UK are represented. We usually refer to it as Europe and it has

been made available for scientific use by the company

PTV AG. For each edge, its length and its road

category are provided. There are four major road cate

gories (motorway, national road, regional road, urban

street), which are divided into three subcategories

each. In addition, there is one category for forest

and gravel roads. The assigned speeds in this order

are 130, 120, 110, 100, 90, 80, 70, 60, 50, 40, 30, 20,

10 km/h.

6.3. Additional Instances

In addition, we also performed some experiments

on two other road networks. A publicly available

version of the continental U.S. road network, which


10/18



has 23,947,347 nodes and 57,708,624 directed edges,

was obtained from the TIGER/Line Files. These were

provided by the U.S. Census Bureau (2002) (USA)

and distinguish between four road categories with

assigned speeds of 100, 80, 60, 40 km/h. The com

pany ORTEC provided a new version of the European

road network (Neiv Europe)with 33,726,989 nodes and

75,108,089 directed edges for scientific use. Addition

ally to Europe, it covers the Czech Republic, Finland,

Hungary, Ireland, Poland, and Slovakia. It distin

guishes between motorways; multiple and single lane

A and B roads; regional, local, and other roads out

side/inside cities; delivery roads; pedestrian zones,

and ferries. We used the rather slow ORTEC car speed

profile that assigns speeds of 87, 84/77, 73/63, 60/53,

50/40, 37/27, 23/17, 13/10, 8, 5, 2 km/h.

Preliminary Remarks. Unless otherwise stated, the

experimental results refer to the scenario where the

road network of Europewithtravel timemetric is used,

and only the shortest-path length is computed without

outputting the actual route.

When we specify the memory consumption, we

usually give the overhead, which accounts for the

additional memory that is needed by our approach

compared to a space-efficient unidirectionalimplemen

tation of Dijkstra's algorithm. This overhead is always

expressed in "bytes per node."

6.4. MethodologyTo calculate the average query time, we pick source-

target pairs uniformly at random. Unless otherwise

stated, we perform 100,000 queries.

For use in applications it is unrealistic to assume a

uniform distribution of queries in large graphs such

asEuropeor the USA. Therefore, we also measurelocal

querieswithin the big graphs . We choose random sam

ple points s and for each power of two r = 2k, we use

Dijkstra's algorithm to find the node t with Dijkstra

rank rks(t) = r. The Dijkstra rank rks is the order

in which the nodes were settled during the search

starting at node s. By plotting the resulting statisticsfor each value r 2*, we can see how the perfor

mance scales with a natural measure of difficulty of

the query. We represent the distributions as a box-

and-whiskers plot: each box spreads from the lower

to the upper quartile and contains the median, and

the whiskers extend to the minimum and maximum

value omitting outliers, which are plotted individu

ally. Such plots are based on 1,000 random sample

points s.

We can obtain a per-instance worst-case guarantee,

i.e., an upper bound on the search space size forany possible point-to-point query for a given fixed

graph G. We do this by executing a forward search

and a backward search from each node of G until the

priority queue is empty; no abort criterion is applied.

For the mobile scenario, we distinguish between

four different query types:

1. cold: After each query, clear the cache. This way,

we can determine the time that is needed for the first

query after the program is started and has an empty

cache.

2. warm: Perform two experi ment s with different

sets of s-t pairs in a row. We measure only the second

one to determine the average query time when the

device has been in use for a while.

3. recompute: We have pairs of queries. We only

measure the second one and clear the cache after each

pair. The second query has the same target node but

another source node: We chose a random neighbor of

a random node on the shortest path of the first query.

4. w/o I/O: Select 100 random source-target pairs.

For each pair, repeat the same query 101 times; ignore

the first iteration when measuring the running time.This way, we obtain a benchmark for the actual pro

cessing speed of the device when no I/O operations

are performed.

For practical scenarios, the first and the third query

type are most relevant; the second query time is clos

est to the situation reported in related work.

6.5. Parameters

Despite the simplicity of the description of CHs,

there are many parameters, i.e., the coefficients of the

priority terms in the priority function for the nodeordering (2.3) and the local search limits for the

contraction (2.1). For our aggressive variant we select

parameters to minimize the query time and for our

economical variant, to minimize the product of query

time and preprocessing time. Additionally to updat

ing the neighbors, we always use lazy updates because

they decrease the query time more than they increase

the preprocessing time; the differences are around

15-20%. Our parameters have been determined by a

manual, systematic coordinate search. Figure 5 shows

the development of the average degree during node

20

15

10i

8

6

5

4

\...V"X

\ vb h ^ . v

\

1 hop

2 hops

3 hops

4 hops

5hops

- 6 hops

No hop limit

.tss r..-. \

x-vi ; . . . . . v

l * * ^ ^ * ^

, S ^

Figure

T 1 1 1 1 1 1 1 1 1 r0 2 5 10 20 50 100 200 400 800 1.600

Size of remaining graph/10.000

5 Average Degree Development for Different Hop Limits on

Europe


11/18



contraction for different hop limits. We see that for

hop limits below four, the average degree eventually

explodes. We choose limits for the average degree

that switch to a larger hop limit before this explosion.

We refer to Geisberger (2008) for an in-depth descrip

tion including a sensitivity analysis.

6.6. Standard Scenario

We start with evolving sets of priority terms and

search space limits to get a deeper insight into them;

see Table 1. The best performance in every column is

bold. Using theedge difference(letter E) as the sole pri

ority term yields a CH that already answers a query

in less than 1 ms. However, the preprocessing time

is still too large. Also regarding the cosfof contraction

as a priority term (letter S) results in more than two

times better node ordering time and 14 times better

hierarchy construction time. The imbalance betweenthe improvement of those two parts is because of the

additional local searches during the node ordering,

particularly the initialization of the priority queue,

which takes more than 30 minutes. So we limit the

local searches(letter L), improving the node ordering

time by an additional factor of four.

Adding thedeleted neighbors counter (letter D) accel

erates the query time, whose average is below 200

/AS. The algorithm in Line EDSL is a simple combina

tion with improved preprocessing, fast query times,

and negative space overhead for shortest path distance

calculation. We can achieve negative space overhead

because in a CH we need to store an edge only with

one of its endpoints, even if the edge is bidirected.

Using the original edges term (letter O) as unifor

mity term decreases preprocessing time and space but

increases query time compared to the deleted neigh

bors term. To significantly decrease the preprocess

ing time, we introduce a hop limit of five to the local

searches, leading to a two times better node ordering

time. Applying staged hop limits (digits 1235) shrinks

the preprocessing time below 10 minutes. Replacing

thedeleted neighbors counter by theoriginal edgesterm

(letter O) further improve preprocessing, query, and

space overhead (Line EOS1235, priority function =

190E + 600 O + S). This is our our economical vari-

ant. Its low preprocessing time of 7.5 minutes and the

fast query of about 200 /ASprovide the best balance.

To further decrease the query time, we first exchange

the current uniformity term to take the square root of

Voronoi region sizes (letter V) into account. We com

bine that with the original edges term (letter O) and

add a priority term to estimate thecost ofqueries(let

ter H) (Line EVOSHL, priority function= 190E+ 60

V+ 7 0 O + S+ 14 5H ) . This leads to ouraggressivevari-

ant, having 29% faster query time then the economical

variant and a speedup of about 40,000 compared to

Dijkstra's algorithm. However we need to invest moretime into preprocessing.

Outputting Complete Path Descriptions. Needs

an average of 323 /ASfor the aggressive variant and

321 /ASfor the economical variant. These unpack

ing times are the fastest we have seen when no

completely unpacked representations of shortcuts are

used (see 3). Because we store the middle node, the

hierarchy construction and query time increases up to

13% and the space overhead reaches 6.2 B/node and

10.3 B/node, respectively. The comparatively large

space overhead is because we even use 12 B/nodefor non-shortcuts. If we would implement a more

sophisticated version with only 8 B/edge for non-

shortcuts, we would achieve a space overhead of only

1.2 B/node for the aggressive variant.

Local Queries. Because random queries are unre

alistic for large graphs, Figure 6 shows the distribu

tions of query times for various degrees of locality.

We see good query performance over all Dijkstra

Table1 Performance ofVarious Node Ordering Heuristics

Node ordering Hierarchy Query Nodes Nonstalled Edges Space overhead

Method [s] construction [s] [MS] settled nodes relaxed [B/node]

E 13,010 1,739 670 1,791 1,127 4,999 -0.6

ES 5,355 123 245 614 366 1,803 -2.5

ESL 1,158 123 292 758 465 2,169 -2.5

EDSL 1,414 165 175 399 228 1.335 -1.6

E0SL 1,110 145 222 531 313 1.802 - 3 0

ECO.

EDS5 65? 99 213 462 256 1,651 -1.1

EDS1235" 545 57 223 459 234 1.638 1.6

E0S12353 451 48 214 487 275 1,684 0.6

AG6R.

EDSHL 1,648 199 173 385 220 1,378 -1.1

EVSHL 1,627 170 159 368 209 1,181 -1.7

EVOSHL 1,644 165 152 356 207 1.163 -2.1

ahop@degree limit: [email protected], 2@10, 3@10,5.


12/18


Transportati on Science 46(3), pp. 388-404, 2012 INFORMS

400

300-

I 200

u3

o

100-

0

B CH aggressive

D CH economical ^

o a ? " . ,.9. 4 ; ! !..

o 8 o : ; o' ?rt '- r g *- OT '".-v--m o o ' i

c# a; 8

T i i i i i i i i i i i i r

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

Dijkstra rank

Figure6 Performance of Queries,Where the Target Is Chosen by the

DijkstraRank from the Source

ranks and small fluctuations. This is further under

lined in Figure 7 where we give upper bounds for the

search space size ofallnxn possible queries. We see a

superexponential decay of the probability to observe a

certain search space size and a maximal search space

size bound less than 2.4 times the size of the average

actual search space sizes (see also Table 1).

6.7. Comparisons

Speedup techniques for routing in road networks areusually compared against each other in the three-

dimensional space of preprocessing time, space over

head, and query time. There are many Pareto-optimal

techniques x; i.e., where for each other technique y,

there is a dimension for which x is better than y.

However, CHs take a particularly strong position. We

100

I _

I io-2

a io-

S 10

3

10"

10 12

\A..

\

\

\

JCH aggr.

CH eco.

1 I I I " I I l | ' I ' I ' ~ f0 200 400 600 800 1.000 1.200 1.400

Maximum847 1322

Settled nodes

Figure7 Upper Bound for the Worst Percentages of Queries

compare the most successful speedup techniques in

Table 2. A technique is dominated by CHs if CH is

better in every dimension. The best performance in

every column is bold. For further algorithms, we refer

to Delling et al. (2009) and Bauer et al. (2010b). We

took the timings from several other papers that used

roughly the same hardware, so we can only do a

rough comparison. Still, all techniques either use CHs

or are clearly dominated by a technique using CHs.

CHs provide the lowest space overhead, even lower

than Dijkstra's algorithm, and the fastest preprocess

ing times except for Dijkstra's algorithm. There are

two kinds of algorithms with faster query times. First,

there are combinations of hierarchical techniques and

goal-directed techniques, of which the most success

ful ones are all based on CHs. Second is TNR, whose

precomputation also relies on the CH node order for

best results (see 7). The combination of TNR + AFcurrently provides the best query time.

6.8. Other Inputs

We also tested our aggressive and economical vari

ant on different road networks and metrics to exam

ine the robustness of CHs using the same parame

ters as for the Europe road network (see Table 3). We

can expect additional improvements if we were to

repeat the parameter search; see 6.5. The USA (Tiger)

graph shows slightly larger preprocessing times than

the Europe graph but faster query times. The New

Europegraph is a larger network thus requiring more

preprocessing time. For the distance metric, where

each edge represents the driving distance, there are

no real fast routes that could be preferred over other

slower routes. It is less clear how to identify impor

tant nodes and more shortcuts are necessary. Note

that the experiments on the distance metric ofEurope

were performed on a subgraph, the largest strongly

connected component consisting of 18,010,173 nodes

and 42,188,664 edges because of availability.

6.9. Mobile ScenarioUnless otherwise stated, our experiments refer to the

case that the path-unpacking data structures exist but

are not used and 1,000 queries are performed. Instead

of giving the space overhead, the space consumption

includes the graph itself. Note that the query times

always include the time needed to map the origi

nal source and target IDs to the corresponding block

IDs and node indices, whereas figures on the mem

ory consumption do not include the space needed for

the mapping. The space consumption for the map

ping is excluded because in most practical applica

tions more sophisticated mappings are needed: For

example, street names are mapped to edges.

In the following we use a block size of 4 KB, which

was found using experiments with block sizes from


13/18

Geisberger, Sanders, Schultes, and Vetter: Contraction HierarchiesTransportation Science 46(3), pp. 388-404, 2012 INFORMS 399

Table 2 Comparison of Various Speedup Techniquesin theThree-Dimensional Space ofPreprocessing Time, Space Overhead, andQuery Time

Data from

Preprocessing Query

UsesCHMethod Data from Time [min] Overh. [B/n.] Settled nodes Time [ms] UsesCH Dominated by CH

Dijkstra'' Baueretal. (2010b) 0 0 9,114,385 5,591.6

Bidir. Dijkstra* Baueretal. (2010b) 0 0 4,764,110 2,713.2

Economical CH This paper 8 0.6 487 0.21 /

Aggressive CH This paper 27 -2.1 356 0.15 /

ALT, 16 landmarks' Goldberg,Kaplan, and Werneck (2009) 13 70 82,348 120.1 /

ALT. 64 landmarks* Delling and Wagner (2007) 68 512 25,234 19.6 /AFC Hilger et al. (2009) 2,156 25 1,593 1.1 /

REAL" Goldberg,Kaplan, and Werneck (2009) 103 36 610 0 91 /HH Schultes (2008) 13 48 709 0 61 /HNR Schultes (2008) 15 2.4 981 0.85 /

SHARC3

Bauer and Delling (2009) 81 14.5 654 0.29 /

Bidir. SHARC* Bauer and Delling (2009) 158 21.0 125 0.065 / "

CAIP Baueretal. (2010b) 11 154 1,394 1.34 /

Eco. CH + AF3 Baueretal. (2010b) 32 0.0 111 0.044 /

Gen. CH + AF* Baueretal. (2010b) 99 12 45 0.017 /

Partial CHa

Baueretal. (2010b) 15 -29 965,018 53.63 /TNR This paper 46 193 N/A 0.0033 / TNR + AF Baueretal. (2010b) 229 321 N/A 00019 /

'2.6 GHz AMD Opteron, SuSE Linux 10.3, 16 GiBofRAM,2 x1 MiBof L2 cache.

"2.4 GHz AMD Opteron, Windows Server 2003,16 GiBofRAM,2MiBof L2cache.c2.2 GHz AMD Opteron, SuSE Linux 9.1,4GiBofRAM, 1 MiBofL2 cache.

"Dominated by CH+AFofBaueretal. (2010b).

"Uses CHstocompute transit nodes.

1 KB to 64 KB. This block size is optimal with respect

to both space consumption and query time. We use a

cache size of 64 MB. Additional experiments indicate

that reducing it to 32 MB has negligible effect on theperformance of warm queries. Even only 256 KB of

cache are sufficient to achieve the performance of our

cold queries.

Table 4 gives an overview of the external-memory

graph representation. The columns give the number

of nodes, the number of edges in the original graph

and in the search graph, the number of graph-data

blocks (without counting the blocks that contain pre-

unpacked paths), the average number of adjacentblocks per block, the numbers of internal edges, inter

nal shortcuts and external shortcuts as percentages

of the total number of edges, the time needed to

pre-unpack the external shortcuts and to build the

external-memory graph representation (provided that

Table3 PerformanceofDifferent Graphs and Metrics

TRAVEL TIME DISTANCE

Europe USA Tiger New Europe Europe USA Tiger

Aggr. Eco. Aggr. Eco. Aggr. Eco. Aggr. Eco. Aggr. Eco.

Node ordering [s] 1,644 451 1,684 626 2,420 657 5,459 2,853 3,586 1,775

LENGTH

Hier. construction [s] 165 48 181 61 646 72 264 137 255 113

Query[/xs] 152 214 96 180 213 303 1,940 2,276 645 1,857

Nodes settled 356 487 283 526 439 629 1,582 2,216 1,081 3,461

Nonstalled nodes 207 275 157 309 247 351 658 962 485 2,100

Edges relaxed 1,163 1,684 885 1,845 1,732 2,600 15,472 19,227 7,905 27,755

Space overh. [B/node] - 2 . 1 0.6 -2 . 6 -1 . 3 -2.0 -0.3 0.6 1.5 -1.5 -0.9

PATH

Hier. construction [s] '76 54 19' 68 673 82 287 152 269 122

Query[/xs] 1 r*C 238 107 198 243 345 2,206 2,615 721 2,121Expand path [/is] 323 321 1,105 1,107 972 953 798 792 1,268 1,336

Space overh. [B/node] 62 10.3 5.8 7.8 5.6 8.5 10.2 11.7 7.4 8.3

Edges 21 23 21 26 21 24 21 29 22 40

Edges expanded 1,370 1,369 4 ,54 8 4,548 4,139 4,136 3,291 3,291 5,128 5,128


14/18



Table4 Building the Graph Representation

,

[x106]

|f|

[x106]Id

[x106] #Blocks

#Adj.

blocks

Int.

edges(%)

Int.

shcs.(%)

Ext.

shcs.(%)

Time

[s]

Space

[MB]

Europe

USA

New Europe

18.0

23.9

33.7

42.2

57.7

75.1

36.9

49.4

65.7

52,107

80,099

103,371

91

8.4

8.3

70.6

69.2

70.3

32.2

33.7

32.7

7.7

8.0

7.5

123

186

210

275

400

548

the search graph is already given), and the total

memory consumption including pre-unpacked paths.

Building the blocks is very fast and can be done

in about two to four minutes. Although the given

memory consumption already covers everything that

is needed toobtain very fast query times (including

path unpacking), we need 30%less space than the

original graph would occupy in astandard adjacency-

array representation in thecaseofEurope.Mostof the

savings come from using less bits than thenaive rep

resentation, but wealso save space because CHs need

to store bidirectional edges onlyat one of theirend

points.

The results for the four query types are repre

sented inTable 5.Onaverage,a random queryhas to

access 39blocks in caseof theEuroperoad network.

When thecache has been warmed up, most blocks

(in particular the ones that contain very important

nodes) resideinthe cachesothatonaverage less than

four blocks have to be fetched from external mem

ory. This yields a very good query time of 10.5 ms.Recomputing theoptimal path using the same target

but a different source nodecan bedone in 14.3 ms.

As expected, thebottleneck of ourapplication is the

accessto theexternal memory: if allblocks hadbeen

preloaded, a shortest-path computation would take

only about5.8 msinsteadof the56.3ms that include

the I /O operations. For comparison, on aPC (our

2 GHz Opteron),thesame code runs about nine times

faster (0.64 ms)this isbasically thespeed difference

between the CPUs. The code for the standard sce

nario (6.6) is another four times faster (0.15 ms)this is the overhead because of thecompressed data

structure. Using thenaive data structurein themobile

scenario would likely result in one block accessper

settled node, resulting inabout a seven times larger

query time.

Path Unpacking. InTable6, we compare five dif

ferent variantsofpath (not-)unpacking, using thefirst

query type (cold) in each case. First (a), we store

no path data at all. This makes thequery very fast

because more nodes fit into a single block. How

ever, with this variant, we can only compute the

shortest-path length. For all other variants, we also

store the middle nodes of the shortcuts in the data

blocks. This slows down the query even if we do

not use the additional data (b).After having computed theshortest-path length, getting thevery first

edgeof thepath (which isuseful togenerate thevery

first driving direction) is almost for free (c). Com

puting the complete path takes considerably longer

if we do not use pre-unpacked path data (d). Pre-

unpacked paths (e) somewhat increase the memory

requirements but greatly improve the running times.

6.10. Mobile Dynamic Scenario

Weuse the same settings as in the mobile scenario.

Because our algorithm needs tounpack the shortest

path forevery query,wedecided touse pre-unpacked

paths.InTable7 weassesstheperformance ofmobile

dynamic CHs. Wecanrestrict ourselves to a compari

son with dynamic HNR because SchultesandSanders

(2007) showed that dynamic HNR is better than all

previous dynamic speedup techniques. Query times

are only given forCHs because there existsnomobile

implementation of HNR. We only changed motor

ways because lower ranked street categories had lit

tle to noimpacton thequery performance. Changing

only oneedge yields a lower performance compared

to the mobile scenario. This is essentially caused bythe additional data that is stored in the graph.For

a small amount of random changes, thequery times

scale quite well,buttheyget out ofhand when chang

ing more than 1,000 edges.Themost importan t parts

Table6 Comparison Between Different VariantsofPath Unpacking

Table5 Query PerformanceforFour Different QueryTypes

(a) Nopath data(b) Length only

(c) First edge

(d) Complete path

(e) Compl. path (fast)

Europe USA New Europe

Cold Warm Recomputew/oI/O

Time

[ms] (a) Nopath data(b) Length only

(c) First edge

(d) Complete path


Time

[ms]

45.756.3

56.4

341.7

73.1

Space

[MB]

140203

203

203

275

Time

[ms]

35.943.6

43.8

691.3

65.6

Space

[MB]

213312

312

312

400

Time Space

[ms] [MB]

52.1 257

Settled Blocks Time Blocks Time Blocks Time

nodes read [ms] read [ms] read [ms]

w/oI/O

Time

[ms] (a) Nopath data(b) Length only

(c) First edge

(d) Complete path


Time

[ms]

45.756.3

56.4

341.7

73.1

Space

[MB]

140203

203

203

275

Time

[ms]

35.943.6

43.8

691.3

65.6

Space

[MB]

213312

312

312

400

Time Space

[ms] [MB]

52.1 257

Europe

USA

New Europe

280 39.2 56.3 3.6 10.5 7.9 14.3

223 30.1 43.6 4.4 9.8 6.1 13.1

351 44.5 65.2 4.6 15.8 8.5 17.2

5.8

4.1

8.8

(a) Nopath data(b) Length only

(c) First edge

(d) Complete path


Time

[ms]

45.756.3

56.4

341.7

73.1

Space

[MB]

140203

203

203

275

Time

[ms]

35.943.6

43.8

691.3

65.6

Space

[MB]

213312

312

312

400

65.3 403

517.9 403

88.7 548


15/18



Table7 Query Performance of the Dynamic Mobile Scenario Dependingon theNumber ofEdge Weight

Increases(x10) on Motorways

Search space

dynamic CH (dynamic HNR)Affected Cold Recompute AverageAffected Cold Recompute Average

|Changeset| queries(%) Touched nodes Relaxed edges [ms] [ms] #iterations

1 0.4 349 (1,337) 1,190 (9,416) 94.4 23.2 1.0

10 5.7 397 (1,546) 1,320 (10,584) 134.1 23.6 1.1

100 40.0 1,311 (3,249) 4,130 (19,726) 184.5 30.4 1.4

1.000 83.7 6,573 (19,790) 23,459 (95,341) 698.6 74.0 27

10,000 97.9 70,179 (396.380) 297,539 (1,609,505) 14,871.4 930.5 7.9

of the hierarchy have been distorted by thechanges.

Dynamic CHsshow a behavior similar to dynamic

HNR when comparing thesearch space. Theydoout

perform them in every test though. Figure 8 shows

the effect on local queries. The column "affected

queries" gives thepercentageof queries whose shortest path isaffected by thechanges. Also,wegivethe

number of average iterations for the cold case. Long

distance queries aredisproport ionately affected:The

shortest path consists mostly of important edgesand

therefore more changes must be taken into account.

Because of this ouralgorithm needs more iterations

for them. Furthermore, some queries are especially

affected by thechanges andneed substantially more

time than the average query.

7. ApplicationsMany-to-Many Shortest Paths. Instead of a point-

to-point query, thegoal of many-to-many routing is

to find alldistances between a given setSof source

nodesand setTof target nodes. Knopp et al.(2007)

developed an efficient algorithm based on HHs to

Table8 Time inSeconds Required toCompute a \S\x |5|Distance

Tables.The TimesforHH and HNR Are from Schultes (2008).

The Times for Dijkstra's Algorithm AreExtrapolated from

Table2.

\S\ 100 500 1,000 5.000 10.000 20,000

Dijkstra 559.1 2,796.5 5.591.0 27,955.0 55.910.0 111,820.0

HH 0.6 1.7 3.3 26.3 76.6 247.7

HNR 0.4 0 8 1.4 8.5 23.2 75.1

CH 0.4 0.5 0.6 3.3 10.2 36.6

compute them. Replacing HHs by CHsimprovesthe

performance, asTable 8shows.For ourexperiments,

we do not use theaggressive variantbut themethod

EVSHL from Table1becauseitdisplays slightly better

performance.

Transit-Node Routing. Weemploy themethod of

Geisberger (2008) to use the nodes designated the

most important by the node ordering to define the

sets of transit nodes. Compared to generousTNR

based on HHs bySchultes (2008),CHs improve pre

processing time from 75>46 min,query time from

woo

2.000-

8

| 1.500-

O 1.000-

500

Cold

Recompute

A e , &&. * * . * . .*, ". . TRQ.

2 H jli

2.500

2,000

1.500

500

0

Dijkstra rank

Figure8 Local Queries After 1,000 Changed Edges


16/18

402



4.3 3.3 /AS and space consumption from 247-*

193 B/node. We have not yet implemented a prepro

cessing completely based on CHs, so it is too early to

judge the whole effect of CHs on preprocessing time,

but we hope for additional improvements.

8. ConclusionThe key features of CHs are their simple concept

and their practicability. The simple query algorithm

together with the highly engineered preprocessing

form an efficient basis for many hierarchical rout

ing methods in road networks. We have currently the

fastest hierarchical, Dijkstra based routing algorithm

with preprocessing times of a few minutes and query

times of a few hundred microseconds. Additionally, our

algorithm is the fastest implementation for the cal

culation of large distance tables and is the preferredhierarchical method to use in combination with goal-

direction when low preprocessing and query times

are desired. Our mobile implementation is, as far as

we know, the first implementation of an exact route

planning algorithm on a mobile device that answers

queries in a road network of a whole continent instan

taneously, i.e., with a delay that is virtually not observ

able for a human user. Furthermore, our algorithm is

simple to implement on a mobile device; our graph

representation is comparatively small (only a few hun

dred megabytes); and we efficiently handle increasesof edge-weights, e.g., caused by traffic jams. These

facts suggest an application of our implementation in

car navigation systems.

Contraction hierarchies also build the basis for rout

ing algorithms beyond a single static edge weight

function. Batz et al. (2009) successfully adapted CHs

totime-dependent road networks, where the travel time

depends on the departure time. Vetter (2009) pro

vides a parallel version, and Kieritz et al. (2010) a

distributed version. Geisberger (2010) researched CHs

on time-dependent timetable networks.And Geisberger,

Kobitzsch, and Sanders (2010) extend CHs to the flex

ible scenariowith two edge weight functions, where

the query returns the shortest path for a fixed ratio

between both functions. This ratio is fixed separately

before each query, but after preprocessing. Flexible

edge restrictions for CHs have been researched by

Rice and Tsotras (2010). A fast algorithm to solve the

one-to-all shortest path problem was presented by

Delling et al. (2010). It processes a CH using a GPU

to compute all distances within a few milliseconds.

Abraham et al. (2010a) studied the computation of

alternative routes and used CHs for a fast computa

tion. A first attempt to grasp the theoretical perfor

mance of shortest path speedup techniques, including

CHs, was published by Abraham et al. (2010b).

AcknowledgmentsIn part, the idea to use only node contraction for preprocessing was developed together with Daniel Delling. Partiallysupported by DFG grant SA933/5-1.

Appendix A. Fast Local SearchThe local search with hop limit described in 2.1 can beaccelerated by certain measures.

Fast Local One-Hop Search. To find witness paths consisting of just one edge, it is sufficient to scan through all outgoing edges of the source nodev e S. The one-hop searchmakes sense if lots of edges of the graph are shortest paths,as in a road network. In this case, it allows to contract asignificant amount of nodes without too many additionalshortcuts being added.

Fast Local Two-Hop Search. We implement a simple variant of the many-to-many shortest paths algorithm of Knoppet al. (2007). We associate a bucket b(x) := \(w,c(x,w)) \w T, (x, w) e ) with each node x > u. Computing

the nonempty b(x) is done by by scanning the incoming edges of all w e T. For v S we then computeSv(w) := min{c(v,x) + c(x,w) | (v, x) e ,(w, c(x, w)) b(x)\U\c(v, w)) by scanning the outgoing edges (v, x) of vand the bucketsb(x).

One-Hop BackwardSearch.To speed up a local search fromv eS with hop limita >3, we first perform a Dijkstra algorithm with (a - 1) hop limit resulting in distances 8V().Then we improve these to Sp(w) := minjS^w)) U[8v(x) +c(x, w) |(x, w) j by scanning the incoming edges ofweT. The distance limit for the forward search changes,and we now stop the search if the last settled node exceedsthe distance c(v, u)+ max(c(u,w)min(c(x,w) \ (x, w)) |(u, w)e , w ^ v).

Appendix B. Node Order SelectionMore details on the effect of the priority terms introducedin 2.3 are given below.

Edge Difference. For our implementation of the edge dif-ference, we used the difference in the space requirements.Note that we store twoedges (v, w) and (w, v) with thesame weight c(v, w) = c(w, v) as only one edge with twoadditional forward and backward flags. We could also usethe cardinality difference but this would ignore the spaceconsumption.

Contracting a node u can affect the edge differenceof node v that is arbitrarily far away, as we show inFigure B.l: The contraction of node v will require anew shortcut (xx,i/i), whereas before this shortcut wasnot necessary because of the witness path (xi,xt,...,xT,u,yr,... ,y2,yx). However, the neighbors of u are affectedthe most because they may get new incident edges.

If after the contraction of a node u, the priority of anode v changes that is not a neighbor of u, u may beextracted from the priority queue in a different order thandesired. Lemma 1 shows that under certain conditions, lazyupdates can reestablish the correct order.

LEMMA1. Wecontract allnodes incorrect order if(a) afterthe contraction of anode,allofits neighbors areupdated, (b)tlocal searches for witness paths areunlimited,(c) theedgediffenceis the the onlypriorityterm and has anonnegative coefficient,and(d)lazyupdates areused.


17/18

Geisberger, Sanders, Schultes, and Vetter: Contraction HierarchiesTransportation Science 46(3), pp. 388-404, 2012 INFORMS 403

Figure B.1 After the Contraction of Node uthe Edge Difference of

Node v in this Directed, Weighted Graph Changes

PROOF. The edge difference of a node v depends only on

the incoming and outgoing edges of v and on the existing

witness paths. After the contraction of a node u, the edges

only change for the neighbors of u. These changes are cov

ered by (a). Therefore, only existing wi tness p aths can affect

a node v that is not a neighbor of u. Because of (b), we will

not find a witness path after the contraction of uif there pre

viously was no witness path. Thus witness paths can only

vanish, leading to an increasing priority (c). Lazy updates

(d) will adjust those priorities in time.

We cannot directly apply Lemma 1 to our preprocessing

because we have search limits. However, if our limits are

sufficiently large, we can expect only few deviations from

the projected node order.

Uniformity Deleted Neighbors:This quantity can be main

tained correctly by either lazy update or by updating the

neighbors of a contracted node.

Voronoi Regions: When v is contracted, its neighboring

Voronoi regions will "eat up" its Voronoi region R(v).

Maue, Sanders, and Matijevic (2006) describe how the nec

essary computations can be made using 0(|R(i>)l) steps

of Dijkstra's algorithm. Assuming that we always con

tract Voronoi regions of size 0(average region size), the

total number of Dijkstra steps for maintaining the Voronoi

regions is 0(n logn); i.e., computing them is reasonably effi

cient. Because they can only grow, lazy updates ensure that

the priority queue works correctly w.r.t. this term of the

priority function.

Cost of Contraction. For Dijkstra searches, we include the

number of settled nodes as priority term, for the fast local

one-hop search we use the number of scanned edges, and

for the fast local two-hop search we use the number ofbucket entries plus the number of scanned edges during the

one-hop forward search. Perfectly updating the cost of con

traction would be difficult because the contraction of any

node in a search tree of the local search can affect it.

Lemma 2 ext ends Lemma 1 to addit ional priority terms;

we omit the proof.

LEMMA 2. Lemma 1 holds if additionally the uniformity

terms and the cost of queries term are used with nonnegative

coefficients.

Appendix C. Mobile Dynamic Data StructuresThe additional data for each edge, witness data and middle

node, is directly stored with the associated edge. To com

press the safety of the witness data, we use the same scheme

employed to compress the weight of an edge. Furthermore,

we reduce the size of the seed sets by storing only (u, Sj) if

two elements (u, 8,), (u, 82),5,


18/18

Documents

CH Introduction