Patent Application
20090125229
1. Field of the Invention
This invention relates generally to methods and systems for electronic download and display of route maps. More particularly, this invention relates to management of deviations from a calculated route map.
2. Description of the Related Art
A variety of systems are known in the art for providing drivers with in-vehicle electronic routing maps and navigation aids. These systems are commonly coupled to a location-finding device in the vehicle, such as a Global Positioning System (GPS) receiver. The GPS receiver automatically determines the current location of the vehicle, to be displayed on the map and used in determining routing instructions.
In-vehicle navigation systems fall into two general categories: “on-board” systems, in which the map data are stored electronically in the vehicle (typically on optical or magnetic media); and “off-board” systems, in which the map data are furnished by a remote map server. Off-board systems typically use a client program running on a smart cellular telephone or personal digital assistant (PDA) in the vehicle to retrieve information from the server over a wireless link, and to display maps and provide navigation instructions to the driver.
Various off-board navigation systems are described in the patent literature. For example, U.S. Patent Application Publication No. 2004/0030493 (Pechatnikov et al.), whose disclosure is incorporated herein by reference, describes a method for displaying a map on a mobile client device. Map data, including vector information delineating features in the map, are stored on a server. The server determines a route from a starting point to a destination within an area of the map. The route includes a sequence of route segments, each having a respective length and heading angle. The server then defines a corridor map comprising a sequence of map segments, each of which contains a respective route segment and has a respective zoom level and orientation determined by the length and heading angle of the route segment. The server downloads the vector information in the map segments to the client device, which renders a succession of images of the map segments as the user travels along the route. Typically, each map segment includes crossroads that intersect the route. If the user deviates from the route, the client device displays a return path to the route on one of the crossroads.
U.S. Patent Application Publication No. 2006/0025923 (Dotan et al.), whose disclosure is incorporated herein by reference, describes a method for displaying a map on a mobile client device. The method includes storing map data on a server, the map data including road data with respect to roads of multiple different road types. The server determines a route from a starting point to a destination within an area covered by the map data, the route including one or more route segments. The server defines a corridor map including the route segments and the roads of the different road types that are within different, respective distances, determined by the road types, of the route segments. The server downloads the road data with respect to the route segments and the roads of the different road types included in the corridor map to the client device. The client device, using the downloaded road data, renders one or more images, each image comprising at least a respective portion of the corridor map.
As another example, U.S. Pat. No. 6,381,535, whose disclosure is incorporated herein by reference, describes improvements required to convert a portable radiotelephone into a mobile terminal capable of functioning as a navigational aid system. Itinerary requests of the mobile terminal are transmitted to a centralized server by a radio relay link. The server calculates the itinerary requested, and transmits the itinerary to the mobile terminal in the form of data concerning straight lines and arc segments constituting the itinerary. The server also evaluates the possibility of the vehicle deviating from its course, and transmits data concerning segments of possible deviation itineraries in an area of proximity to the main itinerary.
Other off-board navigation systems are described in PCT Publications WO 01/01370 and WO 01/27812; in U.S. Pat. Nos. 6,038,559, 6,107,944, 6,233,518, 6,282,489, 6,320,518, 6,347,278, 6,462,676, 6,43,630, 6,526,284 and 7,142,205. The disclosures of all these patents and publications are incorporated herein by reference.
In order to assist the user of a navigation system in recovering from a deviation from the originally planned route, it is desirable to present the user with a complete, accurate picture of all the roads in the vicinity of the route. Off-board navigation systems, however, are subject to bandwidth constraints, which limit the amount of map data that can be transmitted over the air from a server to a user's client device. Therefore, the amount of ancillary road data that can be downloaded along with the actual route is limited.
There is a possibility that the user may deviate from the original route to a new position, such that the best alternative route from the new position to the destination takes the user a long way from the original route. Furthermore, the user may deviate from the alternative route, requiring a new alternative route, and so on. Conventional systems would either require additional communication between the server and the user's client device, or the use of a non-optimal alternative route. Calculating an optimal route from every possible deviation is generally not feasible, since the time and resources required to compute all possible alternative routes would not be reasonable.
An error-prone junction is a location where two or more roads intersect in which there is a high probability that the user will make a mistake in attempting to follow the prescribed instructions. Embodiments of the invention use statistical analysis based on a large set of previously traversed routes, in order to identify error-prone junctions. Error-prone junctions are considered likely deviations. Embodiments of the invention also use statistical analysis to identify types of junctions as error-prone.
Embodiments of the present invention define a corridor around the optimal calculated route taking into account various deviations from the main route. When a user deviates from the calculated route, but remains within the corridor, he continues to be directed to his destination via an alternative optimal route to the destination from his deviant location, without need to access the server for more information. Data from points along the route at which the user is likely to deviate from a prescribed route are used for calculation of respective optimal alternative routes from each likely deviation. This is repeated, recursively, for each alternative route calculated.
Embodiments of the invention also identify junctions at which deviations are likely to occur by analyzing their complexity. The complexity of the junction depends on many factors, including the number of streets meeting at the junction and the angles between the streets.
Every user has a unique driving pattern. Some users prefer highways to smaller city level streets while others avoid highways as much as possible. Some users prefer to take shortcuts through paved roads while others prefer to follow major city streets. Embodiments of the invention analyze the specific driving patterns of the user, by reviewing his or her tendency to follow the optimal route calculated, in order to predict likely deviations by the user.
Occasionally there are two or more possible routes to reach a destination where it is hard to determine the optimal one. In these cases, it is likely that all possible routes will be used evenly among users. Embodiments of the invention treat the alternative routes as likely deviations.
The server calculates and downloads optimal routes to the client device, together with map data for other roads and features near the optimal and alternative routes. This is done prior to downloading map data to the client. The algorithm used to calculate the optimal routes is efficient, and allows calculations for the optimal route from a first deviation to be reused when calculating the optimal route from a second deviation. As a consequence, optimal routes from many deviations may be calculated in a reasonable amount of time.
An embodiment of the invention provides a method for preparing a route map, which is carried out by communicating an origin and a destination to a server, and in the server establishing a prescribed route that extends from the origin to the destination. The method is further carried out by identifying junctions in the route where a traveler is likely to deviate from the prescribed route, and establishing alternative routes to the destination extending from points of departure that are associated with the deviations. The method is further carried out by thereafter downloading map data from the server to a client device, the map data including a route corridor that includes the prescribed route and the alternative routes, and rendering at least a portion of the map data on the client device. The server and client need not communicate between the time a route is requested and the final map data downloaded.
According to an aspect of the method, the alternative routes are optimal alternative routes.
An additional aspect of the method includes prior to performing downloading map data, selecting deviations along the alternative routes and responsively thereto, establishing new alternative routes.
In one aspect of the method, establishing alternative routes is performed by choosing the deviations according to a sort order. The sort order may include remoteness of the deviations from the destination, wherein a first chosen one of the deviations is a most remote deviation from the destination, and the establishment of alternative routes includes a search beginning at the destination and terminating at the points of departure, respectively.
Another aspect of the method includes specifying points of interest, and choosing the deviations only from junctions that are disposed within a predetermined distance of the points of interest.
According to a further aspect of the method, the deviations comprise a first order of deviation on the prescribed route.
According to yet another aspect of the method, the deviations comprise a higher order of deviation on the alternative routes.
One aspect of the method includes collecting records of actual deviations executed in at least a portion of the junctions, and selecting deviations is performed using the records.
An aspect of the method includes compiling a profile of the traveler, the profile including preferences for functional classes of roads, wherein selecting deviations is performed responsively to the profile.
In a further aspect of the method, selecting deviations is performed responsively to proximity between a candidate junction and other junctions.
In yet another aspect of the method, selecting deviations is performed responsively to a number of intersecting roads at the junctions.
In still another aspect of the method, selecting deviations is performed responsively to an angle of intersection at the junctions.
Other embodiments of the invention provide computer software product and apparatus for carrying out the above-described method.
For a better understanding of the present invention, reference is made to the detailed description of the invention, by way of example, which is to be read in conjunction with the following drawings, wherein like elements are given like reference numerals, and wherein:
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent to one skilled in the art, however, that the present invention may be practiced without these specific details. In other instances, well-known circuits, control logic, and the details of computer program instructions for conventional algorithms and processes have not been shown in detail in order not to obscure the present invention unnecessarily.
Turning now to the drawings, reference is initially made to
Map server 23 may be a general-purpose computer, comprising a memory in which map data are stored and a processor, which carries out the methods described herein under the control of software. The software may be downloaded to the processor in electronic form, over a network, for example, or it may alternatively be provided on tangible media, such as CD-ROM, DVD, magnetic media or non-volatile memory.
A location data output is provided by a GPS receiver 26 or other locating device in vehicle 22, and the location is transmitted automatically by client device 24 to map server 23. Alternatively, a cellular network with which client device 24 communicates may provide the location data output to map server 23, or the user may supply location data via the client device.
In the illustrated embodiment, the driver of vehicle 22 asks for current directions and a map showing a route from his current location to a given destination. Map server 23 computes the optimal route to the destination, as well as possible alternative routes to be followed in case vehicle 22 deviates from the optimal route. For example, assuming the original route to the destination to be Route 1, as shown in
Map server 23 then generates a corridor map showing the optimal route. A corridor map comprises a sequence of map segments, each of which contains a respective route segment and has a respective zoom level and orientation determined by the length and heading angle of the route segment. The corridor map produced by the map server 23 comprises map data, typically in the form of vector data, which delineates the route, along with the alternative routes and other roads in the vicinity of the route and the alternative routes. Based on the map data, a client program running on client device 24 renders a map showing the optimal route on a display 30. Methods for generating a corridor map using vector data, and for rendering the map on a client device, are described further in the above-mentioned U.S. Patent Application Publication No. 2006/0025923. In system 20, the roads to be included in the map data are chosen based on the road types and the distances of the roads from the route, or an alternative route, wherein different maximum distances for road inclusion are applied to different road types.
Typically, client device 24 outputs navigation instructions to the driver, based on the optimal route calculated by map server 23. The navigation instructions are generally shown on display 30 along with the map, and they may also be annunciated by the client device using text-to-speech functionality.
Route Deviations.
During or after construction of optimal route 101, map server 23 proceeds to determine possible deviations from the route, which are stored in a list of deviations. For purposes of alternative route calculation, a “deviation” is defined as a segment, sometimes termed a “deviant segment”, leading from a junction in the optimal route to a junction in a deviant route. In the context of
A deviation from the originally prescribed route is called a “first order of deviation”. A deviation from a route consequent to a first order of deviation is called a “second order of deviation”. Third, fourth and subsequent levels of deviation are similarly defined. Orders of deviation other than a first order of deviation are referred to as a “higher order of deviation”. Deviations of any order are identified by the map server 23 as those considered likely to occur. Deviations considered unlikely to occur are ignored in order to avoid an impractical number of route computations.
Reference is now made to
At step 42 an optimal route map is computed from the origin to the destination, using the source and destination chosen in initial step 40. Calculation of the optimal route can be done bi-directionally. Alternatively, it may be calculated unidirectionally.
The methods described in the above-noted U.S. Patent Application Publication No. 2006/0025923 are suitable for preparing the optimal route map and a corridor map based on the optimal route and alternative routes. To summarize briefly, client device 24 submits a route request that specifies various input data, such as the starting location (provided by manual input or automatically) and destination, as well as any interim locations to be passed along the route. The user may also specify a choice of optimal route type (shortest, fastest or simplest), as well as the transport type (car, truck, bicycle, pedestrian), and any road types to avoid, for example, toll roads. Map server 23 then computes the route, using any suitable automatic routing algorithm known in the art, such as the A*, Floyd-Warshall or Dijkstra algorithms. Such algorithms are described, for example, by Cherkassky et al., in “Shortest Path Algorithms: Theory and Experimental Evaluation,” Technical Report 93-1480, Department of Computer Science, Stanford University (Stanford, Calif., 1993), which is incorporated herein by reference.
The A* algorithm has been found to be particular suitable. This is a well known search algorithm that finds a path from a given initial node of a graph to a given goal node, using a heuristic estimate that ranks each node by an estimate of the best route that goes through that node, and expands the nodes in order of the heuristic estimate. Provided that the heuristic estimate is not an overestimate, the A* algorithm always finds the best route. Aerial distance satisfies this condition, since the aerial distance between two points cannot exceed the distance by road, and is easily and quickly calculated without requiring expansion of nodes. The A* algorithm employs a priority queue in order to keep track of unexplored routes. Typically, a route for which a lower bound on the total path length is smallest is given highest priority. Route exploration corresponds to expansion of nodes that represent road junctions.
Reference is now made to
Referring again to
Control now proceeds to decision step 48, where it is determined if all deviations on the optimal route have been identified. If the determination at decision step 48 is negative, then control returns to step 44. The process steps beginning with step 44 are performed recursively to identify higher order deviations—that is deviations on alternative routes, as explained below. The term “recursion” is used simply to facilitate understanding of the method. Efficient implementations of the method that avoid recursive calls will occur to those skilled in the art.
If the determination at decision step 48 is affirmative, then control proceeds to step 49. It is an aspect of the invention that at least one interaction between the map server and the mobile client device is required between initial step 40 and step 42. However, no further server access by the client device is necessary until the completed corridor map is downloaded to the client device.
At step 49 the deviation most remote from the destination in the optimal route is chosen. The measure of remoteness is typically the aerial distances from a deviation to the destination. Alternatively, other indicators of remoteness may be used, e.g., distance measured by traversals of the optimal route, estimated travel time. Choosing the deviations in sort order by remoteness is an important aspect of the invention. As will be seen from the discussion below, a portion of the deviations, as well as other nodes on the route or alternative routes, may be re-encountered. Once it is recognized that an optimal route from a node, including a deviation, to the destination is known, all its previous alternative route computations can be reused and need not be repeated. Selecting deviations in sort order has the effect of maximizing encounters of previously computed deviations, thereby increasing the efficiency of the method.
Reference is now made to
Referring again to
Alternatively, the deviation closest to the destination could be selected in step 49, in which case the alternative routes are computed in a forward direction in step 50. This and other options for performing step 50 are described below in the sections dealing with alternative embodiments of the invention.
In step 52, which is performed after step 50 has been completed, second or higher order deviations are identified on the alternative optimal route that was computed in step 50, using the same techniques as in step 44. As noted above, detection of such deviations in a reverse direction as the A* algorithm progresses contributes to the efficiency of the algorithm, as the same deviations are more likely to be repeatedly encountered during recursions. When a re-identification of such a deviation is recognized, alternative optimal routes (and their respective deviations) from the re-identified points will already have been computed. Of course, these computations need not be repeated.
Control now proceeds to decision step 54, where it is determined if all alternative deviations on the current alternative optimal route have been identified. If the determination at decision step 54 is negative, then control returns to step 52.
If the determination at decision step 54 is affirmative, then control proceeds in two directions. First, the sequence beginning at step 44 is performed at a higher level of recursion, reapplying the current alternative optimal route at step 56. This is shown by in
Second, control passes to decision step 58, where it is determined if more alternative deviations in alternative route at the current level of recursion need to be processed.
If the determination at decision step 58 is affirmative, then control returns to step 49. Otherwise processing of the current alternative route ends at final step 60. At this point, or after all threads have completed, rendering information may be applied, and the route and alternative routes may be embellished by helpful navigational information. For example, Dijkstra's algorithm can be applied to calculate times and distances from road junctions in the corridor to the destination. A route corridor map is computed based on the optimal and alternative routes.
Referring again to
Select all possible deviations from the optimal route between the origin and destination.
Evaluate junction characteristics, considering such factors as the number of intersecting roads at a junction, the angles between the roads and the size of the turn. For example, if a junction has more than four intersecting roads, the probability of a mistake becomes relatively high. All exits from a traffic circle could be included in the list of deviations.
Use statistical analysis of data collected from user experience with the junctions to identify deviations from a prescribed route. Data gathered from a large number of users and routes may indicate junctions where users often deviate from the route. The statistics may also contribute to the identification of common situations that lead to a mistake, not necessarily related to a specific place, e.g., junctions having particular configurations, a rapid succession of turns, confusing signage, and visual distractions.
Evaluate or use statistics to identify points where the user is likely to choose alternative routes intentionally. Statistics gathered from a large number of users and routes may indicate a popular alternative route to a destination. In cases where users may deliberately deviate from the main route, map server 23 identifies the deviations and adds them to the list of deviations. These deviations can also be time dependent. For example, during rush hours, users may deviate from the main route at a certain point in order to avoid a busy road.
Incorporate a known user driving profile, in which the profile reflects preferences for types of roads. Types of roads are sometimes referred to herein as “functional classes”. For example, some users commonly deviate to a highway. Other users commonly deviate to small streets. Some users have a tendency to miss an exit from a highway (in which case segments extending from all highway exits can be added to the list of deviations). Map server 23 (
Use different combinations of the above-noted methods of selecting deviations along the main route according to different conditions, some of which are user-specific and others dependent on the road conditions. For example a road suitable for use only by all-terrain vehicles would be included or excluded as part of an optimal route according to the user's vehicle. Similarly, a route involving administrative obstacles, e.g., a military checkpoint, border control, or tollgate might be included or excluded according to the user's status of being in a favored or disfavored class. For example, a user may have priority at a tollgate by virtue of a transponder in his vehicle. Lacking such a device, he may be required to wait in lengthy queues to pay the toll manually.
Many different road factors may affect the identification of deviations. Highways and small roads have different sets of likely deviations. For example, on a highway a driver is relatively unlikely to execute a mistaken left turn.
Proximity of candidate junctions to one another is another factor. Thus, in a densely populated city, junctions may be particularly confusing if encountered in rapid succession. Here there is a relatively high probability that a driver will make two deviations in succession without returning to the prescribed route, resulting in a larger number of higher order deviations and alternative routes.
Time of day: according to the time of day along the main route, different methods may be used to select deviations. For example, during rush hours, the driving profile may be given more weight in selecting deviations.
Each of the factors and approaches described above can be weighted, and a combination chosen, for example using known multi-factor optimization algorithms. Map server 23 selects the method that scores the highest and uses it to determine the deviations. The weighting is highly application dependent.
In one alternative, weights can have predefined values. For example: 80% for ‘first order of deviation’, 10% for urban/highway areas, 5% for time of day, 5% for a user profile. Then a list of candidate deviations is collected and sorted by score. Using this approach, in one example, a first order of deviation would have relatively high score if it occurred in an urban area.
The assigned weights affect the sensitivity of the algorithm and the number of deviations that are ultimately identified. There is a tradeoff between sensitivity and the time and resources required to perform the computations. Thus, if the configuration results in an identification of too many deviations, latency in the preparation of a display for the user may become unacceptable. On the other hand if too few deviations are identified, then should the user deviate at a road junction that was ignored by the algorithm, further communication between the map server and client device would be necessary to prepare a new optimal route for the user. This is undesirable, as it would add to the load on the server.
Deviations are typically stored as nodes and are associated with a directional property, in ascending order by distance from destination 104.
Reference is now made to
A field 215 contains the aerial distance from a selected likely deviation to the junction represented by node 210. This distance is used as the heuristic for the A* algorithm, as described above.
A field 220 contains a measure of the shortest distance by road, according to routes so far calculated, from the junction represented by node 210 to destination 104. The measure may incorporate a weight for various factors, e.g., turns on the route.
Node 210 may also contain other data fields (not shown) used in the calculation of routes from the junction represented by node 210 to destination 104.
In general, the A* algorithm may be applied by calculating nodes in either direction i.e., from initial node to goal node or vice versa, or it may be bi-directional, i.e., starting at both ends and meeting in the middle. When calculating alternative routes, map server 23 preferably calculates nodes from destination 104 towards the selected deviation, using roads that are traversed in the opposite direction only. This provides calculated routes from many nodes to destination 104, which can be reused when calculating best routes from other destinations. The reuse of data from nodes already calculated is important for the performance of the algorithm.
In one embodiment of the invention, map server 23 (
In particular, the node may be disregarded as the A* algorithm progresses if the aerial distances of the node from a point of interest, e.g., origin, destination and other deviations are greater than a functional class-specific threshold, termed herein a “hierarchy radius” for the node's functional class. In some embodiments of the invention, map server 23 treats a node based on a junction in a previously calculated optimal route or alternative optimal route that fails to meet pre-determined criteria when identifying an optimal route as a new “point of interest” for use in establishing an additional hierarchy radius.
Furthermore, as map server 23 performs the A* algorithm, when dealing with areas remote from the destination, origin, and all deviations, only nodes having high hierarchy radii qualify for consideration. Conversely, the functional class requirement is relaxed as routes less remote from the destination, origin and deviations are calculated. Typical radii range from a few hundred of meters for roads with a low functional class, to hundreds of kilometers for roads with a high functional class.
In some embodiments of the invention, nodes may be expanded even if they are outside the ‘hierarchy radius’, for example if too few roads have been processed at the appropriate hierarchical level.
Reference is now made to
During the operation of the A* algorithm, a deviation other than the deviation containing the junction 108 may be encountered. This event eliminates a second calculation with respect to the other deviation, as an optimal alternative route from the destination to the other deviation has already been found.
Calculated nodes have two significant values: (1) the real distance or weight from the destination (real roads, turn costs etc.) and (2) aerial distance to the junction 108. The real distance, of course, remains fixed. However, the aerial distance may vary during operation of the A* algorithm as the priority queue reorders.
In
Map server 23 now rebuilds the priority queue. Each previously calculated node has values that include the ‘real weight’ from the destination (field 220,
The A* algorithm is run again. The node expansion is continued in the direction of junction 242, as shown in
The A* algorithm then iterates until all deviations are evaluated.
Reference is now made to
Referring again to
An optimal route is computed from each identified deviation to the destination. This will result a relatively heavy computational load, particularly on routes having many deviations.
In this embodiment, alternative routes are calculated, e.g., using the A* algorithm, in a forward direction from identified deviations that are chosen in a sort order according to proximity of the deviations to the destination. The real weights and lengths computed for each node are memorized. A disadvantage of this approach is that recalculation of alternative routes from previously unevaluated deviations does not reuse these weights. The advantage of reusability of the earlier calculation is largely lost.
In this embodiment, reusability of nodes is exploited by concurrently undertaking alternative route calculations in both forward and reverse directions, for example in concurrent processes or threads. The advantage of the bi-directional approach is realized when roads developed from origin and destination rendezvous. In a first forward process or thread, the route search begins at the deviation and in a second at the destination. Eventually the two routes rendezvous. When a node evaluated by the second process or thread is discovered by the first one, the first process may use the weights that were calculated in previous iterations. This is because the previously calculated weights relate to the destination, which of course does not change. However, it is necessary that computed real weights of the first forward process be discarded and recomputed. This is accomplished following completion of a current iteration of the process, and upon initiation of the calculation of a deviation in a succeeding iteration.
In this embodiment, alternative routes are computed in a reverse direction (from destination to deviation). However, the deviations are not sorted. While this avoids the computations required to perform a sort, the number of node calculations required to cover all deviation increases. This approach also requires repeated reordering of the priority queue, and reinitiating the A* algorithm.
It will be appreciated by persons skilled in the art that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention includes both combinations and sub-combinations of the various features described hereinabove, as well as variations and modifications thereof that are not in the prior art, which would occur to persons skilled in the art upon reading the foregoing description.
