#
Space-Efficient, Fast and Exact Routing in Time-Dependent Road Networks^{ †}

^{*}

^{†}

## Abstract

**:**

## 1. Introduction

**Related Work**Route planning in road networks has been extensively studied in the past decade. An overview over the field can be found in [2]. Here, we focus on speed-up techniques for time-dependent road networks. Several time-independent speed-up techniques have been generalized to the time-dependent setting. ALT [10], an approach using landmarks to obtain good A* [11] potentials, has been generalized to TD-ALT [12] and successively extended with node contraction to TD-CALT [4]. Even when combined with approximation, TD-CALT queries may take longer than 10 ms on continental sized graphs. SHARC [3], a combination of ARC-Flags [13] with shortcuts which allows unidirectional queries, was also extended to the time-dependent scenario [14]. It can additionally be combined with ALT yielding L-SHARC [14]. SHARC can find short paths in less than a millisecond but does not always find a shortest path. MLD/CRP [7,15] has been extended to TD-CRP [9] which can be used in a time-dependent setting. TD-CRP requires approximation to achieve reasonable memory consumption. It may find suboptimal paths. Another approach is FLAT [16] and its extension CFLAT [17]. CFLAT features sublinear query running time after subquadratic preprocessing and guarantees on the approximation error. Similar to our approach, CFLAT uses timestamped combinatoric structures to represent the changes in shortest paths over time and computes travel times lazily. Unfortunately, preprocessing takes long in practice and generates a prohibitively large index size.

**Contribution**In this work, we explore a variant of time-dependent Contraction Hierarchies, where shortcuts store paths instead of travel times. We introduce CATCHUp (Customizable Approximated Time-dependent Contraction Hierarchies through Unpacking), a time-dependent generalization of Customizable Contraction Hierarchies [5] and a thoroughly engineered implementation. Preprocessing takes only minutes even on modern production-grade continental sized instances with tens of millions of nodes. We also present algorithms which allow us to employ approximation to accelerate preprocessing without sacrificing exactness for the queries. Our implementation achieves fast and exact queries with performance competitive to TCH queries while requiring up to 38 times less memory.

## 2. Materials and Methods

#### 2.1. Preliminaries

#### 2.1.1. Contraction Hierarchies

#### 2.1.2. Customizable Contraction Hierarchies

#### 2.2. Shortcut Unpacking Data

Algorithm 1:LowerTriangleRelax |

Input: Preliminary unpacking data for arc $uv$: ${X}_{uv},{\underset{\xaf}{b}}_{uv},{\overline{b}}_{uv}$ and travel time function ${f}_{uv}$. Travel time functions of lower triangle arcs ${f}_{uw}$ and ${f}_{wv}$. |

Output: Improved data ${X}_{uv},{\underset{\xaf}{b}}_{uv},{\overline{b}}_{uv}$ and function ${f}_{uv}$. |

1$g\leftarrow {f}_{wv}\circ {f}_{uw}$ |

2${\Pi}_{uv}\leftarrow \{\tau \mid {f}_{uw}\left(\tau \right)\le g\left(\tau \right)\}$ |

3${\Pi}_{\left[uwv\right]}\leftarrow \{\tau \mid g\left(\tau \right)<{f}_{uw}\left(\tau \right)\}$ |

4X_{uv} ← {NewExpansion(x, Π_{uv} ∩ Π_{x})∣ x ∈X _{uv}} ∪ {NewExpansion([u, w, v], Π_{[uwv]})} |

5${f}_{uv}\leftarrow min({f}_{uv},g)$ |

6${\underset{\xaf}{b}}_{uv}\leftarrow min({\underset{\xaf}{b}}_{uv},{min}_{\tau}\left({f}_{uv}\left(\tau \right)\right))$ |

7${\overline{b}}_{uv}\leftarrow min({\overline{b}}_{uv},{max}_{\tau}\left({f}_{uv}\left(\tau \right)\right))$ |

8return${X}_{uv},{\underset{\xaf}{b}}_{uv},{\overline{b}}_{uv},{f}_{uv}$ |

Algorithm 2:Eval |

Algorithm 3:Unpack |

Algorithm 4:ReconstructTravelTimeFunction |

#### 2.3. Preprocessing

Algorithm 5:Customization |

**Parallelization**We employ both loop based and task based parallelism. The original CCH publication [5] suggests processing arcs with their lower ranked endpoint on the same level in parallel. The level of a node is the maximum level of its downward neighbors increased by one, or zero if the node does not have downward neighbors. We use this approach to process arcs in the top-level separators. However, this approach requires a synchronization step on each level. This is detrimental to load balancing. Thus, we use a different strategy when possible.

**Approximation**As we process increasingly higher ranked arcs, the associated travel time functions become increasingly complex. This leads to two problems. First, linking and merging becomes very time-consuming as running times scale with the complexity of the functions. Second, storing these functions—even though it is only temporary—requires a lot of memory. We employ approximation to mitigate these issues. However, for exact queries, we need exact unpacking information. We achieve this by lazily reconstructing parts of exact travel time functions during merging.

#### 2.4. Queries

#### 2.4.1. Earliest Arrival Queries

