The transit network is made up of three core components: transit lines, transit modes, and transit fares. The transit lines were built GTFS feeds from around 2015. The lines are coded with a mode and serve a series of stop nodes. Transit fares are coded according to Cube's TrnBUILD program specification. Several input files and scripts are necessary to create the full transit network:

• 1. Transit Line File
• 2. Auxiliary Modes
• 3. Transit Fares

trn/transit.lin (year specific)

The transit lines are specified in a files ending with the extension .lin, organized by transit operator and line-haul mode. A name is assigned to each route based on the operator mode and a description of the route, usually the line number and the direction of the route if necessary. Attributes of the transit lines include runtime, stop node sequence, line-haul mode, and headways by time period (HEADWAY[1-5] which refer to Early AM, AM Peak, Midday, PM Peak, and Evening respectively). The sequence of nodes specify the path of the route, where the node numbers correspond to the nodes in the highway network. Consult the Cube manual for details on the specification of the transit line files. Fields or attributes present for each route in the line file are given below:

Cube Key	GTFS Key	Details
NAME	agency_id + route_id +time_period +direction_id + shape_id Concatenate, separated by an underscore (“_”)
agency_id	translated to transit operator integer (see next table for dictionary)
LONGNAME	route_long_name
USERA1	agency_id, GTFS file name (when agency_id is missing)	Transit operator string
USERA2	Line haul mode	See dictionary, crosswalk below
HEADWAY	headway_secs / 60	Integer
MODE	route_type	See dictionary, crosswalk below
FARESYSTEM	N/A	See dictionary, value is a function of MODE
ONEWAY	N/A	Should always be set to “T” (for TRUE)
OPERATOR	agency_id, GTFS file name	Transit operator integer (see next table for dictionary)
SHORTNAME	route_short_name
VEHICLETYPE	See dictionary, value is a function of MODE. Vehicle types and their corresponding seating capacity are defined in the vehtypes.pts file
N	shape_id	Travel model node IDs, with a leading “-” (to make the number negative) to indicate a shape point where the bus does not stop
ACCESS	pickup_type, dropoff_type
RUNTIME	Total travel time from start node to end node, calculated by adding all the NNTIMEs for the rail modes
NNTIME	stop_times Calculated from GTFS stop to stop travel time, in minutes

The transit.lin file is converted to a format usable by TRNBUILD by the update_transit_line_file.py script (CTRAMP/scripts/preprocess/update_transit_line_file.py). This script creates a new unique name (within 10 character limit) for each line, replaces HEADWAY with FREQ, and NNTIME with TIME.

Line-haul Mode	Description
10 - 79	Local bus
80 - 99	Express bus
100 - 109	Ferry service
110 -119	Light rail
120 -129	Heavy rail
130 -139	Commuter rail

The following transit modes are defined based on the Open511 attributes (but not completely, since they came from the GTFS database predecessor, the Regional Transit Database). These modes represent combinations of operators and technology.

