Fast and Compact Oracles for Approximate ... - Semantic Scholar

Fast and Compact Oracles for Approximate Distances in Planar Graphs Laurent Flindt Muller1 and Martin Zachariasen2 1

Transvision, Vermundsgade 40D, DK-2100 Copenhagen, Denmark [email protected] 2 Department of Computer Science, University of Copenhagen, Universitetsparken 1, DK-2100 Copenhagen, Denmark [email protected]

Abstract. We present an experimental evaluation of an approximate distance oracle recently suggested by Thorup [1] for undirected planar graphs. The oracle uses the existence of graph separators for planar graphs, discovered by Lipton and Tarjan [2], in order to divide the graph into smaller subgraphs. For a planar graph with n nodes, the algorithmic variant considered uses O(n(log n)3 /) preprocessing time and O(n(log n)2 /) space to answer factor (1 + ) distance queries in O((log n)2 /) time. By performing experiments on randomly generated planar graphs and on planar graphs derived from real world road networks, we investigate some key characteristics of the oracle, such as preprocessing time, query time, precision, and characteristics related to the underlying data structure, including space consumption. For graphs with one million nodes, the average query time is less than 20μs.

1

Introduction

Computation of shortest path distances in road networks has applications in traffic simulation and logistics optimization. Often a huge number of distances are needed, rather than actual shortest paths. A distance oracle is a data structure with an accompanying algorithm that can answer distance queries quickly (preferably in constant time) by preprocessing the graph and storing additional information [3]. For real world applications the preprocessing time and the space consumption both have to be near-linear in the size of the graph. There has recently been a significant development in the practical construction of distance oracles that can answer (exact) distance queries quickly in arbitrary directed graphs. One approach is to identify so-called landmarks for which the distances to all other nodes are precomputed; these computed distances can then be used to speed up Dijkstra’s algorithm using goal directed search [4]. Another technique uses the notion of reach [5], which is a measure of how far away the endpoints of any shortest path through a given node can be. Reach-based pruning is, like the use of landmarks, a highly effective method to speed-up Dijkstra’s algorithm [6]. Sanders and Schultes [7,8] presented a technique that exploits the hierarchy inherent in road networks. In the preprocessing phase the method constructs L. Arge and E. Welzl (Eds.): ESA 2007, LNCS 4698, pp. 657–668, 2007. c Springer-Verlag Berlin Heidelberg 2007

658

L.F. Muller and M. Zachariasen

a multilevel network in which exact shortest path queries subsequently can be answered quickly. Combined with the notion of transit nodes [9,10], distance queries in road networks with several million nodes can typically be answered in less than 10μs. Real world road networks are almost planar (with exceptions such as bridges and no-left-turns). Furthermore, the edge weights are essentially symmetric, so assuming that road networks are undirected planar graphs does not lead to particularly large errors — at least for long range distance queries. For undirected planar graphs, Fakcharoenphol and Rao [11] gave a distance oracle√ with O(n log3 n) preprocessing time that answers (exact) distance queries in O( n log2 n) time, and it appears to be hard to improve this query time bound significantly using label-based methods [12]. If we settle for an approximate distance oracle that can answer distance queries within a factor (1 + ) of the true distance (for any > 0), much better results exist for undirected planar graphs. Klein [13] and Thorup [1] have independently suggested O(n(log n)/)-space approximate distance oracles answering factor (1 + ) distance queries in O(1/) time. Both methods use the existence of graph separators for planar graphs, proved by Lipton and Tarjan [2], in order to divide the graph into smaller subgraphs. Then, for each node in the graph, the distances to a subset of the separator nodes are computed in a preprocessing step; these distances make it possible to answer approximate distance queries very quickly for any pair of nodes. The oracle given by Klein [13] has apparently been implemented as part of a commercial product, but to the best of our knowledge no publicly available experimental results are known. The purpose of our paper is to perform an experimental study of a (simple) variant of the Thorup-oracle. In a sense we attempt to close part of the gap between theory and practice in distance oracles: The worst-case bounds for the highly effective practical algorithms [9,10] virtually give no insight into the practical behavior of the algorithms, and on the other hand, no experimental results are available for the theoretically superior algorithms of Thorup and Klein. For a planar graph with n nodes, the algorithmic variant considered in our paper uses O(n(log n)3 /) preprocessing time and O(n(log n)2 /) space to answer factor (1 + ) distance queries in O((log n)2 /) time. We have performed experiments on randomly generated planar graphs and on planar graphs derived from real world road networks. Key characteristics of the oracle, such as preprocessing time, query time, precision, and characteristics related to the underlying data structure, including space consumption, are studied. For graphs with one million nodes, the average query time is less than 20μs. Although our query times are similar to the query times of the best practical algorithms, this comes at the cost of non-exact distances, and higher preprocessing and space consumption. The paper is organized as follows. In Section 2 we present the approximate distance oracle of Thorup and discuss some important algorithmic and implementation details. In Section 3 we discuss our experimental setup, including the selection of test instances. Our experimental results are presented and discussed in Section 4, and concluding remarks are given in Section 5.

