Contraction hierarchies

In applied mathematics, the method of contraction hierarchies is a technique to speed up shortest-path routing by first creating precomputed "contracted" versions of the connection graph. It can be regarded as a special case of "highway-node routing".

Contraction hierarchies can be used to generate shortest-path routes much more efficiently than Dijkstra's algorithm or previous highway-node routing approaches, and is used in many advanced routing techniques. It is publicly available in open source software to calculate routes from one place to another.

The algorithm

In general, scalable map routing algorithms have two distinct phases: preprocessing of the original graph (which may take more than an hour to finish) and queries (less than a second). Contraction hierarchy (CH) is an extreme case of "hierarchy" approach, which generates a multi-layered node hierarchy in the preprocessing stage. In a CH, every node in the graph is represented as its own level of hierarchy. This can be achieved in many ways; one simple way is simply to label each node in order of some enumeration from 1 to N, where N is the number of nodes in the graph. More sophisticated approaches might consider the type of road (highway vs minor road, etc.).

CHs have been extended to a three phase setup called CCH that supports flexible edge weights. In this setup there is a slow (hours) preprocessing phase, a reasonably fast (about a second) customization phase and a very fast (milliseconds) query phase. In the preprocessing phase only the graph but not the edge weights are revealed to the algorithm. In the customization phase the weights are revealed and in the query phase shortest paths are computed. Changing the weights of the graph requires only rerunning the customization phase but not the preprocessing phase. It is therefore possible to exchange the edge weights within seconds. This setup enables live-traffic updates and routes can easily be adjusted to user specific preferences. An open-source CCH implementation is available.

Preprocessing

Levels/order of nodes in CH can be arbitrary. The main point is that shortcuts are introduced when necessary. To understand when a shortcut is necessary, one has to understand the searching algorithm. The searching algorithm (bidirectional Dijkstra's algorithm) in this case is constrained so that it only relaxes edges that are connected to the nodes that are higher in CH than the current node in one direction, and vice versa. With this constraint, the algorithm would not find certain shortest paths in the unprocessed network, and because of that we need to introduce new edges to the graph that represent existing shortest paths that the algorithm doesn't take into consideration. Not all shortest paths need to be restored as new shortcut edges: it's enough to take in consideration adjacent nodes of some node that are higher in CH (since the sub-path of some shortest path is itself a shortest path). Algorithmically:

• Add order/levels to the graph nodes
• For each node, respecting order, get its adjacent nodes of higher order and find if shortest path between each pair of them goes through current node and if it is, add shortcut edge

Let's say that we take in consideration just 2 adjacent nodes (from, in general, n of them):

From this picture, if shortest path from v to w goes through node u that is lower in CH, a new edge has to be added the CH graph so that the shortest paths that the searching algorithm takes into consideration are preserved.

The weight of the new edge is equal to the path distance from v to w.

When preprocessing of the original graph is done, we have a CH graph which consists of the original graph with node ordering added and with shortcut edges introduced.

Querying

For the searching algorithm, bidirectional Dijkstra's algorithm is used. It is classical Dijkstra's algorithm with some modifications. The algorithm searches from the starting node in one direction and from the ending node in other direction (this is classical bidirectional Dijkstra's algorithm), but it relaxes edges that are directed toward higher hierarchy nodes in one direction (essentially it expands towards higher hierarchy nodes) and edges that are directed toward lower hierarchy nodes in the other direction. If the shortest path exists, those two searches will meet at some node v. A shortest path from s to t consists of paths from s to v and from v to t.

The shortest paths found by this algorithm have the particular form:

$\langle s=u_{0},u_{1},\ldots ,u_{p}=v,\ldots ,u_{q}=t\rangle ,\quad p,q\in \mathbb {N}$

$u_{i}<u_{i+1},\quad i\in \mathbb {N} ,i<p$

$u_{j}>u_{j+1},\quad j\in \mathbb {N} ,p\leq j<q$

A path found by a query is the shortest path because of the preprocessing stage. In the preprocessing stage we transformed the graph by introducing shortcut edges which are used to compute the shortest path, but the resulting path is not the actual shortest path through the original graph.

In order to return the final result, the shortcut edges need to be postprocessed to give the actual path they represent in the original graph.

In order to demonstrate that this algorithm retrieves shortest paths, consider it by contradiction: let's assume (for forward search, identical thing stands for backward search) that there exists a path that is shorter than the one we found with this algorithm:

Let's say that at some point there exists a subpath that is shorter than the aforementioned path. Because the algorithm expands towards nodes that have higher order, the order of $u_{k}$ must be lower than the order of $u_{k-1}$ and $u_{k+1}$. Because of that fact, in the preprocessing stage, that path would be represented as a shortcut edge with equal length, and therefore no such path that is shorter than the one the algorithm found can exist.