Improving ADA Paratransit Demand Estimation: Regional Modeling (2012)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

63 Using the ADA Paratransit Travel Models The body of the report describes the survey data and the estimated choice models of the travel patterns of ADA paratransit users and demonstrates the models’ use to predict demand for ADA paratransit in the Dallas/Fort Worth region under different demographic scenarios and ADA paratransit service scenarios. This appendix provides details about the current implemen- tation of the demand models for the Dallas/Ft. Worth region, followed by a discussion of how a similar implementation could be done in other regions. The current model implementation is programmed in Delphi Pascal, a high-level program- ming language similar to C++, Java, or Python. The program is a console application that can run under Windows on any PC (or Mac with a Windows emulator). Depending on the user settings, the program will run for the entire region in less than 10 minutes on a typical PC. The structure of the program code is given below. This information applies to implement- ing to the Regional Planning Model, referred to here as “Regional Mode.” The documentation describes switches that are set in user-created input files that control whether the model runs in Regional Mode or Sketch Mode. To use the model in Sketch Mode, it is probably easier to do this using the Excel spreadsheet interface available from TCRP and described at the end of this appendix. Program Structure: ADA Paratransit Demand Model Simulation A. ReadUseControllnputs: Reads in the user program control parameters, described below. B. ReadZoneData: Reads in the user-specified input file with zone-level attraction data. C. ReadHighwayMatrices: Reads in user-specified input files with zone-to-zone highway travel times and distances. D. ReadTransitMatrices: Reads in user-specified input files with zone-to-zone scheduled tran- sit travel times, frequencies, and fares. (Optional: The program can be run without these, if specified.) E. CalculateAccessibilityMeasures: Calculates accessibility measures for automobile, walk, and (optionally) scheduled transit from each possible residence zone. Steps F through I are run only if the user indicates that the models are to be run for the entire regional population (“Regional Mode”). Steps F through I are not run in “Sketch Mode.” F. ReadCensusTractData: Reads in a user-specified file with census tract-level socioeconomic distribution data. G. CalculateSurveySampleDistribution: Reads in all survey sample records to calculate a multi-dimensional distribution across expansion variables. A p p e n d i x A

64 improving AdA paratransit demand estimation: Regional Modeling H. ApplyADARegistrationModel: Applies the census tract-level model to predict how many residents in each tract are registered as eligible to use ADA paratransit. I. ReexpandSurveySampleToTractsAndZones: Within each census tract, re-expands the sur- vey sample to approximate the specific ADA-registered population within the tract, includ- ing allocation to specific residence zones within the tract. J. SimulateTravelDay: This is the main routine in the program. For each member of the survey sample, the following steps are executed: If “Regional Mode,” repeat the steps below for each zone in the region for which the sample member has a positive expansion factor. Otherwise, in “Sketch Mode,” just repeat the steps a given number of times specified by the user. (Each sample member can be simulated multiple times to reduce random stochastic simulation error.) • ApplyTourGenerationModel For each generated tour . . . – ApplyTourModeChoiceModel – ApplyIntermediateStopGenerationModel – ApplyTripModeChoiceModel – ApplyTripDestinationChoiceModel • WriteTravelPredictions: This last routine writes the simulation results to user-specified output files that can later be queried and analyzed by the user. Three different files are written: person-day level, tour-level, and trip-level. The key program inputs are supplied by the user in a control file, as in the example shown in Appendix B, where each line has a six-letter prefix that indicates what the value is used for, followed by the user-supplied value. The comments at the end of each line that follow the // symbol are for documentation purposes. The first line is simply a run title that the user can supply. The next switch SKETCH con- trols whether the program is run in “sketch mode or regional mode.” RDSEED is the initial seed for the random number generator. If RDSEED is changed, even without changing other inputs, the forecast results will change somewhat because each choice is predicted stochasti- cally as a discrete choice, which requires the use of random draws from the choice model probabilities. There are two ways to control the amount of random simulation variability, depending on whether the program is run in sketch mode or regional model. If the program is run in sketch mode, each survey sample person can be simulated for multiple different travel days, with the number input on the SKREPT line. Because discrete choices are simulated stochastically, rather than as choice shares, the results contain some random simulation error if each of the 800 sur- vey sample members is simulated only once. Each person can be simulated for many days to “smooth out” the random error. When the choices are written to the results file, the expansion factor is divided by SKREPT, so the total number of expanded simulated choices always remains constant. Similarly, when the program is run in regional mode, there is a value MINEXP used to control how many times each sample member will be simulated and thus influence runtime and random simulation error. In the example, with MINEXP at 50, when a sample member has an expansion factor for a given zone of 1/50 (=0.02) or greater, it will always be simulated for that zone. If the calculated expansion factor (CALCEXP) is less than 1/MINEXP, then a uniform random num- ber is drawn between 0 and 1, and if the random number is less than CALCEXP / (1/MINEXP), it will be simulated with expansion factor 1/MINEXP; otherwise, the expansion factor is set to 0, and it will not be simulated for that zone. (This is a variant of “bucket rounding” often used in travel demand forecasting.)

