Historical traffic

The ArcGIS Network Analyst extension allows you to use historical traffic information to model the time-dependent speeds of traveling on roads. 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, which is available on ArcGIS.com, includes a San Francisco geodatabase with 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. After downloading and extracting the data, you can find the SanFrancisco geodatabase at \Network Analyst\Tutorial\SanFrancisco.gdb.

Learn more about the Network Analyst tutorial exercises

Note:

Traffic can only be configured in a geodatabase; it cannot be configured in a shapefile-based network dataset.

Creating historical traffic data for use with 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 speeds, each travel direction 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 edge direction.

There are several different ways to model multiple costs per edge direction. To understand why Network Analyst uses a particular model, it is important to understand the shortcomings of what is perhaps the most obvious way to model traffic.

How Network Analyst doesn't model historical traffic

One option for storing historical traffic data is to create a series of costs for each edge. The costs would represent traffic speeds at different times of the day, over the course of a week. For instance, a week could be partitioned into 168 discrete, one-hour intervals. This means that each edge would need 168 cost attributes to represent how traffic tends to change over a week's time. If the time span was shortened to five-minute intervals to provide better temporal resolution, each edge would need 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 for Network Analyst.

How Network Analyst models historical traffic

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 speeds or, optionally, travel times for each interval in a day. A row is a traffic profile; it represents how speeds 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 single row in the traffic profiles table to represent these dynamics and have all these streets point to the same row, or traffic profile. As you will see below, further refinements are made so that even those roads with differing speed limits 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 speeds for a one-way street segment over the course of a week, starting on Monday. First, you would determine the free-flow speed, which is the speed a vehicle travels when no other traffic is impeding its movement. The method you use to determine the free-flow speed is your choice, but it is typically the speed limit or the observed, average speed 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 speed is 70 miles per hour.

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 scale factors of the free-flow speeds. The scale factors are limited to a range of zero to one. Assume you observe cars traveling 28 miles per hour at 8:00 a.m. This is 0.4 times the free-flow travel speed. At 5:00 p.m., the average speed is 60 miles per hour, which is about 0.85 times the free-flow travel speed. At 11:00 p.m., there are few cars on the road, and their average speed is 70 miles per hour, which is equal to the free-flow travel speed—the scale factor 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 speeds throughout the day.

You choose traffic profile 68 (plotted in the graph below) to represent the segment's travel time on Mondays.

Traffic profile 68 is chosen because it has relative travel speeds 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 68 will have a speed that is 40% of free-flow speed at 8:00 a.m. Pacific time. An edge in New York that points to the same profile will have a speed that is 40% of the free-flow speed at 8:00 a.m. eastern time.

Learn more about adding time zones to a network dataset

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:

1. Observe or calculate the free-flow travel speeds on the street segment. (This doesn't need to be repeated, since it is the same irrespective of the day of the week.)
2. Observe average speeds for equal intervals throughout the day.
3. Convert the speeds to a scale factor (between 0 and 1) of the free-flow speed. (If you are directly modeling travel times instead of speeds, the scale factor must be greater than or equal to one.)
4. Choose a profile to represent the street segment's traffic for that day of the week.

You determine that traffic profile 68 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 3 (below) to represent travel times on the weekends.

Next, you store the free-flow speeds and the relationships between the street segment and traffic profiles in a table: the Streets-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 speed 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-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 sequencing locations in a route or vehicle routing problem analysis that uses traffic
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 historical 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

Profiles table

Each record in a traffic profiles table has a unique identifier and several fields for storing the free-flow scale factor 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 SpeedFactor_0000 field contains the free-flow scale factors for midnight to 12:05 a.m. The SpeedFactor_1140 field contains the multipliers for 11:40 a.m. to 11:45 a.m. When a street feature is related to a 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 SpeedFactor_1140 value (0.889).

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., when traffic tends to flow freely.

Streets-Profiles join table

The Streets-Profiles join table identifies street features, their free-flow travel speeds (or travel times), and their related traffic 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 Speed Field or Base Travel Time Field	BaseSpeedKPH or FreeflowMinutes	Float or double	The free-flow speed. Optionally, the free-flow travel time. As a base speed field, it can represent kilometers per hour or miles per hour. As a base travel time field, 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-Profiles join table is the table entitled Streets_DailyProfiles in the 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 28803. 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 SPFREEFLOW field indicates the travel speed for 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.