Transferability of Activity-Based Model Parameters (2014)

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.

6The outcomes of parameter transferability tests are just one aspect of assessing the validity of model transfer as an approach to model development. Another important consideration is the level of effort required to develop an activity-based model in a region where it has not previously existed, which may require assembling more detailed data and creating or modifying other procedures in support of the activity-based model. These same steps would be required irrespective of whether param- eters were transferred or estimated from scratch. An agency that decides to transfer a model from another region should recognize that a substantial amount of work will be involved, regardless of the parameter transfer. In this research, the consultant team developed close part- nerships with the modeling staffs of the two subject agencies, NFTPO and FDOT-D7. With each group, there was an estab- lished division of labor in which the agency staff members were responsible for developing and providing • Parcel-level land-use data, including housing units, com- mercial floor space, and establishment-level employment by industry type; • Household and employment control values at the travel analysis zone (TAZ) level; • Socioeconomic data, such as school enrollment and hotels and motels; • Highway and transit network model inputs; • Paid parking spaces; and • Auxiliary demand models, such as external-internal, external- external, and truck trip models and tables. The consultant team was responsible for developing the DaySim activity-based travel demand model components, including estimation and calibration, and for integrating all of the pieces provided by the partner agencies into a com- plete regional model system. In addition, the consultant team developed synthetic 2010 populations for both regions. Full integration of system components was necessary before estimation or calibration could begin; this was necessary because the DaySim specification required several accessibility-related variables that are derived from land-use inputs and skims. In addition, new network assignment procedures needed devel- opment to move from agencies’ all-day assignments to four periods and to provide travel time and cost skims for model variables. Data Development and Integration Integration of the activity-based modeling components with the supply-side and auxiliary demand model components involved numerous steps, some more complex than others, with frequent back-and-forth communication among the consultant team, agency staff members, and local consultants. An abbreviated summary of the major tasks follows. parcel-Based Land-Use Data The Sacramento version of DaySim was notable for being, among other things, the first activity-based modeling system in the United States to use parcel-level land-use inputs. The primary benefit of this approach is greater spatial precision in terms of activity locations, pedestrian and bicycle travel time estimation, and walk access to transit. Although it would have been possible to transfer the Sacramento model to a system that used more aggregate spatial units, it was necessary to develop DaySim accessibility variables at the parcel level in the recipient regions to provide the most mathematically con- sistent comparison between regions. In addition, both Florida agencies expressed an interest in having parcel-level land-use and accessibility resolution. Both NFTPO and FDOT-D7 worked with the consultant team to develop geographic information system (GIS)–based point and polygon layers of land use for each of the counties in the model area. This process was the most time-consuming of C h a p T E R 2 Research Approach

7 the integration steps, primarily because staff for both agen- cies viewed this as the development of an operational regional modeling system and wanted to perform thorough reviews and quality assurance checks. This process involved reconcil- ing logical inconsistencies between tax assessors’ records for housing units and commercial square footage, Census records for households, and establishment-level employment data purchased from a commercial vendor, InfoGroup. Although the Florida Department of Revenue has a set of consistent defi- nitions for coding tax assessor database entries, adherence to these standards was inconsistent between regions. In addition, in some cases there were multiple versions of the GIS layers, which varied in the extent to which polygon slivers had been cleaned and recoded based on previous work efforts. For the DaySim model, the critical parcel attribute fields were the number of single-family, multifamily, and “other” housing units; number of paid parking spaces; and K–12 school enrollment and postsecondary (college/university) enrollment. A summary of these attribute quantities is shown in Table 2.1. Parking and enrollment data were added to the base parcel layer by agency staff and local consultants. House- holds and employment were also assigned to parcels; how- ever, the processes were more complicated due to the need to maintain regional control totals. Regional households and Employment To support the development of synthetic populations and to control the spatial distribution of regional employment within the region, the consultant team worked with the local agencies to develop regional control totals for households and employment. Once control totals were established, the consultant team developed synthetic populations for each region and allocated populations and regional employment to parcels. Households The consultant team developed regional household control totals by multiple attributes and attribute levels, using the 2010 Census at the Block Group level. These control totals were then reallocated to each region’s TAZ system for consistency with past practices and future forecasts. Control totals were developed for three separate population groups: permanent residents living in households, seasonal resident households, and group quarters residents (such as residents of group homes, college dormitories, retirement homes, and military quarters). Table 2.2 shows the number of households by type in each region. Both NFTPO and FDOT-D7 reviewed these data at the TAZ level and provided recommendations for minor adjust- ments, primarily to the locations of group quarters and seasonal populations, based on local knowledge. The consultant team used these regional control totals, along with household sample data from the ACS Public Use Microdata Sample (PUMS), to produce synthetic 2010 populations for each region; the team used the open-source program PopGen 1.1 to simultaneously control both household- and person-attribute levels. Once a set of synthetic households and persons was created at the TAZ level, the consultant team applied a utility program to allocate them to the parcel level, using the locations of housing units found in the parcel data. This allocation pro- cess revealed additional inconsistencies between the spatial distribution of households and the number and locations of single-family, multifamily, and group quarters housing units. These discrepancies were rectified through manual examination by agency staff members, who provided recommendations to the consultant team for reallocation. Employment Because of differences in the ways that employment data are collected and classified by various sources, multiple sources of employment were used in both the NFTPO and FDOT-D7 regions. Both regions purchased 2010 establishment-level data from the commercial vendor, InfoGroup; these data were then geocoded to individual parcel locations. For the Tampa Bay region, FDOT-D7 staff inspected these records and attempted to find and correct missing employ- ment and North American Industrial Classification System Table 2.1. Summary of Critical Parcel Attributes for Tampa and Jacksonville DaySim Models Attribute Tampa Model Jacksonville Model Number of single-family housing units 821,242 405,574 Number of multifamily housing units 433,495 165,017 Number of other type housing units (retirement home, mobile-house, etc.) 181,404 65,155 Number of paid parking spaces 36,117 3,124 K–12 school enrollment 449,905 249,010 Postsecondary (college/university) enrollment 139,470 121,885 Table 2.2. Number of Households by Type Household Type Tampa Model Jacksonville Model Permanent residents 1,092,571 553,265 Group quarters 73,306 16,854 Seasonal residents 52,579 28,328