**Elimination Tree Interval Query**The elimination tree interval query is a bidirectional search starting from both the source node s and the target node t. It constructs a smaller subgraph for the second phase. We denote this subgraph as a shortest path corridor. Node labels contain an upper ${\overline{t}}_{v}$ and a lower bound ${\underset{\xaf}{t}}_{v}$ on the travel time to/from the search origin and a parent pointer to the previous node and the respective arc id. The bounds ${\overline{t}}_{s}$, ${\overline{t}}_{t}$, ${\underset{\xaf}{t}}_{s}$, ${\underset{\xaf}{t}}_{t}$ are all initialized to zero in their respective direction, all other bounds to infinity. We also track tentative travel time bounds for the total travel time from s to t. For both directions, the path from the start node to the root of the elimination tree is traversed. For each node u, all arcs $uv$ to higher ranked neighbors are relaxed, that is checking if ${\overline{t}}_{u}+{\overline{b}}_{uv}<{\overline{t}}_{v}$ or ${\underset{\xaf}{t}}_{u}+{\underset{\xaf}{b}}_{uv}<{\underset{\xaf}{t}}_{v}$ and improving the bounds of v if possible. When the new travel time bounds from an arc relaxation overlap with the current bounds, more than one label has to be stored. As an optimization [28], nodes can be skipped if the lower bound on the travel time to it is already greater than the tentative upper bound on the total travel time between s and t. After both directions are finished, we have several nodes in the intersection of the search spaces. Where the sum of the forward and backward distance bounds of such a node overlaps with the total travel time bounds, the parent pointers are traversed to the search origin and all arcs on the paths are marked as part of the shortest path corridor.

**Lazy Shortcut Unpacking**In the second query phase, we perform Dijkstra’s algorithm on the corridor obtained in the first phase. In the basic query, shortcuts are unpacked completely to evaluate their travel time. However, this may cause unnecessary and duplicate unpacking work. We now describe an optimized version of the algorithm which performs unpacking lazily. The algorithm starts with the same initialization as a regular TD-Dijkstra. All earliest arrivals are set to infinity, except for the start node which is set to the departure time. The start node is inserted into the queue. Then, nodes are popped from the queue until it is empty or the target node is reached. For each node, all outgoing arcs within the shortest path corridor are relaxed. When an arc is from the input graph, its travel time function can be evaluated directly. Shortcut arcs, however, need to be unpacked. The lazy unpacking algorithm defers as much work as possible: Only the first arc of the triangle of each shortcut will be recursively unpacked until an input arc is reached, the second arc will be added to the corridor. Figure 6 shows an example. This way, we unpack only the necessary parts and avoid relaxing arcs multiple times when shortcuts share the same paths.

**Corridor A***The query can be accelerated further, by using the lower bounds obtained during the elimination tree interval query as potentials for an A*-search. For nodes in the CH search space of t, the lower bounds from the backward search can be used. For nodes in the CH search space of s, we start at the meeting nodes from the corridor search and propagate the bounds backwards down along the parent pointers. This yields potentials for all nodes in the initial corridor. However, we also need potentials for nodes added to the corridor through unpacking. These potentials are computed during the shortcut unpacking. When unpacking a shortcut $uv$ into the arcs $uw$ and $wv$, then $\rho \left(w\right)$ will be set to $min(\rho \left(w\right),\rho \left(v\right)+{\underset{\xaf}{b}}_{wv})$.

#### 2.4.2. Profile Queries

**Reconstruction**In this phase, we obtain travel time functions for all arcs in the shortest path corridor. Similar to the customization, the obtained travel time functions may be either exact, or approximated upper and lower bound functions. This keeps the memory consumption low and linking and merging operations fast. We obtain these functions by first recursively reconstructing the travel time functions of all arcs referenced by expansions. The reconstructed functions will be saved for both arcs in the corridor and unpacked arcs, in case another reconstruction operation might reuse an arc. If all arcs referenced by the expansions have an exact function available, we can compute an exact travel time function for the current arc. If not, we end up with an approximation. After reconstruction, we always check if a function has more than $\beta $ breakpoints. If that is the case, we approximate it to reduce the complexity as described in Section 2.3.

**Contraction**In the third phase, we insert additional shortcuts and compute their unpacking data by simulating the contraction of the nodes in the shortest path corridor. We reuse the existing nested dissection order. The ranks of s and t are increased such that they are higher in the hierarchy than all other nodes. This construction leads to a shortcut between s and t, one between s and each node in the corridor on the path from s to the elimination tree root and one from each node in the corridor on the path from t to the root to t. Some of these shortcuts may already exist (see Figure 8 for an illustration).

**Extraction**In this final phase, we can use the unpacking information of the $st$ shortcut to efficiently compute the final result. The shortcut already contains a possibly approximated travel time function from the contraction phase. This may suffice for some applications. If the shortcut contains only an approximation, but we need an exact travel time profile, we can use Algorithm 4 to compute it. For some practical applications, the different shortest paths over the day may be more useful than the travel time profile. Algorithm 6 depicts a routine to compute path switches and the associated shortest paths. The algorithm follows the same schema as all unpacking algorithms. The operation is recursively applied to all expansions limited to the validity time of the expansion. Only the Combine operation is more involved. It performs a coordinated linear sweep over the path sets from $u{w}_{x}$ and ${w}_{x}v$ and appends the paths where the validity intervals overlap. For the paths from ${w}_{x}$ to v, we only know the validity times with respect to departure at ${w}_{x}$. To obtain the corresponding departure time at u, we reverse evaluate the current $u{w}_{x}$ path, i.e., we successively evaluate the inverted arrival time function of all arcs on the path in reverse order.

Algorithm 6:UnpackPaths |

## 3. Results

#### 3.1. Experimental Setup

#### 3.2. Input Road Networks

#### 3.3. Preprocessing

#### 3.3.1. Customization

**Parallelization**We evaluate the effectiveness of our parallelization schema and run the customization with a varying number of threads. Figure 9 depicts the results. As a baseline, we run the experiment with all parallelization code disabled. The baseline running time is indicated by the dashed line. Enabling parallelization but running with only one thread causes only little overhead. Running with more threads introduces more overhead due to synchronization. With 16 threads, parallel efficiency is still around 0.9. We conclude that our parallelization schema scales well and that customization times could be reduced further by utilizing additional cores.

