Searchlimited leastcost routing system
Info
 Publication number
 WO2003079155A1 WO2003079155A1 PCT/US2003/007781 US0307781W WO2003079155A1 WO 2003079155 A1 WO2003079155 A1 WO 2003079155A1 US 0307781 W US0307781 W US 0307781W WO 2003079155 A1 WO2003079155 A1 WO 2003079155A1
 Authority
 WO
 Grant status
 Application
 Patent type
 Prior art keywords
 node
 path
 nodes
 arc
 set
 Prior art date
Links
Classifications

 H—ELECTRICITY
 H04—ELECTRIC COMMUNICATION TECHNIQUE
 H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
 H04L45/00—Routing or path finding of packets in data switching networks
 H04L45/12—Shortest path evaluation
Abstract
Description
SEARCHLIMITED LEASTCOST ROUTING SYSTEM
Inventors: Ronald D. Gutman, Phillip N. Klein, Jesse B. Myers
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application claims benefit of the following U.S. Provisional Application, which is incorporated herein by reference: "Fast RoadDistance Computation and
Routing for Routes That Use Highways" filed March 12, 2003 and assigned Serial No.
60/363,322.
BACKGROUND OF THE INVENTION
[0002] Leastcost routing systems identify desirable sequences of steps from some source node to a destination node along arcs of a directed graph. Such a graph represents components or locations of a network (e.g., points along a road network, routers accessible on the Internet) as nodes and available connections from one component or location to another as directional arcs. To identify a leastcost path from one node to another along a sequence of intervening arcs, routing systems commonly employ a method that E.W. Dijkstra originally demonstrated in 1956 for interactively identifying shortest connections along the Dutch railway system.
[0003] While Dijkstra's method is widely used and is considered efficient for identifying a leastcost path within a full set of interconnected nodes, new and expanding applications of leastcost routing are making even relatively efficient path searches within a given set of nodes increasingly challenging. For example, representing a network of roads within a 200km by 200km region in an area of Japan surrounding the cites of Tokyo and Yokohama has been reported to require some 380,000 nodes connected by 780,000 arcs. Considering all of these nodes to identify a leastcost path within the network is a formidable computational task, typically requiring evaluation of many tens of thousands of paths, most of which will not even come close to being realistic candidates, before an optimal path is finally identified. [0004] U.S. Patent 6,477,515 to Boroujerdi et al. is an example of a conventional routing system that attempts to reduce the complexity of leastcost routing by considering some, rather than all, of the total network nodes. The method disclosed in the '515 patent imposes an additional constraint on path selection. For a given edge (i.e., arc) directed into a vertex (i.e., node), the method seeks edges directed out of the vertex that satisfy the constraint, e.g., a maximum turn angle from the first edge to a successive one. A shortcoming of this method is its dependence on a constraint in some additional variable defined with respect to the relationship between adjacent edges in the network. [0005] Other conventional systems attempt to reduce the complexity of leastcost routing based on a relationship between particular source and destination nodes to select only a subset of the total network nodes for consideration. For example, European Patent Application EP 1 126 667 of Mannepalli et al. discloses a method in which a subset of nodes is defined as falling inside a particular geographic window, e.g., a circular region centered at a midpoint between specified source and destination nodes. U.S. Patent 6,356,911 to Shibuya discloses a speedincrease method for multiple destinations, which employs information concerning the relationship between a node and a set of destinations on a graph. Selecting a subset of network nodes only after a particular source and destination node is specified means, however, that significant computations are still necessary during runtime. Thus overall enhancement of the basic Dijkstra search method's efficiency remains limited.
[0006] In view of the significant shortcomings in conventional attempts to reduce complexity of leastcost routing, and in view of the formidable computational challenges posed by many network routing problems, a need remains for ways of a priori reducing the number of nodes that need to be considered during the identification of a leastcost path between a given source and destination node.
SUMMARY OF THE INVENTION
[0007] A method according to various aspects of the present invention computes a desirable path from a source node to a destination node. In the method, a network data set is provided that includes indicia of a plurality of nodes and a plurality of primary arcs that connect some of the nodes. A preliminary routing data set is further provided, which includes indicia of desirable (e.g., leastcost) paths between each node of a primary arc (i.e., connected directly to at least one primary arc) and connected nodes that are not of a primary arc. Responsive to input (e.g., received from a remote user via a wireless connection) of a specified source and destination node of the plurality of nodes, the method retrieves from the preliminary routing data set a plurality of precomputed desirable paths that concatenate to form a desirable path between the source and destination node. Advantageously, retrieval of the precomputed paths save significant computational expenses during runtime for each requested combination of source and destination nodes.
[0008] In a particularly advantageous method of the invention, the arcs are representative of roadways and the primary arcs are representative of routes along a highway.
[0009] A method according to various other aspects of the invention computes a desirable path from a source node to a destination node, again by providing a network data set including indicia of a plurality of nodes and a plurality of arcs connecting the nodes and providing a preliminary routing data set. The preliminary routing data set according to these aspects of the invention includes indicia of a reach metric associated with each node. The reach metric for a given node is representative of potential for that node to be part of a desirable path between any permissible other nodes of the plurality of nodes. Responsive to input of a specified source and destination node of the plurality of nodes, the method iteratively computes a desirable path from the source node toward the destination node. An associated reach metric is retrieved for each node that is initially considered as part of the desirable path. Nodes are not traversed via the considered node if the reach metric is below an applicable threshold, thus avoiding significant runtime processing for exploring candidate paths that are unlikely or unable to ultimately lead to a desirable path. [00010] The above summary does not include an exhaustive list of all aspects of the present invention. Indeed, the inventor contemplates that the invention includes all systems and methods that can be practiced from all suitable combinations of the various aspects summarized above, as well as those disclosed in the detailed description below and particularly pointed out in the claims filed with the application. Such combinations have particular advantages not specifically recited in the above summary.
BRIEF DESCRIPTION OF THE DRAWINGS
[0010] Various embodiments of the present invention are described below with reference to the drawings, wherein like designations denote like elements.
[0011] FIG. 1 is a schematic block diagram of a roadway routing system according to various aspects of the invention.
[0012] FIG. 2 is a data flow diagram illustrating preliminary and runtime routing computations performed in accordance with various aspects of the invention.
[0013] FIG. 3 is a directedgraph representation of a small roadway network, including primary and secondary roadways, illustrating nodes that are referenced in simplified examples of leastcost routing.
[0014] FIG. 4 illustrates arcs of the directedgraph representation of FIG. 3 that are referenced in the simplified examples.
[0015] FIG. 5 is a data flow diagram illustrating computation of a preliminary routing data set based on an arrangement of primary and secondary arcs in a network data set according to certain aspects of the invention.
[0016] FIG. 6 is a data flow diagram illustrating a first set of runtime computations based on a specified source and destination node and the preliminary routing data set of FIG. 5.
[0017] FIG. 7 is a data flow diagram illustrating a second set of runtime computations computations based on a specified source and destination node and the preliminary routing data set of FIG. 5. [0018] FIG. 8 is a simplified network diagram illustrating regiontoregion routing according to certain aspects of the invention.
[0019] FIG. 9 is a simplified network diagram illustrating node reach according to certain aspects of the invention.
[0020] FIG. 10 is a data flow diagram illustrating computation of a preliminary routing data set characterizing the reach metric for nodes in a networked data set, and further illustrating runtime computations based on the preliminary routing data set and networked data set, according to certain aspects of the invention.
[0021] FIGS. 11 and 12 are equations employed in reachbased node checking according to certain aspects of the invention.
DESCRIPTION OF PREFERRED EXEMPLARY EMBODIMENTS
[0022] Routing systems according to various aspects of the present invention offer numerous benefits, including reduction in number of nodes that are considered during identification of a leastcost path between a given source and destination node based on preliminary routing data. Advantageously, the preliminary routing data can be computed without regard to any specific source and destination nodes. [0023] In exemplary road routing system 100 of FIG. 1, for example, a routing server 110 includes a preprocessor unit 114, a road network database 112, and a route query unit 116. Road network database 112 includes indicia of a road network such as network 300 of FIGS. 34. The indicia includes Euclidean (x,y) coordinates of nodes in the network, e.g., nodes AQ of FIG. 3, and arcs connecting adjacent nodes in permissible directions, e.g., arcs AB, AC, AE, DH, etc. of FIG. 4, along with metrics that each represent a cost of some type that is incurred upon traversing a respective one of the arcs.
[0024] Preprocessor unit 114 performs a priori routing computations based on information in database 112, without regard to any particular source and destination nodes of any particular path. Route query unit 116 operates at runtime, replying to queries from subscriber units 130, 140, 150, which connect to running server 110 via base stations 170, 180 (e.g., conventional cellular telephone base stations conveying signal over conventional data channels, e.g., WAP) and via a suitable bus or network interface (e.g., ethernet WAN) 120.
[0025] Servers, clients, and other portions of routing system according to various aspects of the invention can be suitably implemented with any appropriate hardware, software, or combination thereof, including for example a conventional Harvard architecture computer system including CPU, RAM, nonvolatile mass storage, and I/O subsystems that are suitably interconnected by one or more buses, serial communication links, etc. Wireless units include any suitable type of RF and baseband circuitry for establishing wireless medication links.
[0026] A description of hardware and software, interrelation therebetween, and some suitable variations, which can be employed in particular embodiments of the invention as desired, is found in a U.S. patent application of Wong et al., published as US 2002/0147849, assigned Serial No. 10/117,006, and entitled "Delta Encoding Using Canonical Reference Files." This aforementioned Wong et al. patent application is incorporated herein by reference, with particular attention in this context to its FIGS. 2A and 3 and published paragraphs 0052 through 0061. (The particular "delta encoding" aspects of the Wong et al. patent application are not of interest here.) [0027] A routing system according to certain aspects of the present invention computes a preliminary routing data set through a network of roads from one given location to another, advantageously employing simplifications that arise due to the presence of predefined primary and secondary arcs in the network. Such a system employs a data structure, e.g., in preliminary routing data set 230 of FIG. 2.
[0028] A method 200 performed by a routing system according to various aspects of the invention such as routing server 110 of FIG. 1 may be better understood with reference to FIG. 2. Method 200 includes an a priori routing computation process 220 and a runtime server control process 260, which controls runtime running process 240 for a client "i" (e.g., subscriber unit 130 of FIG. 1) and a runtime running process 250 for another client ")" (e.g., from subscriber unit 140 of FIG. 1), and potentially thousands of other runtime running processes not shown for other clients simultaneously or sequentially requesting routing information. Method 200 further includes a major network update process 270 and a minor network update process 280, which respond to changes in the condition of a network for which routes are determined, e.g., simplified example network 300 of FIG. 34.
[0029] Major network update process 270 updates network data set 210 for major changes, e.g., arcs representing roads no longer present, due to major construction completely blocking a road. Major network update process 270 can also causes process 220 to rerun, if such major changes require new a priori routing computations for runtime routing processes 240250 to work effeciently with contents of data set 230. A minor network update process 280 updates network data set 210 but does not cause process 222 rerun. An example of a situation where process 280 might be able to work effectively with requiring prerun of process 220 is where an arc representing a roadway has somewhat increased cost due to traffic conditions but still remains effective in the network.
[0030] One particularly advantageous routing system according to various aspects of invention computes a desirable path from a source node to a destination node. In such a system, a network data set is provided that includes indicia of a plurality of nodes and a plurality of primary arcs that connect some of the nodes. A preliminary routing data set is further provided, which includes indicia of desirable (e.g., leastcost) paths between each node of a primary arc (i.e., connected directly to at least one primary arc) and connected nodes that are not of a primary arc. Responsive to input (e.g., received from a remote user via a wireless connection) of a specified source and destination node of the plurality of nodes, the system retrieves from the preliminary routing data set a plurality of precomputed desirable paths that concatenate to form a desirable path between the source and destination node. Advantageously, retrieval of the precomputed paths save significant computational expenses during runtime for each requested combination of source and destination nodes. Exemplary methods performed by one such system may be better understood with reference to FIGS. 57. [0031] As may be better understood with reference to FIG. 5, a process 500 employed by the exemplary system for computing the data structure includes a leastcost secondarytoprimary path precomputation process 510, a leastcost primaryto secondary path precomputation process 520, and a leastcost primarytoprimary path precomputation process 530.
[0032] The data structure is intended to be stored in the primary memory of a computer, so it is important that the amount of memory it requires not be exorbitant. The system also includes a method 600 (FIG. 6) for accessing the data structure to find the cost of the shortest path (in this exemplary embodiment cost equals length, and leastcost path is simply the shortest path) from a given origin to a given destination where the path is constrained to use primary arcs, e.g., of a highway. The system also includes a method 700 (FIG. 7) for accessing the data structure to find such a shortest path. Methods 600, 700 are significantly faster at runtime than finding a shortest path or the length of a shortest path from scratch, as is conventional. In accordance with various aspects of the invention, preprocessing (also known as precomputation) is employed to achieve high computational performance at run time.
[0033] A highway is a road with limited access, i.e. the frequency of points along the road at which a vehicle could enter or leave the road is much lower than the frequency for an ordinary city street.
[0034] The input to the method for constructing the data structure is a graph representation of a road network, consisting of nodes and incident (directed) arcs, a table that indicates which arcs belong to highways, and an assignment of nonnegative numbers (costs or lengths) to the arcs. Note that algorithms and data structures are described in terms of arcs, but it is straightforward to modify the structures to work in terms of nodes instead of arcs for most purposes. [0035] The system whose methods are described with reference to FIGS. 57 can be used in concert with the systems and methods disclosed in commonlyowned co pending U.S. Application Ser. No. 10/039,539 entitled "Representations for Estimating Distance," incorporated herein by reference. The methods disclosed precompute a data structure that can subsequently be used to quickly estimate the length of the shortest path from a given origin to a given destination in a planar graph (or nearly planar graph). Since highways contribute to the nonplanarity of a roadnetwork graph, it is most effective to apply such a technique to a road network graph that is obtained by removing all highway arcs. Thus the method of the '539 application can be used to determine a nonhighway distance, with the other methods disclosed herein being used to determine the highway distance. Based on which of the two distances is smaller, the corresponding route can then be found using one of the two techniques. [0036] An advantageous enhancement can be carried out in which every maximal sequence of arcs ai , a_{2 /} . . . aι_{<} forming a directed path whose internal nodes all have in degree 1 and outdegree 1 (i.e. ai and aι+ι are the only arcs incident to their common endpoint) can be replaced by a single arc whose cost is the sum of the costs of the replaced arcs. This modification reduces the size of the graph. We call this modification trivialnode elimination. For the purpose of relating the modified graph to the new graph, tables can be constructed that map from replaced arcs to replacing arcs and vice versa.
[0037] A route is viewed in this case as consisting of three subpaths. For example, as may be better understood with reference to FIGS. 34, the route can consist of a subpath from an origin <A to a highway arc DH, a subpath from highway arc DH to another highway SL, and a subpath from highway arc to SL the destination Q>. We use one table to enable the finding of the first path. Lookups into this table enable the computer system to obtain from the origin a set of nearby highway arcs, the distances to each of them, and the first step towards each of them. Repeated lookups, therefore, enable the routing system to trace out a path to any of the highway arcs of the set. A similar table enables the system to find from the destination a set of nearby highway arcs. In accordance with a rule, a decision is made whether to include a particular highway arc in this set.
[0038] The exemplary data structure consists of two substructures, one for street highway routing and one for highwaytohighway routing. Method 500 constructs the data structures, with results in data sets 512, 522, 532. Later is described how a variation facilitates routing between distant regions. For the following, let S be the set of highway arcs.
[0039] STEP A  For each arc x, process 510 finds a set S+(x) of arcs defined according to the following rule. An arc y belongs to S+(x) if y belongs to S and the shortest path from x to y contains no arc in S other than y. For example, arc DH belongs to S+(AD) because DH belongs to S and the shortest path from AD to DH contains no arc in S other than DH (in case no intervening arc at all). As another example, arc SL belongs to S+(KM) because SL belongs to S and the shortest path from KM to SL contains no arc in S other than SL. (The intervening arc MS is not in S.)
[0040] Process 510 then finds the set H+(x) of triples (y, d, z), where y is an arc in S+(x), d is the distance from x to y, and z is the first arc not equal to x on the shortest xtoy path. For example, if x is arc AD, process 510 finds the set H+(AD) of triples (y, d, z), "where y is an arc in S+(AD), d is the distance from AD to y, and z is the first arc not equal to AD on the shortest ADtoy path, in this case DH. In the example, the only entry in H+(AD) is (DH,54.3,DH). Process 510 constructs a table indexed by arc where the entry corresponding to x contains a representation of H+(x).
[0041] STEP B  Similarly, process 520 finds a set S(x) of arcs defined according to the following rule. An arc y belongs to S(x) if y belongs to S and the shortest path from y to x contains no arc in S other than y. For example, arc HK belongs to S(MS) because HK belongs to S and the shortest path from HK to MS contains no arc in S other than HK. (The intervening arc KM is not in S.) As another example, arc NS belongs to S+(SQ) because NS belongs to set S and the shortest path from NS to SQ contains no arc in S other than NS, in fact no intervening arc at all. (Note that node S should not be confused with the set of highway arcs S.)
[0042] Process 520 finds the set H(x) of triples (y, d, z) where y is an arc in S(x), d is the distance from y to x, and z is the last arc not equal to x on the shortest path from y to x. For example, if x is arc MS, process 520 finds the set H(MS) of triples (y, d, z), here consisting of the single item (HK,35.1,KM), where y is an arc in S(MS), d is the distance from y to MS, and z is the first arc not equal to MS on the shortest ytoMS path, in this case KM. Process 520 construct a table (data set 522) where the entry corresponding to x contains a representation of H(x).
[0043] STEP C  For each pair of highway arcs x and y, process 530 lets f(x, y) denote the pair (d, P), where d is the distance from x to y, and P is the prefix of the shortest xtoy path such that P ends on the first highway arc after x. For brevity, P is called the xtoy prefix, though it does not include the arc x and is therefore not, strictly speaking, a prefix. Process 530 constructs a table (data set 532) that is indexed by pairs of primary, i.e., highway, arcs in which the entry corresponding to the pair (x, y) is f(x, y). The arbitrary convention used herein excludes from P the arc x itself; it involves only minor changes to include this arc.
[0044] For most highway arcs x and y, the first arc after x on the shortest xtoy path is another highway arc; in such a case, the xtoy prefix consists simply of that other highway arc. For some choices of x and y, however, the shortest xtoy path immediately leaves the highway and uses city streets before entering another highway, in which case the xtoy prefix consists of the portion of the path using city streets, together with the first subsequent highway arc. For example, the path from arc HK to arc SL of FIG. 4 immediately exits primary route 320, so the HKtoSL prefix consists of a sequence of nonhighway, i.e., secondary, arcs ending with a highway arc.
[0045] Method 600 quickly computes highway distance from any source arc to any destination arc. Method 600 includes: a first pair selection process 610, a second pair selection process 620, a summation process 630, and a minimum computation process 640. Method 600 ("Step A") finds the pair described by FIG. 12 for which the distance described by FIG. 11 is minimized.
[0046] Process 710 ("Step B") of runtime method 700 finds the shortest path PI from source node v to a suitable primary arc as follows: It initializes x to v and initializes PI to be the empty path. While x is not equal to yl, process 710 appends x to PI, finds the triple (y, d, z) in set H(x) whose first element y equals yl, and then sets x to z.
[0047] Process ("Step C") finds the shortest path P2 from y2 to node w as follows: It initializes x to w and initializes P2 to be the empty path. While x is not equal to Y2, it prepends P to P2, finds the triple (y, d, z) in setH (x) whose first element y equals 112, and set x to z.
[0048] Step D: Find the shortest path P3 from yi to y2 as follows.
[0049]  Initialize x := yl and initialize P3 to consist of the single arc yl.  while z is not equal to y2,
[0050] find the pair (d, P) that is equal to f (x, y2),
[0051] append P to P3,
[0052] Process x the last arc of P. Process 740 produces the output path as the concatenation P1:P3:P2.
[0053] The highway distance is the length of a shortest path that uses some highway arc.
[0054] Method 600 computes a minimum distance from source to destination from the equation of FIG. 11 by iterating through all pairs defined in the FIG. 12. Method 700 constructs a route from any arc v to any arc w whose length is the highway distance computed above.
[0055] Exemplary process for carrying out Step B begins with a process for constructing the table whose entries are the sets H(x). Initialize a table indexed by arc in which each entry is an empty collection. For each highway arc y, find a shortestpath tree rooted at y. (Each path down the tree corresponds to a shortest path in the graph.) Perform a depthfirst traversal of the shortestpath tree. For each arc x other than y reached, (1) add a triple (y, d, z) to the table entry corresponding to x, where d is the distance in the tree and z is the parent of x in the tree; and (2)the process traverses the children of x if (and only if) x is not a highway arc.
[0056] The tree traversal can be carried out using a recursive procedure of the following form. Here and in the following we use the convention that a node of a shortestpath tree (indicated by "treeNode") is a structure consisting of an arc of the graph (indicated by "treeNode.currentArc"), the arc associated with the parent node in the shortestpath tree (indicated by "treeNode.parentArc"), and the distance in the shortestpath tree from the root to the current arc (indicated by "treeNode. distance"). [0057] TABLE I traverse (treeNode) { add triple (y, treeNode . distance, treeNode.parentArc) to H (treeNode . currentArc) ; if treeNode.currentArc does not belong to S { for each child of treeNode { traverse (child) } } j
[0058] To carry out the traversal, for each tree node, "treeNode," that is a child of the root of the shortestpath tree, call "traverse(treeNode)."
[0059] Process 510 for step A to construct a table whose entries are the sets H+(x) is identical except that it uses a "reverse" shortestpath tree rooted at y, i.e. a tree in which each path up the tree corresponds to a shortest path in the graph.
[0060] Exemplary process 530 for carrying out Step C is as follows. For each highway arc x, (1) find a shortestpath tree rooted at x; (2) perform a depthfirst search traversal of the tree to find all arcs y such that y is a highway arc reachable from x, together with the pair (d, P) where d is the distance from x to y and P is the xtoy prefix. For each such arc y, insert the pair (d, P) into a table indexed by the pair (x, y).
[0061] The tree traversal can be carried out using a recursive procedure of the following form, illustrated by example with the pseudocode of TABLE II: [0062] TABLE II traverse (x, treeNode, pathCompleteFlag, path) { flag = pathCompleteFlag; newPath = if pathCompleteFlag then path else path with treeNode . currentArc appended if treeNode.currentArc is a highway arc { flag = true; insert into table the pair (treeNode . distance , newPath) with index (x, treeNode.currentArc);
} for each child of treeNode { traverse (x, child, flag, newPath) }
[0063] To carry out the traversal, for each child of the root of the shortestpath tree, process 530 makes a call to traverse with "treeNode" being the child, "pathCompleteFlag" being false, and "path" being the empty path. [0064] Using the basic representation, for a highway arc x, there is an entry in the table for each highway arc y reachable from x; the entry contains a path P, which is the xtoy prefix. Process 530 advantageously employs the observation that for each highway arc x, the same path P is used for many different highway arcs y. The system uses a parameter k, which should be set to a small positive number, e.g. two. [0065] The compact representation consists of three tables. The first table, Tl, is indexed by highway arcs x; the entry corresponding to a highway arc x is an ordered sequence of at most k distinct paths (we describe how to choose these paths later). The ^{'} second table T2 is, like the table used in the basic representation, indexed by pairs (x, y) of highway arcs. In this compact representation, however, the entry T2[x, y] corresponding to (x, y) is the pair (d, i), where d is the distance from x to y and i is a nonnegative integer less than or equal to k. The third table T3 is a set of keyvalue pairs, where each key is a pair (x, y) of highway arcs. If there is an entry with key (x, y), then the corresponding value is the xtoy prefix. [0066] The interpretation of the integer i is as follows. Recall that i can be 0, 1, 2, or k. If i < k then i is the index into Tl[x], and Tl[x] [i] is the prefix P of the shortest xtoy path such that P ends on the first highway arc after x. If i = k then table T3 contains an entry for (x, y), namely the xtoy prefix. (If i < k, then T3 does not contain such an entry.) This representation can be made more compact than the basic representation by choosing, for each highway arc x, the k paths P that are xtoy prefixes for the greatest number of highway arcs y. These "most popular" paths are stored in Tl [x], and others are stored in table T3.
[0067] Processes for selecting the prefixes and populate the tables used in the compact representation. First described are some procedures used in populating table Tl.
[0068] TABLE III
// pairSet indicates a set of pairs (g, P) , // where q is an integer and P is a path. trim(pairSet) { if pairSet consists of or fewer pairs { return pairSet; } else { return the subset of those k pairs (q, P) in pairSet having the highest values of g } } count (treeNode) { sum = 0 ; if treeNode.currentArc is a highway arc { sum = sum + 1 ;
} for each child of treeNode { sum = sum + count (child) ; } return sum; } traversall (treeNode, path) { pairSet = the empty set; for each child of treeNode { pairSet = trim(pairSet UNION popularPaths (child, path));
} return pairSet;
popularPaths (treeNode, path) { newPath = path with treeNode.currentArc appended if treeNode.currentArc is a highway arc { return the singleton set consisting of (count (treeNode) , newPath)
} return traversall (treeNode , newPath);
[00011] The procedure "count" returns the number of highway arcs that are descendants in the shortestpath tree of the given shortestpathtree node. The procedure "popularPaths" (which uses traversals as a helper function) finds the (at most k) most popular xtoy prefixes (for a fixed x), i.e. the prefixes that occur for the most y nodes. [0010] To populate table Tl, the exemplary method can perform the following acts. For each highway arc x, the method finds a shortestpath tree rooted at x; and calls "traversall" with "treeNode" being the root of the shortestpath tree and "path" being the empty path. The result of the call is a set of at most k pairs (q, P) where q is the number of occurences of P as the xtoyl prefix for some x; the pairs are those having the highest values of q. The method populates the entry of Tl corresponding to x with the paths P returned by the call. The method populates tables T2 and T3, for example as illustrated in the pseudocode of TABLE IV: [0011] TABLE IV f0 (x, treeNode, path) { for each child of treeNode { f1 (x, child, path) ; } } f1 (x, treeNode, path) { newPath = path with treeNode.currentArc appended if treeNode.currentArc is a highway arc { if newPath is among those in Tl [x] { i = position of newPath in Tl [x] } else { i = k; add an entry into T3 with key (x, treeNode.currentArc) and value newPath;
} f2 (x, treeNode, l) ; } else { f0 (x, treeNode, newPath); } } f2 (x, treeNode, i) { set T2 t ( ; treeNode.currentArc)] to be (treeNode . distance, i) ; for each child of treeNode { f2 (x, child, i) ;
} }
[0012] To populate T2 and T3, [0013] A routing system according to various aspects of the invention can advantageously support finding distances and routing where the origin and destination are in two different regions, e.g. different metropolitan areas.
[0014] Such a system also employs a graph representation of the road network, e.g., network data set 210 of FIG. 2. In addition, the system employs a preliminary routing data set, e.g., data set 230, that includes assignments of at most one region to each arc of the network data set. Such a system can accomodate arcs that are assigned to more than one region (arcs that cross region boundaries), as only small changes are needed, but for simplicity of presentation, the exemplary routing system discussed does not encounter any such arcs.
[0015] FIG. 8 illustrates identification of interregion arcs in accordance with the exemplary system. Two regions are illustrated with dashed boundaries. The bold segments are the interregion arcs, and the nonbold segments are external arcs that are not interregion arcs (arcs that do not lie on any shortest path from one region to another). Any arc within a region is referred to herein as an intraregion arc, and an arc not assigned any region is referred to as an external arc.
[0016] The routing system identifies arcs outside the regions that are useful in routing from one region to the other. Such arcs are herein called interregion arcs, a list of which is initialized as empty. For each intraregion arc x (optionally, each intraregion highway arc), the system (1) computes a shortestpath tree; (2) traverses the shortest path tree to identify external arcs that lie on a path between the root of the shortestpath tree and some arc lying in a region other than the region of arc x; and (3) adds each such external arc to the list of interregion arcs if it is not already on the list. The traversal can be carried out using a procedure illustrated with pseudocode of TABLE V: [0017] TABLE V isInterRegional (x, treeNode) { if treeNode.currentArc lies in a region other than x's { return true;
} flag = false; for each child of treeNode { flag = flag or isInterRegional (x, child);
} if flag and (treeNode.currentArc is an externalArc) { add treeNode.currentArc to the list of interregion arcs.
} return flag;
[0018] To carry out the traversal, the system calls the procedure " isInterRegional (x, treeNode)" with "treeNode" being the root of the shortestpath tree. After the interregion arcs have been identified, their number may be reduced using trivialnode elimination, as discussed above.
[0019] The data structures used for interregion routing are analogous to those used for primary path (e.g., highway) routing within a region, as discussed above. An inter region variation includes a table analogous to that constructed in Step A above. For an intraregion arc x, the system uses H+(x) to denote the set of triples (y, d, z) where y is an interregion arc such that the shortest path from x to y contains no interregion arc other than y, d is the distance from x to y, and z is the first arc not equal to x on the shortest xtoy path. The data structures include a table where there is an entry for each intraregion arc x and that entry is a representation of H+(x).
[0020] Similarly, there is a table analogous to that constructed in Step C above. This table has, for each pair of interregion arcs x and y, a. pair (d, P) where d is the distance from x to y, and P is the xtoy prefix. Alternatively, the table can employ the compact structure discussed above. The algorithms for constructing these tables and the algorithms for using them to find distances and routes are analogous to, and can be easily derived from, the algorithms given earlier. [0021] TABLE VI lists street arcs (i.e., secondary arcs) of simplified example network 300 (ξlGS. 34) with Euclidian (x,y) coordinates, Euclidian length, and cost, given an assumed 3x costtolength ratio. Coordinates, length, and cost were generated by the simulation code graph.tcl, listed below, which provides a simplified illustration of a variation of a routing method using primary and secondary arcs. [0022] TABLE VI
Street Arc Node,* Nodey Length Cost (3x)
AB 9,10) B: 17,3) 10.6 31.8 AC 9,10) C: 15,16) 8.5 25.5 AD 9,10) D: 11,28) 18.1 54.3 AE 9,10) E: 24,11) 15 45 BE 17,3) E: 24,11) 10.6 31.8 BF 17,3) F: 42,11) 26.2 78.6 BG 17,3) G: 62,7) 45.2 135.6 CD 15,16) D: 11,28) 12.6 37.8 EC 24,11) C: 15,16) 10.3 30.9 ED 24,11) D: 11,28) 21.4 64.2 EF 24,11) F: 42,11) 18 54 EH 24,11) H: 24,27) 16 48 FG 42,11) G: 62,7) 20.4 61.2 FI 42,11) I: 61,16) 19.6 58.8 GI 62,7) I: 61,16) 9.1 27.3 GJ 62,7) J: 71,14) 11.4 34.2 JI 71,14) I: 61,16) 10.2 30.6 J 71,14) : 72,31) 17 51 KM 41,27) M: 44,31) 5 15 KN 41,27) N: 35,38) 12.5 37.5 KP 41,27) P: 53,26) 12 36 LQ 72,31) Q: 73,36) 5.1 15.3 MP 44,31) P: 53,26) 10.3 30.9 MS 44,31) S: 50,34) 6.7 20.1 PI 53,26) H: 24,27) 29 87 PS 53,26) S: 50,34) 8.5 25.5 SQ 50,34) Q: 73,36) 23.1 69.3 [0023] TABLE VI lists street arcs (i.e., secondary arcs) of simplified example network 300 (FIGS. 34) with Euclidian (x,y) coordinates, Euclidian length, and cost, given an assumed 3x costtolength ratio, again from the simulation. [0024] TABLE VI
Highway Arc NodeΛ" Nodey Length Cost (2.*^
DH D: (11,28) H: (24,27) 13 26
HK H: (24,27) K: (41,27) 17 34
IL I: (61,16) L: (72,31) 18.6 37.2
KI K: (41,27) I: (61,16) 22.8 45.6 R L: (72,31) R: (82,31) 10 20
NS N: (35,38) S: (50,34) 15.5 31
SL S: (50,34) L: (72,31) 22.2 44.4
TN T: (13,51) N: (35,38) 25.6 51.2
UD U: (1,28) D: (11,28) 10 20
[0025] TABLE VII below lists contents of data sets 512, 522 (FIG. 5) as generated by the simulation code highway.tcl, listed below, which is part of the simulation providing a simplified illustration of a variation of a routing method using primary and secondary arcs.
[0026] TABLE VII
Arc H^{+} H
<A (DH,54.3,AD) (IL, 157.8 , AE)
<B (DH, 96.0, BE) (HK,79.8,BE) (IL, 137. , BF)
AD (DH,54.3,DH)
AE (IL,157.8,EF)
BE (DH, 96.0, ED) (HK,79.8,EH)
BF (IL,137.4,FI)
CD (DH,37.8,DH)
DH (HK,26.0,HK) (UD,26.0,UD)
ED (DH,64.2,DH)
EF (IL,112.8,FI)
EH (HK,48.0,HK)
FI (IL,58.8,IL)
GI (IL,27.3,IL)
HK (KI,34.0,KI) (NS,71.5,KN) (SL, 69.1, KM) (DH,34.0,DH)
IL (LR,37.2,LR) (KI,37.2,KI)
JI (IL,30.6,IL)
JL (LR,51.0,LR)
KI (IL,45.6,IL) (HK,45.6,HK)
KM (SL, 35.1, MS) (HK,15.0,HK)
KN (NS,37.5,NS) (HK,37.5,HK)
KP (HK,36.0,HK)
LQ (IL,15.3,IL) (SL,15.3,SL)
LR (IL,20.0,IL) (SL,20.0,SL)
MP (IL,69.3,PI)
MS (SL,20.1,SL) (HK, 35.1, KM)
NS (SL,31.0,SL) (TN,31.0,TN)
PI (IL,38.4,IL)
PS (SL,25.5,SL)
Q> (IL,15.3,LQ) (SL,15.3,LQ)
SL (LR,44.4,LR) (HK,79.5,MS) (NS,44.4,NS)
TN (NS,51.2,NS)
UD (DH,20.0,DH) [0027] H+ can include cost from the beginning of the first arc to the beginning of the last arc, or from the end of the first arc to the end of the last. In TABLE III, include first arc but not last. As shown DH is not included in dl, should be included in dl (H+) or d3 (P).
[0028] TABLE VIII below lists (d,P) for arcs indexed as f(x,y) in data set 532 (FIG. 5), as generated by the simulation code highway.tcl, listed below.
[0029] TABLE VIII
Highway Arcr Highway Arcy (d,P)
DH LR (133.5, HK)
DH SL (113.5,HK)
DH HK (34.0,HK)
DH KI (79.6,HK)
DH DH (0, :)
HK LR (99.5,KM:MS:SL)
HK SL (79.5,KM:MS:ΞL)
HK KI (45.6,KI)
HK HK (0, :)
IL LR (20.0,LR)
IL IL (0, :)
KI IL (37.2, IL)
KI LR (57.2, IL)
KI KI (0, :)
NS LR (64.4,SL)
NS SL (44.4, SL)
NS NS (0, :)
SL LR (20.0,LR)
SL SL (0, :)
TN NS (31.0,NS)
TN LR (95.4,NS)
TN SL (75.4,NS)
TN TN (0, :)
UD LR (159.5, DH)
UD SL (139.5, DH)
UD HK (60.0,DH)
UD KI (105.6, DH)
UD DH (26.0,DH)
UD UD (0, :)
[0030] The variation of the simulation introduces a special case, the null entry (0,:), which has a null path ":". The use of a null arc permits consideration of example source and destination nodes A,B,Q as "arcs" for purposes of illustration. [0031] Example A has the source node at A, destination at Q. The conventional
Dijkstra, as simulated, appears to call for a leastcost path of
<Q:AD:DH:HK:KM:MS:SL:LQ.
[0032] STEP A: The pair (yl,y2) with minimum sum dl+d2+d3+dyl is (DH,SL), as shown in TABLE IX below.
[0033] TABLE IX
W(v) H(w) (yl,y2) dl d2 d3 dyl Sum(d)
(DH,54.3,AD) (IL,15.3,LQ) (DH,IL) X X N/A X
(DH,54.3,AD) (SL, 15.3 , LQ) (DH,SL) 54.3 15.3 113.5 26 209.1
(IL,157.8,AE) (IL,15.3,LQ) (HK, IL) X X N/A X
(IL, 157.8,AE) (SL,15.3,LQ) (HK, SL) 157.8 15.3 79.5 34 286.6
[0034] STEP B: The simulation initially sets x to <A. It appends <A to the empty list PI, setting it to the single arc <A. It finds H+(<A) with y=DH, which is (DH,54.3,AD). It sets x to AD. Then it appends AD to PI, and finds H+(AD) with y=DH, which is
(DH,54.3,DH). The simulation then sets x to DH and stops because x is equal to yl. PI is thus <A:AD.
[0035] STEP C: The simulation initially sets x to Q>. It prepends Q> to P2, finds H(Q>) with y=SL, which is (SL,15.3,LQ). Set x to LQ. Now prepend LQ to P2, find H(LQ) with y=SL, which is (SL,15.3,SL). It sets x to SL and stops because x is now equal to y2. P2 is
LQ:Q>.
[0036] STEP D: The simulation initially sets both x and empty list P3 to DH. It finds f(DH,SL), which is (d,P)=(113.5,HK). It appends HK to P3 and sets x to the last arc of P, which is HK. It finds f(HK,SL), which is (d,P)=(79.5,KM:MS:SL). It appends KM:MS:SL to
P3. It sets x to SL, the last arc of P, and stops because x is now equal to y2. P3 is
DH:HK:KM:MS:SL.
[0037] STEP E: The leastcost path is the concatenation of P1:P3:P2, which is
<A: AD:DH:HK:KM:MS:SL:LQ:Q>, same as with the simulated Dijkstra solution. [0038] EXAMPLE II  The simulation starts at B, with destination Q. The simulated Dijkstra says <B:BF:FI:IL:LQ. (See dijkstra.tcl, listed below.)
[0039] STEP A  The minimumdistance pair is (IL,IL), as shown in TABLE X below. [0040] TABLE X
W(v) Εt{w) (yl,y2) dl d2 d3 dyl S m(d)
(DH, 96.0, BE) (IL,15.3,LQ) (DH,IL) X X N/A X
(DH, 96.0, BE) (SL,15.3,LQ) (DH,SL) 96.0 15.3 113.5 26 250.8
(HK, 79.8, BE) (IL,15.3,LQ) (HK,IL) X X N/A X
(HK, 79.8, BE) (SL,15.3,LQ) (HK,SL) 79.8 15.3 79.5 34 208.6
(IL,137.4,BF) (IL,15.3,LQ) (IL,IL) 137.4 15.3 0 37.2 189.9
(IL,137.4,BF) (SL,15.3,LQ) (IL,SL) X X N/A X
[0041] STEP B: The simulation sets both x and the empty list PI to <B. It finds H+(<B) with y=IL, which is (IL,137.4,BF). It sets x to BF. It then appends BF to PI, and finds H+(BF) with y=IL, which is (IL,137.4,FI). The simulation sets x to FI and appends FI to PI. It finds H+(FI) with y=IL, which is (IL,58.8,IL) and sets x to IL. It appends IL to PI and stops because x is equal to yl. PI is <B:BF:FI:IL.
[0042] STEP C: The simulation initially sets x to Q>. It prepends Q> to P2, finds H(Q>) with y=IL, which is (IL,15.3,LQ). It sets x to LQ, prepends LQ to P2, finds H(LQ) with y=ιL, which is (IL,15.3,IL), sets x to IL, and stops because x is equal to y2. P2 is LQ:Q>. [0043] STEP D: The simulation initially sets both x and P3 to IL. It finds (or infers) the null entry for f(IL,IL), which is simply (d,P)=(0,:), where ":" is a null arc. The simulation would append P to P3 and set x to the last arc of P, except that appending the null arc to empty list P3 leaves it empty. Setting x to IL makes x equal to y2, so the simulation stops after this single null operation, which need not be actually carried out. P3 remains an empty list, i.e., containing only a null arc.
[0044] STEP E: The leastcost path found by the simulation is concatenation of P1:P3:P2, here the same as P1:P2, which is <B:BF:FI:IL:LQ:Q>, same as the simulated Dijkstra solution. [00012] A routing system according to various other aspects of the invention computes a desirable path from a source node to a destination node, again by providing a network data set including indicia of a plurality of nodes and a plurality of arcs connecting the nodes and providing a preliminary routing data set. The preliminary routing data set according to these aspects of the invention includes indicia of a reach metric associated with each node. The reach metric for a given node is representative of potential for that node to be part of a desirable path between any permissible other nodes of the plurality of nodes. Responsive to input of a specified source and destination node of the plurality of nodes, such a system iteratively computes a desirable path from the source node toward the destination node. An associated reach metric is retrieved for each node that is initially considered as part of the desirable path. Nodes are not traversed via the considered node if the reach metric is below an applicable threshold, thus avoiding significant runtime processing for exploring candidate paths that are unlikely or unable to ultimately lead to a desirable path. [0100] "Reach" defines a process for computing routes on a changing network in an efficient way to satisfy a variety of requirements in a variety of applications including but not limited to locationbased services (LBS). Examples of these requirements are: (1) driving directions; (2) support for push services which alert users based on the position of objects moving in the network. Route computations are needed to determine by what time the position of an object must be obtained to avoid missing an alert condition, that is, the computation tells how close the object is to satisfying the alert condition (alerts); (3) support for proximity queries which tell users which of many locations (meeting some criteria) can be reached most quickly using a road network from a given location such as the location of the user himself (proximity search). [0011] Note that the invention is not limited to road networks. Routing systems according to various aspects of the invention can be applied to other kinds of networks with similar properties. [0012] Such a system computes routes in a network of nodes and links where the cost of traversing a link can change. In a road network, examples of such changes are: (1) portions of roads are closed or subject to delays due to construction or maintenance; (2) weather conditions hamper travel on roads or cause them to be closed;(3) large events, road closures, or the commute hours create congestion on the network.
[0013] The routes are computed based on the current state of the network, but need not necessarily take into account future changes to the network that might occur while a route is being followed. Simple wellknown algorithms can meet this requirement as long as a generous amount of computation is allowed. A system according to these aspects of the invention meets the requirement with an efficient process that takes very little computation to service a query.
[0014] This operation is conventionally difficult to do because most methods for computing routes quickly depend on auxiliary data that must be recomputed when there is a change to the network and recomputing the auxiliary data can be too expensive to. perform as quickly as the network changes. One wellknown approach for efficiently computing routes on road networks relies on road priorities that specify how important each road segment is for routing purposes. Interstate highways are deemed most important and residential roads least important. Several priority levels lie between these two extremes. With this information, a routing process can ignore minor roads far from the origin and destination of a route. By ignoring the very numerous minor roads, the process can execute much more quickly. Unfortunately, the road classifications are also invalidated by changes to the network. j NveNJrw/e [0015] The iτwerrtiθΛ'outing system replaces the conventional concept of road priority with a similar concept that permits reasonably fast update when there is change to the costs associated with links in the network. Here, we describe this concept, called reach, in terms of the nodes and links of a graph that represents a road network. Note that reach depends on another concept which is referred to herein as "length". Length might or might not be the metric used in computing paths or routes in the graph. To avoid confusion, the latter metric is referred to herein as cost and the paths that minimize cost are referred to as leastcost paths (instead of shortest paths). The weight of a link in the graph is the cost of the link; the length of a link might or might not be the same. Each node or link in the graph participates in leastcost paths of varying lengths, but many nodes and links only appear near the beginning or end of long leastcost paths, that is paths which are long but for which there is no lesser cost path for the same origin and destination. Only a few appear in the middle of long leastcost paths. Define herein is the "reach" of a node or link, which quantifies the ability of a node or link to appear in the middle of a long leastcost path. Here is the definition of the reach of a node in a weighted graph in which there is a concept of "length" independent of weight: [0016] Let P be any leastcost path in directed graph G with nonnegative weights and nonnegative lengths and let N be a node in P. Let R1(P,N) be the length of the portion of P from the origin of P to N. Let R2(P,N) be the length of the portion of P from N to the end of P. Let R(P,N) be the minimum of R1(P,N) and R2(P,N). The reach of a node N in graph G, R(G,N), is the maximum value of R(P,N) over all leastcost paths P in G containing N. More intuitively, any leastcost path containing a node N with reach R either begins R or fewer length units from N or ends R or fewer length units from N. [0017] Note that weights, not length, determine least cost paths. The definition of reach depends on a metric that defines the concept of "length" of a path. Possible interpretations of the meaning of "length", or "reach metric", in the definition as applied to a road network include but are not limited to: (1) the time it would take to travel the route represented by the path (2) the distance one would travel following the route represented by the path (3) other metrics that describe a cost of traveling the route represented by the path (4) the number of links and or nodes in the path. [0018] TABLE XI illustrates reach metrics computed, illustrative purposes with regard to a simplified "brute force" variation, by simulation code that is listed below ("reach.tcL ') for nodes in simplified network 300 of FIGS. 34. [0019] TABLE XI
Node Reach SLD[u :Q] d[A:u] Test in A:? d[B:u] Test in B:? c 0. 61.4 25.5 0 62.7 0
D 54.3 62.5 54.3 1 96 0
E 45 55 45 1 31.8 1
F 87.6 39.8 99 1 78.6 1
G 34.2 31 160.2 1 135.6 1
H 80.3 49.8 80.3 1 79.8 1
I 77.4 23.3 157.8 1 137.4 1
J 0 22.1 194.4 0 169.8 0
K 114.3 33.2 114.3 1 113.8 1
L 30 5.1 193.8 1 174.6 1
M 114 29.4 129.3 1 128.8 1
N 51.2 38.1 151.8 1 151.3 1
P 30.9 22.4 150.3 1 149.8 1
R 0. 10.3 213.8 0 194.6 0
S 96.3 23.1 149.4 1 148.9 1
[0020] The definition of the reach of a link is similar to reach of a node, but the reach metric is applied from the origin of a path to the starting node of the link and from the target node of the link to the end of the path.
[0021] The invention, is not limited to any particular reach metric and encompasses the concepts of node reach and link reach.
[0022] In many networks, the reach of most nodes is small while the reach of only a few nodes is large. A pathfinding process such as the Dijkstra process can be sped up by ignoring the many nodes whose reach is too small to be part of a path from the origin to the destination. For example, if the process has reached a node N at a length of LI from the origin and it can bet determined that any path from N to the destination is at least L2 in length, then N can be ignored if the reach of N is less than LI and less than L2. [0023] Various aspects of the invention include: (1) the concept of the reach of a node or link; (2) ways of computing the reach of each node or link in a network or an upper bound on the reach of each node or link; (3) ways of computing routes quickly using the reach of nodes or links; (4) additional mechanisms that work with or enhance routing algorithms using the reach of nodes or links; (5) efficient ways of applying the preceding means and mechanisms to proximity search and other LBS functions. [0024] In alert applications, routes must be computed from the position of the object being tracked to the boundary of some region, the alert region. The road network enters (or leaves) the region at some number of points. The position of the object might also be defined by a region since current positioning technologies cannot always determine a position accurately enough to represent it as a single point on the road network. The road network leaves the region defining the position of the object at some number of points. To process alerts, it is necessary to know the minimum time the object could take to reach the boundary of the alert region using the road network. Given the points on the road network at the boundaries of the two regions, one defining the position of the object and the other defining the alert region, the routing problem can be defined in this way: what is the leastcost route starting at any node in one set of nodes and terminating at any node in another set of nodes.
[0025] It does not matter how many nodes are in each of the sets of nodes; each set can be large or small. Also the nodes of either set can be close together or distributed widely. Driving directions requires a solution to a special case of this problem where both sets contain just one or two nodes.
[0026] Thus, a routing system according to these advantageous aspects of the invention provides the means for a single Dijkstra search to efficiently solve the general routing problem stated above.
[0027] Proximity searching involves a variant of this problem. In this case, the user will normally want to know not just the single most quickly reached of the suitable destinations, but a number of suitable destinations that are the most quickly reached. This requires the solution to several instances of the general routing problem stated above where the second problem is like the first problem but excludes the destination found in the solution to the first problem. Each succeeding problem excludes the destination found in the preceding solution. Advantageously, the inventive routing system provides the means by which these multiple routing problems can be solved efficiently using a single Dijkstra search.
[0028] In addition, such a system can include mechanisms that allow using the reach of nodes and links in combination with other techniques that speed up the Dijkstra routing process. These techniques include: (1) the A* process which focuses the search toward the destination(s); (2) bidirectional search which combines a search back from the destination(s) with a search forward from the origin(s)
[0029] In some cases, a bidirectional search can be more efficient than a single directional search. Routing algorithms that use road priorities to prune the search must be bidirectional. However, sometimes it is undesirable to use a bidirectional search, for example, when there is a large number of widely distributed destinations or origins. Included in this invention is a means to allow a single directional search to be used while pruning nodes (or links) based on their reach.
[0030] This invention also provides means for selecting among the various techniques described here depending on the routing problem presented.
[0031] Reachqualification routing systems and methods according to various aspects of the invention can include, inter alia, any suitable combinations of the following advantageous elements:
[0032] SELECTIVELY IGNORING NODES  Using the reach of nodes or of links (as defined above) to speed up computing of leastcost paths in a directed graph with non negative weights by allowing some nodes and links to be ignored. For this purpose, an upper bound on the reach of a node or link can be substituted for the exact reach. [0033] TRAVEL DISTANCE PRUNING  Choosing nodes to be ignored by applying the following pruning rule with "travel distance" defined according to the reach metric: if a search has found that the travel distance from the origin (or to the destination) to (from) a node is greater than the node's reach and if a lower bound estimate of the travel distance from (to) the node to (from) the destination (origin) is also greater than the node's reach, then ignore the node. Otherwise, do not ignore the node. Travel time can be employed as a reach metric in place of travel distance.
[0034] BIDIRECTIONAL SEARCH  Using bidirectional search and choose nodes to be ignored by applying the following pruning rule with travel distance defined according to the reach metric: if the search has found that the travel distance from the origin (or to the destination) to (from) a node is greater than the node's reach and if the search in the opposite direction has explored from all nodes whose travel distance from the destination (origin) according to the reach metric is greater than the node's reach, then ignore the node unless it has already been found by the search in the opposite direction. Otherwise, do not ignore the node.
[0035] ARCS  Assigning reach values to arcs rather than to nodes, in which case arcs can be ignored by applying suitable variants to the pruning rules described above for nodes.
[0100] DISTANCE METRIC  Using a single Dijkstra search (possibly conventional) to find the leastcost path among all paths whose origins lie in one set of nodes and whose destinations lie in another set of nodes. When the nodes of the graph have positions in some space with a distance metric, use travel distance as the reach metric and adapt the pruning rule of (2) by using the straightline distance from the node to the closest destination (or origin) as the lower bound estimate of the travel distance from (to) the node to (from) the destination (origin).
[0101] USING A* SEARCH METHOD  When searching forward to multiple destinations (or backward to multiple origins) in a graph whose nodes have positions in some space with a distance metric, using the A* method by basing the estimated cost of the path from (to) a node to (from) a destination (an origin) on the straightline distance to the closest destination (origin).
[0102] PROXIMITY SEARCH  Employing a proximity search to compute routes to the
N closest destinations to a location, as measured by the length of the leastcost path to each. When computing the closest destination (origin) by straightline distance, ignore destinations (origins) for which the leastcost route has already been discovered, but, to ensure correctness, only determine the closest destination (origin) once for any node, that is, when a node is first encountered by the search, note the destination (origin) used and when subsequently encountered use the same destination (origin) for the estimate even if a route to that destination has already been found. Instead of noting the destination used in the estimate for a node, the estimate itself can be noted and used when the node is subsequently encountered. The closest destination (or origin) can be determined using a spatial index, created at the beginning of the search, that supports nearest neighbor searches. A suitable basis for such a spatial index is a Voronoi diagram.
[0103] PRIORITY QUEUES  Determining the leastcost path as follows: (a) when a node has removed from the priority queues of both searches, cease adding nodes to the priority queues; (b) once (a) has occurred, continue the search but without adding nodes to the priority queues as stated in (a); (c) once (a) has occurred, note all instances in which a node is removed from the priority queues of both searches.; (d) when both queues are empty, select the leastcost path among the paths through the nodes noted in (c).
[0104] PATHFINDING METHOD, PARAMETER SELECTION  Selecting a path finding process or the parameters of a pathfinding process based on one or more of the following criteria: (a) the number of nodes in the set of origins; (b) the number of nodes in the set of destinations; (c) how widely distributed the origin nodes are; (d) how widely distributed the destination nodes are; (e) the straightline distance between the origin nodes and the destination nodes.
[0105] The above criteria can be employed to determine which of the following searches to perform: (a) a single directional search forward from the origin; (b) a single directional search backward from the destination; (c) a bidirectional search. [0106] The following principles can be followed in this determination: (a) if the number of destination nodes is large compared to the number of origin nodes, or if the destination nodes are widely distributed compared to the origin nodes, or if the destination nodes are widely distributed compared to the straightline distance between the origin nodes and the destination nodes, then favor a single directional search forward from the origin; (b) if the number of origin nodes is large compared to the number of destination nodes, or if the origin nodes are widely distributed compared to the destination nodes, or if the origin nodes are widely distributed compared to the straightline distance between the origin nodes and the destination nodes, then favor a single directional search backward from the destination; (c) if the distributions of the origin nodes and destination nodes are not wide compared to the straightline distance between the origin and destination nodes, or if the number of origin and destination nodes is not large, then favor a bidirectional search. [0107] REACH METRIC  Computing the reach of nodes or links in a directed graph with nonnegative lengths associated with each link as follows: (a) for each node in the graph, compute a leastcost path tree using the Dijkstra search process or other search process that computes a leastcost path tree with the node as the tree's root; (b) traverse each leastcost path tree computed in (a) starting at its root and accumulating the reach metric from the root to each node in the tree by adding these two values: (1) the reach metric accumulated from the root to the parent node of the node, and (2) the reach metric for the link from the parent node to the node; (c) during the traversal of each tree in (b), also accumulate the maximum reach metric from each node to the leaves of the tree by selecting the maximum value of such accumulated reach metric from among the child nodes of the node; (d) during the traversal of (b) and (c), compute the reach, within the leastcost path tree, of each node in the leastcost path tree as the minimum of the two values computed for the node in (b) and (c); (e) for each node in the graph, compute its reach as the maximum of the reach values computed for the node in (d) after traversing all leastcost path trees with a root in the graph.
[0108] REACH BOUNDS  Computing upper bounds on the reach of nodes or links of a graph to be used in place of the exact values in order to reduce computation time. This reduction can be realized by using the following process for nodes, or a similar process for arcs: (a) compute each leastcost path tree only far enough so that the reach of most nodes can be determined and compute the reach of those nodes; (b) form a subgraph that is the subset of the graph containing only the nodes whose reach was not computed in (a) or, alternatively, form the subgraph from the following: (1) nodes whose reach was not computed; (2) nodes with links to or from nodes whose reach was not computed; (c) in the subgraph formed in (b) compute leastcost path trees from each node far enough to compute upper bounds on the reaches, in the original graph, of most nodes in the subgraph formed in (b), using the leastcost path trees and the reach values already computed for nodes not in the subgraph to compute upper bounds on the reaches, in the original graph, of those nodes in the original graph; (d) continue to compute upper bounds on the reach of additional nodes by iterating steps similar to those of (b) and (c) using progressively smaller subsets of the original graph until the number of nodes for whom no upper bound has been computed is sufficiently small; (e) establish an upper bound on the reach of nodes for whose reach an upper bound has not been computed after the last iteration of (d) has completed as either infinity or some finite value which is known to be larger than the reach of any node in the original graph. [0109] LEASTCOST PATH TREE EXTENT  Determining how far to compute each leastcost path tree as follows: choose a reach value, say Rl, and compute each tree far enough that it contains all leastcost paths whose origin is the root of the leastcost path tree and whose length, according to the reach metric, minus the length of its first link is not more than 2 x Rl. It can be advantageous to further determine how far to compute each leastcost path tree by computing an upper bound on the length, according to the reach metric, of any leastcost path, P, with the following characteristics: for some node N, P includes N and is a continuous portion of a leastcost path Q such that the reach of N on Q equals the reach of N in the original graph, where P is entirely included in the subgraph in which the leastcost path trees will be computed. Still further, it can be advantageous to compute each tree far enough that it contains all leastcost paths whose origin is tihe root of the leastcost path tree and whose length is not more than the upper bound computed as discussed above.
[0110] SEPARATE UPPER BOUNDS  Compute a separate upper bound for each least cost path tree computed. It can be advantageous to compute upper bounds on the reach of nodes as follows: (a) for each leastcost path tree computed in the subgraph of the original graph do the following: (1) for each node in the original graph, but not in the subgraph, and having a link to the root node of the leastcost path tree, compute a sum by adding the reach of that node (computed in previous steps) and the length of the link from that node to the root node; and (2) determine and store the maximum sum; (b) for each leastcost path tree computed in the subgraph of the original graph do the following for each node in the tree: (1) for each node in the original graph, but not in the subgraph, and having a link from the node in the tree, compute a sum by adding the reach of that node (computed in previous steps) and the length of the link from the node in the tree; and (2) determine and store the maximum sum computed in (i) with the node in the tree; (c) traverse each leastcost path tree computed in the subgraph starting at its root and accumulating the reach metric from the root to each node in the tree by adding these two values: (1) the reach metric accumulated from the root to the parent node of the node (2) the reach metric for the link from the parent node to the node; (d) during the traversal of each tree in (c), also accumulate for each node in the tree the maximum of the following: (1) the value computed in (b) for the node; and (2) the maximum among all child nodes of the node of the sum of the length of the link to the child node and the value computed in this step (d) for the child node; (e) during the traversal of (c), compute an upper bound on the reach, within the leastcost path tree, of each node in the leastcost path tree as the minimum of these two values: (1) the sum of the reach metric computed for the node in (c) and the value computed in (a); and (2) the value computed in (d) for the node; (f) for each node in the subgraph, compute an upper bound on its reach as the maximum of the values computed for the node in (e) after traversing all leastcost path trees computed in the subgraph. [0111] ROAD FINDING  Performing leastcost path searching, again in accordance with any suitable combination of the elements above, to route finding in road networks. [0112] Knowing the reach of the nodes in a graph allows a routing process to avoid considering many nodes. An upper bound on the reach of each node can serve the same purpose as long as the upper bounds are reasonably close to the exact values. These upper bounds can be computed across the whole graph much more quickly than the exact reach values.
[0113] TABLE XII contains exemplary pseudocode for computing exact reach values: [0114] TABLE XII
* In table of reach values indexed by nodes, set reach of each node to 0.
* For each node in the graph {
* Compute a leas cost path tree that includes every node in the graph.
* Traverse the leastcost path tree performing the following at each node : {
* Compute the reach of the node on the path through the node from the root of the tree to the leaf.
* If reach of the node on that path is larger than the value of the node in the table: {
* Replace the table entry with reach value for the path.
} } _)
[0115] The cost of this process is 0(N*L*log(N)) for N nodes and L links if using the dijkstra process to compute the leastcost path tree with a heap as the priority queue. [0116] It can be shown that for nodes of short reach (i.e., a small reach value), reach can be computed using leastcost path trees that extend only a limited distance from the origin. In a road network, the majority of nodes have relatively short reach, so much less computation than the above process is needed to compute the reach of those nodes. Once the reach of those nodes is known, the information can be used to compute reach bounds of the remaining nodes. A graph that excludes the nodes of known reach can be formed and used to compute reach bounds of most of its nodes. The known values of reach make it possible to compute these bounds, and the computation is, again, much faster than the above process. When that is completed, a third iteration based on a still smaller graph can be used to compute reach bounds for additional nodes. This process can be repeated until the number of nodes for which a reach bound has not been computed is very small. The total number of iterations needed to achieve good routing performance on a road network ranges from 3 (a metropolitan area) to 5 (a large nation) and the total computation of those iterations is still much less than the above process. [0117] The total computation for computing reach bounds, with suitable optimizations, is vastly quicker than the above process for computing exact reach. The bounds are reasonably close (e.g., usually within 30%) to the true values for the reach metric. [0118] While the simplified example discussed above employs exact reach values, a routing system according to various aspects of the invention can achieve significant reduction in runtime computations by estimating the upper bound of a reach metric rather than competing its exact value. Such estimation may be better understood with reference to FIG. 9, which represents a least cost path, P, from an origin O to a destination D through a node N in a graph G.
[0119] Node N is a node whose reach is to be estimated. The path from node O to node D is a path for which the reach of N is maximum, that is, R(N,P) = R(N,G). Nodes on the path from D' through D are nodes for which a reach bound (which may equal the exact reach in some cases) has been previously computed. Nodes on the path from O to O' (excluding O' itself) are also nodes for which reach or a reach bound has been previously computed. The path P' from from O' to D' exists entirely in a subgraph Gi, which is used in the ith iteration of the computation. (The initial subgraph Gl is equal to graph G.
[0120] Gi can be configured such that D' is a node whose reach bound has been computed and O' is not. In such a configuration, Gi includes nodes with known reach bounds when there is a link to such a node from a node with unknown reach bound, but does not include other nodes with known reach bounds. That decision leads to the particular approach described here and it has some advantages. It is also possible to exclude all nodes with known reach bounds, such as D^{1}, from Gi and that would lead to a similar but different theory and process with its own advantages. That alternate approach is not described here.
[0121] k is the length, according to the reach metric, of the first link in P'. L is the length of the last link in P'. m is the length of link from node M to node O'. [0122] There are two results from the theory that are used in the algorithms for computing reach bound: (1) an "inclusion" rule that determines how far a leastpath tree must be extended. The rule is applied to a node to determine whether a node needs to be included in the tree; and (2) a formula for the upper bound of the reach of node N on any path in G that includes the path from O' to D'.
[0123] There are two more quantities to define before giving the inclusion rule and the reach bound formula. Ri is maximum reach bound computed for any node in G upon the completion of iteration i. Ri' is a parameter of the process that controls how much each iteration will attempt to do. If it is large then the ith iteration will compute larger leastcost path trees and will also be able to compute reach bounds for more nodes. If it is smaller, it will compute smaller leastcost path trees and fewer reach bounds. Each leastcost path tree in the ith iteration is extended far enough that, for any node N in Gi for which R(N,Gi) < Ri', a reach bound for N in G can be computed from those leastcost path trees. Rl' = Rl. Thus Ri', provides the test that determines for which nodes the reach bound is known. The inclusion is rule is formulated to ensure this test is correct in addition to ensuring that the formula for reach bounds is correct.
[0124] The inclusion rule determines for any node whether it needs to be included in the leastcost path tree. The dijkstra process that computes the tree is modified to apply the inclusion rule to each node it encounters and when there are no nodes in the priority queue that satisfy the inclusion rule, the dijkstra process is terminated. It is known at that point, that, if the search were continued, no subsequently encountered nodes would satisfy the rule. For a node E in Gi, the inclusion rule is satisfied in iteration i if rm(0',E, Gi) < 2Ri' + Ri1 + k + 1 + m, where rm(0',E,Gi) is the distance along the least cost path, in Gi, from O' to E according to the reach metric.
[0125] The formula for the upper bound of the reach of N on any leastcost path in G that includes the path from O' to D' is min ( R(M,G) + m + rm(0',N, P'), rm(N,D',P') + R(D',G) ), where rm(0',N, P') and rm(N,D',P) are the distances from O' to N and N to D', respectively, along the leastcost path P' from O' to D'. In the inclusion rule and the reach bound formula, it is more convenient to use upper bounds for m and R(M,G)+m in place of m and R(M,G)+m. Also an upper bound on R(D',G) is used in place of R(D',G).
[0126] The ith iteration of the reach bound computation takes as input the graph Gi and, for i>l, the reach bounds computed in iteration i1 or earlier iteration. In the process below, the previously computed reach bounds are provided in table R. R[N] is the previously computed reach bound for node N. TABLE XIII contains exemplary pseudocode for the iteration i>l:
[0036] TABLE XIII
Compute Ri as the maximum of all values in input table R Initialize a table, RB :
* For each node N in Gi
* RB [N] = 0 Initialize a table, RV:
* For each node N in Gi
* RV[N] = 0
For each node, 0', in Gi :
* Compute upper bounds on R(M,G)+m and m by examining all nodes, M, in G such tha :
* There is a link from M to O '
* A reach bound for M, R(M,G) , has been provided as input
* Let maxRm = the upper bound on R(M,G)+m
* Let max = the upper bound on m
* Compute a leastcost path tree in Gi rooted at O' until for all nodes E in the priority queue:
* rm(0',E, Gi) >= 2Ri ' + Ri1 + k + 1 + maxm
* Traverse the leastcost path tree computed in the previous step, for each node N in the tree:
* For each node D' which is a leaf in the tree and is descendant of N in the tree:
* Compute an upper bound, B, for the reach of N on any least cost path in G that includes the path P' in the tree from O^{1} to D ' ; use the following formula:
B = min ( maxRm + rm(0',N, P'), rm(N,D',P') + R[D'] )
* If this upper bound is greater than the bound stored in RB[N]
* RB [N] = B
* Compute the reach, V, of N in the leastcost path tree and if it is greater than R [N]
* RV[N] = V
[0100] Upon completion of the above process, RB[N] will be a valid reach bound for all nodes, N, in Gi such that RV[N] < Ri'. Thus table RB provides the inputs to iteration i+1. [0101] Iteration 1 is performed by a similar process. In that case O' is identical to O and D' is identical to D, and there is no input table R. TABLE XIV contains exemplary pseudocode for iteration i: 37] TABLE XIV
Initialize a table, RV:
* For each node N in GI
* RV[N] = 0
For each node, 0, in G:
* Compute a leastcost path tree in G rooted at 0 until for all nodes E in the priority queue:
* rm(0,E, G) >= 2R1' + k + 1
* Traverse the leastcost path tree computed in the previous step and for each node N in the tree :
* Compute the reach, V, of N in the leastcost path tree and if it is greater than RV[N] :
* RV[N] = V
PUBLIC NOTICE REGARDING THE SCOPE OF THE INVENTION AND CLAIMS [0038] The inventors consider various elements of the aspects and methods recited in the claims filed with the application as advantageous, perhaps even critical to certain implementations of the invention. However, the inventors regard no particular element as being "essential," except as set forth expressly in any particular claim. [0039] While the invention has been described in terms of preferred embodiments and generally associated methods, the inventors contemplate that alterations and permutations of the preferred embodiments and methods will become apparent to those skilled in the art upon a reading of the specification and a study of the drawings. [0040] Additional structure can be included, or additional processes performed, while still practicing various aspects of the invention claimed without reference to such structure or processes.
[0041]^{'} Accordingly, neither the above description of preferred exemplary embodiments nor the abstract defines or constrains the invention. Rather, the issued claims variously define the invention. Each variation of the invention is limited only by the recited limitations of its respective claim, and equivalents thereof, without limitation by other terms not present in the claim.
[0042] In addition, aspects of the invention are particularly pointed out in the claims using terminology that the inventor regards as having its broadest reasonable interpretation; the more specific interpretations of 35 U.S.C. § 112(6) are only intended in those instances where the terms "means" or "steps" are actually recited. As— βne
[0043] The words "comprising," "including," and "having" are intended as open ended terminology, with the same meaning as if the phrase "at least" were appended after each instance thereof. A clause using the term "whereby" merely states the result of the limitations in any claim in which it may appear and does not set forth an additional limitation therein. Both in the claims and in the description above, the conjunction "or" between alternative elements means "and/ or," and thus does not imply that the elements are mutually exclusive unless context or a specific statement indicates otherwise.
SIMULATION COMPUTER PROGRAM LISTING ### Written by Edwin A. Suominen, Copyright (c) 2003 Wavemarket Inc. ### FILE: graph.tcl package require struct if { [info exists g] } { catch { $g destroy } }; set g [:: struct :: graph] proc insert { node } { global g if { 1 [$g node exists $node] } { $g node insert $node } } proc length { x y } { foreach i {θ l} j {a b} { set $j [expr { abs ( [lindex $x $i]  [lindex $y $i] ) }] } return [expr { 0. l*round (10*sqrt ( $a * $a + $b * $b ) ) }] } ## Define the graph # First by a node adjacency list, with Euclidian coordinates... set nodes { <,9,10,A A,9,10,BCDE (,17,3,B B,17,3,EFG C,15,16,D' D,11,28,H E,24,11,CDFH F,42,11,IG G,62,7,IJ H,24,27,K I, 61, 16, L J,71,14,IL K,41,27,IMNP L,72,31,QR M, 44, 31, PS N,35,38,S P, 53, 26, SI Q,73,36,> >,73,36, R,82,31, S,50,34,QL T,13,51,N U,1,28,D } # ...then by highway arcs set hares { UD DH HK KI IL LR TN NS SL } ## Build the graph data structure # First defining nodes, node keys, and arcs... foreach i $nodes { foreach j {node x y toList} k [split $i , ] { set $j $k } # Insert node if not already inserted as somebody's neighbor insert $node # Set Euclidian coordinates $g node set $node key coords [list $x $y] # Set downstream neighbor nodes and arcs to them foreach j [split $toList ""] { insert $j ; $g arc insert $node $j "$node$j" } } # ...then setting arc keys if { [info exists text] } { unset text } foreach i [lsort [$g arcs]] { append text "\n$i" foreach j { 0 1 } k {x y} { set node [string index $i $j ] append text \ " \t$node : ( [j oin [ set $k [$g node get $node key coords] ] , ] ) " } # Set Euclidian length of arc $g arc set $i key length [set length [length $x $y] ] append text "\t$length" # Set cost of arc (2xlength for highway arcs, 3x otherwise) set test [expr { [lsearch $harcs $i] == 1 }] $g arc set $i key cost \ [set cost [expr { $test ? 3*$length : 2*$length }]] $g arc set $i key hwy [set hwy [expr { $test ? 0 : 1 }]] append text "\t$cost\t$hwy" } set dashes [string repeat  65] puts "Arc\tNode x\t\tNode y\t\tLength\tCost\tHwy\n$dashes$text\n$dashes"
### FILE: dijkstra.tcl # Conventional leastcost path search for directed graph proc nset {name v args} { foreach {key val} $args { $name node set $v key $key $val } } proc init_single_src {name s } { if { [lsearch [set nodes [ $name nodes] ] $s] ==  1 } { error " ' $s ' is not a node of $name " } foreach i $nodes { if { [string match $s $i] } { nset $name $i d 0 p Nil ;# Source Node } else { nset $name $i d 9999 p Nil } nset $name $i dijkstra_s Q } } proc extract_min {name} { set dmin 9999; set nodes [$name nodes key dijkstra_s value Q] # Search through [Q]ueue for node with miminum d foreach i $nodes { if { [set d [$name node get $i key d] ] < $dmin } { set dmin $d; set node $i } } # Extract minimum from queue by moving to set "S" if { [info exists node] } { nset $name $node dijkstra_s S , return $node } } 92 proc relax {name dir u v} {
93 foreach i { du dv} j {u v} { set $i [$name node get [ set $j ] key d] }
94 set wuv [ $name arc get \
95 [expr { $dir == " out " ? " $u$v" : " $v$u" } ] key cost]
96 if { $dv > $du + $wuv } { nset $name $v d [expr { $du + $wuv } ] p $u }
97 )
98 ## Add new 'dijkstra' method for graph object
99 ## graphName dijkstra ? reverse? origin ?destination?
100 ## * Requires all arcs to have a "cost" key
101 ## * Adds or updates " [d] istance from origin", " [p] redecessor" keys to nodes
102 ## * Creates & destroys " [dijkstra_s] et" node keys for internal computations
103 ## Returns { {v d[v] p [v] } ...} or <leastcost path list> if destination given
104 if { [lsearch $:: struct :: graph :: commands "dijkstra"] == 1 } {
105 lappend :: struct : : grap :: commands "dijkstra"
106 }
107 proc : : struct : : graph : : _dij kstra {name args } {
108 if { [lindex $args 0 ] == " reverse " } {
109 set dir " in" ; set args [lrange $args 1 end]
110 } else { set dir " out " }
111 init_single_src $name [lindex $args 0]
112 while { [llength [ $name nodes key dij kstra_s value Q] ] } {
113 if { [string length [set u [extract_min $name] ] ] } {
114 foreach v [ $name nodes  $dir $u] { relax $name $dir $u $v }
115 } else { break }
116 }
117 if { [llength $args ] == 1 } { 118 foreach node [$name nodes key dij kstra_s value S] { 119 lappend result [list $node [ $name node get $node key d] \ 120 [$name node get $node key p] ] 121 } 122 set result [Isort real decreasing index 1 $result]
123 } else { 124 set p [$name node get [set node [lindex $args 1] ] key p] 125 set result $node 126 while { ! [string match Nil $p] } { 127 set result [linsert $result 0 $p] 128 set p [$name node get $p key p] 129 } 130 } 131 foreach node [$name nodes key dijkstra_s] { 132 $name node unset $node key dijkstra_s 133 } 134 return $result 135
136 ### FILE: highway.tcl 137 package require Tclx
138 proc a2n { arc x } { return [string index $arc $x] }
139 proc arclistify { dir IctList } {
140 global ; while { [$m rows] } { $m delete row 0 }
141 $m add rows [llength $lctList]
142 $m set rect 0 0 $lctList; set arcs_lct {}
143 foreach begin [$m get column 2] end [$m get column 0] {
144 if { $begin != "Nil" } {
145 lappend arcs_lct \
146 [expr { $dir == " out " ? " $begin$end" : " $end$begin" } ]
147 }
148 }
149 return $arcs_lct
150 }
151 proc update_column { var x } {
152 upvar $var y
153 foreach i $x {
154 if { [lsearch $y [set z "([join $i ,])"]] == 1 } { lappend y $z }
155 }
156 }
157 proc walk_lct_P {name arc_root arc_this arcs_lct} {
158 set arcs_next [lindex [intersect3 \
159 [$name arcs out [a2n $arc_this 1] ] \
160 $arcs_lct ] 1]
161 puts "P\t$arc_root\t$arc_this\t [join [lsort $arcs_next] ,]"
162 # Traverse next arcs, i.e., adjacent and in LCT. Consider "this arc" as
163 # our first "next arc" to permit singlearc highway paths
164 foreach arc [concat $arc_this $arcs_next] {
165 # If next arc is hwy, add (d,P) triple for root arc, keyed to next arc
166 if { [$name arc get $arc key hwy] } {
167 set d [$name node get [a2n $arc 1] key d]
168 # P is list of all arcs in leastcost path from root to
169 # this next arc up to and including the first hwy arc
170 # To get path, we need to start at this next arc and work
171 # backwards toward root along path identified by Dijkstra
172 set node [a2n $arc 1] ; set mode [a2n $arc_root 1] , set P {}
173 while { $node != $rnode } {
174 set prev [$name node get $node key p]
175 if { [$name arc get "$prev$node" key hwy] } {
176 # This is hwy arc, so disregard all coming after in path
177 set P "$prev$node"
178 } else {
179 # Not hwy arc, so insert this arc ahead of any others
180 set P [linsert $P 0 "$prev$node"]
181 • }
182 set node $prev
183 }
184 $name arc set $arc_root key P_$arc [list $d $P] 185 }
186 # Traverse further (depth first) , whether or not this next arc is hwy
187 if { $arc != $arc_this } { walk_lct_P $name $arc_root $arc $arcs_lct }
188 }
189 }
190 proc walk_lct_H { name dir arc_root arc_this arcs__lct } {
191 set digit [expr { $dir == "out " ? 1 : 0 } ]
192 set arcs_next [ lindex [intersect3 \
193 [$name arcs  $dir [a2n $arc_this $digit] ] \
194 $arcs_lct ] 1]
195 puts " $dir\t$arc_root\t$arc_this\ [j oin [Isort $arcs_next] , ] "
196 # Traverse the next arcs , i . e . , those that are adj acent and in LCT
197 foreach arc $arcs_next {
198 # Add the (y, d , z ) triple for this next arc
199 $name arc lappend $arc key \
200 [expr { $dir == " out " ? "H_minus " : "H_plus " } ] \
201 [list $arc_root [ $name node get [a2n $arc $digit] key d] \
202 $arc_this]
203 # Traverse further (depthfirst) , if this next arc is not hwy
204 if { ! [$name arc get $arc key hwy] } {
205 walk_lct_H $name $dir $arc_root $arc $arcs_lct
206 }
207 }
208 }
209 if { [info exists m] } { $m destroy }
210 set m [:: struc :: matrix] ; $m add columns 3
211 foreach hare [$g arcs key hwy value 1] {
212 ## Starting from end of hwy arc, do Dijkstra to update
213 ## nodes' d [u] values and obtain list of arcs in leastcost tree
214 set IctList [$g dijkstra [a2n $harc 1]]
215 # Get list of arcs in leastcost tree
216 set arcs_lct [arclistify out $lctList]
217 # Walk through arcs, appending (y,d,z) triples to y key H_minus
218 walk_lct_H $g out $harc $harc $arcs_lct
219 }
220 foreach hare [$g arcs key hwy value 1] {
221 ## Dijkstra, searching *backwards*, starting from beginning of hwy arc
222 set IctList [$g dijkstra reverse [a2n $harc 0]]
223 # Get list of arcs in leastcost tree
224 ^{"}set arcs_lct [arclistify in $lctList]
225 # Walk through arcs, appending (y,d,z) triples to y key H_plus
226 walk_lct_H $g in $harc $harc $arcs_lct
227 }
228 foreach hare [$g arcs key hwy value 1] {
229 ## Dijkstra, starting from end of hwy arc 230 set IctList [ $g dij kstra [a2n $harc 1]
231 # Get list of arcs in leastcost tree
232 set arcs_lct [arclistify out $lctList ]
233 # Walk through arcs , appending ( d, P) pairs to x key P_<y>
234 walk_lct_P $g $harc $harc $arcs_lct
235 }
236 ## Tabulate precomputed data
237 catch {unset text}
238 foreach arc [Isort [$g arcs ] ] {
239 append text "\n$arc"; foreach i {plus minus} { set H_$i "" }
240 foreach {i j} [$g arc getall $arc] {
241 switch glob $i {
242 H_ρlus { update_column H_plus $j }
243 H_minus { update_column H_minus $j }
244 }
245 }
246 append text \
247 " \t [j oin [Isort  index 0 $H_plus] ] \t [ j oin [Isort  index 0 $H_minus] ] "
248 }
249 puts "Arc\tH+\tH\n [string repeat  65] $text\n [string repeat  65]"
250 catch {unset text}
251 foreach hare [Isort [$g arcs key hwy value 1] ] {
252 foreach {i j} [$g arc getall $harc] {
253 if { [string match P_* $i] } {
254 append text "\n$harc\t [string range $i 2 end] \t( [join $j ,])"
255 } } }
256 puts "\nArc x\tArc y\t (d, P) \n [string repeat  65] $text\n [string repeat  65]"
257 ## FILE: reach. tcl
258 ## Bruteforce computation of reach for each node
259 if { [info exists m] } { $m destroy }
260 set m [:: struc : :matrix] ; $m add columns 3
261 set dashes [string repeat  65]
262 ## Compute reach for each nonnull node
263 set nodes [Isort [$g nodes] ] ; set nodes [Irange $nodes [lsearch $nodes A] end]
264 foreach i $nodes { $g node set $i key R 0 }
265 # All possible combinations of source node and destination nodes
266 foreach i $nodes {
267 foreach j $nodes {
268 # Update prospective reach for all nodes along leastcost path
269 if { [llength [set nodes_lct [$g dijkstra $i $j]]] > 2 } {
270 foreach u [Irange $nodes_lct 1 end1] {
271 set Rl [$g node get $u key d]
272 set R2 [length [$g node get $u key coords] \
273 [$g node get $j key coords] ]
274 # Maximum of previous R value and present local minimum
275 set R [expr { $R1 < $R2 ? $R1 : $R2 }]
276 if { [set old_R [$g node get $u key R] ] < $R } {
277 $g node set $u key R $R
278 } } } } }
279 ## Display table of results
280 puts "Node\tReach\tSLD\ [u:Q\] \td\ [A:u\] \tA?\td\ [B:u\] \t?B\n$dashes"
281 array unset REACH
282 foreach i {A B} {
283 $g dijkstra $i
284 foreach j' $nodes { set REACH($j.$i) [$g node get $j key d] }
285 }
286 set coords_Q [$g node get Q key coords]
287 foreach i $nodes {
288 set R [$g node get $i key R]
289 set xl $REACH($i.A) ; set x2 $REACH($i.B)
290 set x3 [length [$g node get $i key coords] $coords_Q]
291 set Tl [expr { $R >= $xl   $R >= $x3 }]
292 set T2 [expr { $R >= $x2 j j $R >= $x3 }]
293 puts "$i\t$R\t$x3\t$xl\t$Tl\t$x2\t$T2"
294 }
Claims
Priority Applications (2)
Application Number  Priority Date  Filing Date  Title 

US36332202 true  20020312  20020312  
US60/363,322  20020312 
Publications (1)
Publication Number  Publication Date 

WO2003079155A1 true true WO2003079155A1 (en)  20030925 
Family
ID=28041751
Family Applications (1)
Application Number  Title  Priority Date  Filing Date 

PCT/US2003/007781 WO2003079155A1 (en)  20020312  20030312  Searchlimited leastcost routing system 
Country Status (1)
Country  Link 

WO (1)  WO2003079155A1 (en) 
Cited By (2)
Publication number  Priority date  Publication date  Assignee  Title 

US7957894B2 (en)  20051109  20110607  Harman Becker Automotive Systems Gmbh  Optimum route determination with tiling 
US8014941B2 (en)  20060613  20110906  Harman Becker Automotive Systems Gmbh  Optimum route determination employing an estimation function 
Citations (11)
Publication number  Priority date  Publication date  Assignee  Title 

US4967345A (en) *  19880623  19901030  International Business Machines Corporation  Method of selecting least weight routes in a communications network 
US5117422A (en) *  19900709  19920526  Itt Corporation  Method for providing an efficient and adaptive management of message routing in a multiplatform and apparatus communication system 
US5561790A (en) *  19920324  19961001  International Business Machines Corporation  Shortest path determination processes for use in modeling systems and communications networks 
US5596719A (en) *  19930628  19970121  Lucent Technologies Inc.  Method and apparatus for routing and link metric assignment in shortest path networks 
US5754543A (en) *  19960703  19980519  Alcatel Data Networks, Inc.  Connectivity matrixbased multicost routing 
US5870564A (en) *  19960301  19990209  Novell, Inc.  Nearoptimal path apparatus and method 
US5987521A (en) *  19950710  19991116  International Business Machines Corporation  Management of path routing in packet communications networks 
US6256295B1 (en) *  19970925  20010703  Nortel Networks Limited  Method and apparatus for determining multiple minimallyoverlapping paths between nodes in a network 
US6321271B1 (en) *  19981222  20011120  Lucent Technologies Inc.  Constrained shortest path routing method 
US6347078B1 (en) *  19970902  20020212  Lucent Technologies Inc.  Multiple path routing 
US6442615B1 (en) *  19971023  20020827  Telefonaktiebolaget Lm Ericsson (Publ)  System for traffic data evaluation of real network with dynamic routing utilizing virtual network modelling 
Patent Citations (11)
Publication number  Priority date  Publication date  Assignee  Title 

US4967345A (en) *  19880623  19901030  International Business Machines Corporation  Method of selecting least weight routes in a communications network 
US5117422A (en) *  19900709  19920526  Itt Corporation  Method for providing an efficient and adaptive management of message routing in a multiplatform and apparatus communication system 
US5561790A (en) *  19920324  19961001  International Business Machines Corporation  Shortest path determination processes for use in modeling systems and communications networks 
US5596719A (en) *  19930628  19970121  Lucent Technologies Inc.  Method and apparatus for routing and link metric assignment in shortest path networks 
US5987521A (en) *  19950710  19991116  International Business Machines Corporation  Management of path routing in packet communications networks 
US5870564A (en) *  19960301  19990209  Novell, Inc.  Nearoptimal path apparatus and method 
US5754543A (en) *  19960703  19980519  Alcatel Data Networks, Inc.  Connectivity matrixbased multicost routing 
US6347078B1 (en) *  19970902  20020212  Lucent Technologies Inc.  Multiple path routing 
US6256295B1 (en) *  19970925  20010703  Nortel Networks Limited  Method and apparatus for determining multiple minimallyoverlapping paths between nodes in a network 
US6442615B1 (en) *  19971023  20020827  Telefonaktiebolaget Lm Ericsson (Publ)  System for traffic data evaluation of real network with dynamic routing utilizing virtual network modelling 
US6321271B1 (en) *  19981222  20011120  Lucent Technologies Inc.  Constrained shortest path routing method 
Cited By (3)
Publication number  Priority date  Publication date  Assignee  Title 

US7957894B2 (en)  20051109  20110607  Harman Becker Automotive Systems Gmbh  Optimum route determination with tiling 
US9279692B2 (en)  20051109  20160308  Harman Becker Automotive Services Gmbh  Optimum route determination with tiling 
US8014941B2 (en)  20060613  20110906  Harman Becker Automotive Systems Gmbh  Optimum route determination employing an estimation function 
Similar Documents
Publication  Publication Date  Title 

Ravi  Rapid rumor ramification: Approximating the minimum broadcast time  
Pitoura et al.  Locating objects in mobile computing  
Cohen et al.  Reachability and distance queries via 2hop labels  
Jain et al.  Geographical routing using partial information for wireless ad hoc networks  
US7174328B2 (en)  Selective path signatures for query processing over a hierarchical tagged data structure  
Korkmaz et al.  Bandwidthdelay constrained path selection under inaccurate state information  
Roughgarden  Designing networks for selfish users is hard  
US6885937B1 (en)  Shortcut generator  
US7418505B2 (en)  IP address lookup using either a hashing table or multiple hash functions  
Stojmenovic et al.  Depth first search and location based localized routing and QoS routing in wireless networks  
US20040017783A1 (en)  Network topologies  
US20050204042A1 (en)  Requesting a service from a multicast network  
US20050050060A1 (en)  Data structure for rangespecified algorithms  
Guerin et al.  QoS routing in networks with inaccurate information: theory and algorithms  
US20030120622A1 (en)  Data packet filtering  
US20060039300A1 (en)  Method and apparatus for location discovery in mobile adhoc networks  
Sanders et al.  Engineering highway hierarchies  
US7415463B2 (en)  Programming tree data structures and handling collisions while performing lookup operations  
US7072304B2 (en)  Network path selection based on bandwidth  
US6646989B1 (en)  Hopbyhop routing with nodedependent topology information  
GarciaLunaAceves et al.  Distributed, scalable routing based on vectors of link states  
Bell  Alternatives to Dial's logit assignment algorithm  
Mouratidis et al.  Anonymous query processing in road networks  
US20070156326A1 (en)  Usercontrolled alternative routing  
Jing et al.  Hierarchical encoded path views for path query processing: An optimal model and its performance evaluation 
Legal Events
Date  Code  Title  Description 

AK  Designated states 
Kind code of ref document: A1 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SC SD SE SG SK SL TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW 

AL  Designated countries for regional patents 
Kind code of ref document: A1 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG 

121  Ep: the epo has been informed by wipo that ep was designated in this application  
122  Ep: pct application nonentry in european phase  
NENP  Nonentry into the national phase in: 
Ref country code: JP 

WWW  Wipo information: withdrawn in national office 
Country of ref document: JP 