Using the AdA paratransit Travel Models 65 The next sets of inputs give the directories and file names for all input and output files to be used by the program. One special switch is USETRN. If no skim matrix files for scheduled tran- sit are available, then this can be set to 0, and the program will not try to read in any files with scheduled transit travel times—instead transit travel time will be approximated as a multiple of automobile travel time. The last group of input variables is a series of overall demographic or ADA paratransit service scenario variables. These switches were used to run the sensitivity tests reported in the preceding sections. Transferring the Models to Other Regions The sketch mode of running the models uses the survey sample “as is,” and is thus specific to the Dallas/Ft. Worth region. The regional mode of running the models, however, can be transferred to other regions. To do so, the user needs to provide region-specific versions of the following: 1. The input census tract data file: Can be compiled from the US Census website, either from the 2000 Census or from the 2005–2009 American Community Survey (ACS), or, starting in Autumn 2011, from the 2010 Census. 2. The input zonal data file: Typically available from the local MPO or another local planning agency. 3. The input automobile zone-to-zone travel time matrices: Also typically available from the local MPO or another local planning agency. If congested automobile travel times are not avail- able, a next-best approximation would be to use free-flow travel times to represent all time periods. 4. The input scheduled walk-to-transit zone-to-zone travel time matrices (optional): These are sometimes available from the local MPO. If not, it is possible to run the model system without such data. Most regions are smaller geographically than Dallas/Ft. Worth, which has over 900 cen- sus tracts and 5,000 traffic analysis zones. As a result, the model application will generally run in even less time for other regions, compared to about 10 minutes per run for Dallas/ Ft. Worth. The model application program (.EXE file) can be run “as is,” without changing or recompil- ing the source code. If, however, the user has validation data on actual ADA paratransit ridership and wishes to re-calibrate any model coefficients to match the existing ridership, then it may be necessary to modify parameters in the source code. Transferring the Model Application to Other Software Systems Relative to most tour-based model microsimulation software, the Pascal code written for this project is simple and straightforward and uses only very standard types of coding (no object- oriented code, assembly language, etc.). Thus, it would be possible to re-program the model application into any network-based software platform that allows record-based data processing and has a flexible scripting language. This certainly includes the main network packages in the US—CUBE, TransCAD, and Visum—and probably includes EMME as well. However, such software platforms require a license which can be costly, and they may not be available to all potential model users.