**Approximation**We perform customization experiments with different approximation parameters. Over the course of the customization, we track the progress over time, the memory consumption and the average travel time function complexity. Figure 10 displays these measurements. We use the number of processed triangles to measure the progress because it corresponds roughly linearly to the time passed (though different parameters lead to different slopes). After about 60% of the triangles, the slope changes slightly. At this point only high-level separator nodes/arcs remain. These have complex travel time functions so linking and merging becomes more expensive. In addition, we switch from task based to loop based parallelization which is less effective. Measuring progress by processed nodes (the for loop in Line 1 in Algorithm 5) or processed arcs (for loop on Line 2) is also insightful. However, for these, the correspondence is not linear. The last couple of thousand nodes and the last million arcs take almost half the total time.

#### 3.4. Queries

#### 3.4.1. Local Queries

#### 3.4.2. Profile Queries

#### 3.5. Comparison with Related Work

## 4. Discussion

## Author Contributions

## Funding

## Acknowledgments

## Conflicts of Interest

## Appendix A. Extended Experimental Results

**Table A1.**Characteristics of test instances used. The third column contains the percentage of arcs with a non-constant travel time function. The fourth column the average number of breakpoints among those. The fifth and sixth columns report the relative total delay for all/only non-constant arcs. The final column contains the graph size in a compact representation in memory.

Nodes [·10 ^{3}] | Arcs [·10 ^{3}] | TD Arcs [%] | Avg. |f| per TD Arc | Rel. Delay [%] | Rel. Delay TD [%] | Size [GB] | ||
---|---|---|---|---|---|---|---|---|

Ber | Monday | 443.2 | 988.5 | 27.4 | 74.6 | 3.1 | 17.7 | 0.2 |

Tuesday | 443.2 | 988.5 | 27.4 | 75.0 | 3.1 | 17.6 | 0.2 | |

Wednesday | 443.2 | 988.5 | 27.5 | 74.9 | 3.1 | 17.5 | 0.2 | |

Thursday | 443.2 | 988.5 | 27.6 | 75.2 | 3.2 | 17.7 | 0.2 | |

Friday | 443.2 | 988.5 | 27.2 | 73.4 | 3.1 | 17.5 | 0.2 | |

Saturday | 443.2 | 988.5 | 20.2 | 69.1 | 2.1 | 14.8 | 0.1 | |

Sunday | 443.2 | 988.5 | 19.9 | 67.2 | 2.0 | 14.6 | 0.1 | |

Ger06 | Monday | 4688.2 | 10,795.8 | 7.0 | 20.1 | 1.7 | 33.1 | 0.3 |

midweek | 4688.2 | 10,795.8 | 7.2 | 19.5 | 1.7 | 33.1 | 0.3 | |

Friday | 4688.2 | 10,795.8 | 6.4 | 18.9 | 1.5 | 32.0 | 0.3 | |

Saturday | 4688.2 | 10,795.8 | 3.9 | 15.8 | 0.8 | 28.5 | 0.2 | |

Sunday | 4688.2 | 10,795.8 | 2.5 | 15.0 | 0.4 | 26.2 | 0.2 | |

SynEur | Low | 18,010.2 | 42,188.7 | 0.1 | 13.2 | 0.3 | 125.2 | 0.8 |

Medium | 18,010.2 | 42,188.7 | 1.0 | 13.2 | 0.8 | 124.9 | 0.8 | |

High | 18,010.2 | 42,188.7 | 6.2 | 13.2 | 4.6 | 124.8 | 1.0 | |

Ger17 | Tuesday | 7247.6 | 15,752.1 | 29.2 | 31.6 | 3.5 | 20.8 | 1.3 |

Eur17 | Tuesday | 25,758.0 | 55,503.8 | 27.2 | 29.5 | 2.7 | 19.0 | 4.2 |

Eur20 | Tuesday | 28,510.0 | 60,898.8 | 76.3 | 22.5 | 21.0 | 34.9 | 8.7 |

CCH Arcs [·10 ^{3}] | Expansions per Arc | Index | Running Time [s] | |||||
---|---|---|---|---|---|---|---|---|

Avg. | Max. | =1 [%] | [GB] | Phase 1 | Phase 2 | |||

Ber | Monday | 1977 | 1.040 | 25 | 98.6 | 0.09 | 1.5 | 6.2 |

Tuesday | 1977 | 1.039 | 31 | 98.6 | 0.09 | 1.5 | 6.2 | |

Wednesday | 1976 | 1.038 | 19 | 98.6 | 0.09 | 1.5 | 6.2 | |

Thursday | 1977 | 1.039 | 23 | 98.6 | 0.09 | 1.6 | 6.2 | |

Friday | 1975 | 1.037 | 28 | 98.7 | 0.09 | 1.5 | 5.8 | |

Saturday | 1961 | 1.023 | 21 | 99.1 | 0.09 | 1.5 | 3.8 | |

Sunday | 1957 | 1.021 | 27 | 99.2 | 0.09 | 1.6 | 3.3 | |

Ger06 | Monday | 22,499 | 1.073 | 42 | 98.4 | 1.06 | 30.0 | 20.9 |

midweek | 22,519 | 1.075 | 44 | 98.4 | 1.06 | 30.1 | 21.6 | |

Friday | 22,445 | 1.064 | 43 | 98.6 | 1.05 | 30.2 | 17.2 | |

Saturday | 22,229 | 1.031 | 37 | 99.2 | 1.03 | 30.2 | 6.0 | |

Sunday | 22,128 | 1.019 | 39 | 99.5 | 1.02 | 29.8 | 3.6 | |

SynEur | Low | 88,884 | 1.036 | 23 | 99.2 | 4.14 | 238.3 | 82.7 |

Medium | 90,514 | 1.109 | 24 | 97.6 | 4.31 | 231.5 | 224.8 | |

High | 94,302 | 1.264 | 31 | 94.6 | 4.71 | 233.3 | 523.0 | |

Ger17 | Tuesday | 31,488 | 1.090 | 107 | 98.5 | 1.50 | 35.0 | 107.4 |

Eur17 | Tuesday | 114,857 | 1.099 | 115 | 98.4 | 5.47 | 189.6 | 557.0 |

