Method and system for fleet navigation, dispatching and multi-vehicle, multi-destination routing

Abstract

A system and method for multiple vehicles to be dispatched and routed to multiple destinations, with or without constraints, containing a software core, which uses bounded geographic regions (“BGRs”) and node Pairs to explicitly optimize, in two dimensions, for user desired dependent variables, by analyzing variance due to standard and user-defined independent variables. The invention stores node pair data, and can use error function, feedback, and ANOVA/manova to create a tightly convergent dispatching and navigation solution.

Description

FIELD OF INVENTION

This invention relates to the field of navigation route calculation and guidance, specifically multi-vehicle, multi-destinations solutions to a generalized navigation problem.

BACKGROUND OF INVENTION

Navigation systems contain certain required basics: input/output device(s); a processing unit, a navigation calculation core; geographic database usually including streets and Points of Interest (“POIs”); and a Global Positioning System chip-set to determine position; inter alia. For automotive systems, there is additionally a gyroscopic chip that provides heading and speed information. Significant disadvantages exist with current systems. Navigation systems built into vehicles by the OEMS require expensive hardware and software, which becomes obsolete far sooner than the car in which it is installed. Additionally, the on-board geographic database requires a storage medium, such as a hard-drive, which, relatively, are more prone to failure than other electronics components, and the database must be updated periodically.

Server-based navigation systems are those in which guidance algorithm is resident on a central processing unit or server. End users input navigation destinations using a variety of devices, including mobile phones, computers, portable navigation devices, embedded vehicle systems and mobile data terminals (“MDT”). The end user request is communicated to the server wirelessly, either via a mobile phone network, a satellite network, a Wi-Fi network, or mixed network containing both wireless and wired connections. The wireless link can be interrupted in a number of circumstances (e.g., tunnels, concrete canyons in the centers of major cities, in unpopulated areas, and at times of heavy wireless usage). Depending on how the system was configured, the amount of data that needs to be transmitted often overwhelms the wireless resource. Cellphone and personal navigation are similarly limited.

In any geographic region, there are a small number of sources for the navigation database information, itself. A navigation database will provide coordinates and names for streets, as well as defining a street-type for each road (e.g., residential, commercial, highway, interstate, etc.). Often, the navigation database will also include points of interest (“POIs”), which are local business, places of civic or historic significance, schools, churches, and other places frequented by the public. In the United States, the U.S. Census Bureau offers Topologically Integrated Geographic Encoding and Referencing system data (“TIGER data”). TIGER data does not contain a complete set of navigatable streets in the U.S., nor does it provide POIs. There are multiple commercial providers of navigation databases, who provide POIs and a substantially complete set of navigatable streets. The two largest, in the United States, are Navteq® and Tele Atlas®. Unless the text is specifically contrary, the use of POIs in this patent means the general idea of points of interests, rather than any specific, discrete collection of points of interests. In Korea and Japan, the navigation databases are government controlled. Other jurisdictions range from government-owned to private services providing the navigation databases. Additional navigation and navigation database competitors are rapidly entering the market, including Apple and Google. Additionally, the crowdsourcing revolution is impacting map databases. For example, MapBox is working on an open-source collaborative map database called OpenStreetMap. In general, at this point, almost all vehicular and mobile phone navigation relies on navigation software from one source, and a complimentary navigation database from another source. Almost always, a single entity bundles and sells the navigations components as a complete solution.

Despite its limitations, the last two decades have seen a proliferation of advanced electronics aimed at navigation. Two decades ago, most vehicles had very little electronic content, and cellphone or mobile phones were in their infancy. Today, the revolution in vehicle and wireless electronics has made global-positioning based navigation ubiquitous. However, the proliferation of options for consumers has not presented an optimized overall solution, yet. Most navigation solutions rely on computational cores which are more than a decade old.

All current navigation algorithms rely on one-dimensional optimization. All streets are represented by vectors of varying length and shape. Fundamentally there are two ways the current methods represent streets. In the first, all vectors are straight line vectors. Curves are decomposed into a number of straight line segments. In the second, curves and splines of one form or another are used to mimic the natural curvature of the roads.