8(NAICS) codes and compared these records with other in-house sources. To set regional control totals, FDOT-D7 staff used a combination of sources to determine regional control totals by county and industry group; sources included 2010 data from the Quarterly Census of Employment and Wages (QCEW) pro- gram, sole proprietor data from the U.S. Bureau of Economic Analysis (BEA), and military employment data from BEA. Regionwide, the disaggregate InfoGroup data summed to 83% of the regional control totals, varying somewhat by industry and county. NFTPO used regional employment control totals provided by the Florida Bureau of Economic and Business Research (BEBR). These corresponded roughly with the regionwide totals for InfoGroup, but they varied by industry and county. Summaries of employment by industry from each source and the final employment numbers may be found in Tables 2.3 (Jacksonville) and 2.4 (Tampa). For both regions, the consultant team developed a program to synthesize missing employment and randomly remove disaggregate employment records in places where county control totals for a particular industry segment were exceeded. Missing jobs by industry group were added to parcels with appropriate land-use designations, favoring locations where such jobs already existed, so that in the aggregate they matched county-level control totals. Agency staff performed extensive reviews of these synthesized disaggregate job records and specified manual re-allocations, as necessary. Network Models Both NFTPO and FDOT-D7 took responsibility for updating their respective 2010 highway and transit networks, such as link coding, facility and area type designations, speed- capacity parameters, and transit travel time factors. To maximize com- patibility with the Sacramento DaySim specifications, the con- sultant team worked with agency staff to develop a.m. peak, midday, p.m. peak, and evening network assignment proce- dures. Before this project, both agencies had maintained Table 2.3. Employment Data by Industry Type and Source, Jacksonville Industry Florida BEBR 2010 QCEW InfoGroup Final Number Used in Model Agriculture, forestry, fishing, and hunting 1,771 1,901 1,646 2,080 Mining 97 124 421 420 Utilities 788 3,427 1,935 1,937 Construction 28,199 27,815 54,486 51,998 Manufacturing 28,839 28,772 47,356 47,509 Wholesale trade 23,346 23,168 27,729 26,443 Retail trade 71,137 71,707 92,234 90,336 Transportation and warehousing 24,919 30,172 27,065 27,083 Information 10,013 9,996 16,892 16,832 Finance and insurance 45,324 45,172 45,485 46,078 Real estate rental and leasing 8,797 8,618 18,455 16,952 Professional, scientific, and technical services 32,531 33,256 37,163 35,687 Management of companies and enterprises 5,705 5,701 488 5,746 Administrative and support and waste management and remediation services 41,940 42,088 25,722 40,938 Educational services 8,854 40,922 44,031 43,066 Healthcare and social assistance 75,649 77,662 77,199 76,661 Arts, entertainment, and recreation 8,770 9,549 8,448 9,299 Accommodation and food services 56,301 56,391 63,433 61,204 Other services (except public administration) 17,274 16,862 34,002 31,374 Public administration 0 33,967 69,396 60,337 Total 490,254 567,270 693,586 691,980 Note: BEBR = Bureau of Economic and Business Research; QCEW = Quarterly Census of Employment and Wages.