66 improving AdA paratransit demand estimation: Regional Modeling Figure A-1 illustrates how the regional mode of the ADA paratransit demand model could fit into a regional forecasting model framework. Input data includes three main types of data typi- cally used in regional modeling: (1) zone-level data on population, employment, parking, and other relevant variables; (2) zone-to-zone matrix data on travel times and costs for automobiles; and (3) similar matrix data on travel times and costs by transit modes. It also includes (4) census tract-level demographic distributions and (5) ADA paratransit service levels, although such data does not need to vary at a zonal level. The input data feeds into the main demand models for resident travel, as well as one or more “special generators” for freight and commercial traffic, trips to airports, and sometimes non-resident visitor travel as well. In the route assignment step, the trips predicted by the main models and the special generators are loaded onto the road and transit networks, and new travel flows and speeds on the networks are predicted. These new speeds and travel times are typically fed back into the travel demand models (at least the mode choice model), and (ideally) the whole system is iterated in this way until the predicted trips and speeds remain stable from one iteration to the next. (The diagram is also valid for most new activity-based (AB) model systems, where the activity-based model components reside in the “Main travel demand models” box.) The new “ADA paratransit demand models” are included at the lower right. These are actually models of travel by ADA-paratransit-eligible people and produce trips by all modes, including ADA paratransit trips, fixed-route transit trips, trips as a passenger in a car, and a small number of trips driving a private vehicle. There are two main ways that ADA paratransit models can fit into this framework. Integrated as another special generator: In this procedure, the ADA paratransit models are run during the main equilibration loop, just as the other special generators are, and the demand from the ADA paratransit models (both car trips and ADA paratransit trips) are loaded onto the networks for traffic assignment, as indicated by the dashed arrow. (This method could lead to double counting of some trips, because the automobile and scheduled transit trips of all house- holds are already predicted by the main demand models, including households that contain registered ADA paratransit users.) Run as a post-process: In this mode, the main travel demand models and other special gen- erators are run until equilibrium, and then the resulting automobile and transit travel times are Main travel demand models: - Trip generation - Trip distribution - Mode choice Special generators: - Freight/ commercial - Airports - Non-resident visitors ADA paratransit demand models: - ADA registration - Trip generation - Trip distribution - Mode choice Input Data: - Zonal data (housing, employment) - Road networks, travel times - Transit networks, travel times - Census data (demographics) - ADA paratransit service levels Route assignment - Traffic speeds - Transit speeds Figure A-1. Diagram of an enhanced regional model framework.

Using the AdA paratransit Travel Models 67 used as input for a single run of the ADA paratransit demand models, with no subsequent route assignment. This mode of using the models is much simpler, particularly if the models are being run by the ADA paratransit agency instead of the MPO. The implicit assumption made is that any changes in network loadings due to changes in travel patterns by registered ADA paratransit users will not noticeably change the traffic speeds in the region. Given that ADA paratransit vehicles and automobiles carrying ADA paratransit users as drivers or passengers are a very minor share of traffic and travelers, this assumption seems valid. We recommend applying the models in this post- process mode. However, it would be possible for any agency to use the models in either manner. In terms of software for running the models, the model system has been designed as a user- configured executable (EXE) file that can be run from within any of the major network model packages such as CUBE or TransCAD. (Some activity-based model software is run in that same manner.). If used as a post-processor, it is also possible to run the ADA paratransit demand model completely outside of the network model software. The model system can be run either by the ADA paratransit operator or by the local MPO, whichever seems most efficient. Use of the model will likely require the following: • Specifying general ADA paratransit-specific parameters for model input, such as travel time factors, fares, and punctuality. • Providing a census-tract-level file of demographic distributions. • Executing a run using pre-existing inputs (zonal demographic segmentation and land use data, zone-to-zone travel time, and cost matrices). • Querying the model output to obtain results in the form of summary tables. The resulting models are applied with the same inputs used in the regional travel demand models and thus can provide forecasts of ADA paratransit demand at an origin-destination level (and system-wide level) under the following: • Various ADA paratransit operating scenarios (e.g., fares, service levels, coverage areas). • Various growth scenarios related to future changes in fuel prices, household size, income, automobile ownership, age distribution, and residential distribution patterns. • Scenarios related to changes in the service levels and/or coverage of the fixed-route transit system, as well as highway service levels. Currently, the model only predicts weekday ADA paratransit trips, and not weekend trips. Modeling weekend trips would require collection of additional survey data. Also, we have not modeled trip departure time choice for ADA paratransit users. It would be possible to provide time-of-day distributions by applying fixed time-of-day factors for each trip purpose, but these factors would be based on the observed distributions from our surveys and not be varied. Using the Sketch Planning Model in Excel The spreadsheet interface available from TCRP provides a simple way of running the model system in Sketch Mode. Download the file ADAModel.zip and unzip the files to a folder on your computer. Make sure you put it in a folder whose complete path name has no spaces in it. For example, you can name your folder “ADAModel” but not “ADA Model” and that folder can be within a folder called “TCRPB-28A” but not “TCRP B-28A” and not within “My Documents.” Open the spreadsheet ADAModelRun.xlsm. On most systems running recent versions of Excel, you will see the warning “Macros have been disabled” as in Figure A-2. Click on the button labeled “Options . . . ,” then in the pop-up window select the radio button “Enable this content,” and then select OK. This enables the macro that will run the demand model when the user presses the “Run Sketch Model” button.