Eur20 | Tuesday | 128,921 | 1.191 | 109 | 96.9 | 6.32 | 209.6 | 1039.5 |

**Table A3.**Query performance with different optimizations. We report the number of nodes popped from the queue, the number of evaluated travel time functions and the running time. All values are arithmetic means over 100,000 queries executed in bulk with source, target and departure time drawn uniformly at random.

Queue Pops | Evaluated Travel Time Functions | Running Time [ms] | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|

Basic | + Corridor | + Lazy | + A* | Basic | + Corridor | + Lazy | + A* | Basic | + Corridor | + Lazy | + A* | ||

Ber | Monday | 167.4 | 38.2 | 1,605.0 | 618.6 | 99,629.0 | 5480.3 | 1762.4 | 674.9 | 8.6 | 0.6 | 0.6 | 0.3 |

Tuesday | 167.4 | 38.1 | 1603.6 | 635.2 | 100,820.5 | 5224.1 | 1747.4 | 691.5 | 8.8 | 0.6 | 0.6 | 0.3 | |

Wednesday | 167.4 | 38.6 | 1640.4 | 643.7 | 101,938.1 | 5405.3 | 1786.6 | 702.0 | 8.9 | 0.6 | 0.7 | 0.3 | |

Thursday | 167.4 | 38.9 | 1647.9 | 642.5 | 101,584.1 | 5498.9 | 1799.8 | 701.8 | 8.8 | 0.6 | 0.7 | 0.3 | |

Friday | 167.4 | 37.8 | 1591.1 | 619.6 | 99,142.5 | 5061.0 | 1722.9 | 674.0 | 8.5 | 0.5 | 0.6 | 0.3 | |

Saturday | 167.1 | 26.1 | 926.5 | 491.5 | 86,470.8 | 2124.5 | 967.4 | 514.1 | 6.4 | 0.3 | 0.3 | 0.2 | |

Sunday | 167.1 | 24.7 | 864.1 | 476.3 | 84,796.6 | 1865.9 | 895.3 | 495.1 | 6.1 | 0.2 | 0.3 | 0.2 | |

Ger06 | Monday | 492.3 | 68.6 | 2649.0 | 727.0 | 751,679.3 | 22,542.0 | 3029.0 | 853.0 | 42.8 | 1.8 | 1.4 | 0.5 |

midweek | 492.3 | 79.7 | 3323.2 | 831.0 | 818,721.3 | 31,740.8 | 3838.0 | 995.1 | 46.4 | 2.3 | 1.7 | 0.6 | |

Friday | 491.9 | 62.9 | 2349.2 | 731.3 | 780,031.8 | 21,423.2 | 2665.4 | 848.3 | 42.6 | 1.6 | 1.2 | 0.5 | |

Saturday | 490.7 | 24.1 | 339.4 | 211.1 | 541,331.4 | 2457.5 | 360.0 | 223.6 | 26.8 | 0.4 | 0.3 | 0.2 | |

Sunday | 490.0 | 20.2 | 219.2 | 163.5 | 503,009.4 | 1599.4 | 226.8 | 169.1 | 24.2 | 0.3 | 0.2 | 0.2 | |

SynEur | Low | 742.8 | 341.3 | 6626.2 | 1704.8 | 4,871,967.5 | 997,409.9 | 16,521.1 | 4730.7 | 201.8 | 39.9 | 5.1 | 2.0 |

Medium | 746.8 | 461.8 | 17,209.3 | 3,796.9 | 5,742,442.6 | 1,596,401.3 | 35,066.3 | 9389.8 | 253.0 | 69.4 | 13.1 | 4.0 | |

High | 749.7 | 554.1 | 33,572.2 | 7018.4 | 6,142,257.3 | 2,031,399.6 | 60,234.2 | 15,685.2 | 289.2 | 96.4 | 25.5 | 6.9 | |

Ger17 | Tuesday | 510.3 | 143.4 | 18,450.0 | 3099.2 | 2,100,731.8 | 164,372.5 | 19,910.5 | 3495.5 | 169.7 | 13.7 | 9.1 | 1.7 |

Eur17 | Tuesday | 861.6 | 229.3 | 39,714.8 | 6876.5 | 9,951,623.1 | 806,727.8 | 43,581.1 | 7911.0 | 808.6 | 62.3 | 20.8 | 4.1 |

Eur20 | Tuesday | 871.0 | 335.6 | 62,677.7 | 7231.9 | 10,527,072.7 | 1,222,655.6 | 70,145.4 | 8844.7 | 813.2 | 92.9 | 33.7 | 4.7 |

**Table A4.**Running times of profile queries and characteristics of the obtained profiles. We report the total running time and the running time of each phase of the query. The total running time is slightly larger than the sum of all phases as it includes some additional initialization and cleanup work. In addition, we report the number of breakpoints in the obtained travel time profile (Column $\left|f\right|$). Column $\left|X\right|$ contains the number of times the shortest path changes during the day. Since the same path may be the fastest for several times, we also report the number of distinct paths in the last column. All values are arithmetic means over 1000 queries executed in bulk with source and target nodes drawn uniformly at random.

Running Time [ms] | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|

Corridor | Reconstruct | Contract | Exact Profile | Paths | Total | |f| | |X| | Distinct Paths | ||

Ber | Monday | 0.1 | 39.7 | 14.9 | 2.6 | 0.4 | 58.4 | 29,090.5 | 2.7 | 2.3 |

Tuesday | 0.1 | 37.8 | 13.9 | 2.8 | 0.4 | 55.6 | 30,974.9 | 2.7 | 2.3 | |

Wednesday | 0.1 | 38.4 | 14.1 | 2.8 | 0.4 | 56.5 | 31,126.2 | 2.6 | 2.2 | |