Fast and Compact Oracles for Approximate Distances in Planar Graphs

2

659

Approximate Distance Oracle

We now give an overview of the theoretical foundations of the oracle. We start by introducing the notion of a graph separator and describe how such a separator can be used to answer distance queries. Then we go on to describe -covers and finally describe the oracle itself. Basic graph terminology is used [2,14]; recall that a graph is called planar if its edges and nodes can be embedded in the plane such that no two edges cross or overlap. 2.1

Graph Separators

A set of nodes C in a graph G is called a graph separator if the removal of C from G results in G being split into components, the size of each being at most some constant fraction of the size of G (where the size refers to the number of nodes in the graph). To be of interest C must be “small”. Lipton and Tarjan [2] proved that it is possible to construct a graph separator for any planar graph in linear time. The construction essentially consists of finding a (rooted) shortest path tree of the graph and then selecting two root paths which separate the graph into components of size no greater than 2/3 the original size. Thorup [1] showed that this construction can be extended to selecting three root paths, where each component has size no greater than 1/2 the original size. We call such root paths separator paths. Assume that we have two nodes u and v lying in two different components, resulting from the removal of a separator path Q. The observation is that any (shortest) path between u and v must cross a node in Q. Assume that we at some previous stage had computed distances from u and v to each node in Q. Now finding the distance between u and v is a simple task of running through the nodes of Q finding the minimum combined distance (see figure 1). This is in essence the idea behind the oracle. For each node u, we construct a set S(u) consisting of separator paths, such that given any other node v the intersection S(u) ∩ S(v) consists of separator paths which, if removed from G, separate u from v. Thus a shortest path from u to v must cross a node in one of these paths. For each node u the distances to nodes in the separator paths in S(u) are precomputed. Computing the distance between u and v then consists of finding the intersection S(u) ∩ S(v), then finding the minimum distance across each separator path in this intersection and finally returning the overall minimum distance. 2.2

-Covers

The most expensive part of the algorithm sketched above is precomputing distances from each node to nodes in the separator paths. In order to reduce this number of nodes, Thorup introduces the notion of -covers. Let G = (V, E) be a planar graph and let Q be a shortest path in G. A connection from v ∈ V to Q is a pair in {v} × V (Q). The length l(v, a) of a connection (v, a) is equal to the distance δ(v, a) between v and a in G. We

660

L.F. Muller and M. Zachariasen 7 10 2 8 8 2 3 5 3 10 5 4 7 5 10 7 2 13 11 1 2 17 5 14 2

5 4

2 9 3 2

u

3 7

1

2

2

4 8 2

3 3

4

3 5

1

3

v

Q

Fig. 1. Shows how a separator path can be used to compute the distance between two nodes u and v. The large nodes are the separator nodes and the topmost number is the distance from u, while the bottommost number is the distance from v. The min distance between u and v in the example is 15. u

v

20

l (v,a) a

10 15 7

δ (v,x)

13

δ (a,x) v x

9 Q

Q

Fig. 2. Connections within the -covers C(Q, u) and C(Q, v) (left). Illustration of a connection (v, a) that -covers another connection (v, x) (right).

