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.
Transit node routing as a framework was established in 2007 and many concrete implementations have surfaced in the years after such as approaches using grids, highway hierarchies and contraction hierarchies. 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. 
Intuition.
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.
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:
The following example implementations of this framework answer these questions using different underlying methods such as grouping nodes in cells of an overlay grid and a more sophisticated implementation based on contraction hierarchies. 
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?
For each cell formula_10, a set of access nodes can be found by looking at an inner area formula_11 of 5x5 cells and an outer area formula_12 of 9x9 cells around formula_10. Focusing on crossing nodes (ends of edges that cross the boundary of formula_10, formula_11 or formula_12), the access nodes for formula_10 are those nodes of formula_11 that are part of a shortest path from some node in formula_10 to a node in formula_12. As access nodes for an arbitrary node formula_21 all access nodes of formula_10 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. 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 formula_23highest nodes of the contraction hierarchy.
How are access nodes selected?
Forward access nodes of a node formula_7 can be found by running the upward-search of the contraction hierarchy starting at formula_7. 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 formula_7. 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.
References.
 ;templatestyles src="Reflist/styles.css" / ;