Thursday | 0.1 | 40.1 | 14.8 | 2.8 | 0.4 | 58.8 | 30,662.1 | 2.7 | 2.3 | |

Friday | 0.1 | 34.2 | 12.5 | 2.4 | 0.3 | 50.2 | 27,671.5 | 2.6 | 2.2 | |

Saturday | 0.1 | 11.2 | 3.4 | 1.5 | 0.2 | 16.6 | 17,892.8 | 1.6 | 1.8 | |

Sunday | 0.1 | 8.9 | 2.5 | 1.4 | 0.2 | 13.2 | 16,768.7 | 1.6 | 1.8 | |

Ger06 | Monday | 0.3 | 42.2 | 17.3 | 0.6 | 0.8 | 62.9 | 9036.7 | 7.0 | 3.1 |

midweek | 0.4 | 56.5 | 23.0 | 0.7 | 0.8 | 83.6 | 9359.6 | 6.9 | 3.3 | |

Friday | 0.3 | 32.4 | 14.0 | 0.5 | 0.7 | 49.3 | 7896.2 | 6.0 | 3.0 | |

Saturday | 0.2 | 1.7 | 0.9 | 0.1 | 0.4 | 3.6 | 2047.2 | 2.8 | 2.0 | |

Sunday | 0.2 | 0.9 | 0.4 | 0.1 | 0.3 | 2.1 | 1386.3 | 2.2 | 1.8 | |

SynEur | Low | 2.1 | 591.3 | 501.7 | 0.2 | 7.3 | 1128.2 | 3379.4 | 151.4 | 144.9 |

Medium | 3.1 | 1664.3 | 962.7 | 0.4 | 6.1 | 2694.1 | 5226.1 | 99.0 | 90.1 | |

High | 3.2 | 3521.5 | 1484.9 | 0.5 | 5.3 | 5102.2 | 5939.1 | 78.0 | 69.2 | |

Ger17 | Tuesday | 0.8 | 452.2 | 189.0 | 6.1 | 2.4 | 660.1 | 66,146.0 | 9.7 | 3.7 |

Eur17 | Tuesday | 1.7 | 1135.8 | 732.9 | 13.0 | 7.8 | 1913.2 | 12,2192.1 | 16.5 | 6.8 |

Eur20 | Tuesday | 2.8 | 3166.6 | 1507.7 | 12.3 | 10.3 | 4747.5 | 107,690.7 | 24.4 | 11.6 |

## References

