WO2003079155A1 - Search-limited least-cost routing system - Google Patents

Abstract

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 (210) 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 (230) set is further provided, which includes indicia of least-cost paths between each node of a primary arc. Responsive to input 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.

Description

SEARCH-LIMITED LEAST-COST 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 Road-Distance Computation and

Routing for Routes That Use Highways" filed March 12, 2003 and assigned Serial No.

60/363,322.

BACKGROUND OF THE INVENTION

[0002] Least-cost 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 least-cost 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 least-cost path within a full set of interconnected nodes, new and expanding applications of least-cost 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 least-cost 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 least-cost 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 least-cost 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 sub-set 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 speed-increase 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 least-cost 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 least-cost 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., least-cost) 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 directed-graph representation of a small roadway network, including primary and secondary roadways, illustrating nodes that are referenced in simplified examples of least-cost routing.

[0014] FIG. 4 illustrates arcs of the directed-graph 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 region-to-region 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 reach-based 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 least-cost 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 pre-processor 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. 3-4. The indicia includes Euclidean (x,y) coordinates of nodes in the network, e.g., nodes A-Q 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] Pre-processor 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. 3-4.

[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 re-run, if such major changes require new a priori routing computations for runtime routing processes 240-250 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 re-run. An example of a situation where process 280 might be able to work effectively with requiring pre-run 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., least-cost) 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. 5-7. [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 least-cost secondary-to-primary path pre-computation process 510, a least-cost primary-to- secondary path pre-computation process 520, and a least-cost primary-to-primary path pre-computation 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 least-cost 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 run-time 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. 5-7 can be used in concert with the systems and methods disclosed in commonly-owned 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 road-network 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 non-highway 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 out-degree 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 trivial-node 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. 3-4, 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 highway-to-highway 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 x-to-y 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 AD-to-y 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 y-to-MS 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 x-to-y path such that P ends on the first highway arc after x. For brevity, P is called the x-to-y 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 x-to-y path is another highway arc; in such a case, the x-to-y prefix consists simply of that other highway arc. For some choices of x and y, however, the shortest x-to-y path immediately leaves the highway and uses city streets before entering another highway, in which case the x-to-y 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 HK-to-SL prefix consists of a sequence of non-highway, 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 run-time 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 shortest-path tree rooted at y. (Each path down the tree corresponds to a shortest path in the graph.) Perform a depth-first traversal of the shortest-path 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 shortest-path 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 shortest-path tree (indicated by "treeNode.parentArc"), and the distance in the shortest-path 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 shortest-path 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" shortest-path 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 shortest-path tree rooted at x; (2) perform a depth-first 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 x-to-y 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 shortest-path 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 x-to-y 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 key-value 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 x-to-y 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 x-to-y 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 x-to-y 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 x-to-y 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 shortest-path tree of the given shortest-path-tree node. The procedure "popularPaths" (which uses traversals as a helper function) finds the (at most k) most popular x-to-y 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 shortest-path tree rooted at x; and calls "traversall" with "treeNode" being the root of the shortest-path 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 x-to-yl 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 inter-region arcs in accordance with the exemplary system. Two regions are illustrated with dashed boundaries. The bold segments are the inter-region arcs, and the non-bold segments are external arcs that are not inter-region 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 intra-region 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 inter-region arcs, a list of which is initialized as empty. For each intra-region arc x (optionally, each intra-region highway arc), the system (1) computes a shortest-path tree; (2) traverses the shortest- path tree to identify external arcs that lie on a path between the root of the shortest-path 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 inter-region 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 inter-region arcs.

} return flag;

[0018] To carry out the traversal, the system calls the procedure " isInterRegional (x, treeNode)" with "treeNode" being the root of the shortest-path tree. After the inter-region arcs have been identified, their number may be reduced using trivial-node elimination, as discussed above.

[0019] The data structures used for inter-region 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 intra-region arc x, the system uses H+(x) to denote the set of triples (y, d, z) where y is an inter-region arc such that the shortest path from x to y contains no inter-region 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 x-to-y path. The data structures include a table where there is an entry for each intra-region 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 inter-region arcs x and y, a. pair (d, P) where d is the distance from x to y, and P is the x-to-y 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. 3-4) with Euclidian (x,y) coordinates, Euclidian length, and cost, given an assumed 3x cost-to-length 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. 3-4) with Euclidian (x,y) coordinates, Euclidian length, and cost, given an assumed 3x cost-to-length 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 least-cost 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 least-cost 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 minimum-distance 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 least-cost 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 location-based 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 well-known 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 re-computing the auxiliary data can be too expensive to. perform as quickly as the network changes. One well-known 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 NveNJ-rw/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 least-cost 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 least-cost paths of varying lengths, but many nodes and links only appear near the beginning or end of long least-cost 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 least-cost 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 least-cost 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 least-cost path in directed graph G with non-negative weights and non-negative 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 least-cost paths P in G containing N. More intuitively, any least-cost 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. 3-4. [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 path-finding 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 least-cost 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) bi-directional search which combines a search back from the destination(s) with a search forward from the origin(s)