TM2_operator	agency_name	TM2_mode	TM2_line_haul_name	faresystem
30	AC Transit	84	Express bus	9
30	AC Transit	30	Local bus	9
30	AC Transit	30	Local bus	11
5	ACE Altamont Corridor Express	133	Commuter rail	1
26	Bay Area Rapid Transit	120	Heavy rail	2
3	Blue & Gold Fleet	103	Ferry service	13
3	Blue & Gold Fleet	103	Ferry service	14
3	Blue & Gold Fleet	103	Ferry service	12
17	Caltrain	130	Commuter rail	3
23	Capitol Corridor	131	Commuter rail	4
19	Cloverdale Transit	63	Local bus	7
17	Commute.org Shuttle	14	Local bus	46
15	County Connection	86	Express bus	16
15	County Connection	42	Local bus	15
15	County Connection	42	Local bus	17
10	Emery Go-Round	12	Local bus	18
28	Fairfield and Suisun Transit	92	Express bus	10
28	Fairfield and Suisun Transit	52	Local bus	10
35	Golden Gate Transit	87	Express bus	8
20	Golden Gate Transit	101	Ferry service	19
20	Golden Gate Transit	101	Ferry service	20
35	Golden Gate Transit	70	Local bus	8
99	MVgo Mountain View	16	Local bus	21
39	Marin Transit	71	Local bus	23
39	Marin Transit	71	Local bus	24
21	Petaluma Transit	68	Local bus	47
13	Rio Vista Delta Breeze	52	Local bus	5
6	SamTrans	80	Express bus	6
6	SamTrans	24	Local bus	6
25	San Francisco Bay Ferry	101	Ferry service	28
25	San Francisco Bay Ferry	101	Ferry service	30
25	San Francisco Bay Ferry	101	Ferry service	31
25	San Francisco Bay Ferry	101	Ferry service	32
25	San Francisco Bay Ferry	101	Ferry service	29
22	San Francisco Municipal Transportation Agency	110	Light rail	25
22	San Francisco Municipal Transportation Agency	20	Local bus	25
22	San Francisco Municipal Transportation Agency	21	Local bus	26
1	Santa Rosa CityBus	66	Local bus	33
12	SolTrans	91	Express bus	35
12	SolTrans	49	Local bus	34
12	SolTrans	49	Local bus	35
19	Sonoma County Transit	63	Local bus	7
7	Stanford Marguerite Shuttle	13	Local bus	22
4	Tri Delta Transit	95	Express bus	36
4	Tri Delta Transit	44	Local bus	37
4	Tri Delta Transit	44	Local bus	36
36	Union City Transit	38	Local bus	38
31	VTA	81	Express bus	40
31	VTA	81	Express bus	41
31	VTA	111	Light rail	41
31	VTA	28	Local bus	41
31	VTA	28	Local bus	39
14	Vacaville City Coach	56	Local bus	48
38	Vine (Napa County)	94	Express bus	43
38	Vine (Napa County)	60	Local bus	42
38	Vine (Napa County)	60	Local bus	44
37	WestCat (Western Contra Costa)	90	Express bus	49
37	WestCat (Western Contra Costa)	90	Express bus	50
37	WestCat (Western Contra Costa)	46	Local bus	49
24	Wheels Bus	17	Local bus	45

Auxiliary Mode	Description
1	walk access connector Walk from centroid to auxiliary rail node/bus stop
2	drive access connector Drive from centroid to drive auxiliary node
3	stop-to-stop or stop-to-station transfer link Walk transfer link between transit stops
4	drive access funnel link Transfer between drive auxiliary node and station platform node
5	walk access funnel link Transfer between walk auxiliary node and station platform node
6	walk egress connector Walk from auxiliary rail node/bus stop to centroid
7	drive egress connector Drive from auxiliary node to centroid
8	Not used
9	Not used