In order to find a route, current algorithms piece-wise optimize in one dimension. Many individual algorithms exist to perform one-dimensional piece-wise navigation optimization, including, but not limited to, single-sided decision tree, double-sided decision tree, single-sided decision tree with gates, double-sided decision tree with gates, buckets, and leaky buckets. Multiple route segments are grown from either the origin or both the origin and the destination. The routes are compared with one another during the process, and a single or multiple rejection criteria are established to discard divergent solutions. Ultimately, a single route is grown between the origin and the destination, either meeting in the middle (in the case of piece-wise solutions growing from both the origin and the destination) or at the destination (in the case of piece-wise solutions growing only from the origin). Strangely enough, if the process was truly piece-wise optimizing a solution, it would be irrelevant for calculation purposes whether the algorithm started at the origin or the destination. In many algorithms, the calculation will pick different routes in a single-sided decision when the origin and destination are reversed. Some algorithms correct for this by calculating both routes and then presenting the more efficient or optimized route to the end user.

The process is facilitated by road weighting. Essentially, interstates and other highways are more highly weighted than major surface thoroughfares. Major surface roads are weighted more heavily than paved secondary roads, which, in turn, are weighted more heavily than residential streets. The weighting combines with the piece-wise, one-dimensional optimization to select a route between any origin and destination. Unfortunately, such weighting often ends up with “interstate bias.” Many users of navigation systems have noted that the systems tend to prefer interstate or highway routes, even when they are significantly detour from the straight line between the origin and destination.

The major characterization to take away about today's technology is that it creates routes using piece-wise optimization and weighting. It does not create explicit solutions, even in the relatively local area, even though modern processors and algorithms would easily allow explicit local solutions. Piece-wise optimization and weighting creates a bias towards interstate or highway travel. Such antiquated computational cores create legacy artifacts, which substantially affects the performance of today's navigation systems. These cores were written for slow processors, such as the first generation of RTOS processors. These cores assumed a much smaller volume of data than what can currently be handled (e.g., petabyte systems). These cores assumed that wireless data transfer, if any, would be at substantially slower speeds than what is currently capable.

This is not to say that companies have not been updating their software over the past twenty years. What it means is that, when a piece of core software is initially written, many limitations are inherently built-in, either through commission or omission, which makes it difficult to create an update which is truly up-to-date. Additionally, when re-envisioning their software, most software teams have unstated (often unconscious) pre-conceptions about what is possible, because they are starting from a knowledge-base that includes their legacy code.

The legacy artifacts caused by antiquated navigational cores include inaccurate estimated-time-of-arrival (“ETA”) calculations, lack of learning, inability to handle multi-vehicle/multi-destination problems with the same software that is used for normal navigation, inability to optimize the solution for multi-vehicle/multi-destination problems, the inability to reasonably assess when the user has substantially diverted from the calculated route, and the inability to pass navigation back-and-forth between devices (e.g., between an in-car unit and a cellphone).

Most navigation systems are capable of giving an ETA with a 10% error rate, or less, 80-90% of the time. Most consumers are satisfied with this because (1) they don't rely on the ETA information as their only estimate of their arrival time; (2) the ETA information is better information than what they have from other sources; and/or (3) end-users have normalized their expectations to the system performance level available. However, there are categories of users for whom the error rate is strictly unacceptable. For example, commercial vehicle drivers, commercial fleet operators, people on a tight deadline, and people living in congested areas (where current technology under-performs).

Poor ETAs are partially related to the inability of current navigation cores to learn in any meaningful sense. For example, most people know that on Monday morning (excluding holidays), Interstate 405 in Los Angeles is going to be congested at 8:00 a.m. Current navigation cores do not. Likewise, I-696 in metropolitan Detroit, I-90/94 in Chicago, I-95 in Boston, and many other major interstates in major cities are routinely congested. Travel speeds at rush hour on these roads can vary between 60 m.p.h. and 10 m.p.h., on average. Much of the variation is entirely predictable: particular times, days, and conditions are particularly bad, such as Friday afternoons and rain. Unfortunately, current navigation solutions are unable to assess this situation a priori.

Current systems attempt to mask this problem with “dynamic navigation.” Dynamic navigation usually entails using “real-time” traffic data, at an additional cost to the user, to re-route the user if there is congestion. Realistically speaking, there is nothing dynamic about dynamic navigation. Most “real-time” traffic reports have a latency of 20 minutes or more, and come from a single source. With little or no motivation to improve performance in a monopolized field, traffic data fed into dynamic navigation systems is atrophying. Moreover, routinely starting a route towards traffic congestion, only to be re-routed when the navigation system's weighting function finally calculates an actionable event from real-time traffic messaging system, creates a big issue, costs the end-user time, money, and tranquility.