9 planning models that performed all-day highway and transit assignments, which occasionally were modified to create peak- period assignments, as needed, for special projects. In addition, the consultant team modified the speed-feedback loop systems in both models, using skim-averaging methods that improved convergence rates in both model systems after integration with DaySim. The speed-feedback loop was modified to account for multiple (four) network-assignment time periods. This was necessary because the original trip-based model setups had just one all-day assignment with feedback to trip distribution; the 2005 Jacksonville-DaySim model used TRANSIMS as the network model, which uses a very different feedback system. auxiliary Demand Models NFTPO and FDOT-D7 assumed responsibility for updating auxiliary demand models in their systems, including the following: • Truck trip tables and embedded procedures; • Generation and distribution of internal-external (IE), external-internal (EI), and external-external (EE) vehicle trips; and • Modification of special generators. While accounting for all sources of auxiliary demand is important for model validation, the consulting team had a limited influence on this process, mainly helping to rebalance the external trip tables to match new counts in the Jacksonville region. NFTPO and FDOT-D7 chose not to change the methods used to produce EE/IE and truck trip tables, which they consid- ered within their purview. In addition, both agencies believed it would be easier for them to compare differences between the activity-based model results and their trip-based models if the auxiliary demand components and networks were consistent. IE/EI trips are intriguing because, in theory, they overlap with activities and travel generated by households through DaySim. For example, persons who live within a region but who work or attend school outside of the region have IE tour and trip patterns. In DaySim, a fixed portion of workers and students are assumed to have usual work or school locations outside of the study area; these IE work and school commutes are predicted, and the entire day pattern for these individu- als is not used in subsequent model steps to create trip tables because that would duplicate the IE flows that already exist in the model. The portion of workers in each TAZ that work outside the region is derived from ACS journey-to-work data. Intuitively, persons who live near the edges of a study region are more likely to work outside of it than those who live closer to the center. Likewise, DaySim assumes that a portion of the jobs within the region will be filled by workers who live outside the region. To accommodate this market, EI work trips are fixed for workplace destinations, thus reducing the availability of those jobs for workers living within the region. The usual work- place location choice is affected by DaySim’s shadow-pricing mechanism, which compares the total employment within each zone to the number of workplace locations predicted for each zone and adjusts the attractiveness of that zone through a series of iterations to balance job supply with worker demand. For both Tampa and Jacksonville models, trial-and-error revealed that a 10-iteration approach to shadow-pricing for employment yielded the best results. Because the DaySim model theoretically covers the portion of special generator travel market that comes from local resi- dents working or patronizing these facilities, some special gen- erators, such as regional shopping malls and hospitals, were not used. Other special generators, such as beaches, amusement parks, and airports draw travel from both local residents and visitors; therefore, these special generators were kept active, and their trip-generating rates were adjusted based on validation outcomes, as necessary. In terms of auxiliary demand’s impacts on transferability analysis, it seems to have the most noticeable impact on the extent to which DaySim trips need to be redistributed across time periods and overall tour/trip rates. It is not clear that the results of this study would have changed in a meaningful way Table 2.4. Employment Data by Industry Type and Source, Tampa Industry InfoGroup Final Number Used in Model Agriculture, forestry, fishing, and hunting; mining; construction 75,593 101,100 Utilities; manufacturing; wholesale trade; transportation; delivery and warehousing; waste and remediation services 177,293 200,600 Retail trade 176,707 192,900 Postal services; arts, entertainment, and recreation; accommodations; other services 107,693 128,700 Information; finance and insurance; real estate, rental and leasing; professional, scientific, and technical services; management of companies and enterprises; administration and support 255,443 355,200 Educational services 95,972 106,600 Healthcare and social services 173,934 198,100 Food services 96,161 106,100 Public administration, government services, and military 52,419 70,100 Total 1,211,215 1,459,400

