Map applications, such as Bing Maps, Google Maps, etc., are often used to provide directions. A user typically specifies starting and ending locations (and possibly some intermediate points), and the map application plans a route that goes from the starting location to the ending location (passing through the intermediate points, if they are specified). Such applications often calculate an estimate of the time that it will take to travel the route. The time estimate is generally based on data that represents the current traffic at the moment that the user interact with the system integrated along the route. For example, if a set of directions from Redmond, Wash., to Seattle, Wash., says “Take state route 520 west for 10 miles, and then take Interstate 5 south for 2 miles,” the system adds the current speeds of travel along these particular stretches of SR-520 and I-5. Thus, the current amount of time that it takes to travel the entire route can be calculated by adding the current amount of time that it takes to travel each stretch of the route.
A problem that arises in providing a time estimate is that the amount of time that it takes to travel a given route tends to vary depending on the time of day. For example, a route may be crowded during rush hour, but may be clear in the middle of the afternoon or late evening. But typical map applications simply give the user only the current amount of time that it takes to travel the route, which does not take into account the time at which the user is actually going to travel the route. For example, when a user is interested in a real estate, he might be interested in the average travel time during rush hour, and not the time it takes to travel when he interacts with the system (Furthermore, the travel time in one rush hour instance may not represent the yearly or seasonal average.) Some automobile navigation systems download current traffic conditions and estimate the time it currently takes to travel based on the current traffic conditions. However, when a user is requesting directions through a map application, the user is typically asking for directions that the user will use at some unspecified time in the future (since the user will often travel after the interaction).
A map application may be created that provides directions for a given route, and that also provides information about how long it will take to travel the route at various times of day. In order to provide time information along with the directions, information may be collected concerning the traffic patterns along various stretches of road. The information may be associated with a particular time. For example, there may be sensors along State Route 520 that determine how fast traffic is moving at a particular point in time—e.g., at 5:35 p.m. traffic was detected to be moving at 19 miles per hour. These data points may be collected in bins that represent different time intervals. For example, there could be one interval for each hour of the day (e.g., a bin for 12 a.m. to 1 a.m., another bin for 1 a.m. to 2 a.m., etc.). As another example, the bins could take into account both specific times and specific days, since traffic might be different on a Saturday than it is on a Monday; thus, Saturday from 12 a.m. to 1 a.m. might be a different bin than Monday from 12 a.m. to 1 a.m.
When sufficient data is collected in the bins, an average is calculated for each bin. Thus, given sufficient data, it is possible to determine that the average speed at a given point along State Route 520 is, say, 21 m.p.h. between 5 p.m. and 6 p.m., and 45 m.p.h. between 2 p.m. and 3 p.m. Similar statistics can be collected for any point on any road at which data is available.
When a user asks for directions, a map application plans a route, and then uses the statistics to calculate how long it will take to travel the route at different times of day. The amount of time that it takes to travel a route at different times of day may be presented to a user in some manner. For example, the user could be presented with a list that says how long the application estimates it will take to travel the route at different times of day. Or, the application could present a graph to the user, showing how the travel time increases or decreases throughout the day. Or, the system could ask the user what time of day he or she intends to travel, and could present a route that is calculated to take the smallest amount of time at the time of day the user has specified. Or, as yet another example, the system could take into account the fact that traffic patterns may change through time as the user drives the route. For example, a driver might leave Seattle heading south toward Portland, Oregon at noon. When the driver leaves Seattle, traffic may be light in the middle of the day, but by the time the driver arrives in Portland it may be rush hour with heavier traffic.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Map applications are used to provide directions from one place to another. Typically, the user lists the starting point, the ending point, and possibly a set of intermediate points. The application then uses geographic data to plan a route from the start to the end, passing through the intermediate points if specified. The application then provides instructions on how to follow the route (e.g., “Start on Main Street, go 1.5 miles, take the exit ramp to State Route 520”). Typically, the application also calculates the amount of time that it will take to traverse the route. There may be different modes of travel (e.g., driving, walking, bus, etc.), and the application may provides estimates of how long it will take to traverse the route using the different modes of travel.
One issue that arises is that the amount of time that it takes to travel a route may depend on the time at which the route is being traveled. Traffic patterns along roads tend to vary throughout the day, or even across days. It may take twenty minutes to traverse a stretch of road at 11:00 a.m. in the morning, but at 5:30 p.m. (which is typically rush hour), it might take an hour to traverse the same stretch of road. Moreover, the amount of time that it takes to traverse a stretch of road may vary based on both the day and the time. For example, a road may be crowded and slow at 5:30 p.m. on Monday through Friday, but the same road might be relatively clear at 5:30 p.m. on Saturday and Sunday. Map applications typically estimate the time to traverse a route based on the up-to-date current traffic patterns that exist on that route, but the traffic pattern at any given time might differ significantly from the average. Some map applications may estimate the travel time based on current conditions, rather than based on some overall average, but one problem is that a user might request directions at one time and might plan to travel the route at a different time.
Estimating the time for auto travel presents a problem, but estimating the time for other types of travel can present related problems. For example, a given trip by train may take longer during rush hour than in the middle of the day, since at rush hour there may be a higher volume of trains on the railroad, and each train may make longer stops to take on or discharge a larger number of passengers. Additionally, trains (and busses, and ferries, etc.) depart at discrete times (e.g., 5:00 p.m., 5:15, 5:30, etc.), so the amount of time that it takes to travel by train may include the amount of time the person spends waiting for the next train. For example, if a train departs every 15 minutes (at, say, :00, :15, :30, and :45 after the hour) for a one-hour journey to some destination, then the amount of travel time is one hour if a person starts traveling at 5:00, but is one hour and fourteen minutes if a person starts traveling at 5:01, since in the latter case the trip includes fourteen minutes of time waiting for the next train. In general, it can be said that the amount of time that a trip takes is dependent on the time at which the trip is taken.
The subject matter described herein provides a way to present a user with information about how long a trip will take based on the time of day at which the trip is taken. Historical information is collected about how long it takes to travel between various points at various times of day. For example, with regard to car travel, a sensor could detect the speed of traffic at a particular point on a road, and could provide data concerning the speed detected and the day and time at which the speed was detected. In such an example, the data collected indicates how long it takes to travel past the location of the sensor. This data then may be collected in bins, representing different times of days, or possibly different days. For example, a bin might represent the 1 a.m. to 2 a.m. time slot, or might represent the 1 a.m. to 2 a.m. Monday time slot (with there being different 1-2 a.m. slots for different days of the week), or might represent the 1 a.m. to 2 a.m. weekday time slot (with there being a different 1-2 a.m. slot for the weekend). When sufficient data has been collected, an average for each bin can be created. In this example, the average would indicate the typical speed for the observed point of the road within a given time interval. A similar set of bins could be created for each observable point of road, and averages can be calculated for each bin. Therefore, it is possible to know how fast a road typically moves at a particular time of day.
Using the information about how fast traffic moves at a particular time of day, it is possible to calculate how long it will take to travel a route at different times of day. For example, a route might take fourteen minutes to travel in the middle of the night when there is no traffic, but might take over an hour to travel during rush hour. Therefore, an application can present, to a user, information that reflects how long it will take to travel a route at a given time of day. For example, the application could present a table that shows the different travel times at different hours of a day. Or, it could present a graph showing how the travel time changes throughout the day. Or, the application could ask the user at what time of day he or she wishes to travel, and could plan a route that is likely to minimize the travel time at that time of day.
Turning now to the drawings,
The application may also provide information about how long it will take a driver to travel the route. This information could be presented in various forms. In the example shown in
Table 106 is merely one way to show the user how travel time varies throughout the day. In general, once an application has information about how travel time varies throughout the day, it can use that information in various ways to provide the user with an indication of how long it will take to traverse the route at various times of day. Some other ways of using and/or presenting this information are described below.
For each location on which data is reported, data aggregator 208 may create a histogram 210, which groups data based on the time to which the data relates. For example, histogram 210 has bins for each hour of a day—e.g., bin 212 is for the 12 a.m. to 1 a.m. hour, bin 214 is for the 1 a.m. to 2 a.m. hour, and bin 216 is for the 11 p.m. to 12 a.m. hour. Providing a bin for each hour of the day is merely one example of how the bins could be arranged. For example, there could be a bin for each two-hour interval, or for each half-hour interval, or for any other interval. Moreover, there could be bins for different hours of different days. For example, as noted above, there might be seven different 1 a.m. to 2 a.m. bins, one for each day of the week, or there might be two different 1 a.m. to 2 a.m. bins, one for weekdays and one for weekends. In general, a bin could be created for any type of time interval.
Histogram 210 collects data received from traffic feeds 202-206 on a continuing basis. When histogram 210 has sufficient data to create meaningful averages, the data in each bin is averaged in order to determine the typical state of traffic in the time interval represented by each of the bins. As noted above, each location for which traffic data is collected may have its own histogram. Therefore, if histogram 210 is the histogram for traffic feed 202 (corresponding to location A), then the average of data points in bin 212 may represent the state of traffic (e.g., the average traffic speed) at location A from 12 a.m. to 1 a.m., and the average of data points in bin 214 may represent the state of traffic at location A from 1 a.m. to 2 a.m., and so on.
At 302, traffic data for a given location is received. The data may be received in any form. For example, as shown in
At 304, the received traffic data is put in bins, based on the time interval to which it relates. As described above, for each location about which data is collected, a histogram containing several bins could be created, and, within a histogram, there could be a bin for each hour of the day. As data for a particular location is received, the data could be put into a particular bin based on the time of day into which the data falls.
At 306, a forecast is calculated for a particular time interval. For example, there may be several data points collected in the 4 p.m. to 5 p.m. interval. Each data point might indicate a speed of traffic that was observed at some point during that time interval. The different data points could be averaged to determine the average speed at which traffic moves at a given location between the hours of 4 p.m. and 5 p.m.
At some point in time, an application receives a request to provide a route (at 308). For example, an on-line mapping application (e.g., Bing Maps) might receive a request to provide directions from one place to another (e.g., from Redmond to Seattle, as in the example of
At 314, the route and the travel-time calculations are presented to the user. These results may be presented in various ways. For example,
However, in addition to the examples of
In one example, the user interface that shows the route could be made interactive. Thus, the interface could provide a control (e.g., a slider) that allows the users to move through different times of day. As the user moves, portions of the route shown on a map could change colors—e.g., red for heavy traffic, yellow for moderate traffic, and green for light traffic. As a variation on this idea, moving the slider could alter the route. For example, the application that provides the route might choose to provide a route that takes the shortest time to travel. As the user moves the slider to different times of day, the route that takes the shortest time to travel could change, and therefore the route shown to the user could change based on what time of day the user is indicating with the slider. As a further variation on this theme, the user might specify that he wants to travel at whatever time of day would take the least amount of time to travel. Thus, the application could pick the combination of a route and a time that would take the least time to travel.
Additionally, the time at which the user will travel could be mined from the user's calendar (assuming, of course, that appropriate permission to use the calendar was obtained from the user, in order to respect the privacy of the user's calendar). Thus, if the user has a meeting on his calendar at a specific location, directions could be calculated from the user's office to the meeting location, and the travel time for the directions could be chosen based on the time that the meeting is to take place. For example, if the user has a meeting at 2:00 p.m., the user could be given directions to the meeting, along with an estimate of how long it will take to traverse the route specified in the directions during the 1-2 p.m. hour.
Moreover, the amount of time that it takes to traverse a route could take into account how traffic patterns will change during the time that the route is being traveled. For very short routes (e.g., a few miles), it may be reasonable to assume that the entire route will be traversed within a specific hour. However, for longer routes (e.g., Seattle to Portland), the traffic patterns may change while the route is being traversed. For example, if the user leaves Seattle at noon heading toward Portland, traffic may be clear in Seattle at noon, but by the time the user arrives in Portland a few hours later, the user may be driving through heavy rush hour traffic. Thus, different time intervals may be used to estimate the time to traverse different portions of the route. For example, the 12-1 p.m. interval may be used to estimate traffic patterns at the beginning of the route in Seattle, but the 4-5 p.m. interval may be used to estimate traffic near the end of the route in Portland, since it is likely to be around four o'clock when the user arrives in Portland.
Additionally, it is noted that driving is merely one mode of transportation for which travel time can be estimated. In other examples, travel time for walking, trains, busses, planes, etc., can be estimated. In the case of public transportation vehicles that leave at specific times, the schedule of the public transportation vehicles can be considered in determining the travel time. For example, if a bus leaves at :00, and :30 after each hour, then the amount of travel time may include, say, 29 minutes of wait time if the user begins his journey at 1:01 in the afternoon, since the next train will not leave for another 29 minutes. The user could provide an indication of what mode of travel the user intends to use, and directions and travel times could be provided that are appropriate to the user's intended mode of travel.
Computer 500 includes one or more processors 502 and one or more data remembrance components 504. Processor(s) 502 are typically microprocessors, such as those found in a personal desktop or laptop computer, a server, a handheld computer, or another kind of computing device. Data remembrance component(s) 504 are components that are capable of storing data for either the short or long term. Examples of data remembrance component(s) 504 include hard disks, removable disks (including optical and magnetic disks), volatile and non-volatile random-access memory (RAM), read-only memory (ROM), flash memory, magnetic tape, etc. Data remembrance component(s) are examples of computer-readable storage media. Computer 500 may comprise, or be associated with, display 512, which may be a cathode ray tube (CRT) monitor, a liquid crystal display (LCD) monitor, or any other type of monitor.
Software may be stored in the data remembrance component(s) 504, and may execute on the one or more processor(s) 502. An example of such software is travel time estimation software 506, which may implement some or all of the functionality described above in connection with
The subject matter described herein can be implemented as software that is stored in one or more of the data remembrance component(s) 504 and that executes on one or more of the processor(s) 502. As another example, the subject matter can be implemented as instructions that are stored on one or more computer-readable storage media. (Tangible media, such as an optical disks or magnetic disks, are examples of storage media.) Such instructions, when executed by a computer or other machine, may cause the computer or other machine to perform one or more acts of a method. The instructions to perform the acts could be stored on one medium, or could be spread out across plural media, so that the instructions might appear collectively on the one or more computer-readable storage media, regardless of whether all of the instructions happen to be on the same medium.
Additionally, any acts described herein (whether or not shown in a diagram) may be performed by a processor (e.g., one or more of processors 502) as part of a method. Thus, if the acts A, B, and C are described herein, then a method may be performed that comprises the acts of A, B, and C. Moreover, if the acts of A, B, and C are described herein, then a method may be performed that comprises using a processor to perform the acts of A, B, and C.
In one example environment, computer 500 may be communicatively connected to one or more other devices through network 508. Computer 510, which may be similar in structure to computer 500, is an example of a device that can be connected to computer 500, although other types of devices may also be so connected.
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.