Patent Grant
7899611
The following disclosure relates generally to techniques for automatically detecting anomalous road traffic conditions for use in facilitating travel on roads of interest, such as based on comparisons of actual and/or predicted traffic conditions information for a segment of road at a selected time to information about traffic conditions that are typical or otherwise normally expected for that road segment at that time.
As road traffic has continued to increase at rates greater than increases in road capacity, the effects of increasing traffic congestion have had growing deleterious effects on business and government operations and on personal well-being. Accordingly, efforts have been made to combat the increasing traffic congestion in various ways, such as by obtaining and providing information about current traffic conditions to individuals and organizations. One source for obtaining information about current traffic conditions in some larger metropolitan areas is networks of traffic sensors capable of measuring traffic flow for various roads in the area (e.g., via sensors embedded in the road pavement), and such current traffic condition information may be provided to interested parties in various ways (e.g., via frequent radio broadcasts, an Internet Web site that displays a map of a geographical area with color-coded information about current traffic congestion on some major roads in the geographical area, information sent to cellular telephones and other portable consumer devices, etc.).
However, while such current traffic information provides some benefits in particular situations, the lack of accurate information about comparative traffic conditions creates a number of problems. In particular, knowledge about comparative traffic conditions, such as when traffic conditions are currently or expected to become unusual or otherwise anomalous, would allow users to improve their travel, such as to initiate travel when current or expected future traffic conditions are better than typical, or to alter travel plans when current or expected future traffic conditions are worse than usual.
Accordingly, it would be beneficial to provide improved techniques for automatically detecting anomalous road traffic conditions for use in facilitating travel on roads of interest, as well as to provide additional related capabilities.
Techniques are described for automatically detecting anomalous road traffic conditions and providing information about the detected anomalies, such as for use in facilitating travel on roads of interest. The detection of anomalous road traffic conditions is performed in at least some embodiments for each of one or more segments of roads at each of one or more selected times with respect to target traffic conditions that are identified to be analyzed for a particular road segment at a particular selected time, such as to identify target traffic conditions that reflect actual traffic conditions for a current or past selected time, and/or to identify target traffic conditions that reflect predicted future traffic conditions for a future selected time. The analysis of target traffic conditions for a selected segment of road at a selected time to detect anomalous road traffic conditions may include comparing the target traffic conditions for the road segment at the selected time to distinct expected road traffic conditions for the road segment at the selected time, with the expected conditions reflecting road traffic conditions that are typical or normal for the road segment at the selected time. When the target traffic conditions have sufficiently large differences from the expected conditions, corresponding anomalous conditions may be identified, and information about the anomalous conditions may be provided in various ways, as discussed below. In at least some embodiments, at least some of the described techniques for detecting anomalous road traffic conditions and providing information about the detected anomalies are automatically provided by an Anomalous Traffic Conditions Detector system, as described in greater detail below.
Traffic conditions data that is analyzed to detect anomalous conditions may reflect one or more of various types of traffic flow measurements in various embodiments (e.g., average traffic speeds, average traffic volume over a period of time, average traffic occupancy that reflects the average percentage of time that vehicles are occupying a particular location, etc.), as discussed in greater detail below. In addition, a particular type of traffic flow data may be detected as being anomalous based on differing in one or more ways from expected traffic flow data of that type, such as to be abnormal, atypical, unusual, or otherwise sufficiently different (e.g., so as to exceed a predetermined or dynamically determined threshold). Furthermore, the target traffic conditions data to be analyzed for anomalous conditions may be obtained in various ways in various embodiments. For example, current actual traffic conditions data may be obtained from various types of sources in various embodiments (e.g., road-based traffic sensors and/or mobile data sources related to vehicles traveling on roads), and in some embodiments may be obtained and analyzed as target traffic conditions in a substantially realtime or near-realtime manner (e.g., within a few minutes or less of the corresponding traffic). Predicted future traffic conditions data may be generated or otherwise obtained for a road segment for a future time (e.g., a time one or more hours in the future) in various ways in various embodiments (e.g., from a predictive traffic information provider system, as discussed in greater detail below), and expected road traffic conditions may also be determined in various ways in various embodiments, as discussed in greater detail below. In this manner, anomalies may be determined, detected, and/or identified that indicate that traffic conditions may be different (e.g., better or worse, faster or slower, etc.) than traffic conditions that would be expected to occur on a particular road segment during or at a particular time.
Information related to detected anomalous traffic conditions may be provided to users and/or other computer systems or applications in various ways in various embodiments. For example, as discussed in greater detail below, users may be provided with graphically displayed maps that indicate degrees or levels to which target traffic conditions differ from expected traffic conditions, such as via one or more Web pages or in other manners. In other embodiments, alerts or other notifications may be sent to client devices and/or client applications that are used or operated by users when specified circumstances occur, so that the client applications/devices may notify the users if appropriate that traffic is likely to differ from normal or other expectations. Furthermore, in some embodiments such information related to detected anomalous traffic conditions may be provided to other entities or systems that may use the information in various ways, including by making some or all of the provided information to customers or other users of the other entities and systems. In addition, information related to detected anomalies and other comparative traffic condition information may be used in other manners in at least some embodiments, as described in more detail below.
As previously noted, in at least some embodiments, predictions of future traffic conditions at multiple future times are generated in various ways. In some embodiments, the predictions are generated using probabilistic techniques that incorporate various types of input data in order to repeatedly produce future time series predictions for each of numerous road segments, such as in a real-time manner based on changing current conditions for a network of roads in a given geographic area. Moreover, in at least some embodiments one or more predictive Bayesian or other models are automatically created for use in generating the future traffic condition predictions for each geographic area of interest, such as based on observed historical traffic conditions for those geographic areas. Predicted future traffic condition information may be used in a variety of ways to assist in travel and for other purposes, such as to plan optimal routes through a network of roads based on predictions about traffic conditions for the roads at multiple future times, or to determine whether predicted future traffic conditions are anomalous with respect to expected traffic conditions. In at least some embodiments, a predictive traffic information provider system generates such predictions, as described in greater detail below.
In some embodiments, the types of input data used to generate predictions of future traffic conditions may include a variety of current, past, and expected future conditions, and outputs from the prediction process include the generated predictions of the expected traffic conditions on each of multiple target road segments of interest for each of multiple future times (e.g., every 5, 15 or 60 minutes in the future) within a pre-determined time interval (e.g., three hours, or one day), as discussed in greater detail below. For example, types of input data may include the following: information about current and past amounts of traffic for various target road segments of interest in a geographic area, such as for a network of selected roads in the geographic area; information about current and recent traffic accidents; information about current, recent and future road work; information about current, past and expected future weather conditions (e.g., precipitation, temperature, wind direction, wind speed, etc.); information about at least some current, past and future scheduled events (e.g., type of event, expected start and end times of the event, and/or a venue or other location of the event, etc., such as for all events, events of indicated types, events that are sufficiently large, such as to have expected attendance above an indicated threshold (for example, 1000 or 5000 expected attendees), etc.); and information about school schedules (e.g., whether school is in session and/or the location of one or more schools). Moreover, current and predicted future traffic conditions may be measured and represented in one or more of a variety of ways, such as in absolute terms (e.g., average vehicle speed, volume of traffic for an indicated period of time; average occupancy time of one or more traffic sensors, such as to indicate the average percentage of time that a vehicle is over or otherwise activating the sensor; one of multiple enumerated levels of roadway congestion, such as measured based on one or more other traffic condition measures; etc.) and/or in relative terms (e.g., to represent a difference from typical or from maximum). In addition, while in some embodiments the multiple future times at which future traffic conditions are predicted are each points in time, in other embodiments such predictions may instead represent multiple time points (e.g., a period of time), such as by representing an average or other aggregate measure of the future traffic conditions during those multiple time points. Furthermore, some or all of the input data may be known and represented with varying degrees of certainty (e.g., expected weather), and additional information may be generated to represent degrees of confidence in and/or other metadata for the generated predictions. In addition, the prediction of future traffic conditions may be initiated for various reasons and at various times, such as in a periodic manner (e.g., every five minutes), when any or sufficient new input data is received, in response to a request from a user, etc.
Some of the same types of input data may be used to similarly generate longer-term forecasts of future traffic conditions (e.g., one week in the future, or one month in the future) in some embodiments, but such longer-term forecasts may not use some of the types of input data, such as information about current conditions at the time of the forecast generation (e.g., current traffic, weather, or other conditions). In addition, such longer-term forecasts may be generated less frequently than shorter-term predictions, and may be made so as to reflect different future time periods than for shorter-term predictions (e.g., for every hour rather than every 15 minutes). Furthermore, in some embodiments and situations, the previously mentioned longer-term forecasts each correspond to a “full” or “complete” forecast that represents a best prediction for the corresponding future time using all relevant information that is available, while a default or baseline forecast may also (or instead) be generated that does not use all of the types of information used by the complete forecast, even if the unused information is available. For example, the default forecast may not consider any information about weather forecasts for the corresponding future time and/or about scheduled events for the corresponding future time. In some embodiments and situations, a generated default forecast may represent the subjective expectations of a group of one or more users for traffic conditions at a particular future time, such as if the users in the group have a conceptualized expectation for what traffic will be like at a particular future time (e.g., next Friday evening at 5:30 pm during a commute home along a particular road) without conceptually adjusting that expectation for particular unusual weather and/or for a particular large event in the area at that time. In addition, in some embodiments expected traffic conditions for a particular road segment at a particular future time may be obtained without generating a forecast or prediction, such as by merely using historical average traffic conditions for that road segment at similar prior times (e.g., for the same or similar day-of-week and the same or similar hour-of-day, but without differentiating based on seasons, holiday schedules, school schedules, event schedules, etc.).
As previously noted, anomalous traffic conditions (also referred to herein as “anomalies”) may be detected in at least some embodiments for current actual traffic conditions, past actual traffic conditions, and/or future predicted traffic conditions, and by comparing target traffic conditions data for a road segment at a given time to expected traffic conditions data for the road segment at the given time. Different embodiments may utilize various combinations of target conditions data and expected traffic conditions data. For example, target traffic conditions data may include current traffic conditions data for a current time, and expected traffic conditions data may include default forecast traffic conditions data for the current time, such that a detected anomaly is with respect to actually occurring current traffic conditions. In other embodiments, target traffic conditions data may include predicted traffic conditions data for a future time that are generated using all available relevant data (e.g., information about planned roadwork for the future time; about a current traffic accident that may affect traffic conditions at the future time, such as if the future time is within the next hour or so; etc.), and expected traffic conditions data may include data that reflects average or other typical conditions at the future time without considering some types of currently available data (e.g., by using baseline forecast information that is generated without using current information about weather, realtime traffic accidents and other incidents, scheduled events, etc., even if that unused information is available when the forecast traffic conditions data is generated; by using historical average traffic conditions data; etc.). Other combinations and variations are possible, and are described in more detail below.
The roads and/or road segments for which future traffic condition predictions and/or forecasts are generated may also be selected in various manners in various embodiments. In some embodiments, future traffic condition predictions and/or forecasts are generated for each of multiple geographic areas (e.g., metropolitan areas), with each geographic area having a network of multiple inter-connected roads—such geographic areas may be selected in various ways, such as based on areas in which current traffic condition information is readily available (e.g., based on networks of road sensors for at least some of the roads in the area) and/or in which traffic congestion is a significant problem. In some such embodiments, the roads for which future traffic condition predictions and/or forecasts are generated include those roads for which current traffic condition information is readily available, while in other embodiments the selection of such roads may be based at least in part on one or more other factors (e.g., based on size or capacity of the roads, such as to include freeways and major highways; based on the role the roads play in carrying traffic, such as to include arterial roads and collector roads that are primary alternatives to larger capacity roads such as freeways and major highways; based on functional class of the roads, such as is designated by the Federal Highway Administration; etc.). In other embodiments, future traffic condition predictions and/or forecasts may be made for a single road, regardless of its size and/or inter-relationship with other roads. In addition, segments of roads for which future traffic condition predictions and/or forecasts are generated may be selected in various manners, such as to treat each road sensor as a distinct segment; to group multiple road sensors together for each road segment (e.g., to reduce the number of independent predictions and/or forecasts that are made, such as by grouping specified numbers of road sensors together); to select road segments so as to reflect logically related sections of a road in which traffic conditions are typically the same or sufficiently similar (e.g., strongly correlated), such as based on traffic condition information from traffic sensors and/or from other sources (e.g., data generated from vehicles and/or users that are traveling on the roads, as discussed in greater detail below); etc.
In addition, future traffic condition prediction and/or forecast information may be used in a variety of ways in various embodiments, as discussed in greater detail below, including to provide such information to users and/or organizations at various times (e.g., in response to requests, by periodically sending the information, etc.) and in various ways (e.g., by transmitting the information to cellular telephones and/or other portable consumer devices; by displaying information to users, such as via Web browsers and/or application programs; by providing the information to other organizations and/or entities that provide at least some of the information to users, such as third parties that perform the information providing after analyzing and/or modifying the information; etc.). For example, in some embodiments, the prediction and/or forecast information is used to determine suggested travel routes and/or times, such as an optimal route between a starting location and an ending location over a network of roads and/or an optimal time to perform indicated travel, with such determinations based on predicted and/or forecast information at each of multiple future times for one or more roads and/or road segments.
For illustrative purposes, some embodiments are described below in which specific types of predictions are generated in specific ways using specific types of input, and in which generated prediction information is used in various specific ways. However, it will be understood that such future traffic predictions may be generated in other manners and using other types of input data in other embodiments, that the described techniques can be used in a wide variety of other situations, that future traffic forecasts may similarly be generated and used in various ways, and that the invention is thus not limited to the exemplary details provided.
Thus,
Using the predicted travel times for these multiple time periods shown in
Returning to
Thus,
Nodes 202g-i may each be used to represent the average or most common traffic conditions on a particular road segment at the present time or at some time in the past. These nodes are labeled SegmentXColor-Y in this example, where X refers to a particular road segment and Y refers to a time in the past (e.g., in minutes, or other unit of time measurement) at which a particular level of traffic congestion on that road segment has been identified (with the traffic congestion level represented here with its corresponding color). For example, node 202h labeled Segment1Color-60 may be used to represent the traffic conditions 60 minutes ago on road segment Segment1, with the level of traffic congestion at that time being illustrated with the appropriate congestion color. Nodes 202j-k may each be used to represent how long the levels of traffic congestion for a particular road segment have been continuously reported as being black. For example, node 202j labeled BlackStartSegment1 may be used to represent how long the level of traffic congestion on road segment Segment1 has been continuously reported as being black. A variety of other input variables may be used in other embodiments, such as to provide additional details related to various of the types of conditions shown or to represent other types of conditions, as discussed in greater detail below.
Nodes 204a-g in
Intuitively, the Bayesian network may be understood to represent causal relationships. For example, the illustrated Bayesian network expresses causal relationships between input factors such as school schedules, stadium events, weather, and current and past traffic conditions (as represented by input nodes 232a-m) and output future traffic conditions on various road segments (as represented by output nodes 234a-g). As one specific example, the traffic conditions reported 60 minutes ago on road segment Segment1 and whether it is a school day may influence the traffic conditions 180 minutes in the future on road segment SegmentN, such as if road segments Segment1 and SegmentN are related (e.g., are nearby to each other) and if significant traffic reported on road segment Segment1 on school days has a later impact on road segment SegmentN. This relationship is depicted in
The structure and probability distributions of a Bayesian network such as that depicted in
In the illustrated embodiment, each decision tree is used to generate the predicted traffic congestion level conditions on a single road segment at a single future time given current condition information for input variables. As described in more detail with reference to
In a manner similar to that of
In the illustrated embodiment, a Predictive Traffic Information Provider system 350, a Route Selector system 360 and optional other systems provided by programs 362 are executing in memory 345 in order to perform at least some of the described techniques, with these various executing systems generally referred to herein as predictive traffic information systems. The server computing system and its executing systems may communicate with other computing systems via a network 380 (e.g., the Internet, one or more cellular telephone networks, etc.), such as various client devices 382, vehicle-based clients and/or data sources 384, road traffic sensors 386, other data sources 388, and third-party computing systems 390. In particular, one or more of the predictive traffic information systems receives various information regarding current conditions and/or previous observed case data from various sources, such as from the road traffic sensors, vehicle-based data sources and other data sources. The Predictive Traffic Information Provider system then uses the received data to generate future traffic condition predictions for multiple future times, and provides the predicted information to the Route Selector system and optionally to one or more other recipients, such as one or more predictive traffic information systems, client devices, vehicle-based clients, third-party computing systems, and/or users. The Route Selector system uses the received predicted future traffic condition information to generate route-related information, such as for frequently used routes and/or upon request for indicated routes, and similarly provides such route-related information to one or more other predictive traffic information systems, client devices, vehicle-based clients, and/or third-party computing systems.
The client devices 382 may take various forms in various embodiments, and may generally include any communication devices and other computing devices capable of making requests to and/or receiving information from the predictive traffic information systems. In some cases, the client devices may run interactive console applications (e.g., Web browsers) that users may utilize to make requests for traffic-related information based on predicted future traffic information, while in other cases at least some such traffic-related information may be automatically sent to the client devices (e.g., as text messages, new Web pages, specialized program data updates, etc.) from one or more of the predictive traffic information systems.
The road traffic sensors 386 include multiple sensors that are installed in, at, or near various streets, highways, or other roadways, such as for one or more geographic areas. These sensors include loop sensors that are capable of measuring the number of vehicles passing above the sensor per unit time, vehicle speed, and/or other data related to traffic flow. In addition, such sensors may include cameras, motion sensors, radar ranging devices, and other types of sensors that are located adjacent to a roadway. The road traffic sensors 386 may periodically or continuously provide measured data via wire-based or wireless-based data link to the Predictive Traffic Information Provider system 350 via the network 380 using one or more data exchange mechanisms (e.g., push, pull, polling, request-response, peer-to-peer, etc.). In addition, while not illustrated here, in some embodiments one or more aggregators of such road traffic sensor information (e.g., a governmental transportation body that operates the sensors) may instead obtain the raw data and make that data available to the predictive traffic information systems (whether in raw form or after it is processed).
The other data sources 388 include a variety of types of other sources of data that may be utilized by one or more of the predictive traffic information systems to make predictions related to traffic flow and/or to make selections of traffic routes. Such data sources include, but are not limited to, sources of current and past weather conditions, short and long term weather forecasts, school schedules and/or calendars, event schedules and/or calendars, traffic incident reports provided by human operators (e.g., first responders, law enforcement personnel, highway crews, news media, travelers, etc.), road work information, holiday schedules, etc.
The vehicle-based clients/data sources 384 in this example may each be a computing system located within a vehicle that provides data to one or more of the predictive traffic information systems and/or that receives data from one or more of those system. In some embodiments, the Predictive Traffic Information Provider system may utilize a distributed network of vehicle-based data sources that provide information related to current traffic conditions for use in traffic prediction. For example, each vehicle may include a GPS (“Global Positioning System”) device (e.g., a cellular telephone with GPS capabilities, a stand-alone GPS device, etc.) and/or other geo-location device capable of determining the geographic location, speed, direction, and/or other data related to the vehicle's travel, and one or more devices on the vehicle (whether the geo-location device(s) or a distinct communication device) may from time to time obtain such data and provide it to one or more of the predictive traffic information systems (e.g., by way of a wireless link)—such vehicles may include a distributed network of individual users, fleets of vehicles (e.g., for delivery companies, transportation companies, governmental bodies or agencies, vehicles of a vehicle rental service, etc.), vehicles that belong to commercial networks providing related information (e.g., the OnStar service), a group of vehicles operated in order to obtain such traffic condition information (e.g., by traveling over predefined routes, or by traveling over roads as dynamically directed, such as to obtain information about roads of interest), etc. Moreover, while not illustrated here, in at least some embodiments other mobile data sources may similarly provide actual data based on travel on the roads, such as based on computing devices and other mobile devices of users who are traveling on the roads (e.g., users who are operators and/or passengers of vehicles on the roads). In addition, such vehicle-based information may be generated in other manners in other embodiments, such as by cellular telephone networks, other wireless networks (e.g., a network of Wi-Fi hotspots) and/or other external systems (e.g., detectors of vehicle transponders using RFID or other communication techniques, camera systems that can observe and identify license plates and/or users' faces) that can detect and track information about vehicles passing by each of multiple transmitters/receivers in the network. Such generated vehicle-based travel-related information may then be used for a variety of purposes, such as to provide information similar to that of road sensors but for road segments that do not have functioning road sensors (e.g., for roads that lack sensors, such as for geographic areas that do not have networks of road sensors and/or for arterial roads that are not significantly large to have road sensors, for road sensors that are broken, etc.), to verify duplicative information that is received from road sensors or other sources, to identify road sensors that are providing inaccurate data (e.g., due to temporary or ongoing problems), etc. The wireless links may be provided by a variety of technologies known in the art, including satellite uplink, cellular network, WI-FI, packet radio, etc., although in at least some embodiments such information about road traffic conditions may be obtained from mobile devices (whether vehicle-based devices and/or user devices) via physically download when the device reaches an appropriate docking or other connection point (e.g., to download information from a fleet vehicle once it has returned to its primary base of operations or other destination with appropriate equipment to perform the information download). In some cases, various factors may cause it to be advantageous for a mobile device to store multiple data samples that are acquired over a determined period of time (e.g., data samples taken at a pre-determined sampling rate, such as 30 seconds or a minute) and/or until sufficient data samples are available (e.g., based on a total size of the data), and to then transmit the stored data samples together (or an aggregation of those samples) after the period of time—for example, the cost structure of transmitting data from a vehicle-based data source via a particular wireless link (e.g., satellite uplink) may be such that transmissions occur only after determined intervals (e.g., every 15 minutes), one or more of the geo-location and/or communication devices may be configured or designed to transmit at such intervals, an ability of a mobile device to transmit data over a wireless link may be temporarily lost (e.g., such as for a mobile device that typically transmits each data sample individually, such as every 30 seconds or 1 minute, and possibly due to factors such as a lack of wireless coverage in an area of the mobile device, other activities being performed by the mobile device or a user of the device, or a temporary problem with the mobile device or an associated transmitter) such that storage of data samples will allow later transmission or physical download, etc. For example, if a wireless transmission of up to 1000 units of information costs $0.25 cents, and each data sample is 50 units in size, the it may be advantageous to sample every minute and send a data set comprising 20 samples every 20 minutes, rather than sending samples more frequently (e.g., every minute). Moreover, in some embodiments additional information may be generated and provided by a mobile device based on multiple stored data samples. For example, if a particular mobile device is able to acquire only information about a current instant position during each data sample, but is not able to acquire additional related information such as speed and/or direction, such additional related information may be calculated or otherwise determined based on multiple subsequent data samples.
Alternatively, some or all of the vehicle-based clients/data sources 384 may each have a computing system located within a vehicle to obtain information from one or more of the predictive traffic information systems, such as for use by an occupant of the vehicle. For example, the vehicle may contain an in-dash navigation system with an installed Web browser or other console application that a user may utilize to make requests for traffic-related information via a wireless link from the Predictive Traffic Information Provider system or the Route Selector system, or instead such requests may be made from a portable device of a user in the vehicle. In addition, one or more of the predictive traffic information systems may automatically transmit traffic-related information to such a vehicle-based client device (e.g., updated predicted traffic information and/or updated route-related information) based upon the receipt or generation of updated information.
The third-party computing systems 390 include one or more optional computing systems that are operated by parties other than the operator(s) of the predictive traffic information systems, such as parties who receive traffic-related data from one or more of the predictive traffic information systems and who make use of the data in some manner. For example, the third-party computing systems 390 may be systems that receive predicted traffic information from one or more of the predictive traffic information systems, and that provide related information (whether the received information or other information based on the received information) to users or others (e.g., via Web portals or subscription services). Alternatively, the third-party computing systems 390 may be operated by other types of parties, such as media organizations that gather and report predicted traffic condition and route information to their consumers, or online map companies that provide predicted traffic-related information to their users as part of travel-planning services.
In this illustrated embodiment, the Predictive Traffic Information Provider system 350 includes a Data Supplier component 352, a Traffic Prediction Model Generator component 354, and a Dynamic Traffic Predictor component 356. The Data Supplier component obtains current condition data that may be used by one or more of the other components or other predictive traffic information systems, such as from the data sources previously discussed, and makes the information available to the other components and predictive traffic information systems. In some embodiments, the Data Supplier component may optionally aggregate obtained data from a variety of data sources, and may further perform one or more of a variety of activities to prepare data for use, such as to place the data in a uniform format; to detect and possibly correct errors or missing data (e.g., due to sensor outages and/or malfunctions, network outages, data provider outages, etc.); to filter out extraneous data, such as outliers; to discretize continuous data, such as to map real-valued numbers to enumerated possible values; to sub-sample discrete data (e.g., by mapping data in a given range of values to a smaller range of values); to group related data (e.g., a sequence of multiple traffic sensors located along a single segment of road that are aggregated in an indicated manner); etc. Information obtained by the Data Supplier component may be provided to other predictive traffic information systems and components in various ways, such as to notify others when new data is available, to provide the data upon request, and/or to store the data in a manner that is accessible to others (e.g., in one or more databases on storage, not shown). Additional details related to the aggregation, filtering, conditioning, and provision of obtained traffic-related data are included in U.S. patent application Ser. No. 11/540,342, filed Sep. 28, 2006 and entitled “Rectifying Erroneous Traffic Sensor Data,” which is hereby incorporated by reference in its entirety.
In the illustrated embodiment, the Traffic Prediction Model Generator component uses obtained observation case data to generate predictive models used to make predictions about traffic conditions, as previously discussed. In some embodiments, the Traffic Prediction Model Generator component utilizes historical observation case data to automatically learn the structure of a Bayesian network for a given group of one or more roads, and further automatically learns multiple decision tree models that each may be used to make predictions of future traffic flow on a particular road segment for a particular future time. The created predictive models may then be provided to other predictive traffic information systems and components in various ways, such as to notify others when the new models are available, to provide the models upon request, and/or to store the models in a manner that is accessible to others (e.g., in one or more databases on storage, not shown).
The Dynamic Traffic Predictor component utilizes the predictive models generated by the Traffic Prediction Model Generator component to generate predictions of future traffic conditions for multiple future times, such as based on real-time and/or other current condition information. Such predictions may be made at various times, such as periodically (e.g., every five or ten minutes), when new and/or anomalous data (e.g., a traffic accident incident report) has been received, upon request, etc. The generated predicted future traffic condition information may then be provided to other predictive traffic information systems and components and/or to others in various ways, such as to notify others when new information is available, to provide the information upon request, and/or to store the information in a manner that is accessible to others (e.g., in one or more databases on storage, not shown).
The Route Selector system selects travel route information based on predicted future traffic condition information, and provides such route information to others in various ways. In some embodiments, the Route Selector system receives a request from a client to provide information related to one or more travel routes between a starting and ending location in a given geographic area at a given date and/or time. In response, the Route Selector system obtains predictions of future road conditions for the specified area during the specified time period from, for example, the Predictive Traffic Information Provider system, and then utilizes the predicted future road condition information to analyze various route options and to select one or more routes based on indicated criteria (e.g., shortest time). The selected route information may then be provided to other predictive traffic information systems and components and/or to others in various ways, such as to notify others when information is available, to provide the information upon request, and/or to store the information in a manner that is accessible to others (e.g., in one or more databases on storage, not shown).
In the illustrated embodiment, an embodiment of an Anomalous Traffic Conditions Detector system 365 is also executing in memory 345 in order to perform at least some of the described techniques related to detection of and/or providing of information about traffic condition anomalies. In some embodiments, the Anomalous Traffic Conditions Detector system 365 obtains target traffic condition information (e.g., that reflects actual traffic conditions) for one or more road segments (e.g., some or all road segments in a given geographic area) and one or more times, obtains expected traffic condition information (e.g., that reflects normal traffic conditions) for the road segments and the times, and compares the target traffic condition information to the expected traffic condition information to identify any anomalous target traffic conditions. Indications of detected anomalies may then be provided to users (e.g., via client devices 382 and/or clients 384) and/or to other systems (e.g., to predictive traffic information systems and/or to 3rd-party computing systems 390), such as to notify human users of detected anomalies affecting travel routes of interest to such users (e.g., notifying a user that traffic on their preferred route to work is or is likely to be worse than normal), to provide indications of detected anomalies upon request, and/or to store indications of detected anomalies in a manner that is accessible to others (e.g., in one or more databases on storage, not shown).
It will be appreciated that the illustrated computing systems are merely illustrative and are not intended to limit the scope of the present invention. Computing system 300 may be connected to other devices that are not illustrated, including through one or more networks such as the Internet or via the Web. More generally, a “client” or “server” computing system or device, or Anomalous Traffic Conditions Detector system and/or component, may comprise any combination of hardware or software that can interact and perform the described types of functionality, including without limitation desktop or other computers, database servers, network storage devices and other network devices, PDAs, cellphones, wireless phones, pagers, electronic organizers, Internet appliances, television-based systems (e.g., using set-top boxes and/or personal/digital video recorders), and various other consumer products that include appropriate inter-communication capabilities. In addition, the functionality provided by the illustrated system components may in some embodiments be combined in fewer components or distributed in additional components. Similarly, in some embodiments the functionality of some of the illustrated components may not be provided and/or other additional functionality may be available. For example, in some embodiments the Anomalous Traffic Conditions Detector system 365 may execute on computing system 300 without any other executing systems or programs 350, 360 and/or 362. Note also that while various items are illustrated as being stored in memory or on storage while being used, these items or portions of them can be transferred between memory and other storage devices for purposes of memory management and/or data integrity. Alternatively, in other embodiments some or all of the software components and/or modules may execute in memory on another device and communicate with the illustrated computing system/device via inter-computer communication. Some or all of the system components or data structures may also be stored (e.g., as software instructions or structured data) on a computer-readable medium, such as a hard disk, a memory, a network, or a portable media article to be read by an appropriate drive or via an appropriate connection. The system components and data structures can also be transmitted as generated data signals (e.g., as part of a carrier wave or other analog or digital propagated signal) on a variety of computer-readable transmission mediums, including wireless-based and wired/cable-based mediums, and can take a variety of forms (e.g., as part of a single or multiplexed analog signal, or as multiple discrete digital packets or frames). Such computer program products may also take other forms in other embodiments. Accordingly, the present invention may be practiced with other computer system configurations.
The routine begins in step 405 and receives a request to provide predicted information for an indicated route in a geographic area (e.g., a route indicated with a starting location, an ending location, a preferred arrival time, a preferred departure time and/or other indicated criteria for use in identifying or evaluating route options) or receives an indication of an update in relevant conditions for a geographic area. In step 410, the route determines the type of input received, and if a request to provide route information has been received, the routine proceeds to step 415 and obtains predictions of future road conditions at one or more future times for the geographic area, such as for future times that correspond to the preferred travel time (if any). The routine may obtain this information from, for example, the Predictive Traffic Information Provider system 350 described with reference to
If it is instead decided in step 410 that an indication of a conditions update for a geographic area has been received (e.g., an indication of a traffic incident along a particular roadway), the routine proceeds to step 450 and identifies any affected route(s) whose associated clients are known. In step 455, the routine updates route options with respect to the updated conditions for the identified routes, with the updated conditions possibly including real-time traffic data and/or updated predictions information from the Predictive Traffic Information Provider system, and with the updated route options possibly resulting in a different predicted optimal or top-ranked route option. In step 460, the routine then optionally provides updated route information to the associated clients, such as if the updated route options information would result in different client behavior. For example, the updated route information may be provided to vehicle-based clients that may be traveling on or near the affected routes, or more generally to client devices 382 that had previously been used to obtain information regarding one or more of the affected routes.
After steps 435 or 460, the routine continues to step 490 to determine whether to continue. If so, the routine returns to step 405, and if not continues to step 499 and ends.
The routine begins in step 502 and receives a request for prediction information (e.g., for an indicated road or road segment at an indicated time, or for all roads and road segments in a geographic area based on current conditions) or an indication of a data update for an indicated geographic area. In step 504, the routine determines whether a data update or a predictions request was received, and if it is determined that a data update was received, the routine proceeds to step 506 and obtains new current conditions data from one or more data sources for use as input in the prediction generations (e.g., from the Data Supplier component 352 in
If it was instead determined in step 504 that a request for predictions was received, the routine proceeds to step 520 and obtains previously generated predictions from one or more predictive models for the indicated geographic area, such as predictions generated in step 508. In step 522, the routine provides the obtained predictions to the client. After steps 510 and 522, the routine proceeds to step 540 and optionally performs any housekeeping tasks. In step 545, the routine determines whether to continue. If so, the routine returns to step 502, and if not continues to step 549 and ends.
The subroutine begins in step 550 and receives indications of a geographic area and of past, current, and future conditions for use as input information. As described in greater detail elsewhere, such conditions may include information about current and past weather conditions, weather forecasts, event schedules, school schedules, current and past traffic conditions, etc. In step 552, the subroutine obtains one or more generated predictive models for the indicated geographic area that include a Bayesian network and one or more decision trees, such as by retrieving previously generated models or by requesting the models from a Traffic Prediction Model Generator component. In step 554, the subroutine generates future traffic condition predictions based on the current conditions input information by using the predictive models, such as to generate predictions at each of multiple future times for each road or road segment in the indicated geographic area. In step 556, the subroutine then optionally performs post-processing of the predicted future traffic conditions information, such as to include merging, averaging, aggregating, selecting, comparing, or otherwise processing one or more sets of output data from the one or more predictive models. In step 558, the subroutine stores the predicted future traffic conditions information, and in step 560 optionally provides the predicted traffic conditions information to one or more clients. In step 599 the subroutine returns.
The routine begins in step 605 and receives a request to generate predictive models for an indicated geographic area or to provide previously generated predictive models for an indicated geographic area. In step 610, the routine determines the type of received request, and if a request to generate a model was received, the routine proceeds to step 615 to obtain observed data for the indicated geographic area, such as from the Data Supplier component 352 or from stored data. In step 620, the routine then generates one or more predictive models with reference to the obtained observed data, as discussed in greater detail elsewhere. In step 625, the routine then optionally provides an indication of the generated one or more models to a client from whom the request was received and/or to others (e.g., the Dynamic Traffic Predictor component 356 of
If it was instead determined in step 610 that a request to provide a model was received, the routine continues to step 640 where one or more models previously generated predictive models for the indicated geographic area are retrieved. In step 645, the routine then provides those models to the client who requested the models or to another indicated recipient, such as the Dynamic Traffic Predictor component 356 and/or a third-party computing system that utilizes the models to perform its own predictions.
After steps 625 and 645, the routine proceeds to step 690 and optionally performs any housekeeping tasks. In step 695, the routine then determines whether to continue. If so, the routine returns to step 605, and if not continues to step 699 and ends.
In some embodiments, the selection of routes may be based on a variety of types of indicated information, such as when information is requested for fully or partially specified travel routes (with a partially specified route not specifying every road segment between a given starting and ending location), when a starting and ending location are specified (optionally with one or more intermediate locations), when one or more desired times for travel are indicated (e.g., on a particular day; between a first and second time; with an indicated arrival time; etc.); when one or more criteria for assessing route options are specified (e.g., travel time, travel distance, stopping time, speed, etc.), etc. In addition, varying amounts of information related to travel routes may be provided in various embodiments, such as to provide clients with only a predicted optimal selected route or to provide clients with a variety of details about multiple route options analyzed (e.g., in a ranked or otherwise ordered manner, such as by increasing travel time). In addition, some embodiments may represent travel routes in various manners, including human-readable, textual representations using common street and road names and/or machine-readable representations such as series of GPS waypoints.
Various embodiments may also employ various conventions for representing and providing current and predicted traffic condition information. For example, in some embodiments a data feed may be provided for each geographic area of interest to indicate predicted future traffic condition information for each of multiple future times. The data feed format may, for example, be defined by an XML schema that defines an element type with one or more attributes that each contain information related to a predicted traffic congestion level conditions for a single road segment for each of multiple future times, with a fragment of an example such XML stream or file as follows:
In addition, various embodiments provide various means or mechanisms for users and other clients to interact with one or more of the predictive traffic information systems. For example, some embodiments may provide an interactive console (e.g. a client program providing an interactive user interface, a Web browser-based interface, etc.) from which clients can make requests and receive corresponding responses, such as requests for information related to current and/or predicted traffic conditions and/or requests to analyze, select, and/or provide information related to travel routes. In addition, some embodiments provide an API (“Application Programming Interface”) that allows client computing systems to programmatically make some or all such requests, such as via network message protocols (e.g., Web services) and/or other communication mechanisms.
In this example, a view of road traffic information is currently selected (based on selection of the “Traffic” navigation tab 701a), the geographic area currently selected is the Seattle/Tacoma Metro area (via control 702), and the time currently selected is 4:45 PM on Feb. 1, 2006 (via slider 703 and/or the calendar date selector control 715), with the various displayed information reflecting those selections. As is shown in the map display area 707 and described in the map legend area 706, traffic road congestion level condition information is currently shown for a selection of major roads in the currently visible portion of the Seattle/Tacoma Metro geographic area. For current or past times for which actual road congestion level condition information is available, the displayed information reflects that actual information, and for future times the displayed information reflects predicted future traffic conditions at those times. In this example, the displayed major roads are divided into logical road segments which are each displayed using a level of grayscale shading to indicate a corresponding level of road congestion of that road segment for the selected time, such as with a road segment 711c of the northbound portion of the Interstate 5 road being illustrated with “Stop-and-go” traffic conditions (shown in black in this example), with the adjacent road segment to the south being illustrated with “Moderate” traffic conditions, and with the adjacent road segment to the north also being illustrated with “Stop-and-go” traffic conditions before the next road segment to the north changes to “Heavy” traffic conditions. Road segment 711a along the Interstate 90 road is currently shown with “Wide Open” traffic conditions, road segment 711b along the Interstate 405 road currently is shown with “Heavy” traffic conditions, and numerous other road segments are similarly shown with corresponding traffic congestion level condition information. While illustrated in grayscale here, in other embodiments the map may be displayed instead in color, such as to show “Stop-and-go” traffic conditions in black, “Heavy” traffic conditions in red, “Moderate” traffic conditions in yellow, and “Wide Open” traffic conditions in green.
The display of traffic-related information may be modified by a user (not shown) in various ways in this example embodiment. For example, the geographic area selection menu control 702 can be used to select from one of a number of different geographic areas for which traffic-related information is available. The time slider control 703 can be used to modify the time that is currently selected for which traffic information is shown, such as to view predicted traffic conditions at future times. The key route selection area 704 includes various user-selectable option controls 704a-d that may be selected in order to highlight key routes on the displayed map, such as to highlight a route from Seattle to Bellevue by selecting option 704a. User-selectable display option controls 705a-d include information about incidents 705a, events 705b, construction 705c, and speed info 705d, such as with corresponding information for one or more selected options being overlaid on the displayed map. Pan button controls 708a-c can be used to scroll or pan the map frame 707 to obtain a different view of the current geographic area, with an additional southern pan button control 708d not currently shown due to the scrolling of the window. The zoom tool control 709 may be used to increase or decrease the display scale of the map. The map data selector control 714 may be used to select an alternate source of map data, such as actual satellite or other imagery of the geographic area (e.g., over which labels or other indications of the roads of interest are displayed). Various other user-selectable controls may be provided in other embodiments, and some or all of the illustrated controls may not be available.
In this example, the map currently displays various information in addition to the traffic conditions for the selected network of roads, such as to indicate venues and other locations that may correspond to events and other areas of traffic concentration (such as Husky Stadium 710a in which college football and other events may occur, Safeco Field 710b in which professional baseball and other events may occur, Seahawk Stadium in which professional football and soccer and other events may occur, the Space Needle tourist attraction, the SeaTac Airport, popular parks such as Marymoor Park and Discovery Park, etc.), cities and neighborhoods, and highway labels such as 712a-b. Various other types of information may similarly be shown, such as at all times or instead in a user-selectable manner.
In addition, each road segment has an adjoining clock icon that can display multiple areas each corresponding to a portion of the hour following the currently selected time, although in other embodiments the clock may represent a period of time other than an hour, or such information may alternatively be displayed in manners other than a clock or a circle. For example, clock 791 adjoins road segment 790a and has four portions 791a-d, with each portion for this clock being a 15-minute quadrant, and with each clock portion being filled with the level of grayscale for the traffic congestion level represented by that portion. Thus, portion 791a represents the 15 minutes following the currently selected time and is shaded to indicate that wide-open traffic conditions are predicted for road segment 790a during those 15 minutes, and portion 791b represents the period of time from 15 to 30 minutes after the currently selected time and also indicates predicted wide-open traffic congestion level conditions. While the portions of example clock 791 are evenly spaced in 15-minute segments (e.g., to reflect predictions made at each of 15-minute time intervals), in other embodiments each distinct portion of time within a clock may instead correspond to a different predicted or actual traffic congestion level—if so, the two portions 791a and 791b that both represent the same level of traffic congestion would instead by combined into a single portion, which in this example would be a portion that fills the first half of the clock. In this example, portion 791c indicates predicted moderate traffic conditions for the road segment during the next period of time (which in this example is 30 to 45 minutes after the currently selected time), and portion 791d indicates predicted heavy traffic conditions for the road segment during the last 15 minutes of the hour. Thus, in contrast to the clock icons illustrated in
In a similar manner to clock icon 791, clock icon 792 adjoins road segment 790b and has four portions 792a-d that in this example are each 15-minute quadrants. Quadrants 792a-d represent, respectively, moderate, heavy, heavy, and stop-and-go predicted traffic congestion level conditions for road segment 790b at the periods of time corresponding to the portions. Conversely, clock icon 793 has only three portions that each represents a traffic congestion level distinct from any other portions adjacent in time. Thus, with respect to adjoining road segment 790c, portion 793a of clock 793 indicates predicted heavy traffic congestion level conditions for the road segment during a first approximately 7 minutes following the currently selected time, portion 793b indicates predicted moderate traffic congestion level conditions for the road segment during the following approximately 15 minutes, and portion 793c indicates predicted wide open traffic congestion level conditions for the road segment during the remainder of the hour. While three portions of time are illustrated here, in will be appreciated that more or less portions could be displayed, that each portion can represent any amount of time down to the difference in times between distinct future time predictions, and that different portions of such a clock may represent the same predicted level of traffic congestion (e.g., if one or more intervening portions have one or more different predicted traffic congestion levels).
Other types of comparative traffic conditions information may be displayed in other manners in other embodiments. For example, in some embodiments, comparative traffic conditions information may be determined and displayed in a manner other than on a per-road segment basis, such as to determine and display aggregate comparative traffic conditions information for multiple road segments (e.g., multiple road segments along a particular route, or in a particular geographic area), whether in addition to or instead of displayed comparative traffic information on a per-road segment basis. In addition, other types of comparative information may be determined and displayed in other embodiments, such as differences in an average amount of time to travel from one end of a road segment to another, differences in average traffic volume or occupancy, etc. Furthermore, in addition to the various comparative traffic condition information that is displayed on the map for the various road segments to indicate the differences from expected conditions, in other embodiments additional alerts or notifications may be provided with respect to particular circumstances of interest. For example, a user may be allowed to request a notification when a road segment of interest (e.g., a particular selected road segment, any road segment along a particular selected route, etc.) has traffic conditions that are much better than expected and/or that are much worse than expected, such as during a particular period of time of interest. If so, corresponding notifications or alerts may be provided to the user in various ways, including as part of the user interface that displays the map to the user (e.g., in a separate pane or other window portion for textual notifications, not shown; by further highlighting or emphasizing particular road segments on the map to which the notifications correspond, such as via distinct colors or other visual indicator; etc.) and/or by sending one or more types of electronic messages to the user (e.g., an email, instant message, text message, SMS message, automated phone call, RSS feed communication, etc.).
The illustrated user interface display of
The illustrated user interface 7020 provides various user-selectable controls with which a user may manage (e.g., create, delete, edit, configure, etc.) one or more comparative traffic notification definitions. In particular, the illustrated user interface 7020 includes a welcome message 7022 customized to the user, identified as “User XYZ” in this example. The user interface 7020 also includes a comparative traffic notification definition management control area 7026 that provides summary information and controls for commonly performed actions for comparative traffic notification definitions previously created by the user. In this example, notification definitions are each associated with a particular geographic area, such that the user may manage groups of comparative traffic notification definitions for each of multiple geographic areas, with a user-selectable geographic area control 7024 indicating the current geographic area. In addition, in this example, each of the illustrated comparative traffic notification definitions is associated with a particular route within the current geographic area, so as to select the road segments along that route, although in other embodiments one or more road segments of interest may be specified in other manners. Alternatively, in other embodiments an anomaly may be determined in a manner that is not specific to a particular road segment, but instead reflects an aggregate amount of deviation between target and expected traffic conditions for multiple road segments (e.g., all road segments along a particular route, all road segments within a defined geographic area, etc.), such as by averaging or otherwise combining individual deviations for each road segment in the group, or by initially assessing the deviation in an aggregate manner. In the illustrated example, the comparative traffic notification management control area 7026 displays three comparative traffic notification definitions, named “Work to Home”, “Home to Work”, and “To Event Center”, respectively. In the illustrated embodiment, a comparative traffic notification definition may be in an active or inactive state, as specified by the user, so as to control whether or not notifications should actually be sent when anomalies are detected that match or otherwise conform to the settings, criteria, and/or conditions specified by the notification definition. In this manner, users may temporarily disable the sending of notifications, such as when their travel patterns temporarily change (e.g., when they leave a given geographic area on a business trip or holiday). In addition, in other embodiments, more or less information may be displayed in area 7026, and the displayed information may be displayed in different ways (e.g., organized by creation date, name, etc.).
User interface 7020 also includes a section 7027 with various controls to enable creation of comparative traffic notification definitions. In particular, section 7027 includes a control 7028 that may be utilized to specify a name for a new notification definition (e.g., “Home to Daycare”) and a route selection control 7030 that may be utilized to specify one or more travel routes for use in identifying relevant road segments. Section 7027 also includes a timing section 7032 that includes multiple controls 7032a-7032c via which the user may specify when anomalous traffic conditions should cause notifications to occur. In this example, controls 7032a-7032c may be utilized to specify frequency, days of week, and a time period, respectively.
In addition, section 7027 includes a designation section 7034 that includes multiple controls 7034a-7034d via which a user may specify one or more types of information to be considered (or not considered) when selecting normal or expected traffic conditions data to use when identifying anomalies for the user for the comparative traffic notification definition being created. In particular, controls 7034a-7034c may be utilized to specify that sporting event schedules, school schedules, and long-term weather forecasts, respectively, should be included or excluded when determining normal traffic conditions. In some embodiments, additional types of information may be specified, as illustrated 7034d, while in other embodiments users may not be allowed to customize their expected traffic conditions data (e.g., if a single type of expected conditions data is used for all users in the same types of situations, such as default forecast information or historical average speed information). In this example, by selecting one or more of the controls 7034a-7034c, the user is indicating the types of information that reflect the user's subjective understanding of normal traffic conditions, so that anomalies may be detected in a manner specific to a particular user's representation of normal or expected traffic conditions. For example, User XYZ may be a baseball fan that regularly attends professional baseball games at a stadium local to his geographic area and is aware of the home game schedule, so that User XYZ is interested in receiving notifications on game days that reflect differences from typical game day traffic conditions. Conversely, if User XYZ does not keep track of the baseball game schedule, User XYZ may prefer to receive notifications that reflect when game day traffic causes traffic conditions that vary from the typical non-game day traffic (e.g., so as to reflect heavy traffic near the stadium or surrounding roads before and after the games). Thus, by selecting (or not selecting) the sporting event schedules control 7034a, User XYZ indicates whether sporting event schedules should be used to determine expected traffic conditions data. In other embodiments, different techniques may be used to obtain information about a given user's expectations and/or mental model with respect to normal traffic conditions. For example, in some cases, such information may be inferred based on demographic information that is associated with the user (e.g., that the user has school-aged children and therefore likely tracks school schedules) and/or may be obtained in other contexts (e.g., during an initial sign-up process), whether with or without the knowledge of the user.
Section 7027 further includes a notification designation section 7036 that includes multiple controls 7036a-7036d via which the user may specify conditions and mechanisms for notifying the user of anomalous traffic conditions and/or related information. In particular, control 7036a may be utilized to specify that the user desires to be notified when traffic is worse than expected, and one or more other controls (not shown) may optionally allow the user to specify a degree or level of difference that is a threshold for the notification (e.g., a minimum number of miles-per-hour speed deviation, a particular one of multiple enumerated levels of difference, etc.). If control 7036a is selected, control 7036b may be utilized in this example to specify that the user desires to be provided with information about one or more alternative routes, such as may be provided by the Route Selector system 360 described with reference to
In this example, section 7027 also includes an advanced notification settings control 7037 that may be utilized by the user to access additional user interface controls for further specifying attributes and/or criteria associated with a comparative traffic notification. For example, a user may be provided with various mechanisms to specify different and/or additional timing triggers, notification conditions and/or mechanisms, default forecast traffic information input types, etc. In addition, a user may be provided with alternative mechanisms for specifying routes of interest, such as a direct manipulation route-mapping tool that may be used to create custom travel routes. Section 7027 further includes controls 7038a-7038b via which the user may create a new comparative traffic notification definition after the various configurations have been completed or to instead reset values in the various presented user input areas to initial and/or default values, respectively. It will be appreciated that other related types of functionality to create and manage comparative traffic notification definitions may be provided in a variety of other ways in other embodiments. In addition, additional details related to displaying and otherwise providing information about anomalous and other traffic conditions are included in U.S. patent application Ser. No. 11/556,670, filed concurrently and entitled “Displaying Road Traffic Condition Information And User Controls,” which is hereby incorporated by reference in its entirety.
In this example, the routine begins in step 805 and receives a request to detect anomalous traffic conditions within an indicated geographic area at an indicated selected time. The indicated time may be any time (e.g., past, current, future) for which traffic conditions data is available for use in detecting anomalies. In step 810, the routine obtains information about road segments of interest for the indicated geographic area. In some cases, this may be all road segments within the geographic area, whereas in other cases, the road segments of interest may be based on preferences expressed by one or more users, such as road segments that are parts of travel routes specified by the users via a user interface such as the one described with reference to
In steps 815-845, the routine performs a loop in which it determines whether traffic conditions associated with each of the road segments are anomalous at the indicated time. In step 815, the routine selects the next road segment of the road segments, beginning with the first. In step 820, the routine obtains target traffic conditions data for the selected road segment at the indicated time. The obtained target traffic conditions data may be based at least in part on the indicated time, as previously discussed, such as to use traffic conditions data that most accurately reflects actual or predicted traffic conditions for the indicated time. For example, if the indicated time is the current time, the routine may obtain current traffic conditions data that reflect actual traffic conditions on the road segment. On the other hand, if the indicated time is a future time that is within a predetermined time interval (e.g., three hours) of the current time, the routine may obtain predicted future traffic conditions data. Furthermore, if the indicated time is a future time that is beyond the predetermined time interval, the routine may obtain long-term forecast traffic conditions data.
In step 825, the routine obtains expected traffic conditions data for the selected road segment at the indicated time. The obtained expected traffic conditions data may also be based at least in part on the indicated time, as previously discussed, such as to use traffic conditions data that most accurately reflects traffic conditions that would be expected and/or considered normal for the indicated time. As such, the obtained expected traffic conditions data may be based on predictions that do not consider the impact of transient, temporary, or otherwise unexpected current conditions, such as accidents, current weather conditions, current traffic conditions, and/or short term construction projects. For example, if the indicated time is the current time or a future time within a predetermined time interval of the current time for which long-term forecast traffic conditions data is available, the routine may obtain default long-term forecast traffic conditions data. On the other hand, if the indicated time is a future time beyond the predetermined time interval for which long-term forecasts are available, the routine may obtain historical average conditions for the indicated time (e.g., average conditions for the indicated time of day, day of week, and/or month of year).
In step 830, the routine compares the target traffic conditions data to the expected traffic conditions data to determine whether traffic conditions on the road segment are or are not likely to be anomalous at the indicated time. For example, if the target traffic conditions data includes current actual traffic conditions data and the expected traffic conditions data includes default forecasted traffic conditions data that each include average speeds data for the road segment, the routine may compare the corresponding average speeds and determine that an anomaly exists when the actual average speed is greater or less than the expected average speed by a predetermined amount (e.g., differing by more than 15 miles per hour, differing by more than 20%, etc.). In other embodiments, other or additional measures of traffic conditions (e.g., traffic volume) may be utilized. For example, when traffic conditions information is represented as a distribution (e.g., a distribution of average traffic speeds for a road segment at a particular time or over a period of time), one or more of various statistical measures may be used to compare two such distributions (e.g., a first distribution to represent actual and/or predicted traffic conditions, and a second distribution to represent expected traffic conditions). The extent to which the two distributions differ may be calculated by statistical measures, such as the Kullback-Leibler divergence, which provides a convex measure of the similarity between two probability distributions, and a similarity difference above a predetermined or dynamically specified threshold may reflect anomalous traffic conditions. In addition, some embodiments may use other statistical measures such as statistical information entropy, whether instead of or in addition to a similarity measure such as the Kullback-Leibler divergence. The statistical entropy of a probability distribution is a measure of the diversity of the probability distribution. Statistical entropy of a probability distribution P may be expressed as follows,
where Pi is a value of the discretized probability distributions P (e.g., each Pi is the probability that speeds within the i-th bucket of the histogram for P occurred). In addition, the difference between two statistical entropy measures may be measured by calculating the entropy difference measure. The entropy difference measure between two probability distributions P and Q may be expressed as
EM=∥H(P)−H(Q)|2
where H(P) and H(Q) are the entropies of the probability distributions P and Q, respectively, as described above. A statistical entropy value and/or a statistical entropy difference value above a predetermined or dynamically specified threshold may reflect anomalous traffic conditions.
The statistical measures described above may be utilized in various ways in order to detect anomalous traffic conditions. In some embodiments, various information about a target traffic conditions distribution is provided as input to one or more automated classifiers, such as based on a neural network, probabilistic Bayesian network classifier, decision tree, support vector machine, etc. For example, the classifier input information may include, for example, the Kullback-Leibler divergence between an expected traffic conditions distribution for a road segment and a target traffic conditions distribution (e.g., actual and/or predicted traffic conditions distribution) for the road segment, and the statistical entropy of the target traffic conditions distribution. The classifier then assesses whether the target traffic conditions are anomalous based on the provided inputs, and provides a corresponding output. In some cases, additional information may also be provided as input to the classifier, such as information about a current or other selected time (e.g., an indication of the time-of-day, such as a time period from 5:00 AM to 9:00 AM; day or days of week, such as Monday through Thursday, Friday, Saturday or Sunday; size of mph buckets for average speed traffic conditions information; etc.).
In other embodiments, anomalous target traffic conditions may be identified without the use of an automated classifier. For example, target traffic conditions may be determined to be anomalous if one or more statistical measures are above a predetermined threshold value. For instance, target traffic conditions may be determined to be anomalous if the Kullback-Leibler divergence between target and expected traffic conditions distribution is above a first threshold value, if the statistical entropy of the target traffic conditions distribution is above a second threshold value, and/or if the entropy difference measure between the target and expected traffic conditions distribution is above a third threshold.
In addition, other non-statistical information may be utilized to determine whether target traffic conditions for a road segment are anomalous, whether in addition to or instead of statistical measures, including based on information about traffic conditions of nearby road segments (e.g., one or more adjoining road segments). For example, if a neighboring next road segment (the next road segment to which traffic on a current target road segment will travel) indicates new anomalous road traffic conditions that are significantly worse than normal, such as may be indicated by a new traffic accident that has recently occurred on the next road segment or on one or more following road segments after the next road segment, the chances may be significantly increased that traffic conditions on the target road segment will also worsen at the current time or shortly afterwards. Conversely, significantly improving traffic conditions on such next road segments may indicate that effects of one or more prior traffic accidents are dissipating, such that target traffic conditions for the target road segment will return to expected traffic conditions at the current time or shortly afterwards. Information about one or more prior road segments (the prior road segment from which traffic on a current target road segment arrives) and/or other nearby road segments (e.g., an adjoining road segment representing travel in an opposite direction on the same road at approximately the same geographic location) may similarly be used to anticipate current and/or near-term changes in actual and/or predicted road traffic conditions information for a target road segment. Furthermore, in some embodiments such information about recent and/or current traffic conditions on nearby road segments may be automatically used to update predicted road traffic conditions information for a target road segment for a current time and/or times in the near future, such as to better identify anomalous road traffic conditions for the target road segment with respect to the updated predicted road traffic conditions information that reflects current conditions on the nearby road segments.
As previously noted, the above techniques may be utilized with respect to a variety of types of traffic conditions flow information, including traffic speed, traffic volume, density, and occupancy. Additional details related to use of statistical measures and classifiers are included in U.S. patent application Ser. No. 11/540,342, filed Sep. 28, 2006 and entitled “Rectifying Erroneous Traffic Sensor Data,” which is hereby incorporated by reference in its entirety.
In step 835, the routine determines whether traffic conditions were determined to be anomalous in step 830. If so, the routine continues to step 840 and provides one or more notifications of an anomalous traffic condition associated with the road segment during the indicated time. The notification may be provided in various ways, such as by formatting and transmitting a machine-readable (e.g., XML) message or other transmission that may be processed by another computing system, such as one of the third-party computing systems 390 described with reference to
If it is instead determined in step 835 that an anomaly was not detected in step 830, or after step 840, the routine continues to step 845 to determine whether there are more road segments to process. If so, the routine returns to step 815. Otherwise, the routine continues to step 850 to determine whether to continue. The routine may continue, for example, if it has received other requests to detect anomalous traffic conditions, or if it was invoked to process each of one or more geographic areas for each of one or more indicated times. If it is determined in step 850 to continue, the routine returns to step 805, and otherwise ends at step 899.
While the illustrated routine 800 detects anomalies in response to a received request or indication, other embodiments may detect anomalies in other ways and/or at other times. For example, another embodiment may run continuously (e.g., as a daemon process) or periodically (e.g., every 5 minutes), such as to process some or all road segments in some or all geographic areas. Furthermore, another embodiment of the routine may record detected anomalies and/or the comparative information used to detect anomalies, such that clients (e.g., users and/or other computing systems) may be later notified by the same or some other routine. In addition, other embodiments may cache or otherwise store the results of traffic conditions data comparisons, so as to avoid performing duplicative comparisons for particular times, road segments, etc.
The following table illustrates one example of various combinations of target traffic conditions data and expected traffic conditions data that may be compared in order to detect anomalous traffic conditions. In particular, each row of the table describes the types of target and expected traffic conditions data that may be used when detecting anomalies for a given time, t, using P to represent a time horizon for which predicted traffic conditions are available.
Additional details related to differences between predicted, full forecast, default forecast and historical average traffic conditions are included elsewhere. In addition, in other embodiments target and expected traffic conditions data may be selected in different ways. For example, as noted elsewhere, in some embodiments users or other systems may be able to configure the inputs upon which various types of expected traffic conditions are to be based (e.g., to base forecast traffic conditions on school schedules but not event schedules), such that expected traffic conditions may better reflect a given user's mental traffic model.
In some embodiments, the described techniques for detecting anomalous traffic conditions may be used in other ways. For example, a newly detected anomaly may indicate the existence of a traffic incident (e.g., an accident) that has recently occurred. As such, some embodiments may utilize detected anomalies to infer the likely existence of traffic incidents or other factors that may affect traffic conditions, and report the likely existence of such incidents to others (e.g., users and/or other client systems, governmental authorities and/or response teams, etc.). Such techniques may be advantageous in geographic areas for which data feeds that include reported traffic incidents are unavailable, slow (e.g., having a substantial time lag between the occurrence of an incident and its report), or otherwise unreliable. The automatic inference of the existence of traffic incidents may be based on various probabilistic models (e.g., neural networks, Bayesian networks, decision trees, etc.) that are capable of classifying the temporal (e.g., how fast one or more anomalies occur) and/or spatial (e.g., anomalies on adjacent road segments possibly indicating a spreading traffic backup due to an accident) characteristics of detected anomalies.
Various embodiments may further utilize various input information and provide various output information for the predictive models used to make future traffic conditions predictions. In some embodiments, inputs to the predictive models related to date and time information include the following variables: MarketId (an identifier for a geographic region); DateTimeUtc (the time of day in Universal Time); DateTimeLocal (the time of day in local time); DateTimeKey, DateDayOfWeekLocal (the day of the week); DateMonthLocal (the month of the year); DateDayLocal; DateHourLocal (the hour of the day); DatePeriod15MinutesLocal (the 15 minute interval of the day); and HolidayLocal (whether the day is a holiday). In some embodiments, inputs to the predictive models related to current and past traffic conditions information include the following variables: RoadSegmentId (an identifier for a particular road segment); SpeedX (the current reported speed of traffic on road segment X); BlackStartLocalX (the length of time that black traffic congestion level conditions have been reported for road segment X); PercentBlackX (the percentage of sensors or other data sources associated with road segment X that are reporting black traffic congestion level conditions); PercentBlackX-N, where X is a particular road segment and N is a member of {15, 30, 45, 60} and where the value corresponds to the percentage of a road segment X (e.g., percent of sensors associated with the road segment) for which black traffic conditions were reported N minutes ago; RawColor X (the current color corresponding to a level of traffic congestion on road segment X); RawColor X-N, where X is a particular road segment and N is a member of {15, 30, 45, 60}, and where the value is a color corresponding to a level of traffic congestion on road segment X N minutes ago; SinceBlackX (the length of time since black traffic congestion levels have been reported for road segment X); HealthX; and AbnormalityX. In some embodiments, inputs to the predictive models related to weather conditions information include the following variables: Temperature (current temperature); WindDirection (current wind direction); WindSpeed (current wind speed); SkyCover (current level of cloud or haze); PresentWeather (current weather state); and RainNHour, where N is a member of {1, 3, 6, 24} and represents precipitation accumulation in the previous N hour(s); and MetarId. In some embodiments, inputs to the predictive models related to event and school schedules information include the following variables: EventVenueId (a venue identifier); EventScheduleId (a schedule identifier); DateDayLocal (the day of a given event); StartHourLocal (the start hour of a given event); EventTypeId (an event type identifier); EventVenueId (a venue identifier); SchoolLocationId (a school location identifier); and IsSchoolDay (whether or not the current day is a school day).
In some embodiments, outputs to the predictive models related to traffic conditions include the following variables: RawColorXN, where X is a particular road segment and N is a member of {15, 30, 45, 60, 75, 90, 105, 120, 135, 150, 165, 180}, and where the value is a color corresponding to an expected level of traffic congestion on road segment X in N minutes time; and PredRawColorXNProb to indicate confidence in given predictions, where X and N are defined as above with reference to the RawColorXN variables and the value is the confidence level in prediction for road segment X in N minutes time (e.g., based on the level of historical support from observed data for the decision tree path taken to make the prediction).
The following illustrates one example of possible values or ranges of values that may be taken by various of the variables described above, with the indicator “ . . . ” between two numbers indicating that any integer between and including those two numbers are possible values (e.g., “1 . . . 4” represents {1, 2, 3, 4}), and with possible values of 0 and 1 indicating true and false for appropriate variables (e.g., casedata.HolidayLocal). In other embodiments, other input and/or output variables may be used, and their values may be represented in other manners.
Those skilled in the art will also appreciate that in some embodiments the functionality provided by the routines discussed above may be provided in alternative ways, such as being split among more routines or consolidated into fewer routines. Similarly, in some embodiments illustrated routines may provide more or less functionality than is described, such as when other illustrated routines instead lack or include such functionality respectively, or when the amount of functionality that is provided is altered. In addition, while various operations may be illustrated as being performed in a particular manner (e.g., in serial or in parallel) and/or in a particular order, those skilled in the art will appreciate that in other embodiments the operations may be performed in other orders and in other manners. Those skilled in the art will also appreciate that the data structures discussed above may be structured in different manners, such as by having a single data structure split into multiple data structures or by having multiple data structures consolidated into a single data structure. Similarly, in some embodiments illustrated data structures may store more or less information than is described, such as when other illustrated data structures instead lack or include such information respectively, or when the amount or types of information that is stored is altered.
From the foregoing it will be appreciated that, although specific embodiments have been described herein for purposes of illustration, various modifications may be made without deviating from the spirit and scope of the invention. Accordingly, the invention is not limited except as by the appended claims and the elements recited therein. In addition, while certain aspects of the invention are presented below in certain claim forms, the inventors contemplate the various aspects of the invention in any available claim form. For example, while only some aspects of the invention may currently be recited as being embodied in a computer-readable medium, other aspects may likewise be so embodied.
This application is a continuation-in-part of U.S. patent application Ser. No. 11/367,463, filed Mar. 3, 2006 and entitled “Dynamic Time Series Prediction of Future Traffic Conditions,” which is hereby incorporated by reference in its entirety. This application claims the benefit of provisional U.S. Patent Application No. 60/778,946, filed Mar. 3, 2006 and entitled “Obtaining Road Traffic Condition Information From Mobile Data Sources,” which is hereby incorporated by reference in its entirety.
| Number | Name | Date | Kind |
|---|---|---|---|
| 3582620 | Noetinger | Jun 1971 | A |
| 3626413 | Zachmann | Dec 1971 | A |
| 4866438 | Knisch | Sep 1989 | A |
| 4985705 | Stammler | Jan 1991 | A |
| 5289183 | Hassett et al. | Feb 1994 | A |
| 5337082 | Fredericks | Aug 1994 | A |
| 5465289 | Kennedy, Jr. | Nov 1995 | A |
| 5610821 | Gazis et al. | Mar 1997 | A |
| 5663720 | Weissman | Sep 1997 | A |
| 5673039 | Pietzsch et al. | Sep 1997 | A |
| 5696502 | Busch et al. | Dec 1997 | A |
| 5745865 | Rostoker et al. | Apr 1998 | A |
| 5827712 | Yokoyama et al. | Oct 1998 | A |
| 6011515 | Radcliffe et al. | Jan 2000 | A |
| 6119013 | Maloney et al. | Sep 2000 | A |
| 6150961 | Alewine et al. | Nov 2000 | A |
| 6292742 | Heimann et al. | Sep 2001 | B1 |
| 6317686 | Ran | Nov 2001 | B1 |
| 6401027 | Xu et al. | Jun 2002 | B1 |
| 6463382 | Bullock | Oct 2002 | B1 |
| 6480783 | Myr | Nov 2002 | B1 |
| 6490519 | Lapidot et al. | Dec 2002 | B1 |
| 6496773 | Olsson | Dec 2002 | B1 |
| 6505114 | Luciani | Jan 2003 | B2 |
| 6574548 | DeKock et al. | Jun 2003 | B2 |
| 6594576 | Fan et al. | Jul 2003 | B2 |
| 6650948 | Atkinson et al. | Nov 2003 | B1 |
| 6664922 | Fan | Dec 2003 | B1 |
| 6728628 | Peterson | Apr 2004 | B2 |
| 6781523 | Matsui et al. | Aug 2004 | B2 |
| 6832140 | Fan et al. | Dec 2004 | B2 |
| 6862524 | Nagda et al. | Mar 2005 | B1 |
| 6882313 | Fan et al. | Apr 2005 | B1 |
| 6922566 | Puranik et al. | Jul 2005 | B2 |
| 6973319 | Ormson | Dec 2005 | B2 |
| 6989765 | Gueziec | Jan 2006 | B2 |
| 7026958 | Wainfan et al. | Apr 2006 | B2 |
| 7027915 | Craine | Apr 2006 | B2 |
| 7069143 | Peterson | Jun 2006 | B2 |
| 7096115 | Groth et al. | Aug 2006 | B1 |
| 7116326 | Soulchin et al. | Oct 2006 | B2 |
| 7161497 | Gueziec | Jan 2007 | B2 |
| 7221287 | Gueziec et al. | May 2007 | B2 |
| 7375649 | Gueziec | May 2008 | B2 |
| 7508321 | Gueziec et al. | Mar 2009 | B2 |
| 7519564 | Horvitz | Apr 2009 | B2 |
| 7557730 | Gueziec | Jul 2009 | B2 |
| 7610145 | Kantarjiev et al. | Oct 2009 | B2 |
| 20010047241 | Khavakh et al. | Nov 2001 | A1 |
| 20020051464 | Sin et al. | May 2002 | A1 |
| 20030028319 | Khavakh et al. | Feb 2003 | A1 |
| 20030069683 | Lapidot et al. | Apr 2003 | A1 |
| 20040039520 | Khavakh et al. | Feb 2004 | A1 |
| 20040249568 | Endo et al. | Dec 2004 | A1 |
| 20040267440 | DeKock et al. | Dec 2004 | A1 |
| 20060041927 | Stark et al. | Feb 2006 | A1 |
| 20060074551 | Zaitsu et al. | Apr 2006 | A1 |
| 20060103674 | Horvitz et al. | May 2006 | A1 |
| 20060106530 | Horvitz et al. | May 2006 | A1 |
| 20060106599 | Horvitz | May 2006 | A1 |
| 20060106743 | Horvitz | May 2006 | A1 |
| 20060122846 | Burr et al. | Jun 2006 | A1 |
| 20060149461 | Rowley et al. | Jul 2006 | A1 |
| 20060155464 | Smartt | Jul 2006 | A1 |
| 20060224797 | Parish et al. | Oct 2006 | A1 |
| 20060229802 | Vertelney et al. | Oct 2006 | A1 |
| 20070005419 | Horvitz et al. | Jan 2007 | A1 |
| 20070073477 | Krumm et al. | Mar 2007 | A1 |
| 20070199050 | Meier | Aug 2007 | A1 |
| 20070208492 | Downs et al. | Sep 2007 | A1 |
| 20070208494 | Chapman et al. | Sep 2007 | A1 |
| 20070208495 | Chapman et al. | Sep 2007 | A1 |
| 20070208496 | Downs et al. | Sep 2007 | A1 |
| 20070208497 | Downs et al. | Sep 2007 | A1 |
| 20070208498 | Barker et al. | Sep 2007 | A1 |
| 20070208501 | Downs et al. | Sep 2007 | A1 |
| 20080021791 | Steelberg et al. | Jan 2008 | A1 |
| 20080046165 | Downs et al. | Feb 2008 | A1 |
| 20080059115 | Wilkinson | Mar 2008 | A1 |
| 20080071465 | Chapman et al. | Mar 2008 | A1 |
| 20080071466 | Downs et al. | Mar 2008 | A1 |
| 20080133517 | Kapoor et al. | Jun 2008 | A1 |
| 20080275309 | Stivoric et al. | Nov 2008 | A1 |
| 20080278328 | Chand et al. | Nov 2008 | A1 |
| 20090118996 | Kantarjiev et al. | May 2009 | A1 |
| Number | Date | Country |
|---|---|---|
| 10063763 | Jul 2002 | DE |
| 102004015880 | Nov 2004 | DE |
| 2006090872 | Apr 2006 | JP |
| 2004021305 | Mar 2004 | WO |
| 2004021306 | Mar 2004 | WO |
| 2006005906 | Jan 2006 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 20070208497 A1 | Sep 2007 | US |
| Number | Date | Country | |
|---|---|---|---|
| 60778946 | Mar 2006 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11367463 | Mar 2006 | US |
| Child | 11556648 | US |
