Section 9 - Transit Network Coding
This section provides guidance for coding transit routes.
Section 9.1 Non-Transit and Transit Modes
The model includes five non-transit modes which are shown in Table 9-1. The mode 1 walk connectors represent both access and egress. The KNR and PNR connectors are also generated in both directions; however, either the access or egress mode has to be walk (i.e. PNR access - transit - walk egress). The directionality is also period specific as previously discussed. The station / feeder mode is generated using the FACTYPE 53 links coded in the network to ensure connectivity between feeder buses and rail stations. The mode 5 transfer links are other transfer opportunities between transit stops that are not explicitly coded in the network such as bus stops in close proximity to one another. These transfer links are generated up to a tenth of mile between transit stops. All connectors are created utilizing PT’s GENERATE command.
Real transit modes are similar to previous model versions and are provided in Table 9-2. There are five modes available for each operator: 1) Local bus 2) Heavy rail 3) Express bus 4) Light rail and 5) Premium BRT. In addition, there is one commuter rail mode. The model also includes place holders for new projects. This is primarily intended for transit studies to allow detailed extraction of trip information for project trips.
Table 9-1 Non-Transit Modes
| Mode | Description |
|---|---|
| 1 | Walk |
| 2 | Kiss-and-ride |
| 3 | Park-and-ride |
| 4 | Station / feeder link |
| 5 | Transfer link |
Table 9-2 Transit Modes
| Mode | Description |
|---|---|
| 14 | MARTA Local Bus |
| 15 | MARTA Heavy Rail |
| 16 | MARTA Express Bus |
| 17 | MARTA Light Rail |
| 18 | MARTA Bus Rapid Transit |
| 24 | Cobb Transit Service (CobbLinc) Local Bus |
| 25 | Cobb Transit Service (CobbLinc) Heavy Rail |
| 26 | Cobb Transit Service (CobbLinc) Express Bus |
| 27 | Cobb Transit Service (CobbLinc) Light Rail |
| 28 | Cobb Transit Service (CobbLinc) Bus Rapid Transit |
| 34 | Connect Douglas Local Bus |
| 35 | Connect Douglas Heavy Rail |
| 36 | Connect Douglas Express Bus |
| 37 | Connect Douglas Light Rail |
| 38 | Connect Douglas Bus Rapid Transit |
| 44 | Gwinnett County Transit (GCT) Local Bus |
| 45 | Gwinnett County Transit (GCT) Heavy Rail |
| 46 | Gwinnett County Transit (GCT) Express Bus |
| 47 | Gwinnett County Transit (GCT) Light Rail |
| 48 | Gwinnett County Transit (GCT) Bus Rapid Transit |
| 54 | ATL Local Bus |
| 55 | ATL Heavy Rail |
| 56 | ATL Express Bus |
| 57 | ATL Light Rail |
| 58 | ATL Bus Rapid Transit |
| 59 | ATL Commuter Rail |
| 64 | Cherokee Area Transit Service (CATS) Local Bus |
| 65 | Cherokee Area Transit Service (CATS) Heavy Rail |
| 66 | Cherokee Area Transit Service (CATS) Express Bus |
| 67 | Cherokee Area Transit Service (CATS) Light Rail |
| 68 | Cherokee Area Transit Service (CATS) Bus Rapid Transit |
| 74 | Hall County Transit (HAT) Local Bus |
| 75 | Hall County Transit (HAT) Heavy Rail |
| 76 | Hall County Transit (HAT) Express Bus |
| 77 | Hall County Transit (HAT) Light Rail |
| 78 | Hall County Transit (HAT) Bus Rapid Transit |
| 84 | Henry County Transit (HCT) Local Bus |
| 85 | Henry County Transit (HCT) Heavy Rail |
| 86 | Henry County Transit (HCT) Express Bus |
| 87 | Henry County Transit (HCT) Light Rail |
| 88 | Henry County Transit (HCT) Bus Rapid Transit |
| 100 | Shuttle buses |
Section 9.2 Transit Route File Structure
PT also allows for the coding of short names and long names of transit routes via NAME and LONGNAME. For ARC, NAME has been designated for operator and route number while LONGNAME is the actual route name. If a route has two different patterns, the LONGNAME is used to differentiate between the two. The NAME attribute can be up to 28 characters while LONGNAME can be up to 50 characters.
The attributes that are utilized in coding are as follows:
- NAME - operator name with route number ("MARTA 180" and "MARTA 180 GMC")
- MODE - mode number of route
- OPERATOR - route operator (corresponds to operator in system data file)
- LONGNAME - operator name and route number ("MARTA 180 ROOSEVELT HWY")
- ONEWAY - true / false indicator if route operates in only one direction
- HEADWAY[1] - early AM headway in minutes
- HEADWAY[2] - AM peak headway in minutes
- HEADWAY[3] - mid-day period headway in minutes
- HEADWAY[4] - PM peak headway in minutes
- HEADWAY[5] - evening / late night headway in minutes
- CIRCULAR - true / false indicator if route operates in circular fashion. Not necessary for routes that do not operate in this manner.
- DWELL_C - dwell time in minutes to be assessed at each transit stop
Figure 9-1. Route Structure Text Format
As was the case in the previous model, the transit routes are split into two files to distinguish between premium and non-premium routes. Premium routes consist of heavy rail, express bus, light rail, BRT, and commuter rail. Non-premium routes include local buses and express buses. When choosing the appropriate mode, the user should consider how the route operates. The followings are guidelines for mode definitions:
Non-Premium:
- Local bus - routes operating on surface streets with numerous stops. Operate in mixed use traffic.
- Shuttle bus - short distance routes distributing passengers back and forth at activity centers or university campuses.
Premium:
- Express bus - routes operating on high speed facilities (interstates) with few intermediate stops. Routes typically serve park-and-ride lots in the suburbs and distribute passengers around an activity center.
- BRT - routes operating in high speed access controlled facilities (managed lanes) or within exclusive bus-ways. Intermediate rail-type stations provided including passenger amenities such as covered stations, platform boarding, etc.
- Heavy or light rail - routes operating on tracks in exclusive right-of-way. In some cases, light rail may also operate in the street as well.
- Commuter rail - routes operating on main line railroad track carrying passengers to and from work around major activity centers.
Section 9.3 Transit Route Coding
From the Data Manager window shown in Figure 9-2, the user can expand the transit files and double click any of them to open the layers. Note that since the transit networks overlay the highway network, this will also add the highway network into the TOC and GIS window as illustrated by Figure 9-3.
Figure 9-2. Opening Route File
Figure 9-3. Route File TOC
Once a transit layer is open, displaying individual or multiple lines is similar to previous versions of Cube. To select a line or lines, click the Display Lines icon (Figure 9-4) in the toolbar. A new window will open containing all the routes currently available in the network as shown in Figure 9-5. By scrolling through the list, the user can select an individual route or multiple routes by left clicking on the desired routes. Once the routes are selected, click OK and the GIS window will open with the route(s) selected.
Figure 9-4. Selecting Transit Line for Display
Figure 9-5. Displaying Transit Lines
To edit a transit route, editing must be enabled in the same manner as for highway coding (make transit layer active and then click Editor - Start Editing). To edit route attributes, the user must select the Edit Feature pointer (same as in highway edit mode). Using the pointer, click on a route to open the Feature Explorer which will also highlight the route as shown in Figure 9-6.
In the Feature Explorer window, the route attributes are stored in the Line tab (Figure 9-7). This tab includes all route attributes that are available; however, most are not used. To change a route attribute, click in the appropriate field and manually type the change.
Figure 9-6. Selected Transit Line for Editing
Figure 9-7. Route Attributes
The Feature Explorer contains a Route Edit function that is used for modifying the alignment of an existing route and is depicted in Figure 9-8. Using the route editor in the GIS window is similar to the standard Cube editor. When in edit mode, the pointer will appear and allow the user to select a beginning node where the alignment is to change. Then, then the user left clicks on desired stop locations and the program will route the transit line through the network to the stop.
Figure 9-8. Route Edit
For example, if the user would like to change the alignment of the route shown in Figure 9-9 to follow the black links with stops at the nodes highlighted, with the route selected, click Route Edit. The user should click on the node where the alignment is changing which in the case of Figure 9-9 is node 19718 (note that the directionality of how the route is coded is important). To code stops at the highlighted nodes, the user should use the pointer to left click on those nodes. Cube will automatically add the non-stops nodes that occur between the highlighted nodes. When modifying the route alignment, Cube displays both the old and new alignment as shown in Figure 9-10. To tie the alignment together, the user needs to click on the first node where the route is back on the original alignment (node 19675 in Figure 9-9). When the modifications are complete, the user should press the ESC key which ends the route editing. However, the route modifications are not changed until the user clicks the green checkmark to save the edits. Conversely, if the user is unsatisfied with the edits, the user can click the crossed-out checkmark to cancel the edits.
Figure 9-9. Route Alignment
Figure 9-10. Route Modification
To create a new route, click on the Create Feature which looks like a pencil in the editor tool bar. To start a new route, left click on the desired starting point node. To code the route alignment, left click on each preferred stop location until the full alignment is coded. Prior to saving the edits, the user must give the route a name and mode. It is helpful to have the transit system data file available to ensure proper attribute coding. For example, to add a new MARTA bus, the mode would be 14 and the operator set to 1.
Alternatively, if the user prefers using the previous coding environment, the transit files can be exported from the geodatabase to a *.lin file. This is accomplished by right-clicking on a transit line layer in the Data Manager window and then selecting Export as shown in Figure 9-11 which produces the Transit Line Layer Export GUI as shown in Figure 9-12. This allows the user to open the text files and change frequencies, dwell times, etc. which can be more efficient in a text editor than clicking individual routes in the GIS window. Once the changes are complete, the transit file needs to be imported back into the geodatabase as shown in Figure 9-13 which produces the Transit Line Layer Import GUI as shown in Figure 9-14. Prior to importing, the transit layer in the geodatabase being updated needs to be deleted. This is done by right-clicking the layer and selecting Delete from the Data Manager window. To import the revised transit line file, left-click the Import/Export Data button in the Data Manager as shown in Figure 9-14.
Figure 9-11. Exporting from Data Manager
Figure 9-12. Transit Line Layer Export
Figure 9-13. Importing from Data Manager
Figure 9-14. Transit Line Layer Import
Section 9.3.1 Dwell Time Coding
Bus speeds are based on the highway speeds. However, dwell times can be added at each coded stop to more accurately reflect the speeds. The dwell times are coded for each route by use of the variable DWELL or DWELL_C. If viewing the transit network in text format, the variable should be placed after the first node and is coded in minutes. The coded dwell time will be applied to the previous node and all subsequent stop nodes. If operating in the GIS window, to update the dwell time, the user must first be in edit mode. Then, once a route is selected for editing, click the Nodes tab as shown in Figure 9-15. This contains node specific attributes for routes, including the dwell time. Right-click the column labeled DWELL and select Multi Cell Edit. This will open another window as shown in Figure 9-16. In this window, the user can select the appropriate nodes for updating the dwell time or apply a dwell time to the entire route. This is done by selecting the first node in the From Row and the last node in the To Row and then setting the cell value to the desired number.
In validation of the bus speeds, the dwell times for local buses were set to 0.5 while express buses were set to 1.0. This is reasonable given that express buses have fewer stops and generally more people boarding/alighting per stop. The coded MARTA rail routes do not include dwell times in the route file. This is because the coded MARTA rail link speeds include the dwell times. When coding fixed guide-way, it is important the user be aware of how the dwell times are represented.
Figure 9-15. Dwell Time Coding 1
Figure 9-16. Dwell Time Coding 2
Section 9.3.2 Circular Route Coding
PT allows for more accurate coding of route alignments by use of circular coding logic. The CIRCULAR variable is a route specific attribute that informs the program whether or not to invoke circular logic in path building. If CIRCULAR is coded as ‘1’, the program treats the route in a circular manner. The default is linear so for non-circular routes, the user can exclude the CIRCULAR variable from the route. The circular logic allows for a route to have the same beginning and ending node without forcing a transfer at that node. In Figure 9-17, the route starts at the airport and then runs clockwise. In reality passengers would stay on the bus which is reflected in PT using the CIRCULAR variable.
Figure 9-17. Circular Coding Example 1
The circular logic is also helpful when routes operate on one-way facilities and/or have deviating alignments by direction. For example, there are numerous buses operating in the downtown area where this is the case. One example is provided in Figure 9-18. The route operates on one-way streets in downtown and has a different alignment on the eastern portion of the route. Previously, this route would have been coded as two separate routes to reflect this pattern. With the circular logic, the entire alignment can be coded as one route. Where the route doubles back on itself the coding can be a bit difficult because Cube doesn’t allow the backtracking without the user clicking on each individual node and holding down either the Shift key or the Alt key. The Shift key will make the node a stop node while the Alt key will result in a non-stop node.
Alternatively, the user could initially code the alignment as two separate one-way routes and then open the route text file in order to merge the routes together. The user would copy/paste the reverse direction nodes at the end of the other route and then delete the reverse route. A simple example of how the copy/paste would work is shown in Figure 9-19. In this example, once the user pasted the backtracking nodes to ‘TestRoute’, the route called ‘TestRoute2’ would be deleted from the text file.
Figure 9-18. Circular Coding Example 2
Figure 9-19. Circular Coding Example 3
Section 9.4 Transit Related Highway Network Coding
A number of modifications have been made in the representation of transit in the highway network in relation to station coding, park-and-ride coding, and fixed guide-way transit.
Section 9.4.1 Station Coding
The link-based coding of stations includes facility types for coding a station with descriptions including:
- FACTYPE 50: Feeder bus access to station
- FACTYPE 52: PNR access to parking lot
- FACTYPE 53: Transfer between feeder buses and station
- FACTYPE 55: Connection between PNR lot and transit station/feeder bus nodes
- FACTYPE 98: Pedestrian access to station
- FACTYPE 99: Fixed guide-way links for transit (MARTA rail or BRT)
The station coding can become pretty complex as shown in the example in Figure 9-20. This example is of the MARTA Oakland City Station. The station includes a feeder bus node, PNR lot, and special pedestrian access. The FACTYPE 55 links were added due to the conversion from TRNBUILD to PT. For generating PNR access links, PT requires a direct connection to the transit stop. For example, if the FACTYPE 55 link were not coded between the PNR node and feeder bus node, drive access paths would not be available to the feeder buses.
The FACTYPE 98 links were added to represent direct pedestrian access that is not currently reflected in the model network by the road system. There are numerous examples of this throughout the region including at the Oakland City station. An aerial photograph of this station is provided in Figure 9-21. As shown in the aerial, the station is bordered on the east side by railroad tracks. There is a portal located east of the railroad tracks which allows transit patrons access to the station under the railroad tracks. The FACTYPE 98 link is coded to represent this access. Otherwise, the transit paths from the east would require a longer walk using the coded road system.
Figure 9-20. Station Coding Example
Figure 9-21. Station Aerial
Section 9.4.2 Transit Coding Highway Node Attributes
Several node attributes have been added to the highway network to facilitate transit coding for rail stations and PNR lots. For station coding, the new attributes are STATION and STAFLAG. The STATION attribute is a text field allowing the user to include the station name. The STAFLAG attribute is a numeric field which should be coded as a ‘1’ to indicate a station. This allows the user to manually view station locations. It is used in Cube Voyager scripts to post-process model results in order to summarize station boardings. The model also uses STAFLAG as an indicator to allow for longer KNR access connectors to nodes designated as stations as the transit on-board survey data revealed the tendency of longer trips to the MARTA rail stations than ordinary transit stops. Figure 9-22 is an example of how the Oakland City station is coded in the node attributes.
Previously, PNR lot coding was handled using text files where the user was required to code the PNR lot nodes in two separate files to represent major and minor lots. This has been streamlined by adding two PNR flags to the node attributes. To designate a node as a PNR lot, the user sets the PNR attribute to ‘1’. To designate the lot as a major lot, the user sets the PNR_MAJOR attribute to ‘1’. The model then reads these attributes to in determining the allowable drive access time to the lot. Currently, the major lots allow for a 40-minute drive time while the minor lots allow for a 10-minute drive time. A major lot should generally include extensive parking spaces (approximately 1,000 spaces or more). However, there are some cases where smaller lots could be designated as major lots when the expected market would exceed the 10-minute threshold. These would include end-of-line locations. In the case of the base year, the suburban PNR lots serving express buses are a good example of where the 10-minute threshold is not sufficient. The new PNR attributes make coding more efficient by allowing the user to manually review lot locations and the major lot designation without having to open multiple files as was previously the case.
Figure 9-22. Node Attributes
Section 9.4.3 Fixed Guideway Coding
The facility type (FACTYPE=99) is included providing the user the ability to code fixed guide-way links directly in the highway network. Additionally, the user is required to code several link attributes to represent the fixed guide-way speeds, distances, and travel times. The attributes are:
- TRNDIST = station to station distance (miles)
- TRNSPD = station to station average speed (mph)
- TRNTIME = station to station travel time (minutes)
For the speed and time, it is recommended the average speeds and travel times include the dwell times associated with passenger boarding and alighting. In the base year, the fixed guide-way links only include MARTA rail. However, the new facility type could be utilized for any new fixed guide-way projects. With the attributes part of the input highway network, it allows the user to manually review the fixed guide-way coding without opening multiple files.