Historical traffic data
Traffic affects the time it takes to travel down a road—the more congestion there is, the longer it takes. If you are planning a route from one location to another and don't account for traffic, your expected travel and arrival times could be far from accurate. Moreover, you might miss routing opportunities that save time by avoiding the slower, more congested roads.
The following two graphics demonstrate how the quickest route can change at different times of the day due to changes in the prevailing traffic patterns.
 |
At 8:00 a.m., commuter traffic to the city is heavy, but traffic to the suburbs is light; therefore, the quickest route from the city to the suburbs at this time is along the divided highway. |
 |
At 5:00 p.m., commuters are driving home from the city, which increases the travel time in that direction. Travel has become slow enough on the divided highway that the serpentine alternative now offers a quicker route to the suburbs. |
ArcGIS Network Analyst allows you to use historical traffic information to model the time-dependent costs of traveling on network elements. This way, your expected travel and arrival times are more reliable, and the time you actually spend driving is likely to be less than if traffic patterns were ignored.
Tip:The Network Analyst tutorial data includes a San Francisco geodatabase with historical traffic data. Studying the Streets feature class, the DailyProfiles table, and the Streets_DailyProfiles table contained in SanFrancisco.gdb will enrich your understanding of this topic. If you have the tutorial data installed, the default file location of the geodatabase is shown here:
C:\ArcGIS\ArcTutor\Network Analyst\Tutorial
Note:- Historical traffic can only be configured in a geodatabase; it cannot be configured in a shapefile-based network dataset.
- At ArcGIS 10, only the route and vehicle routing problem analysis layers support traffic data; other network analysis layers will be supported in future ArcGIS releases.
Creating traffic data for use in ArcGIS Network Analyst
Even if you obtain your data from a third party, it's important to understand how historical traffic data is created so that you can properly configure it in a network dataset. This section presents an overview of the model that Network Analyst employs.
Because traffic data captures the continual ebb and flow of travel times, each side of an edge can have many differing costs depending on the time of day. This is in contrast to a typical cost attribute, which allows only one value per side of edge.
One option for modeling travel-time costs that vary throughout a day is to partition the day into discrete intervals, such as one-hour time spans, then store the travel times as separate cost attributes for each interval. Given one-hour intervals, each edge would require 168 cost attributes to store the average travel time for each hour over the course of a week. Traffic can change substantially in an hour, so hour-long intervals provide a fairly coarse resolution. You would probably want to refine it by shortening the time span to, for example, five minutes. This would give you better resolution, but it would result in 2,016 cost attributes. Storing all these unique values would require a lot of space, especially for large networks. Also, since many streets have the same costs during the day, there would be a lot of unnecessary duplication of data. For these reasons, this modeling option isn't viable in many cases.
Rather than store all the traffic information on a per-feature basis, ArcGIS uses a normalized model to minimize the size of the traffic data. Instead of storing the 168 or 2,016 cost attributes per feature, a related table is created to hold this information. Each row in the table contains the travel times for each interval in a day. A row is a traffic profile; it represents how travel times change throughout the day. For example, if you have many secondary, 35-mile-per-hour streets whose travel speeds vary in unison throughout the day, you could create a row in the traffic profiles table to represent these dynamics and have all these streets point to the row, or traffic profile. As you will see below, further refinements are made so that even those roads with differing speeds that follow the same traffic pattern throughout the day can refer to the same traffic profile.
To better understand this traffic model, assume you need to use it to record and store travel times for a one-way street segment over the course of a week, starting on Monday. First, you would determine the free-flow travel time, which is the time it would take a vehicle to traverse a street segment without other traffic impeding its movement. The method you use to determine the free-flow speed is your choice, but it is typically a function of the segment length and speed limit or the observed, average travel time of cars that pass by when other vehicles aren't present. Let's say you choose the observed, average speed of cars and establish the free-flow drive time as 10 seconds.
Now you can make observations throughout the day at equal time intervals, or time slices. The intervals you choose give your data its temporal resolution. You could choose one-hour intervals, 10-minute intervals, and so on. Say you choose 5-minute intervals. Your observations are recorded as multipliers of the free-flow travel time. For example, you observe cars taking 26 seconds to traverse the segment at 8:00 a.m. This is 2.6 times longer than the free-flow travel time. At 5:00 p.m., the average travel time is 13 seconds, which is 1.3 times the free-flow travel time. At 11:00 p.m., there are few cars on the road, and their average travel time is 10 seconds, which is equal to the free-flow travel time—the multiplier is one.
 |