denote a set of connections from v to Q by C(Q, v) (see figure 2, left). When computing distances across Q, only these connections are allowed to be used. Let > 0. We say that a set C(Q, v) of connections from v to Q -covers Q, if there for any node x ∈ V (Q) is a connection (v, a) ∈ C(Q, v) such that (see figure 2, right): l(v, a) + δ(a, x) ≤ · l(v, a) + δ(v, x). Thorup showed that for any node v and shortest path Q, there exists an -cover of size O( 1 ) [1]. It is further shown that given two nodes u and v, and some separator path Q, the (minimum) distance between u and v across Q can be approximated within a factor (1 + ) by using only the connections from C(Q, u) and C(Q, v). 2.3

Oracle

The preprocessing stage of the oracle proceeds as follows: Given a connected, undirected planar graph G, find up to three separator paths, Q1 , Q2 , Q3 , separating G into components of at most half the size. For each node v in G, construct the -cover C(Qi , v), i = 1, 2, 3. Proceed recursively on each of the components resulting from removing Q1 , Q2 , Q3 from the graph. When the preprocessing terminates, we have for each node constructed a set of -covers, which can be used to answer distance queries. For each connection (u, a) in these -covers we store the distance from u to a and the distance from the first node in the separator path to a.


661

Consider two nodes u and v. At some point of the recursion these nodes get separated. When this happens, all -covers for u and v constructed so far have been coverings of the same set of separator paths: If C(Qi1 , u), . . . , C(Qik , u) and C(Qj1 , v), . . . , C(Qjl , v) are the -covers constructed, then k = l and Qim = Qjm for m = 1, . . . , k. These are exactly the -covers which have to be checked in order to determine the distance between u and v. We call this number of -covers the separation index of u and v. When the preprocessing is done, query-answering proceeds as follows: Given two nodes u and v, find the separation index k. For i = 1, . . . , k find the minimum distance across Qi using the pair C(Qi , u), C(Qi , v). Return the overall minimum distance found. There are a number of implementation details which affect the overall timecomplexity. When building -covers, any algorithm for finding shortest paths in (planar) graphs can be used. One should bear in mind that this algorithm will be called often and the hidden constants should be small. We employ Dijkstra’s algorithm [14], since this is a simple and fast algorithm. On planar graphs it has a time-complexity of O(n log n), where n is the number of nodes, and this results in a time-complexity of O(n(log n)3 /) for the preprocessing stage. Another detail is how to find the separation index when answering distance queries; in order to find this index, each recursion is given a strictly increasing number. Each node maintains a list of recursion numbers representing the recursions in which it has participated. With each recursion number is stored the total number of separator paths generated in that recursion, plus all previous recursions in which the node has participated. In order to find the separation index of two nodes u and v one needs to find the last common recursion number. This marks the point where u and v got separated. We call this number the separation number (when we have found the separation number, we also have the separation index). Given two lists of recursion numbers we use binary search to find the separation number. Since there are at most O(log n) separation numbers for each node, this search has time-complexity O(log log n). A final detail is the size of the -covers. The construction to produce -covers of constant size is a two step process. First covers of size O(log |V (Q)|/) are constructed, where Q is a separator path. Then the size of these covers is reduced to O(1/). This last step is not performed in our implementation. The reason is, as we shall see later, that the covers produced by the first step alone are already small (around 11 connections in each cover for = 0.01 and one million nodes). Moreover, in order to achieve -covers of size O(1/), one needs to run the oracle with = /2, which increases the running time and the size of the -covers produced in the first step (and hence also the second step). We expect that for the sizes of graphs considered, the constant in front of 1/ does not differ enough from the value log |V (Q)| to justify the extra running time. This results in a O((log n)2 /) time-complexity for answering queries (O(log n) -covers must be checked and each -cover contains O(log n/) connections).

662

3


Experimental Setup