None of the current navigation systems handle multi-vehicle/multi-destination problems. Rather, fleet owners and others who are in need of such service must purchase both a navigation package and a dispatch package, or purchase a dispatch package with an embedded navigation package. These solutions are more antiquated than the traditional navigation cores. They also fail to realize that the multi-vehicle/multi-destination navigation solution is just a mathematical generalization of the single-vehicle/single-destination problem. In fact, most of the current navigation packages can now perform a single vehicle navigation to multiple destinations. Unfortunately, it is doing it in a linear piece-wise method (computationally inefficient and ineffective), rather than in an integrated fashion (computationally efficient and effective).

The commercially available dispatch systems which attempt to solve the multiple vehicle/multiple destinations problems do a poor job. In fact, in many market segments, such as vehicles for hire, users prefer performing these activities by hand, because the output from commercially available software is so sub-optimal that it represents a larger cost than performing the activities by hand.

The poor solutions for multi-vehicle, multi-destination navigation pose numerous costs to the users and to society. For example, large fleet owners, who use products with 10% error for their ETA, routinely have to choose between having more vehicle than needed on a given day (added expense) or loosening service standards (losing customers). For many people, this problem presents itself during in-home service calls. Cable companies, phone companies, and repair personnel routinely tell people generalized times, such as 9 a.m. to noon, rather than giving a more precise time. This leads to frustrated consumers and a loss of business (people, out of necessity, have to forego the service call).

Most people have learned preferred routes near their homes and businesses. These preferred routes offer the user a quicker and/or more convenient route. If a user continually traverses a preferred route, current navigation cores are incapable of incorporating the data in a meaningful way.

There are some solutions on the market that attempt to mask this inadequacy, by “learning” a preferred route. However, the way these systems work, the user has to travel between point A and point B. With repetition, the system will learn preferred sub-routes on which to guide the user between point A and point B. However, the systems are unable to generalize this information in a way which is useful to the end user. Most users would find dubious value in a system that will tell them the route they should take, after they have taken that route three or four times. What users desire is a way to take information, such as the avoidance of traffic control devices, particular ways into or out of business parks, shopping centers and residential sub-divisions, and generalize the information to all other route guidance performed by the unit.

The commercially available navigation software cores all have issues when it comes to reasonably re-routing people. In most systems, any divergence from the calculated route will cause the system to re-calculate a solution, which will essentially get the user back onto the originally calculated route. These re-calculations usually entail back-tracking, zigzagging, or returning the user, immediately, to the original route. There is no provision possible for small divergences from the proposed route, seamlessly re-introducing the user into the originally propose route at a reasonable distance.

Current navigation systems also lack interoperability. An end-user may have one system in their car, one on their laptop, and one on their cellphone. However, with few exceptions, little data can be passed from one to another. Additionally, it is impossible to start a navigation on a cellphone, enter into a vehicle, and have the vehicle's navigation system provide the navigation calculated on the cellphone.

SUMMARY OF THE INVENTION

Like most navigation systems, this one includes input/output devices with user interfaces, a method for geo-locating (e.g., a GPS antennae and chip-set)The server 203 is comprised of an assemblage of processor and non-transitory, computer-readable memory elements. The wireless network 202 can be a cellular or mobile phone network, a radio-frequency network, or other wireless means. The transmission could also be made over a mixed means network, such as a wi-fi network that downloads and uploads requests to the server via a wired internet connection (not shown).

FIG. 2 shows an alternative embodiment for the communication and geo-location system. In FIG. 2, the vehicle 201 has been replaced with a cellphone, MDT, or RED 204. The cellphone, MDT, or RED 204, geo-locates via the satellite network 200. The cellphone, MDT, or RED 204, communicates with the server 203, via a wireless network 202.

FIG. 3 shows an alternative embodiment for the communication and geo-location system in FIG. 2. In this system, the wireless network 202 is used for both geo-location and communication with the server. The cellphone, MDT or RED 204 can use multiple cellphone towers or antennae to identify its current location. This data can be transmitted, along with a navigation request, to the remote server 203.

