Bing has implemented a whole new routing engine on Bing Maps with a new route calculation algorithm.
The new algorithm changes how driving directions queries are computed.
Algorithms behind routes on search engines’ maps probably aren’t something that most of us give a whole lot of that, but Bing clearly wants us to know how proud they are of this, having devoted not only a blog post about it, but an entire research paper.
“It started when I took over as PM of backend services for Bing Maps,” says Chris Pendleton. “The Microsoft Research team presented this crazy new idea to replace our modified Dijkstra’s algorithm with the blandly named ‘Customizable Route Planning’ algo. We’ve been using our own modified Dijkstra for years, it’s done a great job and it’s flexible – so, why would we change that? Once we saw the calculation numbers it was a no brainer to begin implementation immediately. For any of our route calculations we’re now processing requests twice as fast as we ever have. Oh, snaps! Now, if only CRP could double the speed limit. Future enhancement!”
The “special sauce” of the routing engine, Pendleton says, is a feature in the API for altenate routes. Applications can request up to 3 separate routes in one request, which can be displayed on the map. Here’s what Pendleton has to say about the basic algorithm:
Our metric-independent preprocessing stage partitions the graph into connected cells with at most U (an input parameter) vertices each, with as few boundary arcs (arcs with endpoints in di erent cells) as possible. The metric customization stage builds a graph H containing all boundary vertices (those with at least one neighbor in another cell) and boundary arcs of G. It also contains a clique for each cell C: for every pair (v;w) of boundary vertices in C, we create an arc (v;w) whose cost is the same as the shortest path (restricted to C) between v and w (or in nite if w is not reachable from v). We do so by running Dijkstra from each boundary vertex. Note that H is an overlay [24]: the distance between any two vertices in H is the same as in G. Finally, to perform a query between s and t, we run a bidirectional version of Dijkstra’s algorithm on the graph consisting of the union of H, Cs, and Ct. (Here Cv denotes the subgraph of G induced by the vertices in the cell containing v.) As already mentioned, this is the basic strategy of separator-based methods. In particular, HiTi [19] uses edge-based separators and cliques to represent each cell. Unfortunately, HiTi has not been tested on large road networks; experiments were limited to small grids, and the original proof of concept does not appear to have been optimized using modern algorithm engineering techniques. Our rst improvement over HiTi and similar algorithms is to use PUNCH [5] to partition the graph. Recently developed to deal with road networks, it routinely nds solutions with half as many boundary edges (or fewer), compared to the general-purpose partitioners (such as METIS [20]) commonly used by previous algorithms. Better partitions reduce customization time and space, leading to faster queries. For our experiments, we used relatively long runs of PUNCH, taking about an hour. Our results would not change much if we used the basic version of PUNCH, which is only about 5% worse but runs in mere minutes. We use parallelism: queries run forward and reverse searches on two CPU cores, and customization uses all four (each cell is processed independently).
The research paper can be found here, in PDF form.