10 had the consulting team exerted more control over the process. The effects of auxiliary demand on tour and trip mode and destination choice models were negligible. Urban Form and accessibility Variables DaySim uses parcels as the main spatial unit; therefore, it is important to have measures not only of what lies on any particular parcel, but also what lies in the area immediately surrounding each parcel. These measures are created by defin- ing a buffer area around each parcel and counting what lies inside the buffer. These variables can then be used in DaySim in a way similar to how zonal land-use and density variables are used in TAZ-based models, with the advantage that the buffer is defined in exactly the same way for each parcel. The buffer variables that DaySim uses include the following: • Number of households in the buffer; • Employment (number of jobs) in the buffer in various employment sectors; • Enrollment in schools in the buffer, segmented by grade schools and colleges; • Number of spaces and average price of paid, off-street parking in the buffer; • Number of transit stops within the buffer (segmented by mode, if relevant); • Number of street intersections in the buffer, segmented by 1-node (dead-end or cul-de-sac), 3-node (T-junction), and 4+-node intersections; and • Area within the buffer that is public, open space (parks, etc.). A special set of buffering programs was created to establish the buffering variables for each parcel. These programs com- bined the GIS parcel layer (complete with the attributes in the preceding list), along with the all-streets network, to calculate the variables. The buffering calculations require the input of an “all streets” network to count all local streets and inter- sections, not just the higher-level facilities used in the regional highway network model. NAVTEQ networks from both NFTPO and FDOT-D7 were obtained for this purpose. The buffering program permits different methods of calculating buffers; however, these projects used a logistic distance-decay for- mulation. Compared with a flat, uniform buffer with a pre- determined cutoff point (e.g., ¼ or ½ mi), a distance-decay formulation has the advantage of weighting nearer attractions more than more distant attractions and avoids the “cliff effects” at the edges of the buffer radius. The buffering program also calculates the distance from the parcel to the nearest transit stop (by transit mode, if relevant) and the distance to the nearest open space area. Model Estimation Once all of the model system components were in place, the consultant team took the lead in calibrating DaySim model components and in estimating model parameters using the NHTS data. The DaySim application software was oper- ated in estimation mode, which enables the user to produce estimation data sets for any particular model component, given household diary records and a set of variable specifi- cations. DaySim includes a data processing step to create transportation system level-of-service variables from skim tables and accessibility variables from combinations of land- use attributes and transportation skims. These are placed in the estimation data set for each survey record in which those variables are specified. DaySim is configured to integrate with ALogit, a commercial estimation software package. This inte- gration includes accepting a variable specification file in a format compatible with ALogit’s “F12” output file format and returning a data set and configuration files in the formats used by ALogit. (The F12 output file format is text-based and is also output by the open-source discrete choice model estimation program Biogeme.) It is incumbent on users to run ALogit to estimate the models and to manually specify any changes to the specification that may be different from the original specification. Manual changes could include removing variables, adding new variables, making linear and nonlinear transformations of variables, and constraining parameter values. Model Calibration Model calibration is the process of applying the estimated models, comparing the results to observed values, and adjust- ing either the model specification or the alternative specific constants. This process uses the application mode of the DaySim software, and the comparisons of results are produced by calibration reports developed for this purpose. The process is complicated by the fact that the various model components in DaySim are not isolated: long-term decisions restrict how people plan their days and where, when, and how they travel; lower-level decisions also can influence the higher-level choices through the log-sum, an explanatory variable in the long-term choice models. As a result, a change in the share of one model is likely to influence the outcome of other models. Therefore, the general approach is to calibrate model components in the order in which they are applied, which generally means that the higher-level models are calibrated before the lower ones. In this instance, the consultant team calibrated the long-term choice models first, followed by the daily activity scheduling models, tour-level models, and trip-level models. In addition, the calibration process must be done in an iterative manner

11 to incorporate all the interactions between models until the model, performing as a system, converges to a stable set of parameter values for all of the model components. For both the Jacksonville and Tampa regional models, the consultant team performed numerous iterations of calibration until all traveler decision modules matched their respective target values and regional demand patterns were well- represented. Target values for long-term choice models were perhaps the best informed because the study team was able to use data from ACS and CTPP for work location choice and auto ownership choice models, respectively. For other models, expanded NHTS data provided the only benchmark values. In addition, validation to traffic count data by time periods was used to refactor some of the NHTS-derived target values to better represent time-of-day choices and what the consultant team and agency staff perceived to be underrepresentation of non-work travel. Finally, transit system boarding count data were used to refactor mode choice target values, which was especially important considering that observed transit trips were not well- represented in the NHTS data for either region. Many different model components and parameters were evaluated as part of the calibration process. The degree of fit that can be tolerated depends on the model and the market seg- ment and how much available data there are for calibration. Moreover, the focus is on fit to individual parameters, not a global fit measure. For example, the consultant team strived for a tighter fit for models that individually have greater impact on the model system—such as auto ownership shares, which applies to all households and persons and has just four constants. In contrast, a lower degree of precision was tolerated for model parameters of some of the more obscure variables in which the confidence in the benchmark data was not so high, such as coefficients on the propensity to make intermediate stops on work-based sub-tours. Often the amount of effort needed to match the more obscure parameter benchmarks does not pay off and can even distort other parameters.