FIG. 4 shows an alternative embodiment for the communication and geo-location system in FIG. 2. In this system, satellites 200 are used for both geo-location and communication. Although GPS satellites are not currently multi-tasked for communication, it is conceivable, in the future, that both geo-location information and communication would happen with the same satellite 200. However, this system is architected according to current satellite trends: one set of satellites 200 provides geo-location information, and another satellite 200 is used for communication to the remote server 203.

FIG. 5 shows an alternative embodiment for the communication and geo-location system in FIG. 1. In this system, the wireless network 202 is used for both geo-location and communication with the server. The vehicle 201 can use multiple cellphone towers or antennae to identify its current location. This data can be transmitted, along with a navigation request, to the remote server 203.

FIG. 6 shows an alternative embodiment for the communication and geo-location system in FIG. 1. In this system, satellites 200 are used for both geo-location and communication. One set of satellites 200 provides geo-location information, and another satellite 200 is used for communication to the remote server 203.

In FIG. 7, an end-user nav request 32 is communicated through one of the communication and geo-location systems in FIG. 1 through FIG. 6. Whether a vehicle 201 or a cellphone, MDT, or RED 204, the user interacts with the system through a user software method, generally referred to as a user application. In FIG. 12, the User Application starts 101 by insuring that the user is registered 102. If the user is registered 102, destination input 128 occurs. The user can add multiple destinations 127, 128, either specifying the order or allowing the system to order the trip. Once input is complete 127, the data is transmitted 129 to the remote server via the means shown in FIGS. 1-6. At this point we will handle the remote server 203 as a black-box that produces a navigation route, using the resident navigation core, given the destination input 128. The remote server 203 transmits the route, where it is received 129 by the end user. At pre-determined intervals, the end user's application 101 will ping 130 the remote server 203, by transmitting 126 its location. The remote server 203 will compare the user's progress versus what the remote server predicts the user's progress ought to be—If the progress towards the destination lies outside the acceptance criteria, the remote server 203 will transmit a re-route signal 125 to the user's application 101. The end user's unit will notify the end user of the re-route, while the remote server 203 provides an alternative route. The new route will be received 126 by the end user's application 101. Eventually, re-route or not, the end user will arrive at the destination 124. After arriving at the destination, the end user's application 101 will transmit a final ping 123 to the remote server 203, so that the remote server has a complete history of the trip.

When starting the end user application 101, if the user is not registered, the unit can allow registration by opening an account 103. After opening the account 103, the user selects ping frequency 104, navigation preferences 106, and navigation exclusions 105. The user then has to complete independent variables concerning him- or herself, and his or her vehicle. Driver information 107 includes years driving 108, driving record 109, miles driven per year 110, age 111, marital status 112, home address 113, where the user learned to drive 114, the user's profession 115, the user's gender 116, and other company- or group-defined data 117. The vehicle information 118 includes vehicle owner 119, make and model 120, model year 121 and miles on the vehicle 122. The independent variable data should be of very high quality, because the user will be aware that their accuracy in answering the questions may directly relate to how well the system can navigate for them.

FIG. 7 shows that Guidance 60 occurs after End User Input 32. In FIG. 11, Guidance 60 begins by selecting nav optimizing factors 1. Once the BGRs have been created, it is possible for the invention to create navigation solutions. FIG. 11 shows a single vehicle navigation solution. The user starts by selecting an optimizing factor 1, or dependent variable: time, distance, fuel, cost, or an user defined dependent variable. Next, the user, if desired, excludes certain solutions from consideration 2, such as interstates, tollways, bridges, or other potential routes. The user enters one or more destinations 3 using the input device. If inputting more than one destination, the user can select 6 an automatic 10 or manual 5 ordering of the destinations. When selecting a manual 5 ordering, the automatic destination ordering module 10 will defer to the manual entry. Once ordered, the origin and the next or only destination is identified 9. If there is only a single destination input at the beginning 7, the navigation core moves directly to identifying origin and destination 9.