Once your observations for the day are completed, you need to reference a table of traffic profiles and choose the one profile that best matches the observed variation of relative travel times throughout the day.
You choose traffic profile 16 (plotted in the graph below) to represent the segment's travel time on Mondays.
 |
Traffic profile 16 is chosen because it has relative travel times that are very similar to those observed on the street segment. |
Note:The time of day in a profile always represents local time, that is, the time zone in which the referencing edge is located. Therefore, an edge in Los Angeles that references profile 16 will have a travel time that is 2.6 times slower than free-flow speed at 8:00 a.m. Pacific time. An edge in New York that points to the same profile will have a travel time that is 2.6 times slower than free-flow speed at 8:00 a.m. eastern time. Time zones are further discussed later in this topic.
You may have any number of traffic profiles to choose from. When you have more profiles, you have the potential to more accurately model travel times. However, when you have fewer profiles, the space requirements for the data are reduced. The objective is to find a good balance between accuracy and space requirements. It is common for large street networks to have anywhere from dozens to hundreds of traffic profiles.
Now that you have chosen a profile for Mondays, you need to repeat the process for the other days of the week. To review, that process is the following:
- Observe or calculate the free-flow travel time on the street segment. (This doesn't need to be repeated, since it is the same irrespective of the day of the week.)
- Observe average travel times for equal intervals throughout the day.
- Convert the travel times to multipliers of the free-flow travel time.
- Choose a profile to represent the street segment's traffic for that day of the week.
You determine that traffic profile 16 also works well for the segment on all other weekdays. This determination is often made, since general traffic patterns are frequently the same on all business days. Still, it's not difficult to find weekdays that use different representative profiles; for example, it could be that Mondays, Tuesdays, and Wednesdays use the same profile, while Thursdays and Fridays share a different profile.
The Saturday and Sunday traffic on your segment is light and steady, so you choose Traffic Profile 10 (below) to represent travel times on the weekends.
 |
Next, you store the free-flow travel time and the relationships between the street segment and traffic profiles in a table: the Streets-Traffic Profiles Join Table. The next sections review this table, as well as other required inputs.
Storing data and relationships in the geodatabase
You need one or more line feature classes and two tables in a geodatabase if you want to create a network dataset with historical traffic data. The line feature classes represent streets, which must be stored in a feature dataset. The traffic profiles are stored in one of the tables, and the relationships between the streets and speed profiles are stored in the other table. These items and the fields required to set up historical traffic on a network dataset are described in the following subsections.
Note:The relationships between streets and speed profiles are simply made by storing values of unique identifiers in tables; you don't need to create any relationship classes.
Streets feature class
Each street feature has a unique identifier: the ObjectID value. The Streets-Traffic Profiles Join Table relates streets to their various traffic profiles through the unique identifier.
 |
Other fields may be useful when setting up historical traffic. They are listed below and described in more detail later in this topic.
|
Field |
Field name examples |
Description |
|---|---|---|
|
Time-neutral travel times |
FT_Minutes TF_Minutes |
For creating a network cost attribute that is used when
|
|
Weekday travel times |
FT_WeekdayMinutes TF_WeekdayMinutes |
For creating a network cost attribute that is used when a street segment doesn't have an associated traffic profile for a weekday (The time-neutral travel times are often also used as weekday-specific travel times.) |
|
Weekend travel times |
FT_WeekendMinutes TF_WeekendMinutes |
For creating a network cost attribute that is used when a street segment doesn't have an associated traffic profile for a Saturday or Sunday |
|
Time zone |
TimeZoneID |
For creating a time-zone network attribute that is needed when a network spans multiple time zones |
Traffic Profiles table
Each record in a traffic profiles table has a unique identifier and several fields for storing the free-flow multiplier at different times of the day. The times of the day are split into time intervals, or time slices, which must be of equal duration and, thus, split a 24-hour period into equal intervals. For instance, if the time slices are five minutes in length, there are 288 fields (one for 12:00–12:05 a.m., 12:05–12:10 a.m., and so on).
The San Francisco geodatabase in the Network Analyst tutorial data has profiles that cover the day in five-minute time slices. The TimeFactor_0000 field contains the free-flow multipliers for midnight to 12:05 a.m. The TimeFactor_1140 field contains the multipliers for 11:40 a.m. to 11:45 a.m. When a street feature is related to this profile, you can get its expected travel time for any time of the day. For example, if a street is related to profile 16, which is shown in the graphic below, you can calculate the expected travel time at 11:41 a.m. by multiplying the street's free-flow travel time with the profile's TimeFactor_1140 value (1.124859).
 |
Caution:Personal geodatabases limit tables to a maximum of 255 fields. Some ArcSDE geodatabases might have similar limits on the number of fields. Therefore, you might need to leave a hole in your data to reduce the number of fields in the traffic profiles table. For example, if your traffic profiles table is going to have five-minute intervals and be stored in a personal geodatabase, the table would require at least 288 fields, which is infeasible. Instead, you could use a file geodatabase, since it supports more than 65,000 fields, or you could delete several fields that represent time intervals of constant speed, such as from midnight to 3:00 a.m.
Streets-Traffic Profiles join table
The Streets-Traffic Profiles join table identifies street features, their free-flow travel times, and their related profiles for each day of the week. The following table lists the required fields, an example field name, their allowed data types, and a short description:
|
Field |
Field name examples |
Data type |
Description |
|---|---|---|---|
|
Edge feature class identifier |
EdgeFCID You must name this field EdgeFCID. |
Long integer |
Identifies the feature class that the street feature is stored in. |
|
Edge feature identifier |
EdgeFID You must name this field EdgeFID. |
Long integer |
Identifies the street feature. |
|
Edge from position |
EdgeFrmPos You must name this field EdgeFrmPos. |
Double |
Works in conjunction with EdgeToPos to identify a direction of travel or side of the street. Zero indicates the beginning of the line feature as defined by its digitized direction. One indicates the opposite end. For example, an EdgeFrmPos value of 0 and an EdgeToPos value of 1 would identify the right side of the line feature (assuming right-hand traffic). The traffic profiles listed in the same record would represent traffic for that side of the street only. Any decimal values specify a position along the digitized direction of the feature, which allows the Dissolve Network tool to maintain the proper profiles for streets after edges have been dissolved together. |
|
Edge to position |
EdgeToPos You must name this field EdgeToPos. |
Double |
Works in conjunction with EdgeFrmPos to identify a direction of travel, or side of the street. |
|
Base Travel Time Field |
FreeflowMinutes FreeflowSeconds |
Float or double |
The free-flow travel time. It can represent days, hours, minutes, or seconds. |
|
Sunday ProfileID Field |
Profile_1 SundayProfile |
Short or long integer |
The profile ID that best represents the traffic pattern on Sundays for the portion of the street identified by EdgeFCID, EdgeFID, EdgeFrmPos, and EdgeToPos. |
|
Monday ProfileID Field |
Profile_2 MondayProfile |
Short or long integer |
The profile ID that best represents Monday traffic. |
|
Tuesday ProfileID Field |
Profile_3 TuesdayProfile |
Short or long integer |
The profile ID that best represents Tuesday traffic. |
|
Wednesday ProfileID Field |
Profile_4 WednesdayProfile |
Short or long integer |
The profile ID that best represents Wednesday traffic. |
|
Thursday ProfileID Field |
Profile_5 ThursdayProfile |
Short or long integer |
The profile ID that best represents Thursday traffic. |
|
Friday ProfileID Field |
Profile_6 FridayProfile |
Short or long integer |
The profile ID that best represents Friday traffic. |
|
Saturday ProfileID Field |
Profile_7 SaturdayProfile |
Short or long integer |
The profile ID that best represents Saturday traffic. |
An example of a Streets-Traffic Profiles join table is the table entitled Streets_DailyProfiles in the first graphic below. The field, PROFILE_1, represents Sunday ProfileID Field; PROFILE_7 represents Saturday ProfileID Field; PROFILE_2 through PROFILE_6 (not shown) represent the Monday through Friday ProfileID Fields.
Look at the selected record (ObjectID 111). It relates profiles for each day of the week with the from-to side of the street feature that has an object ID of 129. The from-to direction of the street is identified by the EdgeFrmPos and the EdgeToPos values, which are respectively zero and one. Traffic profile 12 represents that side of the street on Sundays and Saturdays, since 12 is the value in the PROFILE_1 and PROFILE_7 fields. The FreeflowMinutes field indicates how long it would take to traverse the street in the from-to direction under free-flow conditions.
Now look at the first two records. The first record (Object ID 109) stores the profile IDs for a street segment in the to-from direction, and the second record (Object ID 110) stores them for the same street segment in the opposite direction. This is inferred from the EdgeFCID and EdgeFID values, which are identical, and the EdgeFrmPos and EdgeToPos values, which are reversed. Also notice that their Sunday and Saturday profile IDs are zero. This means data wasn't collected or a profile wasn't chosen for those days. When evaluating Saturday or Sunday historical travel times for that edge, the evaluator will need to fall back to a secondary cost attribute defined in the edge traffic evaluator (described later).
 |
Configuring historical traffic data in the New Network Dataset wizard
After you have received or created historical traffic data, you need to incorporate the data into a new network dataset. This is accomplished in the New Network Dataset wizard.
Note:
- You can only configure traffic data in a network dataset during the creation process, not afterwards.
There are four major steps within the network-dataset creation process for incorporating historical traffic data:
- Configure the two historical traffic tables:
- Traffic Profiles table
- Streets-Traffic Profiles join table
- Create up to four network cost attributes:
- Historical travel time cost attribute
- Fallback travel time cost attribute for weekdays
- Fallback travel time cost attribute for weekends
- Time-neutral cost attribute
- Configure the evaluators for the above cost attributes.
- If your network spans more than one time zone, create a time zone attribute.
The following subsections describe these steps.
Historical traffic tables
The New Network Dataset wizard asks if you want to use historical traffic with the network dataset in the page shown below. By clicking Yes, you can specify the properties regarding the Traffic Profiles table and the Streets-Traffic Profiles join table.
 |
The Traffic Profiles table in the network dataset
The table below lists the properties that you need to configure for the Traffic Profiles table.
|
Property |
Description |
|---|---|
|
Table |
The name of the table that contains the traffic profiles. |
|
First Time Slice Field |
This property, in conjunction with Last Time Slice Field, specifies a time range. Whenever an edge is evaluated for a time of day outside the range, its multiplier is assumed to be one. This assumption hastens the lookup of costs for times of the day when there is little to no traffic. |
|
Last Time Slice Field |
See the description for First Time Slice Field. |
|
Minutes Per Time Slice |
Your traffic profiles table must be divided into equal time intervals throughout the day. This property specifies the length of the interval in minutes. |
|
First Time Slice Start Time |
This property identifies the time of day that the beginning of the First Time Slice Field represents. For example, the First Time Slice Field is set to TimeFactor_0400, which starts at 4:00 a.m.; therefore, First Time Slice Start Time is set to 4 AM. |
|
Last Time Slice Start Time |
This property specifies the time of day that the end of the Last Time Slice Field represents. It is automatically deduced from the number of time-slice fields and the Minutes Per Time Slice value. |
The Streets-Traffic Profiles join table in the network dataset
The Streets-Traffic Profiles join table has 10 properties to set, which are described in the table below.
|
Property |
Description |
|---|---|
|
Table |
The name of the table that contains the free-flow speeds of streets and the relationships between streets and traffic profiles |
|
Base Travel Time Field |
The field that contains free-flow travel times |
|
Base Travel Time Units |
The time units of the field specified in Base Travel Time Field |
|
Sunday ProfileID Field Monday ProfileID Field Tuesday ProfileID Field Wednesday ProfileID Field Thursday ProfileID Field Friday ProfileID Field Saturday ProfileID Field |
The name of the field that contains traffic profile IDs for Sunday traffic, Monday traffic, and so on |
Network attributes
The next step to incorporating historical traffic data is specifying network attributes. The TravelTime cost attribute is created automatically after configuring the historical traffic tables. TravelTime has edge traffic evaluators that read the historical traffic tables to find travel times for a given time of day and day of the week. If an edge doesn't have historical traffic data for a particular day of the week, the evaluators fall back to other time-based cost attributes—one for weekdays and another for weekends.
The edge traffic evaluator also refers to a time-neutral cost attribute. Time-neutral in this case means the travel times of the network attribute don't change with time of day or day of the week. That is, it is a normal network cost attribute wherein each network element has the same expected travel time irrespective of time or day. The edge traffic evaluator uses the time-neutral attribute to do the following:
- Solve network analysis layers that don't support historical traffic. (Only route and vehicle routing problem analysis layers currently support historical traffic data.)
- Solve network analysis layers that support historical traffic when a time and day are not provided.
- Sequence network locations in a route or vehicle routing problem analysis layer. (The sequence of network locations are not optimized using historical travel times; however, the routes between the network locations are.)
The blue rectangle in the graphic below highlights the network cost attributes that are used in historical-traffic analyses. TravelTime is the historical traffic cost attribute. It uses edge traffic evaluators that reference other cost attributes. You'll see later that Minutes is the time-neutral attribute for TravelTime. Minutes uses a field evaluator that reads values from the fields, FT_Minutes and TF_Minutes. Like Minutes, WeekdayFallbackTravelTime and WeekendFallbackTravelTime return the same cost value per side of edge, regardless of time of day. The difference, however, is that WeekdayFallbackTravelTime represents the average travel time on weekdays, and WeekendFallbackTravelTime represents the average travel time on weekends. In this example, a field evaluator reads costs for WeekdayFallbackTravelTime from FT_WeekdayMinutes and TF_WeekdayMinutes. A similar pair of fields provides values for WeekendFallbackTravelTime.
 |
Edge traffic evaluator
The TravelTime attribute has edge traffic evaluators that make use of other cost attributes, which in this example are Minutes, WeekdayFallbackTravelTime, and WeekendFallbackTravelTime. The edge traffic evaluator is shown below.
 |
Edge traffic evaluators calculate the travel times of edges for a given time of the day and day of the week. The Time-Aware Evaluation section of the Edge Traffic Evaluators dialog box lets you know that the evaluator will first search through the Traffic Profiles table and Streets-Traffic Profiles join table to find the profile that represents the segment's traffic on the given day. If it finds a profile, it uses the multiplier (in the Traffic Profiles table) and the free-flow travel time (in the Streets-Traffic Profiles join table) to calculate the historical travel time. However, if the segment doesn't have a profile for the given day, the evaluator relies on the weekday or weekend fallback attribute to provide a travel time. If the evaluator searches for a time on a weekday, it references the Weekdays attribute.
The fallback attribute is split into weekdays and weekends to allow you to get more accurate travel times. Yet, you can choose to have both Weekdays and Weekends point to the same cost attribute; for example, both could point to the attribute Minutes if you didn't have weekday- and weekend-specific travel times.
The time-neutral evaluation cost attribute is Minutes.
Time zones
If your network dataset is covered by more than one time zone, it is imperative that you add a time zone network attribute. If a time zone attribute is not configured, Network Analyst could evaluate travel times for the wrong time of day because it would assume that all edges are in a single time zone.
Editing source features after the network is built
When editing source features that are associated with traffic data, you may also need to edit the Streets Traffic-Profiles table because it references the object IDs of source features. Here are some points to consider:
- If you change the shape or attributes of a street feature, this won't cause the creation or deletion of any object IDs; therefore, the street feature will continue to be associated with the same profiles after the rebuild process.
- If you delete a street feature, the associated records in the Streets Traffic-Profiles table will become irrelevant. The associated records should also be deleted, but this is not required.
- If you split an existing street feature, the feature is divided into two parts; one part retains the Object ID of the original feature, and the other part is assigned a new ID. The street feature with the old ID will continue to be associated with the same profiles as the original street feature. The part with the new ID will not be associated with any traffic profiles; therefore, you will need to add one or more records to the Streets Traffic-Profiles table to relate it to any profiles.
- New features that you add to the network will not have any associated traffic profiles until you add corresponding records to the Streets Daily-Profiles table and rebuild the network.
Copying source features
Each feature class in a geodatabase has a feature class ID, which is an automatically-generated integer that uniquely identifies the feature class within a geodatabase. When you copy a feature class from one geodatabase to another, the feature class IDs of the original and the copy will likely be different.
If you copy a source feature class along with a related table, like the Streets-Traffic Profiles table, then create a network dataset, the records in the table will have references to the old feature class IDs. Consequently, you will get unwanted results. However, if you copy and paste a network dataset, the source features and any associated tables are automatically copied to the new location. Moreover, the fields in the tables that refer to feature class IDs, like EdgeFCID, are updated for you.
Tip:If copying the network dataset is not an option for you, you can use the Python window to determine feature class IDs and manually update the tables. The steps below describe this process.
- Add the feature class to ArcMap.
- Click the Python window button
on the Standard toolbar. - In the Python window that appears, type arcpy.Describe("[layer name]").DSID, replacing [layer name] with the name of the feature layer.
For example, to get the feature class ID of a layer named Streets, type arcpy.Describe("Streets").DSID.
- Press ENTER.
The feature class ID is displayed below the command you typed.
- In the associated tables, replace the old ID with the new one.
Performing an analysis using historical traffic data
Once the network dataset is built to include the TravelTime network attribute; the edge traffic evaluators; and, potentially, a time zone attribute, you can perform time-dependent network analyses.
Route analysis
This subsection highlights properties and solver behavior you should consider when setting up a route analysis layer with historical traffic data. For more information about these properties, see the topic Route analysis.
Network analysis layer properties
- Set the Impedance property to the TravelTime network attribute.
- Check Use Start Time and set the Time of Day and the Day of Week or Specific Date attributes to the time you want the route (or routes) to start.
- If you want to visit stops within time windows, check Use Time Windows.
Network analysis object properties
- If you checked Use Time Windows, specify any time windows for stops with their TimeWindowStart and TimeWindowEnd properties. The time-of-day values you enter are assigned the local time zone, that is, the time zone of the stop's associated edge element.
Vehicle routing problem
This subsection highlights properties and solver behaviors that you should consider when setting up a vehicle routing problem analysis layer with historical traffic data. For more information about these properties, see the topic Vehicle routing problem analysis.
Network analysis layer properties
- Set Time Attribute to the TravelTime network attribute.
- Set Default Date using either Day of Week or Specific Date. This is the day or date that the time-of-day values in the network analysis objects refer to.
Network analysis object properties
- Orders and Depots each have two time windows that you can set with TimeWindowStart1, TimeWindowEnd1, TimeWindowStart2, and TimeWindowEnd2. The time-of-day values you enter are assigned the local time zone, that is, the time zone of the network location's underlying edge element.
- The time windows in which a route can begin are specified with the EarliestStartTime and LatestStartTime properties. The time zone for these property values is taken from the edge that the route's starting depot is located on.
- Breaks have a time window that you specify using TimeWindowStart and TimeWindowEnd. A break is associated with a route, and the time zone is taken from the edge that the route's starting depot is located on.