- Dijkstra, E.W. A Note on Two Problems in Connexion with Graphs. Numer. Math.
**1959**, 1, 269–271. [Google Scholar] [CrossRef] [Green Version] - Bast, H.; Delling, D.; Goldberg, A.V.; Müller–Hannemann, M.; Pajor, T.; Sanders, P.; Wagner, D.; Werneck, R.F. Route Planning in Transportation Networks. In Algorithm Engineering—Selected Results and Surveys; Kliemann, L., Sanders, P., Eds.; Springer: Berlin/Heidelberg, Germany, 2016; Volume 9220, pp. 19–80. [Google Scholar]
- Bauer, R.; Delling, D. SHARC: Fast and Robust Unidirectional Routing. ACM J. Exp. Algorithmics
**2009**, 14, 1–29. [Google Scholar] [CrossRef] - Delling, D.; Nannicini, G. Core Routing on Dynamic Time-Dependent Road Networks. Informs J. Comput.
**2012**, 24, 187–201. [Google Scholar] [CrossRef] [Green Version] - Dibbelt, J.; Strasser, B.; Wagner, D. Customizable Contraction Hierarchies. ACM J. Exp. Algorithmics
**2016**, 21, 1.5:1–1.5:49. [Google Scholar] [CrossRef] [Green Version] - Geisberger, R.; Sanders, P.; Schultes, D.; Vetter, C. Exact Routing in Large Road Networks Using Contraction Hierarchies. Transp. Sci.
**2012**, 46, 388–404. [Google Scholar] [CrossRef] - Delling, D.; Goldberg, A.V.; Pajor, T.; Werneck, R.F. Customizable Route Planning in Road Networks. Transp. Sci.
**2017**, 51, 566–591. [Google Scholar] [CrossRef] - Batz, G.V.; Geisberger, R.; Sanders, P.; Vetter, C. Minimum Time-Dependent Travel Times with Contraction Hierarchies. ACM J. Exp. Algorithmics
**2013**, 18, 1–43. [Google Scholar] [CrossRef] - Baum, M.; Dibbelt, J.; Pajor, T.; Wagner, D. Dynamic Time-Dependent Route Planning in Road Networks with User Preferences. In Proceedings of the 15th International Symposium on Experimental Algorithms (SEA’16), St. Petersburg, Russia, 5–8 June 2016; Springer: Berlin/Heidelberg, Germany, 2016; Volume 9685, pp. 33–49. [Google Scholar]
- Goldberg, A.V.; Harrelson, C. Computing the Shortest Path: A* Search Meets Graph Theory. In Proceedings of the 16th Annual ACM–SIAM Symposium on Discrete Algorithms (SODA’05), Vancouver, BC, Canada, 23–25 January 2005; pp. 156–165. [Google Scholar]
- Hart, P.E.; Nilsson, N.; Raphael, B. A Formal Basis for the Heuristic Determination of Minimum Cost Paths. IEEE Trans. Syst. Sci. Cybern.
**1968**, 4, 100–107. [Google Scholar] [CrossRef] - Nannicini, G.; Delling, D.; Liberti, L.; Schultes, D. Bidirectional A* Search on Time-Dependent Road Networks. Networks
**2012**, 59, 240–251. [Google Scholar] [CrossRef] [Green Version] - Lauther, U. An Extremely Fast, Exact Algorithm for Finding Shortest Paths in Static Networks with Geographical Background. In Geoinformation und Mobilität—von der Forschung zur Praktischen Anwendung; IfGI Prints: Münster, Germany, 2004; Volume 22, pp. 219–230. [Google Scholar]
- Delling, D. Time-Dependent SHARC-Routing. Algorithmica
**2011**, 60, 60–94. [Google Scholar] [CrossRef] - Holzer, M.; Schulz, F.; Wagner, D. Engineering Multilevel Overlay Graphs for Shortest-Path Queries. ACM J. Exp. Algorithmics
**2008**, 13, 1–26. [Google Scholar] [CrossRef] - Kontogiannis, S.; Michalopoulos, G.; Papastavrou, G.; Paraskevopoulos, A.; Wagner, D.; Zaroliagis, C. Engineering Oracles for Time-Dependent Road Networks. In Proceedings of the 18th Meeting on Algorithm Engineering and Experiments (ALENEX’16), Arlington, VA, USA, 10 January 2016; pp. 1–14. [Google Scholar]
- Kontogiannis, S.; Papastavrou, G.; Paraskevopoulos, A.; Wagner, D.; Zaroliagis, C. Improved Oracles for Time-Dependent Road Networks. In Proceedings of the 17th Workshop on Algorithmic Approaches for Transportation Modeling, Optimization, and Systems (ATMOS’17), Vienna, Austria, 7–8 September 2017; Volume 59, pp. 4:1–4:17. [Google Scholar]
- Strasser, B. Dynamic Time-Dependent Routing in Road Networks Through Sampling. In Proceedings of the 17th Workshop on Algorithmic Approaches for Transportation Modeling, Optimization, and Systems (ATMOS’17), Vienna, Austria, 7–8 September 2017; Volume 59, pp. 3:1–3:17. [Google Scholar]
- Huang, Y.; Zhao, L.; Van Woensel, T.; Gross, J.P. Time-dependent vehicle routing problem with path flexibility. Transp. Res. Part B Methodol.
**2017**, 95, 169–195. [Google Scholar] [CrossRef] - Gendreau, M.; Ghiani, G.; Guerriero, E. Time-dependent routing problems: A review. Comput. Oper. Res.
**2015**, 64, 189–197. [Google Scholar] [CrossRef] - Strasser, B.; Wagner, D.; Zeitz, T. Space-efficient, Fast and Exact Routing in Time-dependent Road Networks. In Proceedings of the 28th Annual European Symposium on Algorithms (ESA’20), Pisa, Italy, 7–9 September 2020. [Google Scholar]
- Orda, A.; Rom, R. Traveling without Waiting in Time-Dependent Networks Is NP-Hard; Technical Report; Department Electrical Engineering, Technion-Israel Institute of Technology: Haifa, Israel, 1989. [Google Scholar]
- Dreyfus, S.E. An Appraisal of Some Shortest-Path Algorithms. Oper. Res.
**1969**, 17, 395–412. [Google Scholar] [CrossRef] - Bauer, R.; Columbus, T.; Rutter, I.; Wagner, D. Search-space size in contraction hierarchies. Theor. Comput. Sci.
**2016**, 645, 112–127. [Google Scholar] [CrossRef] - George, A. Nested Dissection of a Regular Finite Element Mesh. SIAM J. Numer. Anal.
**1973**, 10, 345–363. [Google Scholar] [CrossRef] - Gottesbüren, L.; Hamann, M.; Uhl, T.N.; Wagner, D. Faster and Better Nested Dissection Orders for Customizable Contraction Hierarchies. Algorithms
**2019**, 12, 196. [Google Scholar] [CrossRef] [Green Version] - Zündorf, M. Customizable Contraction Hierarchies with Turn Costs. Bachelor’s Thesis, Karlsruhe Institute of Technology, Karlsruhe, Germany, 2019. [Google Scholar]
- Buchhold, V.; Sanders, P.; Wagner, D. Real-time Traffic Assignment Using Engineered Customizable Contraction Hierarchies. ACM J. Exp. Algorithmics
**2019**, 24, 2.4:1–2.4:28. [Google Scholar] [CrossRef] - Douglas, D.H.; Peucker, T.K. Algorithms for the Reduction of the Number of Points Required to Represent a Digitized Line or its Caricature. Cartogr. Int. J. Geogr. Inf. Geovis.
**1973**, 10, 112–122. [Google Scholar] [CrossRef] [Green Version] - Imai, H.; Iri, M. An optimal algorithm for approximating a piecewise linear function. J. Inf. Process.
**1987**, 9, 159–162. [Google Scholar] - Hoefler, T.; Belli, R. Scientific benchmarking of parallel computing systems: Twelve ways to tell the masses when reporting performance results. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, Austin, TX, USA, 15–20 November 2015; pp. 1–12. [Google Scholar]
- Demetrescu, C.; Goldberg, A.V.; Johnson, D.S. (Eds.) The Shortest Path Problem: Ninth DIMACS Implementation Challenge; DIMACS Book; American Mathematical Society: Providence, RI, USA, 2009; Volume 74. [Google Scholar]
- Sanders, P.; Schultes, D. Highway Hierarchies Hasten Exact Shortest Path Queries. In Proceedings of the 13th Annual European Symposium on Algorithms (ESA’05), Palma de Mallorca, Spain, 3–6 October 2005; Springer: Berlin/Heidelberg, Germany, 2005; Volume 3669, pp. 568–579. [Google Scholar]
- Dibbelt, J. Engineering Algorithms for Route Planning in Multimodal Transportation Networks. Ph.D. Thesis, Karlsruhe Institute of Technology, Karlsruhe, Germany, 2016. [Google Scholar]

**Figure 2.**Shortcuts and their travel time functions. (

**a**) A shortcut arc (dashed, black) bypassing several nodes. In our implementation, shortcuts always skip over exactly one node and two arcs, which may in turn be shortcut arcs (dashed gray arcs). (

**b**) Travel time functions for two different paths between the same start and end node.

**Figure 4.**Avoiding allocations when reconstructing shortcut travel time functions with two reusable buffers.