To calculate between an origin and destination, the invention will identify the BGRs that lie, linearly, between the origin and destination 8, and designates them as Active. These BGRs are termed Gen 1. In the BGR containing the origin, the origin is designated the sole entry node 12. In the BGR containing the current destination 9, the current destination is designated as the sole exit node 13. In all other BGRs, Node Pairs are created by selecting only those nodes which have a BGR on both sides 11. The navigation core than creates a Node Pairs list for all Active BGRs 16. In multi-processor systems, the navigation core will simultaneously create a temporary BGR array for all Node Pairs under consideration 20, and survey the NPLUT 14 to see if solutions exist for any Node Pairs under consideration 17. If the Node Pairs solution exists in the NPLUT, it is placed in the temporary BGR array 20. If not, using weighting functions for each street classification, the invention makes dependent variable calculations for each Node Pair of each BGR 19, capturing route information for each potential solution. The invention will delete any exclusions from the potential solution set 21. Since only a limited set of BGRs are used for the initial calculation, not all nodes of each BGR is a potential entry and/or exit. The data generated from the nodes of interest can be stored in an array, in a temporary database format, or in any other data-handling format that allows quick access 20. This temporary data can be stored in cache storage, on the hard-drive, or in any other type of suitable memory element. In a multi-core processor environment, such calculations are speedy, because each BGRs can be independently calculated.

The invention then creates an initial trial route by finding the initial minimum solution from the origin to the destination, travelling only through BGRs that lie, linearly, between the origin and destination 22. As a boundary condition for the initial route calculation, the exit node of one BGR is the entry node of the adjoining BGR. By creating a matrix of possible solutions, the invention yields an explicit solution.

Once the initial trial route is identified, the solution engine adds all BGRs that were adjacent to Gen 1 BGRs 23, 18, and largely repeats the above process. The new BGRs are termed Gen 2. Gen 1 BGRs now use all nodes in the calculation. Gen 2 BGRs use a reduced set of nodes, because not all nodes have an adjoining BGR associated with them.

To calculate the Gen 2 trial route, the potential solutions calculated in the Gen 1 calculation are excluded, because they are found in the temporary array 20. The invention, again, applies the boundary condition that the exit node of one BGR is the entry node of the adjoining BGR. By creating a matrix of possible unique solutions (excluding Gen 1 solutions), the invention yields an explicit solution, the Gen 2 trial route 22.

The process is repeated for Gen 3, in much the same way as for Gen 2 23, 18. All BGRs adjoining Gen 2 BGRs are added to the calculation. All previously considered trial solutions are excluded from the potential solution set. An explicit solution for the Gen 3 trial route is calculated.

Call Gen A the optimum solution. The exit criteria is selected so that C generations are completed, where C=A+B, where C is the total number of generations, A is the optimum generation, and B is the number of desired divergent solutions calculated after the optimum solution. For example, if the Gen 1 trial route is preferable to the Gen 2 or Gen 3 trial route, and the calculations stop, presenting the Gen 1 trial route to the user as the preferred route, C=3, A=1, and B=2.

In practice, B is related to the distance between the origin and destination 23. Additionally, selection of B can be optimized through a simple error feedback function, where the error is related to the distance. The upper limit of B is set by the maximum speed limit. In other words, the process ends when the vehicle would have to exceed the maximum allowable speed limit around the periphery in order to offer a more preferable solution to the dependent variable than the currently available solution.

For MVMD navigation, the above process is repeated for all vehicles. Initial destinations are determined by minimizing the number of BGRs traversed in order for all vehicles to get to a preliminary destination. For each vehicle and destination pair, the above algorithm creates a Route. At the first destination each vehicle is again assigned a destination, with the system attempting to minimize the number of BGRs traversed in order to get all vehicles to their next destination. In this way, it is possible to handle multiple vehicle multiple destination problems, with or without Constraints.

Claims

1. A method and system of navigation guidance, containing, at a minimum, an end-user device with means for comprising the steps of

inputting destinations and a destination and dependent variable into an end-user device;

communicating the destination and dependent variable from the end-user device to an assemblage of non-transitory, computer-readable memory, processing elements, and associated circuitry, referred to as a server;

receiving from the server to the end-user device routing guidance or routing from an origin to the destination;

using a map database, containing roads and, optionally, points of interest; a device and method for determining vehicle position; a server or other assemblage of memory and processing elements; a means for communicating between the end-user device and the server;

geo-locating the end-user device using a global-positioning system (“GPS”) chip-set capable of transmitting and receiving location data; and