To examine the performance of the oracle, we have looked at two classes of graphs: (i) Graphs derived from real world road networks of the United States (made publicly available for the 9th Dimacs Implementation Challenge [15]). The graphs considered are planar and connected, and have the sizes: 321, 270 (BAY ), 435, 666 (COL) and 1,070,376 (FLA). (We were unable to perform experiments on larger graphs due to memory constraints.) In the following, we call this class of graphs real-world instances. (ii) Randomly generated connected planar graphs generated using the random planar graph() function in LEDA [16]. Edge lengths corresponds to Euclidean distances, with a random variance of up to 10%. We expect this choice of edge lengths more closely reflects real world road graphs, as compared to random or exact Euclidean lengths. In the following, we call this class of graphs near-Euclidean instances. When presenting query-times and precision, results have been divided into four groups. Each group corresponds to queries where the distance falls within a certain percentage range of the graph diameter, corresponding to 0%-25%, 25%-50%, 50%-75% and 75%-100% of the diameter. The size of each group of queries is capped at 1000 and filled up as follows: First the oracle is run with = 0.05. Then random queries are generated and answered using this oracle. If the distance returned falls within the range of an unfilled group, then the exact distance is found using Dijkstra’s algorithm. The process stops when all groups are filled or when 200.000 queries have been made. The tests have been run on a machine running Gentoo Base System version 1.12.6. The compiler used is GCC 3.4.6 with optimization flag -O. The machine has 2 GB of main memory and two Intel Pentium 4 CPU 3GHz processors.

4

Results and Discussion

In the following we present our results for the two classes of graphs. For each instance the preprocessing stage has been run a number of times (around 5) and the average taken. For each run has been set to 0.10, 0.05 and 0.01. We also examine the effect of setting = 0, but due to memory constraints results are in this case only presented for the near-Euclidean graphs. In order to keep memory-consumption low, -covers are regularly flushed to disk and in order to keep disc-usage low, the outputted files are compressed. The measured time includes these overheads. In order to examine the query stage, the range groups described above are used. Again, the queries have been run repeatedly and the average taken. 4.1

Real-World Graphs

Figure 3 (left) shows the total CPU-time spent in the preprocessing stage when is varied. For the FLA instance, the preprocessing time varies from around 4000s for = 0.10 to around 9000s for = 0.01. The bulk of this time (around 90%) is spent constructing -covers.

Fast and Compact Oracles for Approximate Distances in Planar Graphs Total times

663

Distribution of the returned distances for epsilon 0.10

9000

30

8000 25 7000 Non-exact results (%)

Time (secs)

6000 5000 4000 3000

20

15

10

2000 5 1000 0 300

0 400

500

600

700

800

900

1000

1100

0

1

2

Vertices (x1000) epsilon = 0.01

3

4

5

6

7

8

9

10

Percentage by which exact distance is exceeded

epsilon = 0.05

epsilon = 0.10

0%-25%

25%-50%

50%-75%

75%-100%

Fig. 3. Total time spent in the preprocessing stage (left) and distribution of distances returned for the FLA instance ( = 0.10), for the four ranges (right) for real-world graphs. (Note that there are only three data points for each -value, and that the points are connected only in order to improve readability).

Figure 4 shows the query-times for the first and the last range group (the results for the remaining two look very similar). The value of has a considerable effect. Query-times are below 7μs for = 0.10, and increase to 20μs for = 0.01. Generally finding shorter distances takes longer time. One explanation for this is that nodes that lie far apart get separated earlier, and thus fewer -covers need to be checked in order to answer a query. Average querytimes (0%-25% of diameter)

Average querytimes (75%-100% of diameter)

18

12 11

16 10 9 Time (microseconds)

Time (microseconds)

14

12

10

8 7 6 5

8

4 6 3 4 300

400

500

600

700

800

900

1000

1100

2 300

400


epsilon = 0.05

500

600

700

800

900

1000

1100


epsilon = 0.01

epsilon = 0.05

epsilon = 0.10

Fig. 4. Average query-times for distances lying in the interval 0%-25% (left) and 75%100% (right) of the diameter (real-world)

We now investigate the precision of the oracle, by examining the results for the FLA instance with = 0.10. Figure 3 (right) shows the results for the four range groups. The numbers indicate how many percent of the 1000 distances were approximated within 1%, 2%, 3% etc, of the true distance. Only non-exact distance are displayed. As can be seen, the further the nodes lie from each other, the more accurate the distances returned are. Those distances that are not exact tend to be very close to the exact distance. The average error is less than 1%, so even with = 0.10 one obtains very good approximations.

