Transit node routing
In applied mathematics, transit node routing can be used to speed up shortest-path routing by pre-computing connections between common access nodes to a sub-network relevant to long-distance travel.[1]
Transit node routing as a framework was established in 2007[1] and many concrete implementations have surfaced in the years after such as approaches using grids, highway hierarchies[2] and contraction hierarchies.[3] Transit node routing is a static approach that requires pre-processing of pair-wise distances between important nodes in the graph (see below how those nodes are chosen). A dynamic approach has not been published.[4]
Intuition
![](http://upload.wikimedia.org/wikipedia/commons/thumb/4/4a/Transit_node_routing_intuition.gif/220px-Transit_node_routing_intuition.gif)
Long-distance travel usually involves driving along a subset of the road network such as freeways instead of e.g. urban roads. This sub-network can only be entered by using sparsely distributed access nodes. When compared to one another, multiple long-distance routes starting at the same location always use the same small amount of access nodes close to the starting location to enter this network. In the same way, similar target locations are always reached by using the same access nodes close to them. This intuition only holds for long-distance travel. When travelling short distances, such access nodes might be never used because the fastest path to the target only uses local roads.
Because the number of such access nodes is small compared to the overall number of nodes in a road network, all shortest routes connecting those nodes with each other can be pre-calculated and stored. When calculating a shortest path therefore only routes to access nodes close to start and target location need to be calculated.
General framework
- Transit node routing starts with a selection of transit nodes as a subset of all nodes of the road network.
- For every node dedicated sets of forward access nodes and backward access nodes are chosen from all transit nodes.
- Now, pairwise distances between transit nodes and distances between nodes and their corresponding access nodes are calculated and stored.
- A distance between two nodes can now be calculated as
Locality filter
Short routes between close start and target locations may not require any transit nodes. In this case, the above framework leads to incorrect distances because it forces routes to visit at least one transit node.
To prevent this kind of problem, a locality filter can be used. For given start and target locations, the locality filter decides, if transit node routing should be applied or if a fallback-routine should be used (local query).
Concrete instances
Transit node routing is not an algorithm but merely a framework for speeding up route planning. The general framework leaves open a few questions that need to be answered to implement it:
- How are transit nodes selected?
- How are access nodes chosen?
- Which locality filter should be used?
- How should local queries be handled?
The following example implementations of this framework answer these questions using different underlying methods such as grouping nodes in cells of an overlay grid[2] and a more sophisticated implementation based on contraction hierarchies.[3]
Geometrical approach using grids
In a grid-based approach, the bounding square of all nodes is equally subdivided into square cells.
How are access nodes selected?
![](http://upload.wikimedia.org/wikipedia/commons/thumb/e/e1/Grid_based_transit_node_routing.png/220px-Grid_based_transit_node_routing.png)
For each cell , a set of access nodes can be found by looking at an inner area of 5x5 cells and an outer area of 9x9 cells around . Focusing on crossing nodes (ends of edges that cross the boundary of , or ), the access nodes for are those nodes of that are part of a shortest path from some node in to a node in . As access nodes for an arbitrary node all access nodes of are chosen (red dots in the image to the right).
How are transit nodes selected?
The set of transit nodes is exactly the union of all sets of access nodes.
Which locality filter should be used?
The way access nodes are selected implies that if source and target are more than four grid cells apart, a transit node must be passed on the shortest path and the distance can be calculated as described above. If they lie closer together, a fallback-algorithm is used to obtain the distance.
How should local queries be handled?
Local queries are only needed if start and target already lie close together, therefore every suitable shortest-path algorithm such as Dijkstra's algorithm or extensions thereof can be chosen.
Space requirements
The pre-computed distances between each node and the corresponding access node as well as the pairwise distances between transit nodes need to be stored in distance tables.
In the grid-based implementation outlined above, this results in 16 bytes of storage that is required for each node of the road graph. A full graph of the USA road network has 23,947,347 nodes.[5] Therefore approx. 383 MB of storage would be required to store the distance tables.
Using contraction hierarchies
How are transit nodes selected?
By definition, a contraction hierarchy moves important nodes (i.e. nodes that are part of many shortest paths) to the top of the hierarchy. A set of transit nodes therefore can be selected as the highest nodes of the contraction hierarchy.
How are access nodes selected?
Forward access nodes of a node can be found by running the upward-search of the contraction hierarchy starting at . During the upward-search, edges leaving previously found transit nodes aren't relaxed. When the search has no more upward nodes left to settle, those transit nodes that have been settled are the access nodes of . Backward access nodes can be found analogously.
Which locality filter should be used?
If the highest node of a shortest up-down-path in the hierarchy is not part of the set of transit nodes, then the query was local. This implies that neither the up-part of the path (beginning at the starting node) nor the down-part of the path (ending at the target node) can contain a transit node and there must be a common node in both paths. During the calculation of the access nodes, the search space (all visited nodes towards the top of the hierarchy) for each node can be stored without including transit nodes. When performing a query, those search spaces for start- and target node are checked for an intersection. If those spaces are disjoint, transit node routing can be used because the up- and down-paths must meet at a transit node. Otherwise there could be a shortest path without a transit node.
How should local queries be handled?
Local queries use the regular query algorithm of the contraction hierarchy.
See also
- Shortest path problem
- Hub labels
- Bidirectional search
- Highway dimension
References
- ^ a b Bast, H.; Funke, S.; Sanders, P.; Schultes, D. (2007-04-27). "Fast Routing in Road Networks with Transit Nodes". Science. 316 (5824): 566. Bibcode:2007Sci...316..566B. doi:10.1126/science.1137521. ISSN 0036-8075. PMID 17463281. S2CID 16559205.
- ^ a b Bast, Holger; Funke, Stefan; Matijevic, Domagoj; Sanders, Peter; Schultes, Dominik (2007-01-06), "In Transit to Constant Time Shortest-Path Queries in Road Networks", 2007 Proceedings of the Ninth Workshop on Algorithm Engineering and Experiments (ALENEX), Society for Industrial and Applied Mathematics, pp. 46–59, doi:10.1137/1.9781611972870.5, ISBN 9781611972870
- ^ a b Arz, Julian; Luxen, Dennis; Sanders, Peter (2013), "Transit Node Routing Reconsidered", Experimental Algorithms, Springer Berlin Heidelberg, pp. 55–66, arXiv:1302.5611, Bibcode:2013arXiv1302.5611A, doi:10.1007/978-3-642-38527-8_7, ISBN 9783642385261, S2CID 14371800
- ^ Schultes, Dominik; Sanders, Peter (2007), "Dynamic Highway-Node Routing", Experimental Algorithms, Lecture Notes in Computer Science, vol. 4525, Springer Berlin Heidelberg, pp. 66–79, doi:10.1007/978-3-540-72845-0_6, ISBN 9783540728443
- ^ "9th DIMACS Implementation Challenge: Shortest Paths". users.diag.uniroma1.it. Retrieved 2019-07-15.