68 improving AdA paratransit demand estimation: Regional Modeling Before running the model, the user should provide input to several fields on the screen. The model is set up so that the user can perform a “base run” and then do a series of runs that test the effect of various changes. For the base run, enter a label of your choice in RUNLAB and enter “None” in BASERN as illustrated in Figure A-3. In the example below, RUNLAB is “ExampleBase.” When the model is run, it will then create a results file called “ExampleBase.” Once the base run is completed, in the test runs, enter “ExampleBase” (or whatever you named the base run) in BASERN and put a label that describes the change being tested in RUNLAB. For instance, in an example shown in detail later, a run that tests the effect of increasing income levels by 10% has the name “ExampleInc10” in the field for RUNLAB. The RUNLAB field should always be used, as that provides the label to use to refer to the run and determines the name of the resulting output files. Each time you run the model, it produces a file with a name based on whatever you have specified in the RUNLAB field. Doing a Base Run The first step in using the sketch model is to do a base run. Figure A-3 shows how the model might be set up for a base run. RUNLAB has been set to ExampleBase. This will be the name given to the output file created by the base run. The BASERN field, immediately below RUNLAB, only needs to be filled in if the user wishes to compare the results to the results of an earlier base run. In this case, we are setting up a new base Figure A-2. “Macros have been disabled” warning. Figure A-3. Performing a base run.

Using the AdA paratransit Travel Models 69 run in ExampleBase, so BASERN is set to “None.” In a base run, policy changes for income, age, household size, and ADA paratransit service levels are typically all left at 0, as in the screen above. The final two user inputs for a base run are RDSEED and SKREPT. RDSEED is the seed for the random number generator used in the simulation. It can be any arbitrary value, such “12345” as shown in the example, but should be the same for a base run and later runs to determine the effect of policy changes, because changing the random number sequence can change the results somewhat, even if no other inputs are changed. The SKREPT value determines the number of model replications run for each member of the proto-typical sample used to run the model. In the example, SKREPT has been set to 100. The higher the number, the longer the program will take to run, but the less influence that random variability will have on the results. Thus, a lower number of replications can be used for initial, more exploratory runs and more replications if one wants results with a lower margin of error. After the RunSketchModel button is pressed, the model starts to run, and a console-type window, such as shown in Figure A-4, pops up to report the progress of the run. If there are no errors, the window will disappear when the model is done running, and the model results will Figure A-4. Report of model progress.

