The shortest distance between two points is a straight line. But in the real world, if those two points are located at opposite ends of the country, or even in different neighborhoods, it is unlikely you will find a route that enables you to travel from origin to destination via one straight road. You might pull out a map to determine the fastest way to drive somewhere, but these days, you are just as likely to use a Web-based service or a handheld device to help with driving directions. The popularity of mapping applications for mainstream consumer use once again has brought new challenges to the research problem known as the “shortest-path problem.”

The shortest-path problem, one of the fundamental quandaries in computing and graph theory, is intuitive to understand and simple to describe. In mapping terms, it is the problem of finding the quickest way to get from one location to another. Expressed more formally, in a graph in which vertices are joined by edges and in which each edge has a value, or cost, it is the problem of finding the lowest-cost path between two vertices. There are already several graph-search algorithms that solve this basic challenge and its variations, so why is shortest path perennially fascinating to computer scientists?

Andrew Goldberg, principal researcher at Microsoft Research Silicon Valley, says there are many reasons why researchers keep studying the shortest-path problem.

“Shortest path is an optimization problem that’s relevant to a wide range of applications, such as network routing, gaming, circuit design, and mapping,” Goldberg says. “The industry comes up with new applications all the time, creating different parameters for the problem. Technology with more speed and capacity allows us to solve bigger problems, so the scope of the shortest-path problem itself has become more ambitious. And now there are Web-based services, where computing time must be minimized so that we can respond to queries in real time.”

Improving on a Classic

The classic general algorithm for shortest path is called Dijkstra’s algorithm, first presented in 1959. But although this solves the problem, it does so essentially by searching the entire graph to compute its lowest-cost path. For small graphs, this is feasible, but for large graphs, the computing time just takes too long. For example, in a solution for driving directions, the road network is represented as a graph, where each vertex corresponds to an intersection and each edge to a segment of road between intersections. A complete map of the U.S. road system contains more than 20 million intersections, a huge amount of data to process if the algorithm has to search every segment of the graph.

Five to 10 years ago, it would not have been realistic for a portable device to store a map of the United States; the user would have loaded data for a local map, then reloaded a different map if traveling to a different area.

“But now, devices have the capacity to store a full map of North America or Europe,” says Renato Werneck, researcher at Microsoft Research Silicon Valley and Goldberg’s teammate on the Shortest Path project. “This is good, but it also makes for a bigger search, so we need more efficient algorithms that can solve problems faster on a larger scale.”

Andrew Goldberg (left) and Renato Werneck of Microsoft Research Silicon Valley.

The research lab embarked upon a series of projects to speed up the classic algorithms for the problem, specifically in the context of road networks with the goal of improving on some of the research that has occurred since Dijkstra’s original algorithm. They found that one of the most promising approaches was to use different techniques in combination, and then refine them.

In 2005, Goldberg and Chris Harrelson, an intern from the University of California, Berkeley, published the paper Computing the Shortest Path: A* Search Meets Graph Theory, which examined the heuristic technique known as A* (pronounced “A star”). They demonstrated the effectiveness of a bidirectional A* search when used in combination with pre-calculated landmarks.

Goldberg and Werneck, along with Haim Kaplan, professor at Tel Aviv University, co-authored two more research papers focused on shortest path, keeping in mind the need to create solutions that would be practical enough to deploy on servers, desktops, and portable devices such as vehicle or handheld navigation devices.

Reach for A*: Efficient Point-to-Point Shortest Path Algorithms explored ways to improve on the reach algorithm by combining it with A*, while Better Landmarks within Reach improved on the results of the first paper by incorporating various time-space performance trade-offs. The effectiveness of the new algorithms resulting from this work has been well worth the effort.

“Six years ago, a heuristic solution required looking at a very large portion of the map,” Goldberg says. “There were no performance guarantees, and the solutions were non-exact. We wanted exact and efficient algorithms. Now, we can look at just 0.1 percent of the graph and still find an exact shortest-path solution. This turned out well, because shortest path is a fundamental problem for which we found new solutions, and, as a bonus, some of the work made it into production.”

Shortest-path implementations are commonly deployed in two stages. In the first stage, algorithms preprocess a data model of the road network to derive information that will help reduce the search time for queries. The second is the actual algorithm to solve user queries. In production environments, servers or portable devices are loaded with preprocessed data, reducing the amount of data that query algorithms need to search. Therefore, the speed of a solution depends on both the quantity of preprocessed data and the efficiency of the query algorithm.

Bidirectional search using Dijkstra’s algorithm, with the green area showing the number of vertices scanned from point of origin and the blue area showing the vertices scanned from the destination point.

The team used Dijkstra’s algorithm as the starting point, to capture baseline performance data; this is a method that does not use preprocessing. The experiment ran searches for 1,000 random origin and destination pairs on a map of the United States represented by 24 million vertices. First, they ran Dijkstra’s algorithm in a bidirectional search, where vertices are processed concurrently from both the origin and destination points until they find a meeting point; the average number of vertices scanned using this method was 8 million and took more than 5 seconds to run on their test system.

“This search has no sense of direction, so to speak,” Werneck says. “The scan goes all over the place. But by using the A* search technique, we knew we could achieve a more directed search by scanning only the most promising vertices.”

Giving Better Direction

To restrict the search in A* and to provide it with a sense of direction, there needs to be a lower bound, or value, that is an estimate of the graph distance between target points. Given this lower bound, A* then prefers to scan the most “promising” vertices, those that are close to the source but also seem to be closer to the target. But this only works well if the estimated distance is reasonably accurate; if roads actually spiral up a mountain pass or have to travel around a lake, A* becomes inefficient.

Using A* with landmarks resulted in a directed search that dramatically reduced search time.

“So we came up with the idea of building in landmarks,” Goldberg says. “We picked some vertices as landmarks and then pre-computed the distances between those landmarks. This was our contribution to this aspect of shortest path―to calculate more accurate lower bounds based on a set of landmarks. When we incorporated landmarks into the solution, we ended up with a directed search that visited a much smaller portion of the map.”

The A*-with-landmarks approach delivered dramatic improvements. The average number of vertices scanned dropped from 8 million to fewer than 200,000, and the average computing time went from more than 5 seconds to fewer than 300 milliseconds.

Reaching for a Shorter Path

Seeking to improve their results even more, the researchers decided to work on a fairly new concept: the reach algorithm. As is often the case in shortest path, this idea is intuitively easy to understand but difficult to implement: When traveling a long distance from one city to another, the best route to take is usually one that gets onto a freeway as quickly as possible and exits as close to the destination as possible. There is no need to look at any of the other exits along the way, because none of those bring you close enough to the destination.

“Reach captures this intuition mathematically, allowing us to prune the search significantly,” Goldberg says. “You only search local intersections to get to a global one, such as the freeway. Thus, even though you prune the search area and end up visiting a very small subset of vertices on the map, you are still able to find the optimal path. Reach is a fairly new and very good idea; we just needed to make it practical.”

As it turned out, implementing reach with shortcuts was crucial to making the algorithm practical. Shortcuts are heuristically preprocessed, “artificial” edges that are equivalent in cost to the actual shortest path between two end points. For example, if the shortest path between point A and point B consists of five edges, preprocessing adds another edge between A and B into the data model that costs the same as the sum of the five edges. The objective is to give query algorithms the time-saving option of taking this mathematical shortcut instead of adding up every edge along the route.

Implementing reaches with shortcuts reduced both preprocessing and query time; the average number of vertices scanned dropped from less than 200,000 to 2,500, and average computing time decreased to less than 2 milliseconds.

Reach-based results: The curved black line shows the actual route, and the red line consisting of straight segments represents the computed shortcuts added during preprocessing.

When comparing A* and reach, the latter is efficient and visits a sparse subset of the map but does not have a sense of direction. On the other hand, A* has a sense of direction but doesn’t differentiate between local and global intersections, so it has to scan everything in the general direction of the destination.

“Reach makes the search sparse, while A* gives the search a sense of direction,” Goldberg says. “Reach and A* are orthogonal, so you can combine them and have a reach-plus-A* solution that is more efficient than reach alone. The research from Better Landmarks within Reach proved that this combination allowed queries to scan almost 1,000 vertices in less than one millisecond.”

From Theory to Driving Directions

There are few things more rewarding to a researcher than the opportunity to put theory into action. Goldberg and Werneck have been collaborating with Microsoft developers on enhancements to the driving directions feature in Microsoft’s Bing Maps; this recently launched with the Bing search engine.

“One of the benefits of working at Microsoft Research is that we have access to real data,” Werneck says. “In our experiments, we ran against census data that any researcher can download from the Internet. But the developers in Redmond had more detailed data models that were more complete and accurate. The data was weighted to take real road conditions into account.”

In a mapping application, distance does not always equate to driving time. A good data model is adjusted over time and weighted to reflect conditions such as slow speed limits, chronic congestion, or unpaved roads. The development team’s data model contained richer information, and the research team modified some algorithms to handle the data better.

“It was a really good experience,” Werneck says. “Some of our project code actually got incorporated in the production system, and we got a good look at real data and what users want. It was a very productive exchange of ideas.”

Goldberg concurs.

“We knew that a faster solution to shortest path was going to be important,” he says. “So we stayed in touch with the product group. They have product cycles and schedules, and there are windows when it is feasible to do the technology transfer. Fortunately, when the time came, we were able to supply them with proven algorithms.”

The Road Not Yet Taken

The project team has been careful to ensure that its algorithms are data-independent and can work correctly on any shortest-path problem, not just road networks. But given the importance of mapping applications, the researchers’ plan is to stay the course and explore ways to extend the flexibility of shortest-path solutions.

Static problems for road networks are quite well solved, in Goldberg’s opinion. He believes the next important challenge is to move from static to dynamic situations. With historical data increasingly available and incorporated into real systems, there is a lot of room for progress in solutions for real-time travel. To the user, this means being able to plan a route and have the system take into consideration the time of day and predict congestion or avoid road closures.

For Goldberg and Werneck, Microsoft Research is the ideal setting for carrying out this sort of work. They say they can make contributions to the scientific community, as well as to Microsoft’s products, a rare opportunity.

“In many labs,” Goldberg says, “either theory is very far removed from product or it’s actually advanced development and not true research. Microsoft Research has a culture of good symbiosis between science, engineering, and product improvements.”