The park and ride connectors are created by the CreatePnRList.job script (CTRAMP/scripts/preprocess/). It takes the transit background network (created by the PrepHwyNet.job script), identifies all the nodes with PnR access (Highway Network), and the unique transit stop nodes (nodes which don't have a - sign in the transit.lin file). The create_pnr_connectors.py script then identifies all the transit stops within a 0.125 mile buffer distance from each PNR node and create a text file (trn/pnr_connectors.txt) that is used in the BuildTransitNetwork.job script (CTRAMP/scripts/skims/) to create access and egress links.

Figure 1 illustrates the transit access link mode coding for an example rail stop and some adjacent bus stops. The rail line is "off-network", meaning that it does not exist in the highway network (.net) file, but is instead defined in the transit-only links specified in the transit line files. The bus routes operate on the highway network, and are represented in the transit line files as a sequence of node IDs.

The drive access funnel link (mode=4) forces all park and ride (PNR) trips to a specific stop or station to go through that funnel link. A single drive access funnel link may be connected to multiple zonal drive connectors (mode=2) links going to diferent TAZs. This coding ensures that the number of PNR trips to a specific stop or station can easily be summarized. The walk funnel links (mode=5) serve a similar purpose for off-network rail stations. That is, by forcing all zonal walk access connectors (mode=1) through a single funnel link, the total number of direct walk access and egress trips to a particular station can be easily tabulated from the results. Any remaining trips to a station, beyond those on the drive and walk access funnel links must be transfers, and therefore must traverse a transfer link (mode=3). Unlike the funnel links, of which there can be only one to a specific station, there can be many transfer links to/from a particular station connecting to any other stations or stops within the transfer link generation threshold. The on-network bus stops may use drive access funnel links, but do not use walk-access funnel links. Instead, zonal walk connectors (mode=1) are generated directly to the on-network bus stops.

The zonal walk connectors (mode=1), zonal drive connectors (mode=2), and transfer links (mode=3) are generated automatically in the script buildTransitNetwork.job. The drive funnel link (mode=4) is generated based on the parameters specified on the trn/pnr_connectors.txt file. The walk funnel link (mode=5) are created for each zone centroid to the transit stops.

In the final setp of BuildTransitNetwork.job script, the two best (closest) park and ride location for each access mode are selected and the support links that are used in transit skimming and assignment are created using the create_optimal_suplinks.py script.

The transit fares are specified in separate files denoted with the “.FAR” extension. The fares are specified in year 2000 cents. There are four types of fare formats used in the MTC model:

• Direct Fare (Initial Boarding Fare)
• Transfer Fare
• Station–to-Station Fare
• Link Based Fares

The files necessary for Transit Fares are:

1. transit_faremat.block (trn/): transit fare matrices to read
2. BART.far: stop to stop fare for BART lines.
3. ACE.far: stop to stop fare for ACE lines.
4. amtrak.far: stop to stop fare for AMTRAK lines.
5. ferry.far: stop to stop fare for ferry lines.
6. FARELINKS.far: special fares for transit links
7. xfare.far: transfer fares

Direct fares are the initial boarding fares for riding a transit line. Direct fares are specified in the xfare.far file. This file lists both the initial and transfer fares in a matrix form of 137 X 137 transit modes (a combination of modes and operators). From this matrix, the initial fare and transfer fares are read into MODEFARE and XFARE variables of TP+ program respectively. The MODEFARE is an array of fares coded to auxiliary-transit links (walk access connector, drive access connector, walk funnel links) for all the transit modes and is used as an initial boarding fare. The XFARE is an array of transfer fares between all modes including auxiliary-transit to transit mode fares (same as MODEFARE). During path building, for the first boarding, the auxiliary-transit to transit MODEFARE value is read as the initial boarding fare instead of the XFARE auxiliary- transit to transit mode. For the subsequent boardings (transfers to another transit mode), the XFARE value for that mode pair is used as the transfer fare.

The transfer fares are explained in the Transfer Fares section below. The initial boarding fares between transit modes to auxiliary-transit modes and auxiliary-transit modes to auxiliary-transit modes are specified as zeros. For some premium transit modes (modes 100-109 and 120-137) the initial fares are also specified as zeros and are substituted with a station-to-station fares, which are described under the Station-to-Station Fares section below.

The transfer fares are fares that are charged when a transfer from one transit line to another occurs. These fares are also specified in the same xfare.far file. The transfer fares between the same premium transit mode (modes 100-109 and 120-137) are specified as zero since the station-to-station fares actually count these transfer fares. Additional transfer fare files are specified to represent a county-to-county transit system transfer, which are described in detail in the Link Based Fares section.

The premium transit lines (modes 100-109 and 120 -137) charge fares between stations. These fares are specified in the .FAR files. For example, the BART.FAR file consists of fares between all BART stations. Figure 13 shows a sample station-to-station fare file.

Some fare structures are provided between zones. Many times is hard to capture the exact fare using the methods explained above. In those cases we use the command FARELINK. This command adds a specific amount indicated in the FARELINK command to the basic fare as a link is traversed in a path. These links are included in the Farelinks.far file.