70 improving AdA paratransit demand estimation: Regional Modeling appear automatically in Excel. In the example case, there is no base run name provided, so the program gives a message that the Base scenario ‘None’ does not exist, and waits for the user to press Enter before returning to Excel. (This warning message is primarily intended for cases where the user intended to provide the name of a valid base run, but that base run cannot be found in the working directory.) When the model is done running, it writes out numerical results in a file named RUNLAB_ summ.csv, where RUNLAB is the run name provided by the user. So, in this example, the results are in ExampleBase_summ.csv. The Excel macro then creates standard tables and charts based on those numbers and saves the results to a file named RUNLAB_summ.xlsx (in this case, ExampleBase_summ.xlsx ). At that point, the user can further edit the tables and graphs if desired, just as in any Excel spreadsheet. The macro creates the following standard tables and graphs: • Trips by tour purpose and mode. • Trips by trip destination purpose and mode (similar to the tour table, but based on each trip, with an extra purpose ‘return home’). • Trips by gender/age group combination and mode. • Trips by main occupation (worker, student, other) and mode. • Trips by impairment type (physical, mental, sensory, multiple) and mode. • Trips by household type (numbers of persons and vehicles) and mode. • Trips by household income group and mode. • Trips by area type (in terms of accessibility of nearby attractions) and mode. The following pages show examples for the first set of tables and graphs. In Figure A-5, the tables first show the predicted number of trips, and then show them with percents within rows (mode shares within purpose) and percents within columns (purpose distributions within modes). In Figure A-6, the first chart shows the number of trips by both mode and purpose in a 3-dimensional graph, while the second chart shows mode share within purpose as a percentage bar chart. A final table and graph within each set show the percentage change relative to the base sce- nario, but in this case there is no base scenario, so those are empty. At the bottom of the .xslx (and .csv) file is a copy of the run settings, as shown in Figure A-7. This is mainly for documentation purposes, so the user can remember which inputs produced a specific set of outputs. Testing Policy or Demographic Changes The values that can be entered for policy changes represent percentages, except for fare change, but must be entered as whole positive or negative numbers without a percentage sign. They are as follows: INCCHG: A percentage increase in household income. For example, a 10% increase would be entered as 10. The fraction of households in each census tract with income below the poverty level is decreased by INCCHG, and the median income in each census tract is increased by the same amount. Also, the expansion factor for any sample members in the lowest income category (less than $15K) is decreased by this same percentage relative to the rest of the sample. AGECHG: The fraction of the population in all age groups over age 60 is increased by the percentage entered in AGECHG. (Do not enter a percentage sign.) Also, the expansion factor

Using the AdA paratransit Travel Models 71 Figure A-5. Model tabular output.

72 improving AdA paratransit demand estimation: Regional Modeling Figure A-6. Model graphical output.

Using the AdA paratransit Travel Models 73 Figure A-7. Output with summary of run settings. for any sample members over age 60 is increased by the percentage relative to the other sample members. HHSCHG: The fraction of the households in each census tract that are single-person house- holds is increased by the percentage entered in HHSCHG, and the average household size in each tract is decreased by the same percentage. Also, the expansion factor for all sample members in single-person households is increased by the same percentage relative to the other sample members. PTTCHG: The travel time by ADA paratransit relative to travel time by car for each trip is increased by the percentage entered in PTTCHG. RELCHG: The likelihood of a pick-up or drop-off being late is increased by the percentage entered in RELCHG. FARCHG: The ADA paratransit fare for each trip is increased by the amount (not a percent- age) entered in FARCHG in cents (e.g., a $1.00 fare increase would be entered as 100). Figure A-8 shows the input for a run done for a scenario with a 10% increase in regional income, to be compared to the base case run done above. Only the values for RUNLAB, BASERN and INCCHG are changed from the previous (base) run. The output now includes the same tables as before, plus values for the change with respect to the base scenario, as shown in Figures A-9 and A-10. In, this case, increasing regional income by 10% reduces the number of total trips by about 2%, but that change is very different for certain purposes, such as work tours (a 9% increase), and for certain modes, such as scheduled transit (a 5% drop).

74 improving AdA paratransit demand estimation: Regional Modeling Figure A-8. Model input for a scenario testing run. Figure A-9. Sample of tabular output for a scenario testing run. Figure A-10. Sample of graphical output for a scenario testing run.