using a computer-readable instruction set, called the navigation software core, resident on the non-transitory, computer-readable memory of the server, by

dividing a geographic region of the map database containing the origin and destination into a plurality of bounded geographic regions (“BGRs”), each bgr being sized so that an explicit navigation solution is possible within the boundaries of the bgr, each bgr having at least two nodes, each node being formed by an intersection of a road in the map database with a boundary of a bgr, wherein a bgr can be entered at any node and exited at any other node,

generating a node pair look-up table (NPLUT) database, containing, as dependent variables, previously stored explicit navigation routing solutions between each potential entry node and each potential exit node of every bounded geographic regions (bgr) of interest to the end user based on the origin and the destination, actual node-to-node transit times, and data describing at least the day of the week, time of day, and weather for each previous solution (“independent variables”); and a navigation software core, resident on the server, having the capability to create bgrs of such a size that explicit navigation solutions are possible within the boundaries of the bgr, to

identify identifying, in response to the destination and dependent variable, node Pairs for each bgr which might be part of a potential solution,

to access accessing the NPLUT to get solutions for each node pair, and using ANOVA and manova techniques to optimize a navigation solution, that uses the node pair combinations between the origin and destination, based on the dependent variable provided by the end user and the independent variables which are inherently part of a solution of the NPLUT database.

2. The invention method of navigation guidance in claim 1, in which the system solves further comprising the step of solving for multi-vehicle-to-multi-destination problems multiple vehicles going to multiple destinations.

3. The invention method of navigation guidance in claim 2, in which the system presents further comprising the step of Routes to each vehicle.

4. The invention method of navigation guidance in claim 2, in which the system tracks further comprising the step of tracking each vehicle's progress along the Route.

5. The invention method of navigation guidance in claim 2, in which the system allows further comprising the step of allowing Dispatching for Ride- sharing or Load-sharing fleets.

6. The invention method of navigation guidance in claim 2, in which the system will re-route further comprising the step of re-routing one or more vehicles when a single vehicle's progress along its route diverges from the predicted value by more than a user-defined an amount derived from a user-defined service standard.

7. The invention method of navigation guidance in claim 2, in which the system solves further comprising the step of solving for the multi-vehicle-to-multi-destination problem multiple vehicles going to multiple destinations, using user-defined Constraints.

8. The invention method of navigation guidance in claim 2, in which the software contains further comprising the step of using an error function calculator and a feedback routine to correct the dependent variable values stored in the NPLUT database.

9. The invention method of navigation guidance in claim 2, in which further comprising the steps of communicating with the NPLUT and storing each end-user's actual value for each node pair solution for the dependent variables, including time, distance, fuel usage, cost, and any user defined dependent variables, as well as independent variables, are communicated to and stored in the NPLUT, either while or after the end-user arrives at the destination.

10. The invention method of navigation guidance in claim 2, in which comprising the further steps of capturing and storing, for each dependent node pair value in the NPLUT, at least one associated independent variable factors are captured and stored, both variable and attribute, including, but not limited to, from the list of time of day, date, day of the week, temperature, construction, precipitation, driver's age, driver's profession, driver's gender, vehicle type, vehicle age, vehicle mileage, and special event, which can be used to create: and creating ANOVA and manova calculations of the dependent variables stored in the NPLUT, in order to give more accurate estimates during future navigation.

11. The invention method of navigation guidance in claim 10, in which further comprising the steps of updating the NPLUT database is compressed by storing only the necessary ANOVA or manova sums and products sum of squares from prior each navigation iterations, and deleting the underlying data off of which the sums and products are calculated iteration.

12. The invention method of navigation guidance in claim 2, in which further comprising the step of storing on each end-user's device memory only stores the detail from Active bgrs.

13. The invention method of navigation guidance in claim 2, in which wherein the communication with the server is made via a least on of wireless or and satellite connection to a plurality of devices from the list of vehicles, mobile telephones, mobile data terminals, or and remote electronic devices.

14. The invention method of navigation guidance in claim 2, in which the server can also collect further comprising the steps of collecting data from other data sources, including, but not limited to, at least one of which is NHTSA traffic sensor information, police report, local traffic reports, and construction reports,; communicating the data to the server; and associating the data with a node pair for inclusion in the NPLUT as either variable or attribute data associated with a node pair.

