<These notes are from the arxiv version>

- “Transit Node Routing (TNR) is a fast and exact distance oracle for road networks.”
- This paper
- Provides a means of speeding up preprocessing by an order of magnitude

- Basic idea in contraction hierarchies is to do some preprocessing to allow for speedups of Dijkstras
- TNR is one of the best methods, and can get queries down to almost constant time (a small number of table lookups)
- The basic assumption behind TNR is that queries that span long geographical distances almost always go through centralized connections <highways> called
*transit nodes*

- Generally, there are only a few entrances to each transit node, so distances to these entrances as well as pairwise between transit nodes is stored
- This information allows for a
*locality filter*, which “… indicates whether the shortest path

might not cross any transit nodes, requiring an additional local path search.”

- A couple of issues with TNR traditionally is very expensive preprocessing, as well as the need for geographic information of the nodes (which a little bit of a poor fit when dealing theoretically with graphs; the hope is that would be abstracted away)
- On a rough level, contraction mappings order nodes by importance, and contracting them — removing them temporarily from the graph, and inserting new shortcut edges between that removed node and its neighbors only when necessary to maintain shortest path distances
- When doing search, all original edges are considered, as well as the additionally processed shortcut edges (although only those that lead to more important nodes). <Its not clear if also the original edges are filtered this way, but it seems like it is the case, as the resulting graph forms a DAG.>
- Leads to a graph with particular structure (all shortest paths now have a midpoint), which allows for a Dijkstra’s with a minor extension to be used

- Basically, these tricks allow for linear as opposed to quadratic all-pair shortest paths to be computed
- “TNR in itself is not a complete algorithm, but a framework. A concrete instantiation has to find solutions to the following degrees of freedom: It has to identify a set of transit nodes. It has to find access node for all nodes.”
- “CHs order the nodes in such a way that nodes occurring in many shortest paths are moved to the upper part of the hierarchy. Hence, CH is a natural choice to identify a small node set which covers many shortest paths in the road network.”
- <This is a loose definition of course, and for a real-world mapping problem you can’t hope to tackle it with an exact solution, so the trick must be what sort of heuristic to use>

- The algorithm presented here does not require geometric information about the nodes, resolving that wrinkle
- <skimming some parts of the papers, like the lemmas>
- <the remainder of the paper is empirical results – actually on a DIMACS dataset of Europe with about 20M nodes/edges>
- <discussion of application of other common graph-search extensions/heuristics>
- <discussion>
- “In particular, at the price of twice the (quite fast) preprocessing time of contraction hierarchies, we get two orders of magnitude faster query time. Our purely graph theoretical locality filter outperforms previously used geometric filters. To the best of our knowledge, this eliminates the last remnant of geometric techniques in competitive speedup techniques for route planning.”