664


We now look at some of the characteristics of the oracle. Figure 5 (left) shows the average number of connections in each -cover when is varied. These -covers are on average surprisingly small. For the FLA instance with = 0.01, there are 11 connections per -cover and for = 0.10, there are 5. We remind the reader that the bound on the size of these covers is O(log V (Q)/), where Q is the separator path. As mentioned earlier, since the -covers are already so small, we do not expect that using an algorithm with a better bound on the size will have any dramatic effect on the query-time.

Number of connections per epsilon cover

Number of epsilon covers per vertex

11

21

10 20.5

8

Epsilon covers

Connections

9

7

20

19.5

6

5

4 300

19

400

epsilon = 0.01

500

600

700 Vertices (x1000) epsilon = 0.05

800

900

1000

1100 18.5 300

epsilon = 0.10

400

500

600

700

800

900

1000

1100

Vertices (x1000)

Fig. 5. Average number of -covers for each node (left) and average number of connections in each -cover (right) for real-world graphs

Figure 5 (right) shows the average number of -covers for each node (this number is independent of ). This number lies between 18 and 21, so on average around 200 connections have to be examined in order to answer a query for = 0.01. The total number of connections constructed during preprocessing gives an indication of the memory consumption of the oracle. In the current implementation, one connection consists of two floats, which is 8 bytes in total. The total number of connections for the FLA instance with = 0.01 is around 250 million, which results in a memory consumption of about 2GB. The number of connections is strongly affected by . When is increased to 0.10 for the same instance, the number of connections drops to just under 100 million. 4.2

Near-Euclidean Graphs

In this section we look at the class of near-Euclidean graphs. There are some notable differences compared to the previous section. Figure 6 (left) shows the CPU-time spent in the preprocessing stage when is varied. The preprocessing time is within the same order of magnitude as for the real-world instances, but varying has less effect. In order to examine the query-times, we proceed as for the real world graphs. In figure 7 the results for the first and the last range group are shown (the remaining two look very similar) On this class of graphs query-times are lower

Fast and Compact Oracles for Approximate Distances in Planar Graphs Total times

665

Distribution of the returned distances for epsilon 0.10

8000

100 90

7000

80 6000 Non-exact results (%)

70 Time (secs)

5000 4000 3000

60 50 40 30

2000

20 1000 10 0 200

300

400

500

600

700

800

900

1000

0 0

Vertices (x1000)

1

2

3

4

5

6

7

8

9

10

Percentage by which exact distance is exceeded epsilon = 0.00 epsilon = 0.01

epsilon = 0.05 epsilon = 0.10

0%-25%

25%-50%

50%-75%

75%-100%

Fig. 6. Total time spent in the preprocessing stage (left) and distribution of distances returned for the instance with 1 million nodes ( = 0.10), for the four ranges (right) (near-Euclidean graphs) Average querytimes (0%-25% of diameter)

Average querytimes (75%-100% of diameter)

8

6.5 6

7 5.5 5 Time (microseconds)

Time (microseconds)

6

5

4

3

4.5 4 3.5 3 2.5 2

2 1.5 1 200

300

400

500

600

700

800

900

1000

1 200

300

400

Vertices (x1000) epsilon = 0.00 epsilon = 0.01

500

600

700

800

900

1000




Fig. 7. The average query-times for distances lying in the interval 0%-25% (left) and 75%-100% (right) of the diameter (near-Euclidean graphs)