**Figure 5.**Merging approximated travel time functions by reconstructing the exact functions where bounds overlap.

**Figure 6.**Lazy relaxation of arc $uv$. Since $uv$ is a shortcut, it needs to be unpacked. This causes $wv$ to be added to the corridor and $uw$ to be relaxed. Relaxing $uw$ causes $xw$ to be added to the corridor and $ux$ to be relaxed. In this example, $ux$ is an original arc and the recursion stops. $xw$ will be relaxed (or unpacked) only once x is popped from the queue.

**Figure 7.**Example of a query where our A* potentials lead to a non-label-setting query. Dashed arcs are shortcuts. The shortcut weights are not known to the query algorithm.

**Figure 8.**Example of profile query search space with inserted shortcuts. Gray nodes and arcs are not in the shortest path corridor. Dashed arcs are new shortcuts.

**Figure 9.**Average customization running times and parallelization efficiency (speedup/number of threads) on five customization runs of Eur20. The black bars (barely visible) indicate the standard deviation. The dashed line indicates running time with all parallelization code disabled.

**Figure 10.**Customization behavior depending on the approximation parameters difference $\u03f5$ (varying by column) and threshold $\beta $ (indicated by color). The x-axis in all plots indicates the progress of the customization by number of processed triangles. The y-axis is the passed time in the first row, the memory usage in the second row (measure by the total number of stored breakpoints) and the mean travel time function complexity in the third row. There are many more elements which contribute to memory consumption. However, the breakpoints for travel time functions are the biggest chunk and are the easiest to measure. A breakpoint has a size of 16 bytes in memory. Thus, $8\times {10}^{9}$ breakpoints correspond to 128 GB memory consumption for travel time functions alone. The configuration $\beta $ = 10,000, $\u03f5=0.1$ s caused an out-of-memory error and is not listed.

**Figure 11.**Query running times in milliseconds with different optimizations by Dijkstra ranks on Eur20. The boxes cover the range between the first and the third quartile. The band in the box indicates the median. The whiskers indicate 1.5 times the interquartile range. Running times outside this range are considered as outliers and displayed separately.

**Table 1.**Characteristics of test instances used. The third column contains the percentage of arcs with a non-constant travel time function. The fourth column the average number of breakpoints among those. The fifth and sixth columns report the relative total delay for all/only non-constant arcs. The final column contains the graph size in a compact representation in memory.

Nodes [·10 ^{3}] | Arcs [·10 ^{3}] | TD Arcs [%] | Avg. |f| per TD Arc | Rel. Delay [%] | Rel. Delay TD [%] | Size [GB] | |
---|---|---|---|---|---|---|---|

Ber | 443.2 | 988.5 | 27.4 | 75.0 | 3.1 | 17.6 | 0.2 |

Ger06 | 4688.2 | 10,795.8 | 7.2 | 19.5 | 1.7 | 33.1 | 0.3 |

Ger17 | 7247.6 | 15,752.1 | 29.2 | 31.6 | 3.5 | 20.8 | 1.3 |

Eur17 | 25,758.0 | 55,503.8 | 27.2 | 29.5 | 2.7 | 19.0 | 4.2 |

Eur20 | 28,510.0 | 60,898.8 | 76.3 | 22.5 | 21.0 | 34.9 | 8.7 |

CCH Arcs | Expansions per Arc | Index | Running Time [s] | ||||
---|---|---|---|---|---|---|---|

[·10^{3}] | Avg. | Max. | =1 [%] | [GB] | Phase 1 | Phase 2 | |

Ber | 1977 | 1.039 | 31 | 98.6 | 0.09 | 1.5 | 6.2 |

Ger06 | 22,519 | 1.075 | 44 | 98.4 | 1.06 | 30.1 | 21.6 |

Ger17 | 31,488 | 1.090 | 107 | 98.5 | 1.50 | 35.0 | 107.4 |

Eur17 | 114,857 | 1.099 | 115 | 98.4 | 5.47 | 189.6 | 557.0 |

Eur20 | 128,921 | 1.191 | 109 | 96.9 | 6.32 | 209.6 | 1039.5 |

**Table 3.**Query performance with different optimizations. We report the number of nodes popped from the queue, the number of evaluated travel time functions (TTFs) and the running time. All values are arithmetic means over 100,000 queries executed in bulk with source, target and departure times drawn uniformly at random.

Queue Pops | Evaluated TTFs | Running Time [ms] | ||
---|---|---|---|---|

Ber | Basic | 167.4 | 100,820.5 | 8.8 |

+ Corridor | 38.1 | 5224.1 | 0.6 | |

+ Lazy | 1603.6 | 1747.4 | 0.6 | |

+ A* | 635.2 | 691.5 | 0.3 | |

Ger06 | Basic | 492.3 | 818,721.3 | 46.4 |

+ Corridor | 79.7 | 31,740.8 | 2.3 | |

+ Lazy | 3323.2 | 3838.0 | 1.7 | |

+ A* | 831.0 | 995.1 | 0.6 | |

Ger17 | Basic | 510.3 | 2,100,731.8 | 169.7 |

+ Corridor | 143.4 | 164,372.5 | 13.7 | |

+ Lazy | 18,450.0 | 19,910.5 | 9.1 | |

+ A* | 3,099.2 | 3495.5 | 1.7 | |

Eur17 | Basic | 861.6 | 9,951,623.1 | 808.6 |

+ Corridor | 229.3 | 806,727.8 | 62.3 | |

+ Lazy | 39,714.8 | 43,581.1 | 20.8 | |

+ A* | 6876.5 | 7911.0 | 4.1 | |

Eur20 | Basic | 871.0 | 10,527,072.7 | 813.2 |

+ Corridor | 335.6 | 1,222,655.6 | 92.9 | |

+ Lazy | 62,677.7 | 70,145.4 | 33.7 | |