15. The invention method of navigation guidance in claim 2, in which the system is used to monitor and route further comprising the step of monitoring and routing traffic in congested urban areas.

16. A system of navigation guidance comprising an end-user device capable of inputting destinations and at least one dependent variable, and receiving routing guidance;

an assemblage of non-transitory, computer-readable memory, processing elements, and associated circuitry referred to as a server and a computer-readable instruction set called the navigation software core, resident on the non-transitory computer-readable memory of the server;

a map database containing roads, stored within the non-transitory computer-readable memory elements of the server;

a global-positioning system (“GPS”) chip-set, within the end-user device, capable of transmitting and receiving location data;

a means for communicating between the end-user device and the server using a wireless transceiver and a data communication network;

a node pair look-up table (NPLUT) database;

wherein the navigation software core, when executed, is capable of determining the position of the end-user device from the GPS location data;

wherein the navigation software core, when executed, causes the system to divide a portion of the map database, containing the destination and the origin into a plurality of bounded geographic regions (bgrs) of such a size that explicit navigation solutions are possible within the boundaries of the bgr, each bgr having at least two nodes and each node being formed by an intersection of a road with a boundary of the bgr, wherein a bgr can be entered at any node and exited at any other node;

wherein the NPLUT database contains, as dependent variables, previously stored explicit navigation routing solutions between each potential entry node and each potential exit node of every bgr of interest based on the origin and destination, actual node-to-node transit times, and data describing at least the day of the week, time of day, and weather for each previous solution (“independent variables”);

wherein the navigation software core, when executed, further causes the system, in response to input of the destination and the at least one dependent variable, to identify node pairs between the origin and the destination, and provide routing guidance from the origin to the destination, performing an ANOVA, selecting the optimum sequence of bgr entry nodes and exit nodes based upon the ANOVA of previously stored explicit navigation solutions of the NPLUT and the dependent and independent variable.

17. The system of navigation guidance in claim 16, wherein the system solves for multiple vehicles going to multiple destinations.

18. The system of navigation guidance in claim 17, in which the system presents Routes to each vehicle.

19. The system of navigation guidance in claim 17, in which the system tracks each vehicle's progress along the Route.

20. The system of navigation guidance in claim 17, in which the system allows Dispatching for Ride-sharing or Load-sharing fleets.

21. The system of navigation guidance in claim 17, in which the system will re-route one or more vehicles when a single vehicle's progress along its route diverges from the predicted value by more than an amount derived from a user-defined service standard.

22. The system of navigation guidance in claim 17, in which the system solves for multiple vehicles going to multiple destinations, using user-defined Constraints.

23. The system of navigation guidance in claim 17, in which the software method contains an error function calculator and a feedback routine to correct the dependent variable values stored in the NPLUT database.

24. The system of navigation guidance in claim 17, in which each end-user's actual value for each node pair solution for the dependent variables, including time, distance, fuel usage, cost, and any user defined dependent variables, as well as independent variables, are communicated to and stored in NPLUT, either while or after the end-user arrives at the destination.

25. The system of navigation guidance in claim 17, in which, for each dependent node pair value in the NPLUT, associated independent variable factors are captured and stored, both variable and attribute, including, but not limited to, time of day, date, day of the week, temperature, construction, precipitation, driver's age, driver's profession, driver's gender, vehicle type, vehicle age, vehicle mileage, and special event, which can be used to create ANOVA and manova calculations of the dependent variables stored in the NPLUT, in order to give more accurate estimates during future navigation.

26. The system of navigation guidance in claim 25, in which the NPLUT database is updated by storing only the ANOVA or manova sums and sum of squares from each navigation iteration.

27. The system of navigation guidance in claim 17, in which each end-user's device memory only stores detail from Active bgrs.

28. The system of navigation guidance in claim 17, in which the communication with the server is made via a wireless or satellite connection to a plurality of vehicles, mobile telephones, mobile data terminals, or remote electronic devices.

29. The system of navigation guidance in claim 17, in which the server can also collect data from other data sources, including, but not limited to, NHTSA traffic sensor information, police report, local traffic reports, and construction reports, for inclusion in the NPLUT as either variable or attribute data associated with a node pair.

30. The system of navigation guidance in claim 17, in which the system is used to monitor and route traffic in congested urban areas.