and range from around 2μs for = 0.10 to around 3μs for = 0.01 and increase to about 7μs for = 0. The reason for the lower query-times will become clear later. On these instances, there is no noticeable difference w.r.t. range groups. As for the real-world instances, we examine the precision of the oracle. Figure 6 (right) shows the results for the largest instance and for = 0.10. The distances are even closer to the exact distance than for the real-world instances. In fact all distances in the three last groups lies within 0.5% of the exact distance. Figure 8 (left) shows the average number of connections in each -cover when is varied. These are only about half the size of the covers produced for the real-world instances. Varying only has a minor effect on the size, which for the largest instance ranges from 3 for = 0.10 to 6.5 for = 0. Figure 8 (right) shows the average number of -covers for each node. This number (between 17 and 23) is about the same as for the previous class. Together with the smaller -covers, this explains why we on this class see faster querytimes than before. We believe that the -covers are smaller because the edge lengths are closer to fulfilling the triangle-inequality, and therefore it is easier for a connection to cover another.

666

L.F. Muller and M. Zachariasen Number of connections per epsilon cover

Number of epsilon covers per vertex

6.5

22.5 22

6

21.5 5.5 21 20.5 Epsilon covers

Connections

5 4.5 4

20 19.5 19

3.5 18.5 3 2.5 200

18

300

400

500

600

700

800



900

1000

17.5 17 200

300

400

500

600 Vertices (x1000)

700

800

900

1000

Fig. 8. Average number of connections in each -cover (left). Average number of covers for each node for near-Euclidean graphs (right).

The total number of connections constructed is about half as large as for the real-world instances. This is as expected, since the -covers are about half the size. The number is still affected by and for the largest instance it ranges from around 60 million connections for = 0.10 to around 110 million connections for = 0.01 and 140 million for = 0. 4.3

Comparison to an Alternative Oracle

We make a brief comparison to an alternative algorithmic variation of the Thorup-oracle. In the variant examined this far, the number of separator paths to check when answering a query is O(log n). Thorup [1] describes another variant, where this number is O(1). In this variant, alternating between two types of recursions, one can ensure that at most 12 separator paths needs to checked when answering a query, i.e., |S(u) ∩ S(v)| ≤ 12 for all u, v. There are, however, certain drawbacks. The alternation between two types of recursions results in a doubling of the total number of connections having to be made, thus one should also expect a doubling of the space consumption and an increase of the total running time. Considering that memory consumption already is a major issue, this doubling is unfortunate. Despite this we have made an implementation of this variant, hoping that it would result in a significant improvement of the query-time. Regrettably, this is not the case, as the query-times observed are within the same order of magnitude as the previous variant, while the preprocessing-time and memory consumption grew as expected. For the FLA instance ( = 0.05) the preprocessing time grew from 5000s to 16000s, while the total number of connections grew from 150 million to 275 million. A closer inspection of the number of -covers for each node gives a good insight as to the reason for not seeing any improvement in query-times. Looking at figure 5 (left) the average number of -covers for each node lies around 21 for the FLA instance. Thus on average 21 -covers need to be checked. It is this


667

number which is reduced to at most 12. The constructed -covers are of the same sizes, so one should not expect any significant gain for the query-times. For the real-world instances considered (and near-Euclidean) the number of -covers for each node rises rather slowly with graph size (from around 18 for BAY to around 21 for FLA). So the reduction to size 12 would only begin to be noticeable for very large graphs. For the graph sizes considered, we do not find that the rather limited improvement in query-time warrants the extra running time and space consumption.

5

Conclusion

In this paper we presented an experimental evaluation of an oracle recently suggested by Thorup [1]. For the examined class of real-world road network graphs, the observed query-times were less than 20μs ( = 0.01). The preprocessing time associated with the largest instance (one million nodes) was around 9000s and the memory needed to hold the generated connections was about 2GB for = 0.01. For the examined class of randomly generated near-Euclidean graphs, even faster query-times below 3μs were observed (still with = 0.01). For the largest instance (with one million nodes) the preprocessing time was faster, around 7000s, and memory consumption was about 1GB for = 0.01. For this class of graphs, we also examined the effect of setting = 0 (exact distance). This did not worsen the preprocessing time (around 8000s), query-time (below 6.5μs) and memory consumption (around 1.2GB for all connections) as much as could have been feared, which is interesting. When examining the precision of the returned distances, we observed that these tend to lie very close to the exact distances, even for = 0.10. This suggests that in practice one could set to a relatively large number and still get good approximations. The strongest merit of this oracle is its fast query-times and guaranteed bounds. This though, comes at the expense of approximate (but near-optimal) distances, and a preprocessing time and memory consumption, which is rather large. Other recent approaches, such as transit node based algorithms [9,10] achieve similar results on road networks, but without sacrificing exactness. When compared to these approaches, the results for the oracle considered do not appear to be competitive. Whether the preprocessing time and memory consumption may be improved is not yet clear. One way to reduce the former would be to experiment with other shortest path algorithms when constructing -covers. An improvement here would lead to a reduction in preprocessing time. In order to reduce the latter, one has to reduce the total number of connections needed (or reduce the space needed for each connection). Both Thorup [1] and Klein [13] show that it is possible to construct -covers of constant size. Further examination of the effect of this on the total number of connections is needed, but as argued in section 2.3 we do not expect the effect to be dramatic.

