Transit Everywhere Scenario
Travel Model Improvement Program – Exploratory Modeling and Analysis Tool (TMIP-EMAT) is a tool designed to integrate with any existing transportation models to perform exploratory analysis of a range of possible scenarios. Under the TMIP-EMAT implementation, the transportation model is run for range of inputs and performance metrics of interest are generated. The SO-ABM framework is very flexible in terms of modeling future scenarios. The Oregon DOT has identified one such future scenario as a Transit Everywhere scenario, in which a door-to-door transit service is available throughout the modeling network. A Transit Everywhere switch has been developed for the SO-ABM to run the existing model using the necessary assumptions required to implement the Transit Everywhere scenario. The key assumptions and the model steps under the Transit Everywhere scenario are described in the next section.
The key assumption under the transit everywhere scenario is the availability of an on-demand transit service between any origin and destination MAZ. The traditional transit service is made unavailable under this scenario. The door-to-door transit service can be thought of as a future mobility service but can be modeled of as a public (possibly subsidized) transit service, like a regional implementation of dial-a-ride accessible to the full population. The Introduction to Transit for the ABM section describes the representation of transit accessibility and level-of-service (LOS) in the SO-ABM. The same framework with appropriate assumptions can be used to model a door-to-door transit everywhere service. The SO-ABM uses TAPs as zone centroid for transit skims. Transit can be accessed from each MAZ centroid via these TAPs. Only MAZs that are reasonably close to the transit line have access to transit via drive or walk. The SO-ABM transit skimming process produces TAP-TAP transit LOS skims. These skims are then used by the transit path building process to find an optimal transit path between each MAZ pair. Given the SO-ABM framework to model the traditional transit service, modeling a Transit Everywhere scenario requires the following assumptions:
- A TAP for each MAZ: to model transit availability across the entire network
- No drive access: a door-to-door transit service would not require driving to access the service
- No transfer: a door-to-door service does not include any stops or transfers
Coding TAPs and transit network to represent a door-to-door service can be a tedious and time-consuming exercise. An easier solution is to skip the SO-ABM skimming procedure altogether and instead create dummy skims based on the assumptions for the Transit Everywhere scenario. Similarly, the transit assignment procedure must also be skipped. The SO-ABM calls a Transit Everywhere skims creation procedure function to generate dummy transit skims and other required files under the Transit Everywhere scenario.
The demand that shifts to Transit Everywhere service can burden the highway system depending on how the service is being provided. The portion of Transit Everywhere demand that gets served by a fixed guideway service will not use the highway system. While the demand served by Autonomous Vehicles (AV) can lead to more auto trips due to deadheading vehicles. The model setup gives users the option to convert the Transit Everywhere demand to an equivalent auto demand which gets assigned to the highway network with the regular auto demand. The user can specify an auto factor and auto occupancy distribution to convert the Transit Everywhere demand to an equivalent auto demand. These settings are available in the OR-RAMP properties file. Find more details in the configuration section.
The SO-ABM model flow under the Transit Everywhere scenario is as follows:
-
Set properties and empty outputs folder
-
Run the input checker tool
-
Build networks for skimming in VISUM + Python for TAZs, then MAZs
- All steps related to transit network creation are skipped under the Transit Everywhere scenario
-
Create skims using "warm start" speeds in VISUM + Python for TAZs, then MAZs
- The traditional transit skimming steps are skipped and the Transit Everywhere skims creation procedure is called under the Transit Everywhere scenario
-
Run the commercial vehicle model and external model in R
-
Start a feedback loop up to max iterations
- Run OR-RAMP ABM in Java
- Build TAZ trip demand matrices for assignment
- The TAP demand matrix creation is skipped under the Transit Everywhere scenario
- Create skims and assignments using congested speeds in VISUM + Python for TAZs
- Again, the transit assignment is skipped under the Transit Everywhere scenario
- Check for completion and repeat feedback loop if needed
The Transit Everywhere skims creation procedure generates the transit LOS skims and other transit related inputs for the SO-ABM demand module (CT-RAMP). The following input files are created by the skims creation procedure - tap_data.csv, tap2maz_Walk.csv, drive_taz_tap.csv and TAP-TAP OMX skims. These files are generated using the user specified parameters and assumptions for the Transit Everywhere scenario as described below:
-
tap_data.csv: The TAP inputs data file is created using a dummy TAP list assuming one TAP for each MAZ.
-
tap2maz_Walk.csv: This file is generated based on the user specified global MAZ to TAP access walk time.
-
drive_taz_tap.csv: An empty drive access file is created which is interpreted as unavailability of drive access between TAP and TAZ.
-
TAP-TAP OMX skims: Dummy OMX skims are created for 5 time-periods (EA, AM, MD, PM and EV) and three sets (local, premium and local + premium). The door-to-door transit service under the Transit Everywhere scenario is modeled as a Walk-Transit service. Therefore, all the premium and local+premium transit LOS skims are set to zero. Only the following skims are populated for all the periods of the local bus skim set:
- IVTT(Bus) - The TAP-TAP local bus in-vehicle time is computed as follows: IVTT(Bus) = (auto time) * in-vehicle time multiplier. Where, auto time is for the TAZ-pair that the corresponding MAZ-pair is in.
- IVT - The total in-vehicle time is set to the Bus IVT
- OWT - The origin wait time, or the first wait time is set to the first wait time values specified for each MAZ in the input MAZ data.
- FAR - The TAP-TAP fare is computed as follows: Fare = (auto distance) * auto distance fare multiplier, or the flat fare depending on user specification. Where, auto distance is for the TAZ-pair that the corresponding MAZ-pair is in.
All the parameters used for creating the above described dummy inputs are exposed to the user in the properties file. Only the first wait time is read from the input MAZ data. The next section describes how to configure a Transit Everywhere run.
The SO-ABM under the Transit Everywhere scenario is run the same way as the base run as described here. Configuring the Transit Everywhere run involves setting the following properties in the OR-RAMP properties file:
| Property | Data Type | Example | Purpose |
|---|---|---|---|
| Transit.Everywhere.Switch | String | true or false | Switch to enable or disable the Transit Everywhere scenario |
| Access.Walk.Time | Double | 5.0 | Global access walk time (in minutes) from each MAZ to dummy TAP |
| IVT.Multiplier | Double | 1.25 | Multiplier to convert TAZ-TAZ auto time to TAP-TAP local bus IVT |
| Distance.Based.Fare.Multiplier | Double | 1.1 | Multiplier to convert TAZ-TAZ auto distance to TAP-TAP fare in cents |
| Flat.Fare.Switch | Double | 0.0 | Flat fare switch (0 when fare is distance based else the flat fare) |
| Transit.Everywhere.Bonus.Parameter | Double | 10.0 | Total minutes of benefit for transit in the Transit Everywhere scenario |
| Transit.Everywhere.Auto.Factor | Double | 1.2 | Factor to convert the Transit Everywhere demand to an equivalent auto demand. The equivalent auto demand is converted to vehicle trips using the user specified auto occupancy distribution specified below |
| Transit.Everywhere.SOV | Double | 0.2 | Share of SOV Transit Everywhere autos |
| Transit.Everywhere.HOV2 | Double | 0.5 | Share of HOV2 Transit Everywhere autos |
| Transit.Everywhere.HOV3 | Double | 0.3 | Share of HOV3 Transit Everywhere autos. The SOV, HOV2, and HOV3 share must sum to 1.0 |
| MAZ.Variables.To.Factor | Comma separated Strings | HPARKCOST, DPARKCOST, MPARKCOST | MAZ-level variables to be factored |
| MAZ.Factors | Floats stored as comma separated strings | 1.0,1.0,1.0 | Factor value for each MAZ variable specified above |
The first five properties in the above table are directly related to design and assumptions of the Transit Everywhere scenario. The Transit.Everywhere.Bonus.Parameter is applied to tour and trip mode choice UECs as an Alternative Specific Constant across all transit modes and purposes. This feature can be used to model scenario involving attractiveness to transit modes. Similarly, the MAZ.Factors can be used to modify MAZ-level variable to model different scenarios.
Note the Bonus Parameter is used whether "Transit Everywhere" is on or off (true or false). By default, the bonus parameter must be set to 0 (no bonus effect on transit modes). The bonus parameter can be set to both positive or negative values depending on the scenario being modeled. Positive values of bonus parameter results in higher utility for transit modes which mimic people seeing transit trips as less onerous. On the other hand, negative values add more penalties (negative attitudes / experiences) to riding transit. The value of the bonus parameter is expressed in units of travel time on transit modes, i.e. minutes. For example, a bonus parameter value of 10 reduces the travel time on all transit modes by 10 minutes, while a parameter value of -10 adds 10 minutes to the travel time on all transit modes. The user must carefully estimate the equivalent transit travel time benefit or dis-benefit of the scenario being modeled and set the bonus parameter accordingly. This parameter can be used to test transit for any scenario whether "Transit Everywhere" is being applied or not.
The SO-ABM produces the same set of outputs under the Transit Everywhere scenario as in the base run. Please refer the Model Outputs section for detailed description of SO-ABM outputs. Since transit assignment is skipped under the Transit Everywhere scenario, none of the transit assignment related files are generated. The transit assignment based summaries such as the boardings summary are omitted from the HTML dashboard since ridership by line is not captured with transit everywhere (since there are no specific lines).
A door-to-door transit service can have a variety of impacts on the regional transportation system. A very likely impact of an on-demand transit service would be the shift in systemwide mode share from conventional auto modes to the on-demand transit mode. The assumptions for the transit everywhere scenario (such as transit everywhere auto factor and occupancy distribution) would determine the systemwide impact on transportation infrastructure. The impact on transportation infrastructure can be assessed by the estimated change in systemwide VMT and traffic volumes. Traffic volume and VMT analysis can be performed by facility types and area types (urban, rural, low-income neighborhood, etc.). Besides systemwide impacts, an interesting trend to review would be the change in overall travel behavior. The ABM Visualizer offers an ideal tool to analyze the changes in travel behavior. The Visualizer tool can be configured to compare the transit everywhere scenario run with a base run. The visualizer summaries can help to understand the change in travel behavior. Non-driving age children cannot drive and retirees tend to drive less. Another interesting trend to review would be the travel behavior change for these groups. The transit everywhere scenario would provide higher accessibility to these groups and can lead to some induced travel demand. The daily activity pattern (DAP) by person type summary comparison can provide insights into travel behavior changes across all person types. Similarly, tour frequency distributions and tour length distributions can also offer insights about travel behavior change. Follow these steps to review DAP and other summaries using the HTML Visualizer:
- Open the HTML Visualizer (
visualizer\outputs\SOABM_Dashboard.html) using an internet browser (preferably Google Chrome). - To review DAP and tour frequency summaries, click on Tour Level on the menu at the top of the screen, and then select Tour Summaries. Select the Person Type from the drop down menu next to each chart to review summaries for specific person type groups.
- To review non-mandatory tour length frequency distributions, select Destination from the Tour Level drop down menu. Again, select the appropriate Person Type from the drop down menu next to the chart.
Household-level trip rates can be computed to understand travel behavior change across various demographic segments (zero-auto, low income, etc.). Household and person trip rates by different demographic segments can be computed from the ABM outputs. Below are example R code snippets to read ABM outputs and compute trip rates from the ABM outputs:
Read ABM Outputs
Household Trip Rates
Person Trip Rates
An equity analysis can also be useful for transit everywhere impact analysis. Zone level accessibility maps comparing before and after accessibilities can be used to perform basic equity analysis. The ABM outputs include the zonal accessibilities which are stored in the outputs\other\accessibilities.csv file. The second column in the accessibilities.csv file corresponds to the zone-level transit accessibilities to all non-mandatory activities. This can be used to compare the accessibility between the base and transit everywhere scenario.
The transit everywhere service will have operating expenses. Systemwide operating expenses can be estimated by assuming a per mile average operating cost for the transit everywhere service. Below is an example R code snippet to compute an average systemwide operating cost:
