Section 6.3.1 Network Attributes

The network attributes necessary for the model to function properly are provided in Table 6-4. These attributes include items such as the number of lanes, facility type, distance, etc. The attributes in Table 18 are also recommended when coding networks to facilitate summarizing the output networks. Special attention should be given to the traffic count locations especially when copying/pasting link attributes or splitting existing links as it could result in traffic counts in incorrect locations.

Table 6-4 Highway Network Attributes

Table 6-5 Recommended Highway Network Attributes

Section 6.3.2 Capacities

In previous model versions, the lookups for link capacities were embedded in the model script. In this newer version, the lookup has been transferred to a DBF structure which is called within the code. The table is called CAPACITY.DBF and is located in the PARAMETERS folder. Table 6-6 shows the hourly capacities by facility type and area type. Similarly, the capacity for the auxiliary lanes is called AUXLANE.DBF (Table 6-7) and is also located in the PARAMETERS folder.

Table 6-6 Hourly Capacities

Note: ATYPE1-CBD; ATYPE2-Urban Commercial; ATYPE3-Urban Residential; ATYPE4-Suburban Commercial; ATYPE5-Suburban Residential; ATYPE6-Exurban; ATYPE7-Rural

Table 6-7 Auxiliary Lane Capacities

Section 6.3.3 Speeds

Similar to the capacities, link speeds were also previously embedded in the model script. These have also been converted to a DBF structure residing in the PARAMETERS folder. Table 6-8 provides the free-flow speeds by facility type and area type while Table 6-9 depicts the AM congested speeds for the first feedback loop.

Table 6-8 Free-Flow Speeds

Note: ATYPE1-CBD; ATYPE2-Urban Commercial; ATYPE3-Urban Residential; ATYPE4-Suburban Commercial; ATYPE5-Suburban Residential; ATYPE6-Exurban; ATYPE7-Rural

Table 6-9 AM Congested Speeds - First Feedback Loop

Note: ATYPE1-CBD; ATYPE2-Urban Commercial; ATYPE3-Urban Residential; ATYPE4-Suburban Commercial; ATYPE5-Suburban Residential; ATYPE6-Exurban; ATYPE7-Rural

Section 6.3.4 Lane Coding

When coding the number of lanes, there are certain guidelines to follow for auxiliary lanes and when the facility may operate with a different number of lanes by time period. The LANES field should include auxiliary lanes. There are several attributes in the network that allow for varying the number of lanes by time period:

• LANESEA: available lanes during early AM period (3:00 AM to 6:00 AM)
• LANESAM: available lanes during AM Period (6:00 AM to 10:00 AM)
• LANESMD: available lanes during midday Period (10:00 AM to 3:00 PM)
• LANESPM: available lanes during PM Period (3:00 PM to 7:00 PM)
• LANESEV: available lanes during evening/late night Period (7:00 PM to 3:00 AM)

If the lanes do not vary by time period, the LANES attribute should be the only lanes attribute coded (i.e. the period lanes should all be set to zero). However, if the lanes do vary by period, then the appropriate values should be entered by time period. The code is written such that if the period lanes are zero, the program defaults to LANES when computing capacity. If the period lanes are greater than zero, the program uses the period lanes to compute capacity. Some examples are provided below in Table 6-10 through Table 6-12. In example 1, four lanes (two lanes each direction) are available throughout the day which requires only LANES to be coded. The period lanes are left as zero.

Table 6-10 Time of Day Lanes Example 1

Example 2 shows how one type of reversible lane could be handled. An additional lane is coded in the AB direction for the AM period; however, the BA direction for AM lanes is set to zero. For the AM period, this facility would operate as 3 lanes in the AB direction and 2 lanes in the BA direction (because LANES = 2). The reverse is true in the PM period (BA direction = 3 lanes, AB direction = 2 lanes). With no values coded in the EA, MD, and EV periods, the lanes would default to 2 lanes in each direction.

Table 6-11 Time of Day Lanes Example 2

Example 3 shows a case where a one-way facility has lanes that are only available in the EA and AM period. In this example, only the LANES EA and LANESAM should have values. All other lane attributes should be coded as 0 (including LANES).

Table 6-12 Time of Day Lanes Example 3

Section 6.3.5 Toll Facilities

The coding of toll facilities has not changed in the new model version. The user must code the TOLLID attribute on the appropriate links to represent a toll facility. The value on this attribute is at the user’s discretion; however, it is recommended that the user follow a defined set of guidelines when coding. One method is to make the first digit of the toll identifier unique to the corridor it represents and the second digit a directional flag. An example is provided below in Figure 6-2. Discussed later in this document is the process of optimizing tolls for managed lane facilities. To optimize tolls, a comparison between the travel times of the general-purpose lanes and managed lanes is necessary. To accommodate this, a link attribute called GPID can be used to inform the toll optimization algorithm of the level-of-service characteristics of the competing lanes. The GPID should be coded with the same number as the competing managed lane facility (i.e. TOLLID = 11 and GPID = 11 for a competing route). Further information is provided in the highway network coding portion of this document.

Figure 6-2. Toll ID Example

The toll rates are defined by the file TOLLS{year}.DBF residing in the INPUTS folder. The {year} should be representative of the last two digits of the model run year. Within the file, there should be six column attributes labeled as follows:

• TOLLID: identifier used to provide the linkage to the highway network
• TOLLEA: toll rate for early AM
• TOLLAM: toll rate for AM period
• TOLLMD: toll rate for midday period
• TOLLPM: toll rate for PM period
• TOLLNT: toll rate for evening/late night period
• FIXED: flag which informs the model if the toll is fixed or distance based

The TOLLID in the database should correspond to the toll identifier coded in the highway network. Within the model this identifier is used as a lookup value to determine the toll rates to be assessed on the highway links. The toll rate should be entered in cents (e.g. one dollar is 100) and applied to the appropriate time period. If the toll rate is unchanged throughout the day, each period should have the same value.

The FIXED attribute is a simple Boolean logic applying a ‘1’ or ‘0’ which informs the program how to treat the toll (‘1’ is true and ‘0’ is false). If the toll rate is fixed, the value should be set to ‘1’. If the toll rate is a distance based toll, the FIXED attribute should be set to ‘0’ which tells the program to compute the toll based on the rate and link distance. The entered toll values should be reflective of the rates applied per mile for each time period. An example toll file setup is provided below in Table 6-13.

Table 6-13 Toll ID Database

Section 6.3.6 Prohibitions

The ARC model includes the ability to test various lane restrictions (e.g. HOT lanes, truck lanes, etc.). This is handled through coding a link attribute in the network called PROHIBIT. The path building procedures in the model script utilize this link attribute to determine what vehicle types can use the links. Figure 6-3 provides a list of the prohibition codes and how each vehicle type is treated.

Figure 6-3. Prohibition Coding

Section 6.4.1 Transit Route Files

The transit route files are similar to the previous model versions but are now stored in the Cube geodatabase. There are two transit networks stored in the geodatabase:

• NONPREMIUM_TRN{YY}: All non-premium transit routes
• PREMIUM_TRN{YY}: Premium only transit routes

The route files can still be viewed in a text format containing line information and node numbers. The primary differences in the route files are some attribute name changes, required variables, and PT specific available attributes. More information is provided about the route files in the transit coding section of this document.

Section 6.4.2 Transit System Data File

The transit modes, first and second wait curves, and operators are defined in the transit system data file called TRANSIT_SYSTEM.DAT located in the PARAMETERS folder. This file contains mode numbers and names as provided in Figure 6-4. The wait curves are stored in this file with an example shown in Figure 6-5. Also, the operator numbers are stored here as well. The operator numbers are set so that if an operator has varying fares by mode, each mode would have a unique operator. For example, if an operator charged $2.00 for local bus usage but $3.00 for rail, there would be an operator number for both local bus and rail. Figure 6-6 shows an example of how the operators are specified.

Figure 6-4. System Data File Example Modes

Figure 6-5. System Data File Example Wait Curves

Figure 6-6. System Data File Example Operators

Section 6.4.3 Transit Factor Files

The transit factor files are in text format and contain information regarding the access/egress modes, path building parameters, and linkage between the fare systems and operators. The wait curves specified in the transit system data file are also linked here for the initial wait time and transfer wait time. There are six transit factor files located in the PARAMETERS folder:

• TRANSIT_WALK.FAC: walk access factors
• TRANSIT_KNR.FAC: KNR access factors (KNR access mode)
• TRANSIT_KNR_INBOUND.FAC: KNR access factors (KNR egress mode)
• TRANSIT_PNR.FAC: PNR access factors (PNR access mode)
• TRANSIT_PNR_INBOUND.FAC: PNR access factors (PNR egress mode)

An example of the format of the factor files is provided in Figure 6-7.

Figure 6-7. Transit Factor File Walk Access Example

Section 6.4.4 Transit Fare File

The transit fare structures are also specified in a text file located in the PARAMETERS folder and is titled TRANSIT_FARES.FAR. An example format is shown in Figure 6-8. This file specifies the fare amount as well as the how the fare is assessed for each of the fare systems defined in the transit factor files. Linking the fare systems between the two files is handled by the test: FARESYTEM, NUMBER=# where the number is equal to the fare system. The fare systems also include names (e.g. MARTA FARES) to make interpretation easier. The way in which the fares are implemented for a given fare system are handled by STRUCTURE. There is much more flexibility in PT for how the fares are assessed. For example, fares can be applied as a single boarding fare, distance based, or from fare zone to fare zone. IBOARDFARE is the boarding fare for the system and is entered in dollars. To define how the fares are treated between fare systems, the FAREFROMFS is used. The FAREROMFS is specified from each of the fare systems to the system that is being defined. The value entered represents the fare incurred when transferring from another fare system to the current fare system. For example, if all operators allow for free transfers between systems, then the FAREFROMFS would all be set to zero. However, if fare system 1 charges a $1.00 and fare system 2 charges $2.00, there could be an up-charge from fare system to 1 to fare system 2 of $1.00. This would be specified using the FAREFROMFS.

An example of free transfers versus two different up charge scenarios is illustrated below:

Figure 6-8. Transit Fare Charge Example

Figure 6-9. Transit Factor File Walk Access Example

Figure 6-10. Fare Structure Cube Help