+ A* | 7231.9 | 8844.7 | 4.7 |

**Table 4.**Running times of profile queries and characteristics of the obtained profiles. We report the total running time and the running time of each phase (Corridor, Reconstruction, Contraction, Extraction) of the query. The total running time is slightly larger than the sum of all phases as it includes some additional initialization and cleanup work. In addition, we report the number of breakpoints in the obtained travel time profile (Column $\left|f\right|$). Column $\left|X\right|$ contains the number of times the shortest path changes during the day. Since the same path may be the fastest for several times, we also report the number of distinct paths in the last column. All values are arithmetic means over 1000 queries executed in bulk with source and target nodes drawn uniformly at random.

Running Time [ms] | |||||||||
---|---|---|---|---|---|---|---|---|---|

I | II | III | IV | Total | |f| | |X| | Distinct | ||

TTF | Paths | Paths | |||||||

Ber | 0.1 | 37.8 | 13.9 | 2.8 | 0.4 | 55.6 | 30,974.9 | 2.7 | 2.3 |

Ger06 | 0.4 | 56.5 | 23.0 | 0.7 | 0.8 | 83.6 | 9359.6 | 6.9 | 3.3 |

Ger17 | 0.8 | 452.2 | 189.0 | 6.1 | 2.4 | 660.1 | 66,146.0 | 9.7 | 3.7 |

Eur17 | 1.7 | 1135.8 | 732.9 | 13.0 | 7.8 | 1913.2 | 122,192.1 | 16.5 | 6.8 |

Eur20 | 2.8 | 3166.6 | 1507.7 | 12.3 | 10.3 | 4747.5 | 107,690.7 | 24.4 | 11.6 |

**Table 5.**Comparison with related work. We list unscaled numbers as reported in the respective publications for algorithms we could not run ourselves. Values not reported are indicated as n/r. OOM means that the program crashed while trying to allocate more memory than available. A similar overview with scaled numbers can be found in [34].

Preprocessing | Index | Query | |||||
---|---|---|---|---|---|---|---|

Time | Cores | Size | Time | Rel. Error | |||

[s] | [GB] | [ms] | Avg. [%] | Max. [%] | |||

Ger06 | TD-Dijkstra | - | - | - | 719.26 | - | - |

TDCALT [4] | 540 | 1 | 0.23 | 5.36 | - | - | |

TDCALT-K1.15 [4] | 540 | 1 | 0.23 | 1.87 | 0.050 | 13.840 | |

eco L-SHARC [14] | 4680 | 1 | 1.03 | 6.31 | - | - | |

heu SHARC [14] | 12,360 | 1 | 0.64 | 0.69 | n/r | 0.610 | |

KaTCH | 169 | 16 | 4.66 | 0.64 | - | - | |

TCH [8] | 378 | 8 | 4.66 | 0.75 | - | - | |

ATCH (1.0) [8] | 378 | 8 | 1.12 | 1.24 | - | - | |

ATCH (∞) [8] | 378 | 8 | 0.55 | 1.66 | - | - | |

inex. TCH (0.1) [8] | 378 | 8 | 1.34 | 0.70 | 0.020 | 0.100 | |

inex. TCH (1.0) [8] | 378 | 8 | 1.00 | 0.69 | 0.270 | 1.010 | |

TD-CRP (0.1) [9] | 289 | 16 | 0.78 | 1.92 | 0.050 | 0.250 | |

TD-CRP (1.0) [9] | 281 | 16 | 0.36 | 1.66 | 0.680 | 2.850 | |

FLAT [17] | 158,760 | 6 | 54.63 | 1.27 | 0.015 | n/r | |

CFLAT [17] | 104,220 | 6 | 34.63 | 0.58 | 0.008 | 0.918 | |

TD-S+9 | 542 | 1 | 3.61 | 2.07 | 0.001 | 1.523 | |

CATCHUp | 52 | 16 | 1.06 | 0.72 | - | - | |

Ger17 | TD-Dijkstra | - | - | - | 814.60 | - | - |

KaTCH | 859 | 16 | 42.81 | 1.26 | - | - | |

TD-S+9 | 601 | 1 | 5.28 | 2.61 | 0.001 | 0.963 | |

CATCHUp | 142 | 16 | 1.50 | 2.02 | - | - | |

Eur17 | TD-Dijkstra | - | - | - | 2929.72 | - | - |

KaTCH | 3066 | 16 | 146.97 | OOM | - | - | |

TD-S+9 | 3149 | 1 | 18.84 | 4.70 | 0.002 | 1.159 | |

CATCHUp | 747 | 16 | 5.47 | 4.92 | - | - | |

Eur20 | TD-Dijkstra | - | - | - | 3784.11 | - | - |

KaTCH | 7149 | 16 | 239.78 | OOM | - | - | |

TD-S+9 | 3352 | 1 | 20.65 | 4.23 | 0.006 | 1.733 | |

CATCHUp | 1249 | 16 | 6.32 | 5.60 | - | - |

Publisher’s Note: MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations. |

© 2021 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (http://creativecommons.org/licenses/by/4.0/).

## Share and Cite

**MDPI and ACS Style**

Strasser, B.; Wagner, D.; Zeitz, T.
Space-Efficient, Fast and Exact Routing in Time-Dependent Road Networks. *Algorithms* **2021**, *14*, 90.
https://doi.org/10.3390/a14030090

**AMA Style**

Strasser B, Wagner D, Zeitz T.
Space-Efficient, Fast and Exact Routing in Time-Dependent Road Networks. *Algorithms*. 2021; 14(3):90.
https://doi.org/10.3390/a14030090

**Chicago/Turabian Style**

Strasser, Ben, Dorothea Wagner, and Tim Zeitz.
2021. "Space-Efficient, Fast and Exact Routing in Time-Dependent Road Networks" *Algorithms* 14, no. 3: 90.
https://doi.org/10.3390/a14030090