[0029] In some cases, a bi-directional search can be more efficient than a single directional search. Routing algorithms that use road priorities to prune the search must be bi-directional. However, sometimes it is undesirable to use a bi-directional 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] Reach-qualification 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 least-cost 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] BI-DIRECTIONAL SEARCH - Using bi-directional 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 least-cost 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 straight-line 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 straight-line 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 least-cost path to each. When computing the closest destination (origin) by straight-line distance, ignore destinations (origins) for which the least-cost 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 least-cost 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 least-cost path among the paths through the nodes noted in (c).

[0104] PATH-FINDING METHOD, PARAMETER SELECTION - Selecting a path- finding process or the parameters of a path-finding 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 straight-line 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 bi-directional 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 straight-line 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 straight-line 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 straight-line distance between the origin and destination nodes, or if the number of origin and destination nodes is not large, then favor a bi-directional search. [0107] REACH METRIC - Computing the reach of nodes or links in a directed graph with non-negative lengths associated with each link as follows: (a) for each node in the graph, compute a least-cost path tree using the Dijkstra search process or other search process that computes a least-cost path tree with the node as the tree's root; (b) traverse each least-cost 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 least-cost path tree, of each node in the least-cost 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 least-cost 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 least-cost 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 sub-graph that is the subset of the graph containing only the nodes whose reach was not computed in (a) or, alternatively, form the sub-graph 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 sub-graph formed in (b) compute least-cost path trees from each node far enough to compute upper bounds on the reaches, in the original graph, of most nodes in the sub-graph formed in (b), using the least-cost path trees and the reach values already computed for nodes not in the sub-graph 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] LEAST-COST PATH TREE EXTENT - Determining how far to compute each least-cost path tree as follows: choose a reach value, say Rl, and compute each tree far enough that it contains all least-cost paths whose origin is the root of the least-cost 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 least-cost path tree by computing an upper bound on the length, according to the reach metric, of any least-cost path, P, with the following characteristics: for some node N, P includes N and is a continuous portion of a least-cost 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 sub-graph in which the least-cost path trees will be computed. Still further, it can be advantageous to compute each tree far enough that it contains all least-cost paths whose origin is tihe root of the least-cost 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 least-cost path tree computed in the sub-graph of the original graph do the following: (1) for each node in the original graph, but not in the sub-graph, and having a link to the root node of the least-cost 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 least-cost path tree computed in the sub-graph 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 sub-graph, 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 least-cost path tree computed in the sub-graph 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 least-cost path tree, of each node in the least-cost 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 sub-graph, compute an upper bound on its reach as the maximum of the values computed for the node in (e) after traversing all least-cost path trees computed in the sub-graph. [0111] ROAD FINDING - Performing least-cost 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 least-cost 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 least-cost 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 least-cost 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 run-time 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 sub-graph Gi, which is used in the i-th iteration of the computation. (The initial sub-graph 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¹, 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 least-path 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 i-th iteration will compute larger least-cost path trees and will also be able to compute reach bounds for more nodes. If it is smaller, it will compute smaller least-cost path trees and fewer reach bounds. Each least-cost path tree in the i-th 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 least-cost 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 least-cost 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' + Ri-1 + 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 least-cost 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 least-cost 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 i-1 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 least-cost path tree in Gi rooted at O' until for all nodes E in the priority queue:

* rm(0',E, Gi) >= 2Ri ' + Ri-1 + k + 1 + maxm

* Traverse the least-cost 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¹ 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 least-cost 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 least-cost 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 least-cost path tree computed in the previous step and for each node N in the tree :

* Compute the reach, V, of N in the least-cost 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 least-cost 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 <least-cost 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 single-arc 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 least-cost 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 (depth-first) , 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 least-cost tree

214 set IctList [$g dijkstra [a2n $harc 1]]

215 # Get list of arcs in least-cost 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 least-cost 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 least-cost 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 ## Brute-force 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 non-null 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 least-cost path

269 if { [llength [set nodes_lct [$g dijkstra $i $j]]] > 2 } {

270 foreach u [Irange $nodes_lct 1 end-1] {

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

CLAIMSWhat is claimed is:

1. A method for computing a desirable path from a source node to a destination node,

the method comprising:

(a) providing a network data set including indicia of a plurality of nodes and a

plurality of primary arcs connecting some of the nodes;

(b) providing a preliminary routing data set including indicia of desirable paths

between each node of a primary arc and conneted nodes that are not of a primary

arc; and

(c) responsive to input of a specified source and destination node of the

plurality of nodes, retrieving 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.

2. The method of claim 1 wherein the arcs are representative of roadways and the

primary arcs are representative of routes along a highway.

3. A method for computing a desirable path from a source node to a destination node,

the method comprising:

(a) providing a network data set including indicia of a plurality of nodes and a

plurality of arcs connecting the nodes; (b) providing a preliminary routing data set including indicia of a reach metric

associated with each node, wherein 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; and

(c) responsive to input of a specified source and destination node of the

plurality of nodes, iteratively computing a desirable path from the source node

toward the destination node, wherein (1) an associated reach metric is retrieved

for each node that is initially considered as part of the desirable path; and (2)

nodes are not traversed via the considered node if the reach metric is below an

applicable threshold.

4. The method of claim 1 wherein the applicable threshold is the lesser of (1) least-cost

path distance between the source node and the considered node and (2) straight-line

distance between the considered node and the destination node.

5. The method of claim 1 or 3 wherein the desirable path is a least-cost path.

6. The method of claim 1 or 3 further comprising repeating act (c) for different source

and destination nodes without repeating (a) and (b).