668


References 1. Thorup, M.: Compact Oracles for Reachability and Approximate Distances in Planar Digraphs. Journal of the ACM 51, 993–1024 (2004) 2. Lipton, R.J., Tarjan, R.E.: A Separator Theorem for Planar Graphs. SIAM Journal on Applied Mathematics 36, 177–189 (1979) 3. Thorup, M., Zwick, U.: Approximate Distance Oracles. Journal of the ACM 52, 1–24 (2005) 4. Goldberg, A.V., Harrelson, C.: Computing the Shortest Path: A∗ Meets Graph Theory. In: Proceedings of the 16th ACM-SIAM Symposium on Discrete Algorithms, pp. 156–165. ACM Press, New York (2005) 5. Gutman, R.: Reach-Based Routing: A New Approach to Shortest Path Algorithms Optimized for Road Networks. In: Proceedings 6th Workshop on Algorithm Engineering and Experiments (ALENEX), pp. 100–111 (2004) 6. Goldberg, A.V., Kaplan, H., Werneck, R.: Reach for A∗ : Efficient Point-to-Point Shortest Path Algorithms. In: Workshop on Algorithm Engineering and Experiments (2006) 7. Sanders, P., Schultes, D.: Highway Hierachies Hasten Exact Shortest Path Queries. In: Brodal, G.S., Leonardi, S. (eds.) ESA 2005. LNCS, vol. 3669, pp. 568–579. Springer, Heidelberg (2005) 8. Sanders, P., Schultes, D.: Engineering Highway Hierachies. In: Azar, Y., Erlebach, T. (eds.) ESA 2006. LNCS, vol. 4168, pp. 804–816. Springer, Heidelberg (2006) 9. Bast, H., Funke, S., Sanders, P., Schultes, D.: Fast Routing in Road Networks with Transit Nodes. Science 316, 566 (2007) 10. Bast, H., Funke, S., Matijevic, D., Sanders, P., Schultes, D.: In Transit to Constant Time Shortest-Path Queries in Road Networks. In: Proc. 9th Workshop on Algorithm Engineering and Experimentation (ALENEX) (2007) 11. Fakcharoenphol, J., Rao, S.: Planar Graphs, Negative Weight Edges, Shortest Paths, and Near Linear Time. In: Proceedings of 42nd IEEE Symposium on Foundations of Computer Science, pp. 232–241. IEEE Computer Society Press, Los Alamitos (2001) 12. Gavoille, C., Peleg, D., Pérennes, S., Raz, R.: Distance Labeling in Graphs. Journal of Algorithms 53, 85–112 (2004) 13. Klein, P.: Preprocessing an Undirected Planar Network to Enable Fast Approximate Distance Queries. In: Proceedings of the thirteenth annual ACM-SIAM Symposium on Discrete Algorithms, pp. 820–827. ACM Press, New York (2002) 14. Cormen, T.H., Leiserson, C.E., Rivest, R.L., Stein, C.: Introduction to Algorithms. MIT Press, Cambridge (2001) 15. Demetrescu, C., Goldberg, A.V., Johnson, D.: 9th DIMACS Implementation Challenge (2006), http://www.dis.uniroma1.it/∼ challenge9/ 16. GMBH, A.S.S.: LEDA 5.2 (2007), http://www.algorithmic-solutions.com/