National Academies Press: OpenBook

Passenger Counting Systems (2008)

Chapter: Summary

« Previous: Front Matter
Page 1
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 1
Page 2
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 2
Page 3
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 3
Page 4
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 4
Page 5
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 5
Page 6
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 6
Page 7
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 7
Page 8
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 8
Page 9
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 9
Page 10
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 10
Page 11
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 11
Page 12
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 12
Page 13
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 13
Page 14
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 14
Page 15
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 15
Page 16
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 16
Page 17
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 17
Page 18
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 18
Page 19
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 19
Page 20
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 20
Page 21
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 21
Page 22
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 22
Page 23
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 23
Page 24
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 24
Page 25
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 25
Page 26
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 26
Page 27
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 27
Page 28
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 28
Page 29
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 29
Page 30
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 30
Page 31
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 31
Page 32
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 32
Page 33
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 33
Page 34
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 34
Page 35
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 35
Page 36
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 36
Page 37
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 37
Page 38
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 38
Page 39
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 39
Page 40
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 40
Page 41
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 41
Page 42
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 42
Page 43
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 43
Page 44
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 44
Page 45
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 45
Page 46
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 46
Page 47
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 47
Page 48
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 48
Page 49
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 49
Page 50
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 50
Page 51
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 51
Page 52
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 52
Page 53
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 53
Page 54
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 54
Page 55
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 55
Page 56
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 56
Page 57
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 57
Page 58
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 58
Page 59
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 59
Page 60
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 60
Page 61
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 61
Page 62
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 62
Page 63
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 63
Page 64
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 64
Page 65
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 65
Page 66
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 66
Page 67
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 67
Page 68
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 68
Page 69
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 69
Page 70
Suggested Citation:"Summary." National Academies of Sciences, Engineering, and Medicine. 2008. Passenger Counting Systems. Washington, DC: The National Academies Press. doi: 10.17226/14207.
×
Page 70

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.

SUMMARY PASSENGER COUNTING SYSTEMS TCRP Synthesis 29, published in 1998, summarized information from selected transit agencies regarding the benefits and pitfalls associated with various passenger counting technologies, as reported by users. The synthesis provided advice for agencies considering automatic passenger counter (APC) systems. At that time, manual passenger counting was the most prevalent technique in the transit industry. This report documents the state of the practice in terms of analytical tools and tech- nologies for measuring transit ridership and other subsidiary data. Results of a web-based survey of a cross-section of transit agencies in North America document tools and technol- ogies used to count passenger boardings and alightings. Forty-one completed surveys were received from the 56 transit agencies approved by the panel for inclusion in the sample, a response rate of 73%. In addition, 45 agencies responded to an invitation to all American Public Transportation Association (APTA) members to participate in the survey, for a total of 86 transit agencies. Survey results include transit agency assessments of the effective- ness and reliability of their methodologies and of desired improvements. The survey was designed to emphasize APC systems, but agencies using manual systems were also sur- veyed to gain an understanding of why new technologies have not been adopted. Key survey findings include the following: The most common reason to collect ridership and travel time data is to compile rid-• ership data by route, although the majority of respondents also collect ridership and travel time data for more specific microlevel uses at the route segment or stop level. Tracking ridership changes, calculating performance measures, and adjusting sched- ules were the three most common uses of ridership and travel time data. A majority of respondents use a combination of automated and manual methods to • collect ridership data. The most common combinations involve APC plus manual data collection and farebox plus manual collection. In many cases, an older technol- ogy is retained to test the validity of the new technology or for a specific purpose, such as National Transit Database reporting or data validation. Agencies that continue to collect ridership data manually cite cost as a reason, fol-• lowed by low priority for automated data collection at the agency. Smaller systems (fewer than 250 peak buses) are more likely to continue to rely on manual data collection. Only a portion of most agencies’ buses are APC-equipped; however, more than one-• quarter of responding agencies have installed APCs on all buses. Nine of the 12 agencies that are 100% APC-equipped bought APCs as part of a broader intelligent transportation systems (ITS) purchase. Changes in professional staffing levels as a result of APC implementation were mini-• mal in most cases: More than 70% of all agencies reported no changes or decreases in

2 staff levels. However, there were notable decreases in the size of traffic checking units. The case studies suggest that assigning analytical and maintenance staff specifically to the APC program is an important factor in successful implementations. The median reported capital cost per APC unit was $6,638 among the 26 agencies • responding. The median reported annual operating and maintenance cost per APC unit was $600 among the 11 agencies responding. Cost data from the survey should be interpreted cautiously, as respondents varied in their ability to break down cost data (especially for older systems or for APC systems purchased as part of a larger ITS procurement). Processing APC data often requires changes to existing data systems, such as addi-• tion of global positioning system coordinates for stops and an updated or new bus stop inventory. A few agencies noted the establishment of defined interfaces between computerized scheduling software packages and APC or automatic vehicle location systems. For data storage and analysis, the most common changes were the addition of servers for data storage and new database software for analysis. Automated data validation programs, provided by the APC vendor, developed in-house, • or purchased from a third party, can simplify the process of converting raw APC data into usable data. Agencies reported various thresholds for determining validity at the block or trip level. A majority of agencies rely on the hardware vendor for data processing and report • generation software, but several indicated in-house software development or use of an outside vendor other than the APC vendor. Anyone who has been through the process of implementing a new technology knows • that there is a “debugging” period. The debugging period, during which start-up prob- lems are resolved, averages 17 months for APCs, identical to the finding of the 1998 synthesis, with a median of 18 months. The planning department is the most common location for management of the APC sys-• tem, followed by the operations department. There is widespread involvement across departments in procurement of the APC system and use of the APC data. Downstream users typically access APC data electronically by means of standard reports, and 41% of agencies noted that downstream users could query the database directly. Implementation of APCs necessarily involves multiple departments within the tran-• sit agency. Positive aspects include improved communication among departments, greater value placed on ridership data, improved decision-making ability, greater responsiveness, and the ability to provide the needed data to end users. Difficulties include problems ensuring that assignments were completed, new demands for reports, low priority for APC equipment in the maintenance department, and unrealistic expec- tations regarding turnaround time and data quality. Implementation of APCs creates a need for training. A majority of respondents noted • increased training needs in the areas of software/computer, analytical, and hard- ware skills. Only one-quarter of responding agencies reported no additional training needs. The primary benefits of APCs included data disaggregated at the stop, segment, and trip levels; better quality of ridership data; availability of running time data to adjust schedules; and a better basis for decision making.

3 Problems encountered with the APC system included reporting software, data process- ing and analysis, data validation, and hardware problems. One-quarter of all respondents reported either no problems or only the usual start-up issues. Results regarding agency satisfaction with the performance of its APC system in terms of counting passengers are positive: Eighty-five percent of respondents were very or some- what satisfied. Forty percent were very satisfied, and 45% were somewhat satisfied. Contract elements, procurement procedures, purchase of additional APC units, and the overall approach to APC implementation were the most frequently mentioned aspects of the APC process that transit agencies would like to change. Regarding procurement, stricter contractual requirements, purchase of a complete system through a single vendor, and changes to internal procedures were all important. Changes to the overall approach included being more informed about APC hardware and software choices, involving main- tenance personnel at the start of the process, dedicating one or more technicians to work full time on APCs, completing the bus stop inventory before installation, and hiring a stat- istician to develop a methodology for passenger counting before vendor selection. Almost three-quarters of all survey respondents that have implemented APC systems shared lessons learned from the process. Agencies focused on use and validation of the APC data, purchase and implementation, and ongoing agency maintenance in the discus- sion of lessons learned. Agencies offered lessons in many areas, but the emphasis on data systems and agency procedures suggests that these areas are critical to the success of APC implementation. Major conclusions include the following: APCs provide a rich ridership and travel time database at a finer level of detail than • farebox or manual counts, even for agencies with only a few APCs. The increased number of observations lends greater confidence to decisions regarding changes in service levels. An agency does not need APC units on all vehicles to establish a work- able APC system, although installation of APCs on all vehicles produces a richer database and avoids vehicle assignment problems. An APC system does not work automatically. Successful agencies have developed • procedures (in-house or through an outside vendor) to match APC data to bus stops, clean and validate data, generate standard reports, simplify the process of creating ad hoc reports, and flag potential hardware and software problems for the mainte- nance and information technology departments. The data processing and reporting software is the most important part of an APC implementation. Integration of APC data with existing agency databases, which may also be changing as a result of new technologies is challenging. Agencies’ business practices and procedures may not be designed to make optimal use of available data. APC implementation is not simple, and the first year is the most difficult. There is • a steep learning curve, particularly on the software side, and there are likely to be internal agency issues regarding responsibilities and priorities. Ownership of the APC system is important, as is collaboration across departments. • The ownership part of the equation, in which one department assumes overall respon- sibility, ensures that the APC system receives priority, whereas the collaboration part works best when the lead department is attuned to the needs and procedures of other departments and can adjust to meet these needs. A good working relationship between the lead department and the maintenance personnel assigned to APCs is critical.

4 Staffing presents a challenge, especially to small and medium-sized agencies. • Successful implementations are characterized by close review of APC data as part of a quality assurance program, particularly in the first year when bugs are being worked out, and a dedicated maintenance technician or group of technicians who assumes primary responsibility for hardware issues. Agencies may not have the staff available or may not have staff with the right mix of skills. Transit agencies that have worked through the myriad issues associated with APC • implementation cannot imagine life without APCs. These agencies reap the benefits of extensive and statistically valid data that are used with confidence to make important service-related decisions. Findings from this synthesis suggest eight major areas for future study: In-depth investigation of critical factors to success. Are there optimal routines to match • APC data to specific bus stops? What elements of a validation program are most critical to ensuring quality data? Which elements of reporting software are most useful, and what is the best way to create ad hoc query ability? How can APC data be integrated most usefully with existing agency databases? How can an agency “manage” the learn- ing curve? Are there techniques to foster APC system ownership and collaboration? What if adequate staff is not available and added staff is not an option? How important is a strong commitment from senior management to the APC program? Exploration of various avenues to success. Both in-house and third-party approaches • have been successful. Are there circumstances in which one is preferable to another? What is the state of the art in software packages? Ongoing developments within the transit industry, such as deployment of ITS technology, increased vendor attention to complete (hardware plus software) product packages, and a wider choice of hardware and software options (including off-the-shelf software), affect the answer to this ques- tion and suggest additional possibilities. Evaluation of data cleaning and validation techniques. This is an important barrier to • success and is perhaps the major source of frustration to agencies that indicated dissat- isfaction with their APC systems. Confidence in the accuracy of APC data is critical to their widespread use and acceptance within and outside the transit agency. Many agen- cies struggling with this step view it as a hardware problem, but its solution resides in considering both the hardware and the software used to clean and validate the data. More precise identification of factors preventing success and ways to overcome them. • Data validation is not the only barrier to success. Broader hardware, software, and personnel issues need to be addressed and overcome, and a closer examination of suc- cessful strategies would serve the transit industry well. Exploration of new technologies that may improve APC data collection accuracy. As • ITS technologies evolve, new hardware and software options that improve the accuracy of APC data are likely to emerge. What are the most promising options in this area? Investigation of alternative techniques, algorithms, and methodologies that can improve • the state of the art of APC systems. As more agencies implement APC systems, the market for innovation grows larger. Using existing technology, what improvements can address the needs of transit agencies? Identification of business intelligence and data reporting tools that can be used with • APC data. As data systems are integrated and downstream users begin to rely on APC data, new approaches and innovative analytical strategies can be expected. Additional

5 uses of APC data will continue to emerge as users become more knowledgeable and will affect data needs or the priority afforded to the APC system. Establishing a data warehouse can provide an opportunity to take advantage of many business intelli- gence techniques such as data mining. Institution of new methods of disseminating information on APC systems. This syn-• thesis has provided a snapshot of the state of passenger counting systems in 2008. An APC forum or workshop, webinars on APC implementation and use of APC data, and an electronic mailing list devoted to APC-related issues are all possibilities to extend the findings of this report and to provide a continuing means for agencies to share information and learn from each other’s experiences.

7 TechnicaL approach The approach to this synthesis included a literature review, a survey of transit agencies, and telephone interviews with six agencies selected as case studies. A Transportation Research Information Services search was conducted to aid the litera- ture review. The survey on passenger counting technologies was designed to elicit information on automated technologies. At the time of the last synthesis, manual data collection was the most common means of gathering information on rider- ship. Over the past 10 years, use of APCs has become more common. Manual passenger counting was well documented in the previous synthesis; therefore, this synthesis focuses on the state of the practice for nonmanual passenger counting systems, particularly APC systems. Once finalized by the panel, the survey was posted and pretested by panel members and selected transit agencies. The pretest resulted in minor changes to survey logic and flow. The sampling plan involved a “core” sample of transit agencies that have active passenger counting programs, have participated in similar studies, and have implemented or are considering APC systems. The core sample included 56 agencies. The project manager sent an e-mail with an attachment from the TCRP program manager explaining the importance of the survey and a link to the online survey site to each of the 56 agencies. In most cases, a known contact had been identified; otherwise, the e-mail was sent to the planning director or the general manager with a request to forward the message to the most appropriate staff member. Follow-up e-mails were sent approximately 2 and 4 weeks after the original contact to encourage response. To guard against missing any agencies that are making interesting use of APCs and to ensure a broader sample, an identical e-mail message was sent to all APTA transit agency members inviting their participation in the survey. These agencies did not receive follow-up e-mails because of the sheer number of agencies. Forty-one completed surveys were received from the 56 transit agencies in the core sample, a response rate of 73%. CHAPTER ONE inTrodUcTion proJecT BacKGroUnd and oBJecTiVes TCRP Synthesis 29: Passenger Counting Technologies and Procedures, published in 1998, summarized information from selected transit agencies regarding the benefits and pit- falls associated with various passenger counting technolo- gies, as reported by users. The synthesis provided advice for agencies considering automatic passenger counter (APC) systems. At that time, manual passenger counting was the most prevalent technique in the transit industry. Since that time, improved technologies for boardings and alightings counts, reliable location detection, and data pro- cessing have entered the passenger counting marketplace. The use of APC technology has increased among transit agencies of all sizes, often in conjunction with automated vehicle location systems, improved fare collection systems, and the use of geographic information systems as an ana- lytical tool. One result has been improved timeliness and reliability (because it is drawn from a larger sample) of the ridership data, which in turn has encouraged agencies to rely on and make greater use of the data. The purpose of this synthesis is to document the state of the practice in terms of analytical tools and technologies for collecting transit ridership and other subsidiary data. Results of a web-based survey of a cross-section of transit agencies in North America document tools and technologies used to count passenger boardings and alightings. Survey results include transit agency assessments of the effective- ness and reliability of their methodologies and of desired improvements. The survey was designed to emphasize APC systems, but agencies using manual systems were also sur- veyed to gain an understanding of why new technologies have not been adopted. This report includes a review of the relevant literature in the field, concentrating on material published since TCRP Synthesis 29 in 1998. A final important element of this syn- thesis is the chapter documenting case studies, based on interviews with key personnel at selected agencies, to profile innovative and successful practices and to explore ongoing issues. Findings from all of these efforts are combined to summarize lessons learned, gaps in information and knowl- edge, and research needs.

8 FigURE 1 Map of Fta regions. orGaniZaTion oF The reporT Following this introductory chapter, chapter two summa- rizes the findings of the literature review. Chapter three, the first of two chapters to present the results of the survey, focuses on reasons that transit agencies collect ridership and travel time data and the means by which data are collected and analyzed. Chapter four discusses the responding agencies’ assess- ment of their APC systems. This chapter summarizes satis- faction with current methodologies, desired improvements, lessons learned, and advice for other transit agencies. Chapter five reports detailed findings from each of the six case studies. Agencies were selected for the case studies for different reasons. Some approaches can be characterized as “best practices,” and others highlight problems common to APC implementation. All show a thoughtful response to the issues posed in implementing APC systems. Chapter six summarizes the findings, presents conclu- sions from this synthesis project, and offers recommen- dations for further research. Findings from the surveys and particularly the case studies provide an assessment of strengths and weaknesses and likely future directions. Appendix A presents a copy of the survey as it appeared online. Appendix B provides survey results by question. Appendix C lists all transit agencies participating in the sur- vey. Appendix D summarizes APC implementation, includ- ing percentage of vehicles equipped with APCs, hardware supplier, software supplier, and procurement process, for each agency. Forty-five agencies responded to the broad-based invitation to participate in the survey, for an overall total of 86 transit agencies. These 86 agencies range in size from fewer than 10 to more than 2,000 buses. Table 1 presents the distribution of responding agencies by size. Exactly half of all responding agencies operate fewer than 250 vehicles in peak service. TABLE 1 TRANSIT AGENCIES BY SIZE Agencies Responding Vehicles Operated in Maxi- mum Service No. No. % Fewer than 250 43 50.0 250 to 999 32 37.2 1,000 or more 11 12.8 Total 86 100.0 Table 2 shows the distribution of responding agencies by FTA region. Regions IV, V, and IX led in terms of agencies responding. Figure 1 is a map of FTA regions. TABLE 2 TRANSIT AGENCIES BY FTA REGION Agencies Responding FTA Region No. % I 4 4.7 II 7 8.1 III 9 10.5 IV 11 12.8 V 17 19.8 VI 4 4.7 VII 1 1.2 VIII 2 2.3 IX 20 23.3 X 7 8.1 Canada 4 4.7 Total 86 100.0

9 GeneraL oVerVieW oF aUToMaTic passenGer coUnTers Several studies and articles have provided a sound overview of APC use and benefits. Baltes and Rey present results of a survey of North American transit systems related to APC usage, and summarize important issues for transit systems to consider (2). Rakebrandt summarizes the uses of APC data and reviews benefits and difficulties for transit systems (3). Jasmin and Vicente highlight the implementation of an intelligent transportation system (ITS) project at Metro in Los Angeles, noting that APCs allow service planners to use current data in making route and service decisions (4). hoW aUToMaTic passenGer coUnTer daTa are Used Furth et al. (5) has conducted extensive research into the uses of APC data. Furth was the primary author of a comprehen- sive TCRP study that offered guidance on five subjects: Analyses that use automatic vehicle location (AVL)–• APC data to improve management and performance; AVL–APC system design to facilitate the capture of • data with the accuracy and detail needed for offline data analysis; Data structures and analysis software for facilitating • analysis of AVL and APC data; Screening, parsing, and balancing automatic passenger • counts; and Use of APC systems for estimating passenger-miles for • National Transit Database (NTD) reporting. Appendices to this TCRP study addressed needs, cur- rent practice, and potential in relation to the use of archived AVL–APC data and noted organizational barriers to suc- cessful use (6). Furth et al. also examined critical factors in converting APC data into useful information (7). Several others have examined this subject, particularly in relation to performance monitoring. Hammerle et al. describe challenges faced by the Chicago Transit Authority in the use of APC and AVL data for service reliability indicators (8). Herrscher reports inTrodUcTion This chapter summarizes findings from a literature review related to transit ridership forecasting. A Transportation Research Information Services search was conducted to aid the literature review. The literature review focuses on studies completed since 1998, when TCRP Synthesis Report 29: Passenger Counting Technologies and Procedures was published (1). preVioUs sYnThesis TCRP Synthesis 29 summarized information from selected transit agencies about benefits and problems associated with various passenger counting technologies, as reported by cur- rent users. It also presented advice for agencies considering each technology. Conclusions included the following: Procedures are more important than technology.• Internal changes are necessary to ensure the success of • new passenger counting technologies. Visiting and learning from other agencies before • deciding on a new passenger counting technology are essential. Unnecessary customization should be avoided.• A strong commitment from senior management is • required. Active management of the passenger counting system • is critical to success. Responsibilities must be clarified.• Advanced passenger counting technologies offer • several benefits, including more frequent data col- lection, analysis of ridership at finer levels of detail, greater timeliness and responsiveness, and lower cost. However, these benefits do not accrue automatically. There is no one perfect solution.• TCRP Synthesis 29 encompassed manual (paper and pen- cil) as well as automated data collection techniques. In 1998, APC systems were still in the early adoption phase in the United States. APCs have become more commonplace since 1998, and this report focuses on new developments in auto- mated passenger counting within the transit industry. CHAPTER TWO LiTeraTUre reVieW

10 set (23) and the use of APC and AVL data to develop better performing models (24). daTa processinG As noted earlier, the ability to turn APC data into useful information is critical in realizing the benefits of APCs. Rucker provides examples of how APC data are processed for use in analyzing routes and schedules (25). Hammerle et al. describe methods developed at CTA to extract informa- tion for use in computing service reliability indicators (8). daTa inTeGraTion One of the challenges of new technologies, noted in the previous TCRP Synthesis 29, is the sometimes unexpected effects of their implementation on an agency’s data systems. Bolden et al. (26) reported that interfaces between bus-re- lated systems can be either unreliable or nonexistent, result- ing in difficulty in coordinating data. The authors also note that agencies’ business processes and procedures may not be designed to make optimal use of available data even when there is good technological integration (26). Use of database management and GIS tools to analyze APC and AVL data has been cited by researchers (13, 27) as a means to make more complete use of the data. Although stand-alone APC systems collect a significant amount of valuable data, integration with data from AVL systems and other ITS applications enhance the overall usefulness of the data (28). Procuring APCs as part of a broader ITS system can reduce the overall cost of APC installation (29). In a report on a survey of eight transit agencies deploying ITS technologies, Jeng suggests that the integration of these technologies presents a challenge that goes beyond the tech- nical realm. This paper also provides lessons learned in ITS deployment (30). Within the transit industry, TriMet is generally acknowl- edged as one of the leading agencies in the use of APC data. As noted earlier, several researchers have focused on TriMet as an important case study in evaluating the use of APC data in conjunction with data from AVL systems and other sources (11, 14–16, 31). iMpLeMenTaTion oF aUToMaTic passenGer coUnTinG sYsTeMs Marx and Bruun reported on a successful implementa- tion of APCs as part of a broader ITS implementation at the Potomac and Rappahannock Transportation Commis- sion (32). An interesting aspect of this report is that the benefits of advanced technologies do not accrue automati- on use of advanced technologies at the Orange County (Cali- fornia) Transportation Authority (9). Nokel and Schweiger describe the design and implementation of a monitoring system for passenger counts and delays and suggest impli- cations for future projects of this nature (10). Bertini and El-Geneidy are among many transit researchers to examine TriMet’s (Tri-County Metropolitan Transportation District of Oregon, Portland) innovative use of APC and AVL data to improve service quality and reliability (11). Not surprisingly, APC data are extremely useful in iden- tifying ridership impacts and passenger flows. Paliska and Kolene used APC and AVL data to evaluate the effects of unscheduled stops on ridership demand; any stop that was not associated with a known stop could be assumed to be unscheduled (12). Golani reports on the use of APC, AVL, and geographic information system (GIS) tools to define passenger flow on a bus route experiencing chronic delays (13). Strathman et al. analyzed the relationship between transit service headway deviations and passenger loads using TriMet’s AVL and APC archived data, and show that excess loads are systematically attributable to headway devi- ations (14). Kimpel et al. found that APC data can be used for internal reporting and annual NTD reporting if there is widespread deployment of APC technology (15). APC data have been useful in analyzing dwell time. Again using TriMet data, Dueker et al. report that passenger activity is an important determinant of dwell time (16). Rajb- handari et al. examine the impact of boarding and alighting passengers, the effect of standees, time of day, and service type on bus dwell time (17). An exhaustive examination of the state of the art with regard to advanced public transportation systems (APTS) deployment noted that optimizing the data processing and reporting capabilities associated with an APC system may take years (18). Persistence is needed to cleanse and filter the data, verify route and trip attributes, and correct or remove anomalous data. Sharing data across departments is often hindered by lack of data consistency, continuity, and com- pleteness. The report also notes state-of-the-art deployments that have overcome these issues. aUToMaTic passenGer coUnTinG daTa and ModeLinG The reliability and sheer volume of APC data have encour- aged researchers to use the data in modeling efforts. Several studies report on the use of APC data to develop a model to predict bus arrival times (19–21). Other researchers have used APC data to calibrate or validate travel models. One author notes that APC boarding data are far more reliable than data used to estimate the current set of boarding equa- tions (22). Others note the benefits of an enriched transit data

11 reLaTed TechnoLoGies Most APC units count passengers by means of infrared beams. Older units used treadle mats mounted to vehicle steps. Sun et al. proposed video technology, including multi-object recognition, image segmentation, and feature matching, to count boardings and alightings (35). Navick and Furth explored the use of location-stamped farebox data to estimate origin–destination patterns and loads under the assumption that boardings and alightings are symmetrical on the return trip in the opposite direction (36). This approach has been used by transit agencies in Chicago and New York to estimate origin–destination patterns from farecard data (37, 38). sUMMarY Awareness of and experience with APCs are clearly greater now than in 1998 when the previous synthesis on this topic was published. At that time, the transit industry was in the latter stages of early adoption of this new technology. APCs are in more widespread use now, but issues remain in the areas of data integration and implementation. A recent addition to the literature is a series of fact sheets related to transit technologies (39). These fact sheets sum- marize useful information on various technologies, includ- ing APCs. The next two chapters present the results of a survey of transit agencies regarding experiences with APCs. Survey results provide a snapshot of the state of the art as it exists today with regard to APCs. cally. At the Potomac and Rappahannock Transportation Commission, ITS efforts began in 1995, however full ITS functionality was achieved only in 2003 after the second procurement attempt. The report attributes success to more mature technologies; a turnkey project contract model; and refined, firm specifications based on both practical and academic experience. Schweiger notes that the process of ITS implementation benefits from a consensus among a variety of project stake- holders regarding uses and benefits of new technologies (33). The author describes the challenges associated with stakeholders’ input, from the selection of ITS components to the design of system functionality and from procurement to deployment. Monahan et al. (34) document the implementation of APCs in conjunction with the deployment of ITS technolo- gies at the Metropolitan Atlanta Rapid Transit Authority for the 1996 Olympic Games. The report summarizes the benefits of APCs and other ITS technologies and provides lessons learned (34). Many of the implementation-related lessons address how to overcome obstacles. Furth et al. note that one key to APC usefulness is the automatic, routine conversion of the APC data stream into a database of accurate counts (7). In the CTA’s experience, typical of many transit agencies, opera- tional challenges included bus assignments (ensuring that an APC-equipped bus went out on the correct assignment), bus stop inventory (maintaining an up-to-date list with all stops accounted for), and undercounting on crowded trips (8).

12 CHAPTER THREE ridership and TraVeL TiMe daTa coLLecTion and anaLYsis inTrodUcTion This is the first of two chapters presenting the results of a survey of transit agencies regarding passenger counting technologies. The survey was designed to elicit information on automated technologies. At the time of the last synthe- sis, manual data collection was the most common means of gathering information on ridership. Over the past 10 years, use of APC systems has become more common. Manual passenger counting was well documented in the previous synthesis; therefore, this synthesis focuses on the state of the practice for nonmanual passenger counting systems, particularly APCs. Forty-one completed surveys were received from the 56 transit agencies approved by the panel for inclusion in the sample, a response rate of 73%. In addition, 45 agencies responded to an invitation to all APTA members to partici- pate in the survey, for a total of 86 transit agencies. These agencies range in size from fewer than 10 to more than 2,000 buses. This chapter analyzes survey results related to the reasons that transit agencies collect ridership and travel time data and the means by which data are collected and analyzed. The introduction of new technologies such as APCs changes data processing and reporting requirements; these are analyzed in this chapter as well. Technological changes can also have organizational impacts, and these are also explored. Chapter four discusses survey results related to the responding agencies’ assessment of APCs. WhY coLLecT ridership and TraVeL TiMe daTa There are many reasons to collect ridership data. At the sys- tem level, ridership is an important measure of success for a transit agency. Federal and state funding agencies require ridership reports. At the route level, ridership provides a general indication of the level of demand. More detailed ridership data are used by service planners and schedulers to analyze performance and make changes to routes down to the trip and stop level so that service provided matches demand. Time-related data, often collected in conjunction with ridership data, are used to monitor running times and schedule adherence. Manual collection of ridership data is time-intensive and expensive, and typically would result in data for only a few days. An atypical event (increased congestion owing to a traffic accident or unusual weather) could skew the data. Use of automatic passenger counter (APC) systems creates a much richer database, with multiple observations for each trip. Issues regarding accuracy and analytical techniques are discussed later. Table 3 summarizes survey responses regarding reasons for collecting data. The most common reason is compiling ridership by route, followed by tracking systemwide rider- ship totals. A majority of all respondents also collect data on ridership for more specific microlevel uses at the route seg- ment or stop level. National Transit Database (NTD) report- ing was the most common response in the “other” category and is reported separately in Table 3. The percentages in Table 3 do not add up to 100% because multiple responses were acceptable. Any table in this report in which the sum of the percentages is greater than 100% reflects a survey question where multiple responses were allowed. TABLE 3 PURPOSES FOR COLLECTION OF RIDERSHIP AND TRAVEL TIME DATA Agencies Responding Purpose No. % Compile ridership by route 83 96.5 Track systemwide ridership totals 76 88.4 Compile boardings/alightings by stop 68 79.1 Monitor passenger loads at the maxi- mum load point 64 74.4 Monitor schedule adherence and run- ning times 56 65.1 Other 25 29.1 Total responding 86 100.0

13 combinations (28 of the 44 combinations reported in Table 5) and including the number of agencies using only one means, also noted in Table 5. The top circle represents agen- cies using manual techniques, the bottom left agencies using APCs, and the bottom right agencies using fareboxes. The most common combinations involve APC plus manual (12) and farebox plus manual (8). TABLE 5 MEANS OF RIDERSHIP DATA COLLECTION Agencies Responding Means No. % Combination of automated and manual methods 44 51.2 Manual (paper and pencil) only 18 20.9 APCs only 12 14.0 Other automated methods (registering fareboxes, handheld units) only 12 14.0 Total responding 86 100.0 TABLE 6 MEANS OF RIDERSHIP DATA COLLECTION BY AGENCY SIZE No. of Agencies Technology Total Large Medium Small Combination of automated and man- ual methods 44 6 23 15 Manual (paper and pencil) only 18 2 2 14 APCs only 12 1 5 6 Other automated methods (registering fareboxes, handheld units) only 12 2 2 8 Total responding 86 11 32 43 The variety of combinations in Figure 2 provides insight into the process of integrating new technologies into exist- ing systems. In some cases, an older technology is retained to test the validity of the new technology. Agencies also retain older technologies for specific purposes, for example: NTD reporting or “official” systemwide ridership data col- lected through registering fareboxes. Several agencies noted problems with the accuracy or reliability of APC counts and thus have not transitioned to use of the new technology. Methods may also vary by mode, type of service, and type of vehicle. Table 4 indicates how agencies use ridership and travel time data. Tracking ridership changes, calculating perfor- mance measures, and adjusting schedules were the three most common uses, each reported by more than 85% of all respondents. TABLE 4 AGENCY USE OF RIDERSHIP AND TRAVEL TIME DATA Agencies Responding Use No. % Assess changes in ridership 80 93.0 Calculate performance measures 77 89.5 Adjust schedules (add/ delete trips, change headways) 75 87.2 Compile NTD reports 71 82.6 Revise routings 69 80.2 Determine locations for bus shelters and other facilities 63 73.3 Adjust running times/select or change timepoints 62 72.1 Other 8 9.3 Total responding 86 100.0 Means oF coLLecTinG ridership daTa Table 5 addresses how agencies collect ridership data. A majority of respondents reported a combination of auto- mated and manual methods. Twenty-one percent use man- ual methods only. Fourteen percent use APCs only, and 14% rely solely on some other automated means (fareboxes, turn- stiles, and preprogrammed personal data assistants or other handheld data collection units). Table 6 presents means of data collection by system size. A majority of respondents reported a combination of auto- mated and manual methods. Smaller systems account for half of all agencies in the sample and are more likely to col- lect data manually or with some other automated method. Medium systems account for 37% of all agencies in the sample, and are much more likely to collect data by means of a combination of automated and manual methods. Large systems account for 13% of all agencies in the sample and use the various technologies in roughly the same proportion as all respondents. Agencies using a combination of methods are of par- ticular interest because these constitute a majority of all respondents. Figure 2 is a Venn diagram indicating the major

14 tion, see Appendix D.) Only one agency reported the use of treadle mats, whereas APC installations were split between infrared beam and treadle mat in the 1998 synthesis. Another difference is the universal inclusion of a global positioning system (GPS) element in the APC system. In the 1998 synthesis, by contrast, almost half of the APC systems were signpost-based. Interestingly, the majority of agencies with both APC and automated vehicle location (AVL) pri- marily use AVL time and location data. In many cases, the reason is that AVL is on all buses, whereas only a portion is equipped with APCs. Almost half of all respondents indicated that their APC purchase was part of a broader ITS project. Among the “other” responses in Table 8 are differences by mode and stand-alone systems that have subsequently been (or will be) integrated with other ITS components. TABLE 8 APC PURCHASE: STAND-ALONE OR PART OF A BROADER ITS PROJECT Agencies Responding Category No. % Part of a broader ITS project 24 49.0 Stand-alone 16 32.7 Unsure 1 2.0 Other 8 16.3 Total responding 49 100.0 More than 80% of survey respondents noted that APC equipment was used only on buses. Four agencies use APCs on their light rail systems, three others are planning or beginning to implement APC on light rail, and one agency has installed APC on a heavy rail system. Table 9 indicates the percentage of the agencies’ bus fleets equipped with APC. It is still the rule rather than the excep- tion to install APCs on only a portion of the bus fleet and then rotate the APC buses among the various routes. How- ever, more than one-quarter of responding agencies have installed APCs on all buses. Universal installation is more common as APC costs have come down, especially when APCs are part of a broader ITS purchase. Nine of the 12 agencies that are 100% APC-equipped bought APCs as part of a broader ITS purchase. As many transit agencies have found, the planning and operations departments must work closely together on bus assignments when only some buses are APC-equipped. Introduction of APCs has resulted in changes in how buses are assigned. A typical arrangement is that service planners Manual Farebox APC 18 12 12 12 4 8 4 FigURE 2 Combinations of automated and manual data collection techniques. Agencies that continue to collect ridership data manually were asked for reasons why they have not switched to an automated technology. As Table 7 shows, cost is the most common reason, followed by low priority for automated data collection at the agency. TABLE 7 REASONS FOR NOT SWITCHING FROM MANUAL TO AUTOMATED DATA COLLECTION Agencies Responding Reason No. % Cost 10 71.4 Low priority at agency 6 42.9 Awaiting broader ITS purchase 4 28.6 Satisfied with manual data collection 4 28.6 Planning to change, but have not yet 4 28.6 Other 4 28.6 Total responding 14 100.0 Use oF aUToMaTic passenGer coUnTers aT TransiT aGencies Given the inroads that APCs have made in the transit indus- try among agencies of all sizes, the remaining questions in the survey focused on APC installation and use of APC data. This section discusses types of equipment and percentage of fleet equipped with APCs. The question of manufacturer was simpler to answer before integrated ITSs came on line. (For further informa-

15 connection and real-time dynamic or periodic remote retrieval of APC data are the most common methods. Some agencies in the “other” category use a combination of methods or use different methods by mode. TABLE 10 MEANS OF APC DATA RETRIEVAL Agencies Responding Means of Retrieval No. % At garage without a physical connection 23 48.9 Real-time dynamic or periodic remote retrieval 13 27.7 Direct download (probe) of APCs with a physical connection 4 8.5 Other 7 14.9 Total responding 47 100.0 An important step in APC implementation is to ensure that the data meet the specified level of accuracy. Most respon- dents reported a threshold for acceptance of the APCs at the 90% or 95% level of accuracy. Some were more specific, for example, with a confidence level of 90% that the observations were within 10% of actual boardings and alightings. A few agencies were even more specific: Total boardings and alightings for a trip: maximum error of 10% for load along a trip and maximum error of 10% on no more than 10% of observations. Passenger load accuracy should be +/- 5% at each stop and in 95% overall concurrence with manual passenger counts. The system is to identify the correct stop location 95% of the time with 100% of APC-generated stops being within +/- 1% of manually observed stops. Stop-by-stop: for 85% of stops the ON or OFF count shall be correct; within +/- 1 person 90% of the time; and within +/- 2 persons 97% of the time. Overall, total Ons and Offs within +/- 5%. For stops with 1–5 boardings, the APC count was to have an absolute error of 0 in 80% of the cases, of 1 in 90% of the cases, and of 2 in 95% of the cases. For stops with 6–10 boardings, the APC count was to have an absolute error of 0 in 50% of the cases, of 1 in 75% of the cases, and of 2 in 90% of the cases. For stops with 11 or more boardings, the absolute error was to within 10% in at least 90% of the cases. Almost three-quarters of respondents (71%) indicated that they use their accuracy requirements on an ongoing basis. An FTA report notes passenger count accuracy in the 2% to 3% error range using APCs (18). An important question regarding data accuracy is, Com- pared to what? Manual counts are typically used as the basis of comparison, as noted in the preceding examples, although or schedulers prepare a weekly list of blocks to be sampled and transmit the list to the operations department. TABLE 9 PERCENTAGE OF BUS FLEET EqUIPPED WITH APCS Agencies Responding Percentage Range No. % 100 12 26.7 50 to 99 5 11.1 20 to 49 11 24.4 10 to 19 11 24.4 1 to 9 6 13.3 Total responding 45 100.0 Some agencies have automated the assignment process using APC system software to identify blocks for which no APC data have been collected. One agency noted that the operations department assigns APC buses randomly for the first half of a pick, and the software takes over this function for the second half to ensure that all blocks are sampled. However, only 16% of respondents reported use of an auto- mated assignment process. On average, 80% of daily APC assignments are com- pleted as scheduled. This percentage varies from 40% to 100% among respondents. Anecdotal evidence suggests that the percentage of successfully completed APC assign- ments increases over time, as departments adjust to the new procedures. The number of times each trip is surveyed in a given time frame varies with the percentage of APC-equipped buses. Clearly, APCs provide a richer ridership and travel time database at a finer level of detail than farebox or man- ual counts, even for agencies with only a few APCs. The increased number of observations lends greater confidence to decisions regarding changes in service levels. Being rich in data provides clear benefits but can cre- ate its own challenges. How agencies process and manage the increased amount of ridership data is addressed in the next section. aUToMaTic passenGer coUnTinG daTa: processinG, VaLidaTinG, and reporTinG This section examines survey responses related to APC data processing, validation, and reports. The first step in data pro- cessing is to transfer the data from the APC unit. Table 10 indicates that data retrieval at the garage without a physical

16 TABLE 12 EXAMPLES OF AUTOMATED VALIDATION PROGRAM RULES Test Threshold Action Boardings vs. alightings by block or by trip 5% 10% 20% 30% Discard block or trip data if exceed threshold Loads Less than 0 Adjust boardings/ alightings at heavi- est use stops Bus stop location within 200 feet of actual bus stop Flag stop data if exceed threshold Actual vs. scheduled block miles/kilometers 10% Discard data exceed threshold Actual vs. scheduled block pullout/pull-in times 30 minutes Actual vs. scheduled trip start/end times 20 minutes “significantly off-schedule” Observed vs. “expected” results at the route, block, trip, and stop levels Not specified Assign quality code to data Geographic information vs. computerized sched- uling software data Look for match Assign probable route/block Block data No data Discard block data If the ratio of ons/offs for a bus-date-block is less than 1. 0.7 or greater than 1.3, then data for all trips operated by that bus-date-block are declared invalid. If 0 ons and 0 offs are counted for a complete bus-2. date-block, then the data is declared invalid. Multiple measurements for the same stop (when a bus 3. opens its doors more than once at a stop, for example) are aggregated into a single record. Data for trips measured by more than one bus on a 4. single day (e.g., when an APC bus is traded off with another APC bus) are merged. At route terminals at which layovers occur, all offs 5. measured for the arriving trip and for the departing trip are assigned to the last stop of the arriving trip. All ons measured for the arriving trip and depart- ing trip are assigned to the first stop of the departing trip. APC vendors and some users note correctly that manual counts are not 100% accurate. Table 11 reveals that com- parison to manual counts is the most common technique to edit and validate APC data. However, agencies use a variety of methods to edit and validate data. Many validation tech- niques look for internal inconsistencies without reference to another data source to use as a comparison. TABLE 11 METHODS TO EDIT AND VALIDATE APC RIDERSHIP DATA Agencies Responding Method Purpose No % Compare with manual counts Accuracy 32 69.6 Look for unexplained variance across trips Validation 27 58.7 Compare ridership totals across days for reasonableness Validation 25 54.3 Rely on professional judgment of planners and schedulers Validation 24 52.2 Use an automated program to analyze APC data Validation 24 52.2 Compare ridership and revenue totals Accuracy 18 39.1 Compare on/off totals by trip and adjust as needed Validation 14 30.4 Other Varies 7 15.2 Total responding 46 100.0 Automated data validation programs can make life much simpler for data analysts. These programs are provided by the APC vendor, developed in-house, or purchased from a third party. Agencies using third-party programs noted that they feature up to 36 validation routines with adjustable thresholds. Vendor software is not always transparent to the user, and it is important to understand how the validation checks work. The most common test is to compare boardings and alightings. As Table 12 shows, agencies reported vari- ous thresholds for determining validity at the block or trip level. The table shows reported examples of validation tests, thresholds, and actions. The following annotated version of one of the more detailed descriptions of APC data editing and validation in the survey is presented as an example: The data collected by the APC buses and then matched to the stop/schedule data is stored in a DB2 database. We use a [Statistical Analysis System] SAS program to process this data, screen out “bad” data, and store the validated data in SAS datasets. The following tests are used to screen out “bad” data:

17 software packages and APC or AVL systems. Only one- quarter of all respondents indicated no changes to existing data systems. For data storage and analysis, the most common changes were the addition of servers for data storage and new database software for analysis. Software development is discussed in greater detail later. More than 85% of respondents indicated that they archive APC data. The average and median length of time to keep APC data is 5 years, although four agencies indicate that they plan to keep archived data forever. Table 13 describes type and frequency of routine APC reports. The most common type of report is boardings and alightings by stop, but all types of reports are generated by a majority of agencies that use APCs. Detailed (segment/ stop level) ridership and scheduling-related reports are most likely to be generated as needed. Table 14 indicates a variety of sources for data processing and report generation software. A majority of agencies rely on the hardware vendor, but several indicated in-house soft- ware development, and it was not uncommon for agencies to use an outside vendor other than the hardware vendor. More than 70% of agencies that used an outside vendor indicated that the process involved customization of the software to meet the agency’s specific needs. More than 90% of responding agencies indicated a capa- bility to generate nonstandardized reports from the APC system. The most common method was for the end users to generate these reports, but one-quarter of agencies with this capability rely on the outside vendor for specialized report generation. Leaving loads are calculated for each stop. Special 6. rules are used for open loop routes where passengers ride through a terminal. Trip samples that have a mismatch between date and 7. schedule type (as a result of stop matching errors) are eliminated from the database. This happens rarely, mainly for the first day of a booking that happens on the same day that a switch between standard time and daylight saving time occurs. Trip samples that have large imbalances between total 8. ons and offs are eliminated from the database. Some agencies use APC data for NTD purposes. FTA requires manual checks annually to validate APC data for NTD submittal. The concept of manual validation of APC data as a one-time or periodic (every 3 years, for example) exercise is of interest to agencies as they become more con- fident in the accuracy of APC data. The survey included a question on the percentage of raw APC data that is converted into useful information for ser- vice planners, schedulers, and others. The overall average is 74%, comparable to findings from 10 years ago, with a median value of 80%. Processing APC data often requires changes to exist- ing data systems. The majority of respondents reported the need to identify GPS coordinates for stops and to create or maintain a bus stop inventory. Several agencies had already done this for implementation of AVL or automated passen- ger announcements. A few agencies noted the establishment of defined interfaces between computerized scheduling TABLE 13 TYPES OF REPORTS ROUTINELY GENERATED FROM APC DATA Type No. Agencies Responding Frequency of Reports (percentage of agencies responding) Annually quarterly Monthly Weekly Daily As Needed Stop-level boardings and alightings 41 2 15 10 2 10 61 Route-level ridership 38 5 26 16 3 18 32 Route segment ridership 38 11 11 5 3 8 63 System ridership 33 9 15 27 — 21 27 Performance measures 33 6 27 12 3 12 39 Schedule adherence 32 — 16 13 — 16 56 Running times 31 — 13 3 3 13 68 Total responding 42 7 15.2 100

18 Interaction among data users, impacts on staffing levels and needs, and cost are all considered here. It should be noted, however, that costs reported by transit agencies var- ied depending on methods and assumptions used. In par- ticular, it was difficult for agencies that purchased APCs as part of a broader ITS procurement to separate out the costs involved. The reader is cautioned that cost data are neither uniform nor complete. Table 16 summarizes departmental involvement in man- agement, purchasing, and use of APC systems. The planning department is the most common location for management of the APC system, followed by the operations department. The “other” responses related to management represent agen- cies where this responsibility is split among departments: planning and maintenance; maintenance and information technology (IT); operations, maintenance, and IT; planning and IT. Table 16 also shows widespread involvement across departments in procurement of the APC system and use of the APC data. Only one agency reported no downstream users of APC data. In terms of data users, more than 80% of responding agencies reported electronic access to APC data through standard reports. Half of agencies indicated that hard copies of APC reports were available to data users, and 41% noted that data users could query the database directly. TABLE 16 DEPARTMENTS INVOLVED IN AGENCY PURCHASE, MANAGEMENT, AND USE OF APC SYSTEMS Department % Involved in APC Purchasing Decision % Primary Ownership of APC Management and Operation % User of APC Data Planning 90 42 91 Operations 62 20 73 Information ser- vices/computer services 67 16 14 Scheduling 57 7 82 Budget/finance 52 2 34 Maintenance 43 2 14 Marketing/market research 24 0 59 Senior management N/A N/A 52 Other 7 9 9 Total responding/ percentage 42/100 44/100 44/100 N/A = not available. TABLE 14 DEVELOPMENT OF DATA PROCESSING AND REPORTING SOFTWARE Agencies Responding Source No. % Hardware vendor 26 55.3 In-house, by end users of data 16 34.0 In-house, by information sys- tems or computer services department 13 27.7 Another outside vendor 12 25.5 Other 3 6.3 Total responding 47 100.0 Anyone who has been through the process of implement- ing a new technology knows that there is a “debugging” period, during which start-up problems are resolved. The debugging period for APCs averages 17 months, identi- cal to the finding of the 1998 synthesis, with a median of 18 months. There was a wide variation in responses to the debugging question, from 1 month to 5 years. Table 15 groups the responses by time frame. There were no signifi- cant differences by system size. Respondents involved on a day-to-day basis with APCs may have been more aware of problems and issues than others. TABLE 15 LENGTH OF “DEBUGGING” PERIOD FOR APC IMPLEMENTATION Agencies Responding Time Frame No. % Less than 6 months 3 9.7 6 to 11 months 4 12.9 12 to 23 months 8 25.8 24 months or more 6 19.4 Ongoing 10 32.3 Total responding 31 100.0 orGaniZaTion and resoUrce reQUireMenTs Organizational issues can affect the success of new tech- nologies. Implementation of APCs and other ITS technolo- gies fosters or requires integration and cooperation among departments that may have previously managed their data in isolation. This section explores organizational aspects of the purchase, management, and use of APC systems.

19 The most frequently mentioned challenges to successful implementation and operation included problems ensur- ing that bus assignments were completed, new demands for reports, priority for APC equipment in the maintenance department, and unrealistic expectations regarding turn- around time and data quality. One respondent characterized maintenance personnel’s attitude as very negative: APCs drain power from the bus batteries and take technicians’ time away from important work. Among other negative effects were concerns from opera- tors and the union, tensions regarding data accuracy and pro- cesses for addressing missing data, frustrations regarding start-up problems, APC system vulnerability to communi- cations problems, lack of commitment from all departments regarding maintenance of the data collection process, and unmet training needs. Staffing levels for the passenger counting program are summarized in Table 18. Smaller systems were more likely to assign fewer people in each category. The survey also asked about changes in staffing associated with an APC program. More than 70% of all agencies reported no changes or decreases in staff levels in each of the catego- ries in Table 18, with notable decreases in the size of traffic checking units. About one-quarter of respondents, none from small systems, indicated a minor increase (defined as one or two full-time positions) in maintenance staff, and 22% (consistent across systems of all sizes) reported a minor increase in professional staff. Implementation of APCs does create a need for training. A majority of respondents noted increased training needs in the areas of software/computer, analytical, and hardware maintenance skills (Table 19). Only 24% of responding agencies reported no additional training needs. Implementation of APCs necessarily involves multiple departments within the transit agency. Table 17 reports on the impacts of APC use on the transit agency. The most positive aspects of APC implementation included improved communication among departments, greater value placed on ridership data, improved decision-making ability, greater responsiveness, and the ability to provide the needed data to end users. Among other positive effects were better rela- tions with external agencies and management’s reaction to better reporting. TABLE 17 EFFECTS OF INTERACTION AMONG MULTIPLE APC USERS Agencies Responding Effects No. % POSITIVE Improved communications between departments 7 20.6 Greater value placed on ridership data 7 20.6 Better data leading to improved deci- sion-making ability 5 14.7 Greater responsiveness to public/others 3 8.8 Ability to provide data to end users 3 8.8 NEGATIVE Difficulty with bus assignments 7 20.6 Constant/increased demands for new or reformatted reports 5 14.7 APC maintenance has low priority 4 11.8 Unrealistic expectations re: turnaround time and data quality (i.e., not perfect) 4 11.8 Total responding 34 100.0 TABLE 18 STAFF POSITIONS (FULL-TIME EqUIVALENTS) ASSIGNED TO CARRY OUT PASSENGER COUNTING PROGRAM Category Less than 1 1 to 1.9 2 to 3.9 4 or more Don’t Know Total No. Responding Managers/professionals 47.7% 29.5% 20.5% 2.3% — 44 Support (e.g., equipment maintenance 54.1% 27.0% 13.5% 5.4% — 37 Clerical 72.0% 20.0% — — 8.0% 25 Traffic checkers 44.4% 11.1% 7.4% 29.6% 7.4% 27 Other 42.9% — 14.3% 42.9% — 7 NOTE: “Other” includes data retrieval, data editing/analysis/report writing, and ad hoc traffic checking personnel.

20 sUMMarY The most common reasons to collect ridership and travel time data are to compile ridership by route and to track sys- temwide ridership totals. A majority of all respondents also collect data on ridership and travel time for more specific microlevel uses at the route segment or stop level. Tracking ridership changes, calculating performance measures, and adjusting schedules were the three most common uses of rid- ership and travel time data. A majority of respondents use a combination of automated and manual methods to collect ridership and travel time data. The most common combinations involve automatic passen- ger counter (APC) system plus manual data collection and farebox plus manual collection. In some cases, an older tech- nology is retained to test the validity of the new technology. Agencies also retain older technologies for specific purposes, for example, National Transit Database (NTD) reporting or “official” systemwide ridership data. Several agencies noted problems with the accuracy or reliability of APC counts, and thus have not transitioned to use of the new technology. Meth- ods also vary by mode, type of service, and type of vehicle. Agencies that continue to collect data manually were asked why they have not switched to an automated technol- ogy. Cost is the most common reason, followed by low pri- ority for automated data collection at the agency. Smaller systems (fewer than 250 peak buses) are more likely to con- tinue to rely on manual data collection. Nearly all agencies with APC systems use infrared beams, whereas APC installations split between infrared beam and treadle mat in the 1998 TCRP synthesis. Another difference is the universal inclusion of a GPS element in the APC sys- tem. Almost half of all respondents indicated that their APC purchase was part of a broader ITS project. Only a portion of most agencies’ buses are APC- equipped; however, more than one-quarter of responding agencies have installed APCs on all buses. Nine of the 12 agencies that are 100% APC-equipped bought APCs as part of a broader ITS purchase. The majority of agencies with both APC and automated vehicle location (AVL) primarily use AVL time and location data, typically because AVL is on all buses, whereas only a portion of the fleet is equipped with APCs. Introduction of APCs usually requires a closer working relationship between the planning and operations depart- ments. Typically, service planners or schedulers prepare a weekly list of blocks to be sampled and transmit the list to the operations department. Some agencies have automated the assignment process using APC system software to iden- tify blocks for which no APC data have been collected. On TABLE 19 TRAINING NEEDS ASSOCIATED WITH APC IMPLEMENTATION Agencies Responding Skill No. % Software/computer 29 69.0 Analytical 23 54.8 Hardware maintenance 23 54.8 Other 5 11.9 No training needs 10 23.8 As noted earlier in this section, cost data from the survey should be interpreted cautiously. Respondents varied in their ability to break down cost data (especially for older systems or for APC systems purchased as part of a larger ITS pro- curement). As one example, reported capital costs for the agency’s APC system ranged from $90,000 to $40,000,000. An attempt was made to standardize costs by asking the cost per APC unit installed. The average capital cost per APC unit was $7,500. The median capital cost per APC unit was $6,638, with 26 agencies responding. Table 20 shows median capital cost and median capital cost per APC unit by number of vehicles with APCs. FTA’s Transit Technology Fact Sheets (39) report a median cost of $350,000 for an APC system, compared with the median in this sample of $490,000. Average annual operating and maintenance cost per APC unit was $1,458. The median annual operating and maintenance cost per APC unit was $600, with 11 agencies responding. TABLE 20 APC MEDIAN CAPITAL COST AND MEDIAN CAPITAL COST PER UNIT BY NUMBER OF VEHICLES EqUIPPED No. of Vehicles with APCs Median Capital Cost ($) Median Capital Cost per APC Unit Installed ($) No. Systems Less than 100 200,000 7,500 13 100 to 400 500,000 2,700 7 Over 400 1,800,000 1,100 3 Total sample 490,000 6,638 26 NOTES: Three systems reported total cost only; three systems reported unit cost only. All three systems in the over-400 category had at least 1,450 vehicles with APCs.

21 system. The most common method was for the end users to generate these reports, however one-quarter of the agencies with this capability rely on the outside vendor for specialized report generation. Some agencies use APC data for NTD purposes. FTA requires manual checks annually to validate APC data for NTD submittal. The concept of manual validation of APC data as a one-time or periodic exercise is of interest to agen- cies as they gain confidence in the accuracy of APC data. Anyone who has been through the process of implement- ing a new technology knows that there is a “debugging” period, during which start-up problems are resolved. The debugging period for APCs averages 17 months, identi- cal to the finding of the 1998 synthesis, with a median of 18 months. Implementation of APCs and other ITS technologies fosters or requires integration and cooperation among departments that may have previously managed their data in isolation. The planning department is the most common location for management of the APC system, followed by the operations department. There is widespread involve- ment across departments in procurement of the APC sys- tem and use of the APC data. Data users typically access APC data electronically through standard reports, and 41% of agencies noted that data users could query the database directly. Implementation of APCs necessarily involves multiple departments within the transit agency. The most positive aspects of APC implementation included improved com- munication among departments, greater value placed on ridership data, improved decision-making ability, greater responsiveness, and the ability to provide the needed data to end users. The most frequently mentioned difficulties included problems ensuring that assignments were com- pleted, new demands for reports, priority for APC equipment in the maintenance department, and unrealistic expectations regarding turnaround time and data quality. Changes in staffing levels as a result of APC imple- mentation were minimal in most cases: More than 70% of all agencies reported no changes or decreases in staff levels, with notable decreases in the size of traffic check- ing units. About one-quarter of respondents indicated a minor increase (defined as one or two full-time positions) in maintenance staff, and 22% reported a minor increase in professional staff. Implementation of APCs does create a need for training. A majority of respondents noted increased training needs in the areas of software/computer, analytical, and hardware skills. Only one-quarter of responding agencies reported no additional training needs. average, 80% of daily APC assignments are completed as scheduled. Most respondents reported a standard for acceptance of the APCs at the 90% or 95% level of accuracy. Almost three- quarters of respondents indicated that they use these stan- dards on an ongoing basis. An important question regarding data accuracy is, Compared to what? Manual counts are typically used as the basis of comparison. APCs provide a richer ridership and travel time database at a finer level of detail than farebox or manual counts, even for agencies with only a few APCs. The increased number of observations lends greater confidence to decisions regarding changes in service levels. Being rich in data provides clear benefits but can create its own challenges. Processing APC data often requires changes to existing data systems, such as addition of GPS coordinates for stops and an updated or new bus stop inventory. A few agencies noted the establishment of defined interfaces between computerized scheduling soft- ware packages and APC or AVL systems. For data storage and analysis, the most common changes were the addition of servers for data storage, new database software for analysis, and network upgrades. Automated data validation programs, provided by the APC vendor, developed in-house, or purchased from a third party, can simplify and streamline the process of convert- ing raw APC data into usable ridership data. Agencies using third-party programs noted that they feature up to 36 vali- dation routines with adjustable thresholds. Vendor software is not always transparent to the user, and it is important to understand how the validation checks work. The most com- mon validation test is to compare boardings and alightings. Agencies reported various thresholds for determining valid- ity at the block or trip level. The percentage of raw APC data that is converted into useful information for service planners, schedulers, and oth- ers averages 74%, comparable to findings from 10 years ago, with a median value of 80%. A majority of agencies rely on the hardware vendor for data processing and report generation software, but several indicated in-house software development or use of an out- side vendor other than the hardware vendor. More than 70% of agencies that used an outside vendor indicated that the process involved customization of the software to meet the agency’s specific needs. The most common type of report is boardings and alightings by stop. Detailed (segment/stop level) ridership and scheduling-related reports are most likely to be generated as needed, suggesting that the report process for these types of reports may not be automated. More than 90% of responding agencies indicated a capa- bility to generate nonstandardized reports from the APC

22 was $7,500. The median capital cost per APC unit was $6,638, with 26 agencies responding. Average annual oper- ating and maintenance cost per APC unit was $1,458. The median annual operating and maintenance cost per APC unit was $600, with 11 agencies responding. Cost data from the survey should be interpreted cau- tiously, as respondents varied in their ability to break down cost data (especially for older systems or for APC systems purchased as part of a larger ITS procurement). An attempt was made to standardize cost data by asking the cost per APC unit installed. The average capital cost per APC unit

23 CHAPTER FOUR aGencY assessMenT oF aUToMaTic passenGer coUnTer sYsTeMs and trip), improved quality of the data, and the availability of running time data for schedule adjustments. TABLE 22 PRIMARY BENEFITS OF APCS Agencies Responding Benefit No. % Finer level of detail (stop/segment/ trip) 14 36.8 quality of data 11 28.9 Running time data to adjust schedules 10 26.3 Better basis for decision making 6 15.8 quantity of data 6 15.8 Timeliness of data 5 13.2 Total responding 38 100.0 Table 23 summarizes problems with the APC system, also representing responses to an open-ended question. The most frequently cited problems involved reporting, data pro- cessing, data validation, and hardware. One-quarter of all respondents reported either no problems or the usual start-up issues. There were no differences in problems encountered by system size or type of purchase (stand-alone vs. part of a larger ITS procurement). TABLE 23 PROBLEMS ENCOUNTERED WITH THE APC SYSTEM Agencies Responding Problem No. % None/usual start-up issues 10 25.6 Reports/reporting software 5 12.8 Data processing and analysis 4 10.3 Data validation 4 10.3 Hardware problems 4 10.3 Total responding 39 100.0 inTrodUcTion This is the second of two chapters presenting the results of a survey of transit agencies regarding passenger counting. The previous chapter addressed the “nuts and bolts” of how agen- cies count passengers. This chapter’s focus is on agencies’ evaluations of automatic passenger counter (APC) systems. Specific topics include agency satisfaction with current methods, potential improvements, and lessons learned. saTisFacTion WiTh aUToMaTic passenGer coUnTer sYsTeMs Table 21 shows transit agency satisfaction with the perfor- mance of its APC system in terms of counting passengers. Most respondents are either very satisfied or somewhat satisfied with the performance of their APC system. Inter- estingly, 93% of agencies purchasing a stand-alone system were either very or somewhat satisfied, compared with 74% of agencies purchasing APCs as part of a larger ITS procure- ment. More than half of all stand-alone agencies were very satisfied, compared with 16% of agencies involved in a larger procurement. TABLE 21 AGENCY SATISFACTION WITH APC SYSTEM PERFORMANCE IN TERMS OF COUNTING PASSENGERS Agencies Responding Level of Satisfaction No. % Very satisfied 16 40.0 Somewhat satisfied 18 45.0 Somewhat dissatisfied 2 5.0 Very dissatisfied 4 10.0 Total responding 40 100.0 Table 22 presents the primary benefits of APC for the agency. These represent responses to an open-ended ques- tion. The most frequently cited benefits included availability of data at a much finer level of detail (e.g., stop, segment,

24 TABLE 25 LESSONS LEARNED FROM SURVEY RESPONSES Agencies Responding Category No. % Data processing/use/reporting 14 41.2 Purchase/implementation 9 26.5 Data validation 7 20.6 Maintenance 7 20.6 Staff/resource needs 5 14.7 Time frame 5 14.7 Testing 5 14.7 Experience of peers 4 11.8 Training 4 11.8 Other: procedures 6 17.6 Other: staff/management 3 20.6 Other: APC system inputs 2 17.6 Total responding 34 100.0 Survey Responses: Data Processing, Use, and Reporting Pay attention to post-processing capabilities.• Concentrate on the soft side of the system—this is • where success is really achieved. Listen to and tailor reports for system users (planners, • schedulers, management). Ensure that staff monitors the system and understands • how to use the data. Ensure that staff is capable and comfortable analyzing • and using APC data. Find out how valuable the canned reporting software • is, and be prepared to buy a good program and hire or use people in your agency to develop a program. Be sure that the system purchased has good report-• ing capabilities and can balance loads in a statistically valid manner. Purchase reporting and analysis software on the front end.• Develop report generation software internally if the • agency has staff with the right skill sets; having an internal capability to modify or generate new report is very beneficial. Ensure that the software program provides required • analysis. Think long-term, and ensure that data structures can • be integrated with downstream applications. Be sure that the system purchased has good software • with diagnostic capabilities. Respondents were asked, “If you could go back in time and change ONLY ONE aspect in the process of purchasing, installing, and using your APC system and associated meth- odology, what would you change?” Table 24 summarizes the results. Improvements related to the procurement process and contract elements were most frequently mentioned. These included stricter contractual requirements (regarding accu- racy, timely support, availability of spare parts, and time- lines), purchase of a complete system through a single vendor, avoidance of purchase through a consortium, and changes to internal procedures. Additional APCs and differences in approach also ranked highly. “Approach” is a catch-all category that includes being more informed about hardware and software choices, involv- ing maintenance personnel at the start of the process, dedi- cating one or more technicians to work full time on APCs, completing the bus stop inventory before installation, and hiring a statistician to develop a methodology for passenger counting before vendor selection. Testing, different choices of hardware, and enhanced training were also mentioned by more than one respondent. Lessons Learned FroM sUrVeY responses Approximately 40% of all survey respondents and 73% of agencies that have deployed APCs shared lessons learned from the implementation and use of APC systems. The les- sons learned can be grouped into nine broad categories plus three miscellaneous categories (respondents had a lot to say!), as shown in Table 25. Lessons regarding data process- ing and use led the list of topic areas, followed by purchase and implementation, data validation, and maintenance. Responses are presented by category below. TABLE 24 ONE IMPROVEMENT TO THE APC PROCESS Agencies Responding Improvement No. % Contract and procurement 8 25.0 Additional APCs 7 20.6 Approach 7 20.6 Testing 4 11.8 Hardware 3 9.4 Training 2 5.6 Total responding 32 100.0

25 Understand uses and limitations of the data, depending • partly on how many APC units are deployed. Realize that software issues are part of APC growing • pains. Survey Responses: Purchase and Implementation Buy APC software and hardware from the same ven-• dor—life is much easier. Be aware that a stand-alone APC system (i.e., not part • of a larger ITS system) is best. Do not implement until software is ready.• Realize that more is always better when it comes to • APC units to maximize the degree to which signifi- cant data levels can be aggregated over time for spe- cific routes. Realize that an APC program can be successful with • 10% of the buses equipped with APCs. Specify standards for accuracy of both counts and pas-• senger-mile calculations as a disqualifying factor for acceptance in the request for proposals. Focus on equipment acceptance standards.• Work with a company that can deliver the total proven • package. Calibrate units as part of the standard operating proce-• dure before implementation. Survey Responses: Data Validation Conduct an ongoing manual versus machine validation • program. Maintain manual staff for periodic manual checks to • validate data. Understand the error rate of manual counts before • expecting 100% accuracy from machines. Make sure the data are validated.• Ensure all data are correct.• Maintain a manual method or develop some other • method to cross-check the data before eliminating manual method. Do not assume that calibration testing will occur: Go • out and verify the counts for yourself. Survey Responses: Maintenance Involve maintenance early and find people who can • handle troubleshooting of APC equipment. Dedicate a maintenance person to the APC system.• Ensure timely maintenance on the basis of good diag-• nostics produced by or derived from the collected data. Plan on extra maintenance staff.• Realize that hardware issues are part of APC growing • pains. Develop a maintenance plan upfront.• Identify malfunctioning equipment and to transmit • this information to maintenance personnel in a timely fashion by means of vendor equipment diagnostic data files and reports. Survey Responses: Staff and Resource Needs Make sure your staff has or gets the required resources • and knowledge—APCs don’t automatically work. Include a hardware technologist on the APC staff to • coordinate new bus installations and ensure that all buses are counting properly. Consider staff abilities when planning for any new system.• Do not expect miracles without very responsible and • involved “owners” of the APC system. Plan on extra staff in the short term and for maintenance.• Be sure to have at least one dedicated full-time staff • person to support the APC system. Dedicate one full-time maintenance person to the APC • system. Survey Responses: Time Frame Make sure that the organization knows that APC imple-• mentation cannot be done in a year—it takes about 3 years to work out all the bugs. Be patient.• Prepare for the long haul; counters are not as easy to • install as people think. Realize that start-up time is longer than stated.• Expect growing pains associated with APCs.• Survey Responses: Testing Do not always believe what vendors tell you.• Test every single aspect of the system before acceptance.• Do exhaustive testing of the APC system.• Focus on testing.• Do not let a vendor tell your management that its sys-• tem will get 100% of the data. Survey Responses: Experience of Peers Always try to find other agencies that have this new • equipment and ask about their experience before decid- ing to purchase. Contact and visit other agencies and bring a cross-func-• tional team with you to see how they use APCs. Seek advice from peers using the same or similar • equipment. Visit other properties and learn from them.• Survey Responses: Training Make sure that your staff gets the needed knowledge of • the system through training. Make sure that qualified staff are trained to monitor the • system and use the data.

26 Results regarding agency satisfaction with the perfor-• mance of its APC system in terms of counting passen- gers are positive. Forty percent were very satisfied, and 45% were somewhat satisfied. The primary benefits of APCs included data disag-• gregated at the stop, segment, and trip levels; better quality of ridership data; availability of running time data to adjust schedules; and a better basis for decision making. Problems encountered with the APC system included • reporting software, data processing and analysis, data validation, and hardware problems. One-quarter of all respondents reported either no problems or the usual start-up issues. Contract elements, procurement procedures, purchase • of additional APC units, and the overall approach to APC implementation were the most frequently men- tioned aspects of the APC process that transit agencies would like to change. Stricter contractual requirements, purchase of a complete system through a single vendor, and changes to internal procedures were all important. Changes to the overall approach included being more informed about hardware and software choices, involv- ing maintenance personnel at the start of the process, dedicating one or more technicians to work full time on APCs, completing the bus stop inventory before instal- lation, and hiring a statistician to develop a methodol- ogy for passenger counting before vendor selection. Almost three-quarters of all survey respondents that • have implemented APC systems shared lessons learned from the process. Agencies focused on use and valida- tion of the APC data, purchase and implementation, and ongoing agency maintenance in the discussion of lessons learned. Agencies offered lessons in many areas, but the emphasis on data systems and agency procedures suggests that these areas are critical to the success of APC implementation. The following chapter describes findings from six case studies that explore issues related to APC implementation and use in greater detail. Realize that good upfront training is needed.• Train, train, and train again.• Survey Responses: Other—Procedures Establish and track bus assignment procedures to iden-• tify any problems. Make sure a crosssection of the fleet is APC-• equipped. Provide online assignment instructions to dispatchers • to ensure correct assignments. Realize that integration with scheduling software is a • major factor in how the system will work. Get prior FTA approval to use APC data for National • Transit Database (NTD) reporting. Realize that other agencies took their lumps in getting • approval of APC data for NTD, so you should not have to do the same. Survey Responses: Other—Staff and Management Realize that some employees are not so open to change.• Do not get rid of all traffic checkers; they are needed • for other purposes such as NTD. Realize that ongoing support from upper management • is important. Survey Responses: Other—APC System Inputs Make sure bus stops have correct GPS coordinates and • route inventories are accurate. Understand the data requirements for stop matching • and establish a system to generate the required data before implementation. sUMMarY This chapter has described agency assessments of automatic passenger counter (APC) systems. Findings include the following:

27 CHAPTER FIVE case sTUdies directly by the agency. The interviews explored issues raised by the survey responses in greater depth. OC Transpo and TriMet also served as case studies for the previous TCRP synthesis on this topic. oc Transpo (oTTaWa–carLeTon reGionaL TransiT coMMission), oTTaWa, onTario, canada OC Transpo was a case study for TCRP Synthesis 29 and is a long-time user of APC systems with more than 25 years’ experience. OC Transpo was formed in 1973, but has a his- tory dating back to the 1870s under different names. The agency serves an area with a population of 778,000 and oper- ates 832 peak buses out of a total fleet of 991 buses. Annual ridership is 95.6 million (as of 2007). The Transitway, a ded- icated system of bus-only roadways, provides an exclusive rapid transit link across much of Ottawa’s urban area. The agency originally relied on a signpost-based APC system, however it is now moving to GPS. Earlier ver- sion APC equipment had no GPS capability, however now GPS is built into all new APC hardware purchased since 2000. The switch to GPS “virtual” locations, replacing the on-street signpost “fixed or hard” locations, has greatly improved APC locational accuracy. To gain further benefits of GPS, the operating software still needs to be updated. OC Transpo has plans to migrate to new software that is more mainstream and provided by a supplier that has other transit clients. The current software is customized and used only by OC Transpo; therefore, the agency pays the full cost of any upgrades and has no recourse if the company decides to inTrodUcTion Survey results provide an excellent overview of the major issues regarding automatic passenger counter (APC) system procurement, implementation, and use. Following a review of these results, six agencies were selected as case study sites. Personnel directly involved with APC deployment and use agreed to be interviewed by telephone. In some cases, more than one person at an agency either participated in the interviews or reviewed the draft summary of the case study. The case studies are intended to provide additional details on innovative and successful practices as well as on issues related to APCs. The selection process for case studies had several criteria: (1) to include transit agencies of various sizes in different parts of the country, (2) to include agencies that have achieved success in the use of APCs, and (3) to select agencies with varied levels of reported satisfaction with APCs so that ongo- ing issues can be better understood. More than two-thirds of responding agencies offered to serve as a case study and, as shown by examples from non–case-study respondents in chapters three and four, these agencies offered very interest- ing responses based on their experiences. The six agencies chosen do not necessarily consider themselves as examples of best practices, but together they provide a representative overview of the state of APC system use. The six case study agencies are OC Transpo (Ottawa–Carleton Regional Transit • Commission), Ottawa, Ontario, Canada RTD (Regional Transportation District), Denver, • Colorado NFTA (Niagara Frontier Transportation Authority), • Buffalo, New York RTC (Regional Transportation Commission of • Washoe County), Reno, Nevada Metro Transit, Madison, Wisconsin• TriMet (Tri-County Metropolitan Transportation • District of Oregon), Portland, Oregon The case studies summarize survey responses and inter- view observations from each agency. The introduction to each case study includes a basic description of the system, with data taken from FY 2006 NTD reports or provided

28 APC assignments appear in real time on their working screen. Even with this system, however, some assignments are still not completed as scheduled. The biggest of the agen- cy’s three garages is where most of the assignment problems occur, owing in large part to overcrowded conditions that make it difficult to park the APC buses in a separate area. A new bus garage is being constructed and is expected to lessen problems with assignments not being properly com- pleted. Even so, the assignment process works better now than it did 10 years ago. The agency plans to implement new APC software by 2010, with benefits including GPS identification of bus stops, more accurate trip and stop matching, increased data throughput, enhanced data quality, and improved hardware maintenance through the use of maintenance management tracking software. Another less tangible benefit of integrated hardware and software is establishing a good, solid product with excellent technical support that will lessen the current reliance on the two staff members who have been the source of all APC knowledge within the agency. This will allow for a smoother transition on their retirement. Although there was initially a steep learning curve regard- ing training in the use of the APC system, APCs are now a part of the fabric of the agency. Most planners and manag- ers who use passenger count data have never used anything other than APC data. There are now many good APC suppliers offering com- plete packages of hardware and software, as opposed to the early 1980s when OC Transpo cobbled together its first system. Using a single supplier for hardware and software should greatly improve an agency’s ability to get APCs up and running. All new OC Transpo bus purchases are prewired for APCs. This significantly reduces the installa- tion time for new hardware or moving equipment from bus to bus. It also allows greater flexibility in the selection of which buses to equip. The validation techniques have not changed over the past 10 years. Critical factors analyzed in the validation of APC data include the balance between boardings and alightings at the trip level, total trip distance, stop recognition, and start–end times. These same parameters will be used after the software change, with an expectation of improved stop- level accuracy through the use of GPS. Bus itineraries are now seen as more accurate. Until recently, OC Transpo had a separate bus stop file for the APC system, but now APC taps into and uses the bus stop inventory in the scheduling and information systems’ data- base. Customer service and other departments also use this inventory, resulting in quick discovery and correction of any errors and enhanced accuracy. redeploy staff to other projects or even to discontinue sup- porting the product altogether. The agency sees strong ben- efits in using hardware and software provided by the same supplier. The possibility of being a part of an APC user com- munity that shares a common product, and its cost, is very appealing. Ninety buses, slightly less than 10% of the OC Transpo fleet, are equipped with APCs. Each scheduled trip is sam- pled three times on average during each of the quarterly booking periods. Spread spectrum radio is used to down- load data at the garage. Spread spectrum radio has a limited range, but is constantly polling and will find a bus entering the garage and download APC data. Data are then moved to a central computer for processing. Automated downloading is simple, low cost, reliable, and low maintenance. Buses continue to collect and store data for at least 2 to 3 days; therefore, no information is lost during rare system prob- lems that cause automatic downloading to fail. OC Transpo has not employed traffic checkers since the APC system went online in the early 1980s. Current staff- ing needs include 3.5 positions: an APC supervisor, an APC analyst, a hardware technologist, and a part-time student from one of the local universities who assists with equip- ment maintenance. Estimated replacement cost for capital equipment is $600,000 ($525,000 to purchase hardware plus $75,000 for installation) and $225,000 for software. Esti- mated annual operating and maintenance cost is $315,000. The hardware technologist is a key position. This person has excellent rapport with other employees in the garages and also with the vendors. The hardware technologist maintains the APC system and oversees all work on the bus (union mechanics must do any work on the bus itself). The part-time student position, APC technician, may be unique to OC Transpo and is extremely useful. The agency tries to hire a first- or second-year student who will stay on the job for 2 to 3 years. He (or most recently, she) usually works nights and weekends when the hardware technologist is not at work. She can perform preventative maintenance, troubleshoot and identify problems with APC units as they come in for the night or are parked on weekends, and com- municate her findings electronically to the hardware tech- nologist, who then arranges for a union mechanic to correct the problem. OC Transpo uses internally developed software to assist in managing the sampling program to ensure that all trips are sampled. The program looks for trips and runs that have not been sampled, identifies these runs to have an APC bus assigned the following day, and transmits the information to the bus starter’s screen in the garages. The bus starter assigns buses to operators, and it is very important that the requested

29 second-year student who then stays with OC Transpo for approximately 3 years. Listen to planners, schedulers, and management; they • are the real clients of the APC staff. Tailor reports to what they want, both content and format-wise. Involve fleet/equipment staff early in the process. It • is important that they are on board, understand the importance of the system, and fully accept it. Promote the system as a planning tool that benefits • both union and nonunion stakeholders. This can be done through demonstrations or talks with all parties. It is important that the union realizes the system will not be used for disciplinary reasons. Adapt to shifts in planning interests. The increased • concern over budgets has made weekend sampling as well special service new hot spots for planners. APC must, more than ever before, ensure adequate coverage of these service types. Realize that implementing a successful APC system is • a large undertaking that shouldn’t be underestimated. It could stand on its own and not be viewed as an “add-on” to a larger system such as a real-time moni- toring system. If possible, the contract for the system should be with the APC supplier and not a system inte- grator who subcontracts the work to the APC supplier. After implementation, include a line item in the agency • budget for improvements and enhancements to the APC system to meet the needs of the clients as they gain more experience with using the data. Several case studies have noted similar ongoing enhancements. Improvements and enhancements can involve both hardware and software. rTd (reGionaL TransporTaTion disTricT), denVer, coLorado The RTD is a public agency created in 1969 by the Colorado General Assembly to develop, operate, and maintain a mass transportation system in the 2,326 square mile district, which includes all or parts of eight counties. The agency serves an area with a population of 2.6 million and operates 921 peak buses out of a total fleet of 1,060 buses. A significant portion of service is contracted to private operators. RTD operates light rail service with 57 peak vehicles. Annual ridership is 86.6 million, including all services operated (FY 2006). In downtown Denver, RTD offers frequent service on the 16th Street Transitway/Mall. APC data are more important than ever for OC Transpo’s planners and managers, who rely on them as the primary input to all planning decisions covering, for example, route planning, bus stop usage, shelter justification, long-range plans, and transit priority strategies. Like all transit agen- cies, OC Transpo is under added scrutiny to ensure that it spends public funds wisely. Performance standards are an important tool in this regard, but performance measures depend on ample and accurate ridership data. The use of APC data for scheduling purposes took longer to gain acceptance. All OC Transpo buses are now “smart buses,” equipped with mobile data terminals and GPS, and will provide running time data for schedules because it pro- vides a 100% sample compared with the 10% sample for APC. APC data will supplement these data because they can provide detailed time utilization information such as dwell times at stops. If OC Transpo could go back and change only one thing, it would purchase a complete system from a single APC vendor. Of course, this was not an option when APCs were introduced in Ottawa, but today there are several proven suppliers of hardware and software systems. Lessons learned include the following: Do not expect miracles overnight. It may take up to 3 • years to fully implement, get the procedural bugs out, and have all internal staff accept and adjust to working with APC. It cannot be done in a year. Make sure that the organization, including management, knows and accepts this. Buy APC software and hardware from the same ven-• dor. Life is much easier. Before buying, talk to users of APC systems and find out why their system succeeded or failed. Concentrate on the “soft side” of the system—this is • where real success is achieved. An example is an auto- mated bus assignment program that both determines assignments for tomorrow and reports on how well the assignments were made. It is important to measure this so those responsible for operational assignments (e.g., bus starters at OC Transpo) know when there are problems. Include a hardware technologist on staff responsible • for coordinating new bus installations and also ensur- ing that all existing APC buses are counting properly. This involves an ongoing program of rotational on- board checks (manual vs. machine). OC Transpo also employs a part-time technology student on a year-round basis. The student works off-hours (weekends, very late at night), which works well with school schedules and is also when most buses are in the garages. The student checks count accuracies and carries out minor adjustments on the bus. The agency hires a first- or

30 RTD is a large system, and setting up the entire APC system took a lot of work. The first year of APCs required extensive troubleshooting, as problems were identified and solved and as staff moved up the learning curve. The second year saw considerable improvement. After 3 years, service planning staff has confidence in the data and has developed the means to use it fully. Staff still finds oddities or prob- lems—this is, after all, a very complex process—so vigi- lance and technical support are constants. Service planners are also identifying enhancements to the software in terms of reports and validation procedures. The vendor is creat- ing a query to address Furth et al.’s suggestions regarding crowding (5) as one example. Training played an important role in APC implementa- tion. Service development has overall responsibility for the APC system, and staff needed to understand the workings of both the APC system and the report software. RTD arranged for training for all service development staff, and a specific staff member specializes in a particular area, such as APC monitoring, reporting using Ridecheck Plus, or the overall data processing function. Broad staff training emphasized an understanding of the reports, includ- ing how to generate a report and how to use filters. Technical training to support Ridecheck Plus was modest; instead, ser- vice development established tech support with the vendor’s program manager for an annual fee. On the maintenance side, the vendor trained RTD’s elec- tronic technicians, who troubleshoot APC equipment to the unit level. Defective units are removed and sent to the vendor for repairs on a unit cost basis. The end result is that hard- ware maintenance is carried out by expert technicians; spe- cialists oversee APC data, software applications, and all data processing; and all service development staff understands the use of APC data. Ridecheck Plus has the capability to display APC rider- ship data in a geographic information system (GIS). This ability is extremely useful in preparing presentations for the board of directors or for public meetings. Ridecheck Plus includes extremely detailed reports (e.g., running time by direction between time points) for internal use. Over time, RTD has identified which reports are most useful for specific purposes and has generated enhanced reports to meet spe- cific agency needs. Using APCs on the light rail system introduced new chal- lenges. A train is not a bus, but rather (for the purposes of APC data) a combination of buses. Given that not all light rail vehicles are APC-equipped, RTD factors the data from an individual vehicle according to how many APC vehicles were included in the train set. RTD assumes random placement of the assigned APC-equipped car(s) in a consist, allowing for use of a simple expansion factor to calculate train loads. RTD has established a very successful ridership tracking program using APCs on 20% of its bus fleet. RTD purchased its APC system in 2004. At the beginning of the process, the agency realized that getting the data was only half the program. RTD needed a way to analyze and report the data. Its survey of other agencies using APCs indicated that this element seemed to be lacking in many cases. RTD’s first important step was to purchase software for data analysis at the same time as it purchased APCs. RTD uses Ridecheck Plus to analyze ridership data. The second important step was to realize that an effective ridership analysis program using APC data requires a sub- stantial amount of support. There would be a learning curve, plus the usual problems that arise when implementing a new technology. Training was a critical aspect of the program. RTD also needed to get the support staff in place. One of the first support team activities was to decide how to assign buses to ensure a comprehensive ridership database with all trips surveyed within a given pick (or run board, to use RTD’s terminology). It was clear to RTD that this would involve more than a person making a list and sending it to someone else. The service development staff sat down with garage supervisors to discuss the current vehicle assignment process and how APC assignments could fit into the cur- rent process. The operations division made revisions to a draft assignment process to make it work in the garages, and service development then arranged to transmit APC assign- ments to the operations division. Once the assignment process was agreed on, service planning then focused on back-office aspects such as track- ing data as they came in, planning the next set of assign- ments, and quality assurance in general. These activities have become routine and semiautomated. The collaborative nature of this effort was an important factor in its ultimate success. An important factor was the understanding that operations was most interested in sched- ule adherence data because the division was accountable for this. The Ridecheck Plus system is able to accept data collected on a laptop by road supervisors (separate from the APC system) to analyze on-time performance. Service development set up a system in which operations collects field data on flash drives and turns these in to service devel- opment, which then uploads the data for validation and analysis. The APC system has been incrementally improved over the past several years and is now the primary source of data for ridership and running time analysis. However, the flex- ibility of the Ridecheck Plus software helped to encourage collaboration and acceptance of the APC system. Support of upper management and the board of directors also helped.

31 nFTa (niaGara FronTier TransporTaTion aUThoriTY)—BUFFaLo, neW YorK The NFTA is the transit operator in the Buffalo–Niagara region in western New York State. The agency serves an area with a population of 1.2 million and operates 280 peak buses. NFTA also operates light rail service with 23 peak vehicles. Annual ridership is 23.8 million, including all ser- vices operated (FY 2006). NFTA first considered APCs in the mid-1990s, when its board of directors expressed interest in their use. The subject arose again in 2000, at a time of declining ridership. APCs offered the means to obtain detailed ridership data and thus be able to identify exactly where the greatest use of transit was occurring. NFTA specified that APCs be included in its bus procurement. The APC system was implemented in 2001 after considerable testing, in which the counts proved to be very accurate. NFTA had implemented a talking bus system the previous year, so GPS data and the bus stop inventory had already been prepared and tested. NFTA added a pro- cess to share those data with the APC system. The implementation went smoothly, but it took 2 years of tweaking to ensure that the system worked under all circum- stances for all NFTA routes. The APC vendor performed (and continues to perform) post-processing data validation using proprietary software. In general, APC information is compared with the schedule for accuracy. Some agencies preload the schedule information on board vehicles, but post-processing works well at NFTA. APC implementation was accompanied by minor staff adjustments. Most routine processing issues were resolved by 2005. NFTA developed many report requests, and noted slow turnaround by the APC vendor. The customized reports did not always exactly match NFTA’s request. NFTA eventu- ally built an entire suite of reports in Statistical Package for the Social Sciences, the software used by the APC system, although it would have preferred a different platform with greater capabilities. In 2005, NFTA began investigating the ability of using APC data for NTD reporting. There was very little infor- mation on this at the time. FTA saw many places where things could go wrong with this process. NFTA realized that passenger-mile calculations were fraught with difficul- ties. First, the APC system uses GPS differential to calculate distance, and it does not produce correct results. Second, Over the 3-year period since APCs were introduced, service development staff have achieved a high confidence level in the data and the analyses and have conveyed this to others inside and outside the agency. There is a clear under- standing that comprehensive, in-depth ridership and run- ning time data are now being used, and that data analysis is more rigorous. The agency and the board understand that the APC system combined with GIS has enabled service changes to be easily and quickly depicted on a map to aid in making decisions. RTD is very satisfied with the performance of its APC system. The primary benefit is extensive and statistically valid data produced by the system, which in turn provide a sound basis for service development and maintenance. RTD characterizes problems with the system as typical start-up issues. The process is very complex: The agency is taking data from its computerized scheduling system and on-board bus and light rail systems, making wireless data transfers, and building or revising complex databases to store and analyze the data. Extensive troubleshooting is inevitable under these circumstances. RTD staff from various depart- ments worked together with the hardware and software ven- dors over a period of several years to develop an accurate and reliable passenger counting system. If RTD could go back and change only one thing, it would purchase additional APC units. Its ongoing efforts have shown that, with effort and dedication, a robust APC program can be developed with APCs on only 20% of the fleet. RTD provides an excellent example of successful APC implementation using third-party software. Lessons learned include Purchase reporting and analysis software on the front • end at the same time that APCs are purchased. The validation and reporting capabilities of the third-party software used by RTD were a huge part of RTD’s suc- cessful implementation of its APC system. quality assurance of both data and reporting is key • to acceptance by service planning and scheduling staff, and the public. Staff support and validation and maintenance procedures are critical for quality assurance. Ownership of the system is important, as is collabora-• tion with other departments within the agency and with the vendors. Ownership ensures that the APC system does not “fall between the cracks,” and collaboration builds support for the system. Successful implementation takes time. Introduction • of new technologies, integration of complex data sys- tems, and identification and resolution of problems do not happen overnight.

32 is also placed on APC ridership data because of their accu- racy and level of detail. NFTA has concluded that deployment of APC vehicles will always be an issue in need of constant supervision. To date, 90% have been deployed correctly, but the percentage has not increased as the number of APC-equipped buses has risen from 57 to 160 (approximately 40% of the fleet). Con- straints in the garage, some personnel issues, and mechani- cal issues all contribute to the problem. All APC buses have cameras, and requests for camera buses can conflict with APC assignments. Other APC-related issues include evolv- ing demands for new reports and a lack of understanding that even APC data are not 100% accurate all the time. APCs are being installed on light rail. The decision was made to equip all rail vehicles because a single roundabout and few crossovers can make it difficult to ensure that a spe- cific car is in a specific place at a specific time. NFTA is mostly satisfied with the performance of its APC system in terms of counting passengers. The primary benefit is the amount of data available, up to 80 samples per trip per year compared with one sample every other year with manual checking. NFTA encountered several problems in implementation of the APC system, and describes a painful growing pro- cess until it got the system tailored to its service and needs. Passenger counting is very accurate, but the unreliability of passenger-mile calculations, which precludes use of APC data for NTD reporting, is an unresolved issue. Bus assign- ment is still problematic, but the reasons for this are external to the APC system. If NFTA could go back and change only one thing, the agency would include a passenger-mile accuracy require- ment in the request for proposals (RFP). Lessons learned include the following: Require vendors to meet NTD reporting accuracy (95% • confidence and +10% precision levels) in the RFP as a disqualifying factor for acceptance of the system. Specify accuracy requirements for both boardings and • alightings and passenger loads. Test every aspect of the system, despite vendors’ claims • that things work, before accepting it. passenger-miles are calculated by multiplying load times distance. Passenger load calculations are a weak link in the APC system. To NFTA, the inability to use APC counts for NTD reporting is an important shortfall. The APC vendor is considering alternative ways to address distances between stops, but the major stumbling block is the passenger-mile calculations. NFTA uses APC data in its in-house monthly reports. Management and in-house users are very pleased. Route rid- ership and productivity figures are reported for every sched- ule change. APC data are used to justify adding, deleting, and adjusting service. APC data are also used for detailed running time analy- sis. The computer-aided dispatch (CAD)/automated vehicle location (AVL) system only measures by timepoint, whereas APC data are available at each stop. AVL uses a large geo- graphic buffer because the system is used for other purposes such as changing headsigns and NFTA prefers to err on the side of caution for passenger-related functions. NFTA designed a routine to move APC running time data into the computerized scheduling software package. The bus stop database does not reside in the computerized scheduling software but is a separate Access file. NFTA is pleased with post-processing tests for data valid- ity. The agency discards 10% to 15% of the raw APC data based on confidence calculations, but is it confident in the remaining data. To date, data have never been assigned to an incorrect block. Adjustments are also made in post-process- ing to try to deal with load accuracy. In any one signup period, the APC system provides 15 to 20 samples of each trip. Staff review and discard outliers. The sheer amount of data is self-validating. Interestingly, system ownership is split between the plan- ning and maintenance departments. Downstream users receive reports, but the data are very well filtered within the department. A set of reports goes to the Surface Transporta- tion Committee of the board. Planners are sometimes frus- trated by inaccurate load totals and the occasional time issue (e.g., if the operator takes layover before or after the assigned location, running times for the preceding and subsequent segments can be incorrect). Users are generally happy. Working relationships between departments have improved, as have relationships with outside agencies. A greater value

33 each vehicle type based on how fast the doors opened. The workings on the units are based on door-opening logic in the programming, a fact that was never considered. The importance of the door-opening logic also affects subsequent use of APCs. If APC units are included as part of the original equipment manufacture, then a unit cannot be switched to a different type of bus without reprogramming. The APC manufacturer can do the reprogramming if it has a prototype, but it is an added cost. When RTC introduced articulated buses, the manufacturer had to create a new pro- totype that addressed the third door. It is important to test how the software on the analyzer works when introduced into service. A test in a controlled non–revenue-service environment such as a bus garage will not reveal everything an agency needs to know. The valida- tion process was interesting. RTC compared the APC data with manual counts during an on-board survey by connect- ing a laptop to the analyzer, so that the surveyor could see what the analyzer was counting at each stop. RTC used a standard of 90% accuracy for boardings and alightings. The agency found that accuracy varied by bus type: Vehicles with narrow doors achieved an accuracy level of 97%, and vehicles with wide doors had a 93% accu- racy level. A wide-door vehicle allows riders to board more quickly, however passenger bunching affects the accuracy of counts at busy stops. RTC retrieves APC data from each bus when it pulls into the garage at the end of the day by means of a wireless down- load. Interlines can create problems, and bus detours result in unidentified stops. RTC has adopted a policy of repro- gramming stops for detours that will be in effect for at least 1 month. Route and stop information are housed within the computerized scheduling software, which is accessed by the ITS/APC database. Introduction of APCs results in training needs. There are two basic categories of training requirements: hardware and software. Hardware training for maintenance personnel is essen- tial. RTC has two master technicians who specialize in elec- tronics on its maintenance staff. These master technicians are the troubleshooters for ITS-related issues. RTC cautions that the involvement of too many mechanics in APC main- tenance creates its own problems. Although all maintenance personnel are trained in basic APC maintenance, the master technicians are responsible for all nonroutine issues. Software training for planning and other staff who will use APC data is focused on the use of databases. The ITS system at RTC stores data in a Structured query Language (SqL) server database. Canned reports are available but rTc (reGionaL TransporTaTion coMMission oF Washoe coUnTY), reno, neVada RTC was formed in 1979 as a result of legislation approved by the Nevada legislature. RTC operates public transporta- tion service in the cities of Reno and Sparks and in unin- corporated areas of Washoe County. The service area has a population of 253,000. RTC operates 62 peak buses. Annual ridership is 9.0 million, including all services operated (FY 2006). RTC started the process of purchasing ITS equipment with a special earmark in the Intermodal Surface Trans- portation Efficiency Act of 1991 (ISTEA). The agency had always lacked current passenger data by stop. RTC used to do a full system count every 3 years, but it was typically only one day per route. The idea of purchasing APCs had a lot of appeal throughout the agency. The central motivation was to have real-time, always current ridership data at a very detailed level. At the beginning of the procurement process, RTC staff traveled to other agencies to see examples of APC systems first hand. After hearing from one agency’s maintenance depart- ment how side-mounted beams were frequently bumped out of alignment by passengers, RTC opted for overhead sen- sors. The process was helped because the APCs were no lon- ger cutting-edge. Agencies like TriMet (Portland, Oregon) offered a model for APC implementation. RTC purchased its APC system as part of a broader ITS procurement in 2002. RTC highly recommends going to other agencies to see how APCs work in the real world. Even honest and well- meaning vendors do not always inform clients of all potential problems. For example, after implementation RTC found that the APC units were counting but were not meeting the speci- fications for accuracy. The solution was for the APC manu- facturer to prototype each bus, that is, calibrate the units for

34 do not always meet the agency’s needs. RTC worked with the manufacturer before implementation to create custom- ized reports. It was not possible to anticipate all the types of desired reports, especially because the availability of so many data through APCs leads to ideas and requests for dif- ferent reports. Staff versed in SqL programming can create needed reports and thus make maximum use of APC data. RTC also notes the need to scrutinize canned reports in terms of parameters and data used. For example, a canned schedule adherence report may or may not use the same defi- nition of “on time” as the agency does. There is a need to have staff resources, time, and knowledge to make sure the report represents the actual situation. RTC is moderately satisfied with its APC system. The APCs function well once they are installed and tested, and the data are very useful. Post-processing functions, particu- larly the ability to customize reports, need improvement. RTC designed customized reports before implementation, but reporting is an iterative process. Enhanced data avail- ability and accuracy have spurred new report designs that better meet the needs of RTC. The major benefits of APCs for RTC include detailed passenger activity at the stop level and running time data at the route segment level. The data provide a dependable basis for service and scheduling decision as well as the abil- ity to respond to passenger requests for stop amenities such as shelters and benches. APC-related issues at RTC include the ease and function- ality of post-processing and reporting procedures, inability to shift an APC unit to a different type of bus without repro- gramming the door-opening logic, and the need for hardware and database training to make full use of APCs. When RTC began to explore APCs in the context of a broader ITS purchase, there were fewer APC vendors. If the agency could change one thing, it would explore APC capabilities across manufacturers, particularly in the areas of hardware–software interface and post-processing procedures. Lessons learned include the following: APCs do not automatically work once installed. • Agencies need lots of resources and knowledge on the hardware (electronics) and software (database) sides. Delegate primary responsibility for APC upkeep and • trouble-shooting to a single maintenance group or per- son with knowledge of electronics and the equipment being used. Involve the maintenance department early on in the process. Test everything in real-world conditions. Do not always • believe what the vendor tells you. Reports can be misleading—do not assume the data on • the report are what you are looking for. MeTro TransiT—Madison, Wisconsin Metro Transit provides public transportation services in the city of Madison, Wisconsin, and surrounding communi- ties. The combined service area had a population of around 280,000 in the 2000 Census. Metro operates 167 peak buses when the University of Wisconsin and the public schools are in session. Annual ridership across all services is 12.3 mil- lion (FY 2006). Metro Transit purchased APCs in 2004 as part of an upgrade of its radio system. Metro purchased an ITS-type package, with voice and data communication capabilities and computers, GPS, and mobile data terminals on board each bus. APCs were a marginal cost in the scope of the entire procurement, and 40 APC units were installed on approximately 18% of Metro’s fleet. The primary benefit of purchasing APCs as part of a larger procurement is that the GPS component and the entire data structure are included. A disadvantage was perhaps a more limited selection of APC technologies because the prime contractor for the radio system had a preferred set of APC subconsultants with whom it had worked in the past. Metro has never been completely satisfied with the func- tioning of the APC units. The system uploads raw data (unadjusted counts by bus number, with only positional coordinates and a time stamp) to a database, where this information is then automatically processed overnight. The system correlates the raw data with route, block/trip, and

35 additional APC units to enhance the ridership database, but this argument is difficult to make if staff is not com- pletely satisfied with the underlying quality of the data produced by the existing APC units. On the other hand, staff also struggles with how much effort to dedicate to generating other outputs from the APC data, given the lim- ited fleet of APC buses available for data collection, and the complications described earlier regarding the complex scheduling requirements. Overall, Metro is moderately dissatisfied with the perfor- mance of its APC system in terms of its ability to deliver usable data on passenger counts. The primary benefit to date is a general picture of boarding and alighting trends at the bus stop level. Problems include inaccuracies in boarding and alighting counts across an entire trip, which lead to inac- curate loads, and lost data owing to the inability to maintain route adherence correctly. The latter problem often results from detours or other unusual operating circumstances, such as special events, but can also stem from insufficient or inac- curate route data programming. If Metro could go back and change only one thing, the agency would go into the process with a better understand- ing of potential pitfalls. The request for proposals for the ITS procurement included a requirement for 95% accuracy in the APC units, and the prime contractor has subsequently been on-site addressing various issues. More staff involvement and attention in the testing and acceptance phases would have been useful, but staff limitations played a role here as well. The primary lesson learned is to set better equipment acceptance standards and testing. TriMeT (Tri-coUnTY MeTropoLiTan TransporTaTion disTricT), porTLand, oreGon TriMet was a case study for TCRP Synthesis 29 and is a long- time user of APCs. TriMet began operation on December 1, 1969. In 1975, the agency began operating Fareless Square in downtown Portland, 2 years before the opening of the tran- sit mall. The Banfield light rail line began service in 1986, and the light rail system now has four lines. TriMet serves an area with a population of 1.3 million and operates 526 peak buses and 81 peak light rail vehicles. Annual ridership is 101.6 million (2006). Over the past 25 years, the agency’s IT staff has sought to develop new and innovative applications of APC data. A fairly large IT staff and a strong analytical staff that has worked together with APCs for a long time have been two stop data and produces adjusted boarding and alighting data at the stop level. The first problem is errors within the APC technology. Boardings and alightings do not balance on any given trip, resulting in incorrect loads. A second problem that contrib- utes to the first is that the system is set up to parse data that may have occurred “off-route.” Every trip is programmed as a series of stop intervals. As a trip progresses, the sys- tem calculates distance traveled and constantly confirms adherence to the preprogrammed compass headings and proximity to the coordinates for the next stop. Distances, stop coordinates, and compass headings were populated by driving a staff car. Data errors, odometer problems, or excessive lane changes can result in mismatches from the preprogrammed adherence guidelines, which can result in the bus falling back into an “off-route” status. The sys- tem will disregard the raw APC data collected during any period of time the bus was either correctly (owing to actual detour) or mistakenly (as a result of data mismatch) in this “off-route” status. One solution to load issues is to “zero out” the load at the end of each trip. Metro schedules a fair amount of interlines and loop routes, and in many cases passengers remain on the bus at the “end” of a trip. Another issue with interlin- ing is that it becomes more challenging to collect a single day’s data on a given run. Some core routes may have up to 20 blocks providing trips. This issue is exacerbated by the geography of Madison. There is a narrow isthmus between two lakes, with three primary corridors that buses use to access the downtown and university campus. This results in a network structure where multiple routes provide service along these three trunk corridors. Metro is not able to get a single-day 100% count at a given stop on one of these three trunk corridors. Metro has only been able to find effective use for its APC data at the stop level. Each trip serving a given bus stop is assumed to have an APC bus assigned on at least a few days within a pick (typically 90 days). An external reporting pro- cess is used to calculate the average number of boardings and alightings at each stop for each trip, and then to sum these averages for all the trips serving this stop over the course of a day for a total count of daily boardings and alightings by stop. The resulting data are used primarily within the agency to provide an order of magnitude type of comparison of pas- senger activity by stop. Overcoming the various issues with APC data is a chal- lenge. As is the case at many small and medium-sized agencies, limited staff resources affect what can be done. APCs are just one of many ITS-related projects that Metro has implemented in recent years, and staff has had lim- ited opportunity to dedicate the time needed to iron out the problems. Planning staff recognizes the benefits of

36 approximately 80% of the raw APC data being used for analy- sis. A recent study indicated that APC counts are accurate at a confidence level of 95% and an error of +5%. Previously, TriMet would balance loads by block, but now the program adjusts loads at the trip level. Boardings and alightings are averaged, and adjustments are made at stops with the greatest passenger activity. Loads are zeroed out at the end of the line if the bus lays over for at least 5 minutes. This condition allows for non-zero end loads on through trips. The balanced loads are used only for load-related anal- yses; stop-level analyses use the actual APC counts. In-house programs also address other data anomalies. For example, if a bus lays over before its designated layover loca- tion, running time and load data are not registered correctly. TriMet developed a routine to use time-stamp information from the AVL system to correct the data. Another routine associates boardings at a layover point with the following trip and alightings with the previous trip. IT staff has devel- oped these and similar routines to address the data oddities that have been observed over 25 years. All APC and AVL data reside in an Oracle database maintained by the IT department. Scheduling and payroll data are integrated into this database. The open nature of the database provides access to a wide variety of data and its inclusiveness encourages innovative analysis. TriMet is cur- rently examining factors contributing to absenteeism among bus and light rail operators and is able to explore a num- ber of hypotheses related to loads and on-time performance through the database. Use of APC data for NTD reporting is a topic of great interest. TriMet keeps a separate database to calculate loads as an input to the passenger mile calculations required for NTD. The reason is that the standard validation program adjusts for negative loads, which biases the load estimate upward. TriMet works with James Strathman from Portland State University to ensure that any errors in APC boardings and alightings are random. FTA approved TriMet’s use of APC data for NTD in 1986, but has since changed its pro- cedures and requires annual validation of APC data, with a minimum sample of 100 trips. FTA granted TriMet a waiver for its most recent NTD report, but the agency is conducting manual validation this year. TriMet would prefer to see a periodic validation requirement of every 3 to 5 years instead of an annual requirement for NTD reporting. Maintenance of APC units is the responsibility of elec- tronic technicians in the maintenance department. Origi- nally, when TriMet had less than 60 APCs and no AVL, TriMet had one project manager/technician to perform the equipment maintenance and data programming/processing requirements. With the increasing number of electronic com- ponents on the buses, additional technicians have been hired positive factors in TriMet’s success. The addition of a CAD/ AVL system several years ago improved the passenger counting program by greatly enhancing and simplifying the ability to identify bus stops. TriMet is a good example of an agency that developed its own analytical software, mainly because nothing of that sort existed when it first implemented the APC system. The in- house program is driven by block-level and stop-level data, which are then matched to the schedule and the bus stop. The bus stop matching program can identify and flag a location with no matching stop and assign the data to the nearest bus stop. This capability was developed in the early days when stop matching relied on odometer data and continues to be useful in many circumstances today. Approximately 75% of the bus fleet is equipped with side- mounted APCs. The integrated APC/AVL system collects data every time a bus passes a stop or opens its doors. Data upload occurs in the garage through PCMCIA (Personal Computer Memory Card International Association) cards that are removed from the buses by operators and placed into a networked computer by station management person- nel. This older technology has its challenges. It is difficult to obtain new 1-megabyte cards. Today 1-gigabyte cards are common, but the data transfer takes much longer with the larger cards. The data retrieval and processing automatically happens every night and data are available the next day. Overhead APC units are installed on light rail vehicles. The APC database treats rail like bus, except that adjustments are made if only one car in a two-car train is equipped with APCs. The Oracle database contains all the scheduling information needed to make these adjustments. APCs transmit data wire- lessly, but sometimes the overnight transmission does not hap- pen and data are not available the next day. The next generation of APC for the bus fleet is likely to use overhead beams. TriMet did use a program that randomly assigned APC- equipped vehicles to specific blocks, but no longer does so. The Service and Performance Analysis manager will check periodically that all blocks have been scheduled for APC within a given pick. All new buses have APCs, but only about 30% of the oldest buses in the fleet are APC-equipped. All buses collect AVL data, therefore arrival and departure times at stops are always available. Specific requests for an APC bus assignment are occasionally made, usually for a low-frequency low-ridership route that is under consider- ation for discontinuation or service adjustment. The overnight data processing includes automated programs to ensure that the beams are working correctly, to match data to schedules, and to validate boarding and alighting totals. The validation program checks that boarding and alighting totals differ by no more than 10% and adjusts for negative loads. Any suspect data are removed from the system, resulting in

37 department in conjunction with data users. Lessons learned include the following: Check and validate all data. • Develop accurate and reasonable techniques to balance • loads. Load data are often the weak link in an APC system. Develop routines to address end-of-trip data. Consider • where and when to zero out loads and handle other anomalies that can arise at the end of the trip. Realize that a close working relationship with the infor-• mation technology department is essential. TriMet’s success was aided by a large IT department that has developed and refined data processing and reporting procedures. Use the open architecture of the agency’s Oracle • database and integrate with the computerized scheduling software to access a wide variety of data. TriMet relies on this extensive database as it continues to develop innovative analytical and reporting techniques. and the APC system is only one of their responsibilities. The maintenance director understands the importance of APCs for the agency, but repairs can take longer than expected. TriMet is very satisfied with the performance of its APC system. The primary benefits are a large amount of statisti- cally valid ridership data, greater confidence in the accuracy of the data, and no need for ride checkers. TriMet has such a long history (25 years) with APC data that it has been able to address all the problems encoun- tered. For example, the agency noted that it took about a year to work out all issues in the integration of APC and AVL databases. The system works very well and there is a high degree of confidence in using the data. Because of this his- tory and the current state of affairs, TriMet was hard pressed to answer the question of what it would go back and change if it could. TriMet provides an excellent example of successful APC implementation using internal software developed by its IT

38 CHAPTER SIX concLUsions and sUGGesTions For FUTUre sTUdY inTrodUcTion This chapter summarizes findings and presents conclusions from this synthesis project, and offers suggestions for future study. Findings from the surveys, particularly the case stud- ies, provide an assessment of factors contributing to the suc- cess or failure of automatic passenger counter (APC) system implementation. The chapter is organized in five sections: Automated Passenger Counting (APC) • Implementation APC data: Processing, Reporting, and Validating• Agency assessments of APCs• Lessons learned • Conclusions and areas of future study• The further research needs offered here attempt to place the study findings in a larger context of how APC use might evolve at transit agencies. aUToMaTic passenGer coUnTer iMpLeMenTaTion The most common reason to collect ridership and travel • time data is to compile ridership by route, although the majority of respondents also collect ridership and travel time data for more specific microlevel uses at the route segment or stop level. Tracking ridership changes, cal- culating performance measures, and adjusting sched- ules were the three most common uses of ridership and travel time data. A majority of respondents use a combination of auto-• mated and manual methods to collect ridership data. The most common combinations involve APC plus manual data collection and farebox plus manual col- lection. In many cases, an older technology is retained to test the validity of the new technology or for a spe- cific purpose: for example, National Transit Database (NTD) reporting or data validation. Agencies that continue to collect ridership data manu-• ally cite cost as a reason, followed by low priority for automated data collection at the agency. Smaller sys- tems (fewer than 250 peak buses) are more likely to continue to rely on manual data collection. More than 90% of respondents indicated that their APC • systems included a global positioning system element. Almost half of all respondents reported that their APC purchase was part of a broader intelligent transporta- tion systems (ITS) project. Only a portion of most agencies’ buses are APC-• equipped; however, more than one-quarter of respond- ing agencies have installed APCs on all buses. Nine of the 12 agencies that are 100% APC-equipped bought APCs as part of a broader ITS purchase. Most respondents reported a standard for acceptance • of the APCs at the 90% or 95% level of accuracy for passenger boardings and alightings, and almost three- quarters of respondents indicated that they use these standards on an ongoing basis. Manual counts are typi- cally used as the basis of comparison. Changes in professional staffing levels as a result of • APC implementation were minimal in most cases: More than 70% of all agencies reported no changes or decreases in staff levels. However, there were notable decreases in the size of traffic checking units. About one-quarter of respondents indicated a minor increase (defined as one or two full-time positions) in main- tenance staff, and 22% reported a minor increase in professional staff. The case studies suggest that assign- ing analytical and maintenance staff specifically to the APC program is an important factor in successful implementations. The median reported capital cost per APC unit was • $6,638 among the 26 agencies responding. The median reported annual operating and maintenance cost per APC unit was $600 among the 11 agencies respond- ing. Cost data from the survey should be interpreted cautiously, as respondents varied in their ability to break down cost data (especially for older systems or for APC systems purchased as part of a larger ITS procurement). aUToMaTic passenGer coUnTer daTa: processinG, VaLidaTinG, and reporTinG Processing APC data often requires changes to exist-• ing data systems, such as addition of GPS coordinates for stops and an updated or new bus stop inventory.

39 A few agencies noted the establishment of defined interfaces between computerized scheduling software packages and APC or AVL systems. For data storage and analysis, the most common changes were the addi- tion of servers for data storage and new database soft- ware for analysis. Automated data validation programs, provided by the • APC vendor, developed in-house, or purchased from a third party, can simplify the process of converting raw APC data into usable ridership data. Agencies reported various thresholds for determining validity at the block or trip level. The percentage of raw APC data that is converted into • useful information averages 74%, comparable to find- ings from 10 years ago, with a median value of 80%. A majority of agencies rely on the hardware vendor • for data processing and report generation software, but several indicated in-house software development or use of an outside vendor other than the hardware vendor. Detailed (segment/stop level) ridership and scheduling-related reports are most likely to be gener- ated as needed, suggesting that the reporting process for these types of reports may require intervention in defining parameters. More than 90% of responding agencies indicated a • capability to generate ad hoc, specialized reports from the APC system. The most common method was for the end users to generate ad hoc reports, but one-quarter of agencies with this capability rely on the outside vendor for specialized report generation. Some agencies use APC data for NTD purposes. FTA • requires manual checks annually to validate APC data for NTD submittal. The concept of manual validation of APC data as a one-time or periodic exercise is of interest to agencies as they gain confidence in the accu- racy of APC data. Anyone who has been through the process of imple-• menting a new technology knows that there is a “debug- ging” period. The debugging period, during which start-up problems are resolved, averages 17 months for APCs, identical to the finding of the 1998 synthesis, with a median of 18 months. The planning department is the most common location • for management of the APC system, followed by the operations department. There is widespread involve- ment across departments in procurement of the APC system and use of the APC data. Downstream users typically access APC data electronically through stan- dard reports, and 41% of agencies noted that down- stream users could query the database directly. Implementation of APCs necessarily involves multiple • departments within the transit agency. Positive aspects include improved communication among departments, greater value placed on ridership data, improved decision-making ability, greater responsiveness, and the ability to provide the needed data to end users. Difficulties include problems ensuring that assign- ments were completed, new demands for reports, low priority for APC equipment in the maintenance depart- ment, and unrealistic expectations regarding turn- around time and data quality. Implementation of APCs creates a need for training. • A majority of respondents noted increased training needs in the areas of software/computer, analytical, and hardware skills. Only one-quarter of responding agencies reported no additional training needs. aGencY assessMenTs oF aUToMaTic passenGer coUnTinG sYsTeMs The primary benefits of APCs included data disag-• gregated at the stop, segment, and trip levels; better quality of ridership data; availability of running time data to adjust schedules; and a better basis for decision making. Problems encountered with the APC system included • reporting software, data processing and analysis, data validation, and hardware problems. One-quarter or all respondents reported either no problems or only the usual start-up issues. Results regarding agency satisfaction with the perfor-• mance of its APC system in terms of counting passen- gers are positive: Eighty-five percent of respondents were very or somewhat satisfied. Forty percent were very satisfied, and 45% were somewhat satisfied. Contract elements, procurement procedures, purchase • of additional APC units, and the overall approach to APC implementation were the most frequently men- tioned aspects of the APC process that transit agencies would like to change. Regarding procurement, stricter contractual requirements, purchase of a complete sys- tem through a single vendor, and changes to internal procedures were all important. Changes to the overall approach included being more informed about APC hardware and software choices, involving mainte- nance personnel at the start of the process, dedicating one or more technicians to work full time on APCs, completing the bus stop inventory before installation, and hiring a statistician to develop a methodology for passenger counting before vendor selection. Lessons Learned Almost three-quarters of all survey respondents that • have implemented APC systems shared lessons learned from the process. Agencies focused on use and valida- tion of the APC data, purchase and implementation, and ongoing agency maintenance in the discussion of lessons learned. Agencies offered lessons in many areas, but the emphasis on data systems and agency

40 and refined data processing and reporting procedures and integrated APC data with other agency databases. The agency paid close attention to balancing loads in a statistically reliable fashion and addressing other data anomalies. The open architecture of the agency’s data- base and the integration with the computerized sched- uling software resulted in the ability to access a wide variety of data and generate innovative analyses. concLUsions and areas oF FUTUre sTUdY APCs provide a rich ridership and travel time data-• base at a finer level of detail than farebox or manual counts, even for agencies with only a few APCs. The increased number of observations lends greater confi- dence to decisions regarding changes in service levels. An agency does not need APC units on all vehicles to establish a workable APC system, although installation of APCs on all vehicles produces a richer database and avoids vehicle assignment problems. An APC system does not work automatically. • Successful agencies have developed procedures (in- house or through an outside vendor) to match APC data to bus stops, clean and validate data, generate standard reports, simplify the process of creating ad hoc reports, and flag potential hardware and software problems for the maintenance and information technology depart- ments. The data processing and reporting software is the most important part of an APC implementation. Integration of APC data with existing agency data- bases, which may also be changing as a result of new technologies, is challenging. Agencies’ business prac- tices and procedures may not be designed to make opti- mal use of available data. APC implementation is not simple, and the first year • is the most difficult. There is a steep learning curve, particularly on the software side, and there are likely to be internal agency issues regarding responsibilities and priorities. Ownership of the APC system is important, as is col-• laboration across departments. The ownership part of the equation, in which one department assumes overall responsibility, ensures that the APC system receives priority, and the collaboration part works best when the lead department is attuned to the needs and proce- dures of other departments and can adjust to meet these needs. A good working relationship between the lead department and the maintenance personnel assigned to APCs is critical. Staffing presents a challenge, especially to small and • medium-sized agencies. Successful implementations are characterized by close review of APC data as part of a quality assurance program, particularly in the first year when bugs are being worked out, and a dedicated maintenance technician or group of technicians who procedures suggests that these areas are critical to the success of APC implementation. The Ottawa-Carleton Regional Transit Commission • (OC Transpo) (Ottawa, Ontario, Canada) was a case study for the previous TCRP synthesis on passenger counting and has been using APC data for more than 25 years. It is an example of an APC system developed in-house over a number of years that works extremely well. The agency has assigned staff to support the pro- gram and has developed bus assignment, reporting, and maintenance procedures to overcome problems. OC Transpo continues to adapt and refine APC use. The Regional Transportation District (RTD) (Denver, • Colorado) provides an example of successful APC implementation using third-party software. RTD pur- chased reporting and analysis software at the same time that the APC system was purchased. Clear iden- tification of responsibilities, close collaboration with maintenance and other departments from the outset, training for all staff using APC data, and emphasis on quality assurance are the major factors contributing to success. The Niagara Frontier Transportation Authority (NFTA) • (Buffalo, New York) case study provides an example of an agency that developed its own in-house reporting capabilities in response to dissatisfaction with the ven- dor’s reports. NFTA is also interesting in that system ownership is split between the planning and mainte- nance departments. All issues have not been resolved, even after 2 years of tweaking, but management and in-house users are pleased with the monthly ridership reports. Use of APC data to justify service changes is a standard practice. The Regional Transportation Commission of Washoe • County (RTC) (Reno, Nevada) is an example of the introduction of APCs as part of a broader ITS procure- ment. RTC involved maintenance personnel at the out- set and continues to focus on collaboration. RTC is still working through post-processing issues, but already uses APC data for service-related decisions. The Metro Transit (Madison, Wisconsin) case study • is typical of the stage in many APC implementations where there is no confidence in the APC data at any level other than stop-level boardings and alightings. Potential solutions involving revisions of the bus stop inventory and route itineraries are known but are dif- ficult to implement with limited staff resources. In turn, the lack of extensive useful APC data makes it hard to justify added resources. The Tri-County Metropolitan Transportation District • of Oregon (TriMet) (Portland, Oregon) was also a case study for the previous TCRP passenger count- ing synthesis and is an example of successful APC implementation using in-house analytical software. Its success over the past 25 years was aided by a large information technology department that has developed

41 assumes primary responsibility for hardware issues. Agencies may not have the staff available or may not have staff with the right mix of skills. Transit agencies that have worked through the myriad • issues associated with APC implementation cannot imagine life without APCs. These agencies reap the benefits of extensive and statistically valid data that are used with confidence to make important service- related decisions. Findings from this synthesis suggest eight major areas of future study: In-depth investigation of critical factors to success.• Are there optimal routines to match APC data to spe- cific bus stops? What elements of a validation program are most critical to ensuring quality data? Which ele- ments of reporting software are most useful, and what is the best way to create ad hoc query ability? How can APC data be integrated most usefully with exist- ing agency databases? How can an agency “manage” the learning curve? Are there techniques to foster APC system ownership and collaboration? What if adequate staff is not available and added staff is not an option? How important is a strong commitment from senior management to the APC program? Exploration of various avenues to success.• Both in- house and third-party approaches have been success- ful. Are there circumstances in which one is preferable to another? What is the state of the art in software pack- ages? Ongoing developments within the transit indus- try, such as deployment of ITS technology, increased vendor attention to complete (hardware plus software) product packages, and a wider choice of hardware and software options (including off-the-shelf software), affect the answer to this question and suggest addi- tional possibilities. Evaluation of data cleaning and validation tech-• niques. This is an important barrier to success and is perhaps the major source of frustration to agencies that indicated dissatisfaction with their APC systems. Confidence in the accuracy of APC data is critical to its widespread use and acceptance within and outside the transit agency. Many agencies struggling with this step view it as a hardware problem, but its solution resides in considering both the hardware and the software used to clean and validate the data. More precise identification of factors preventing suc-• cess and ways to overcome them. Data validation is not the only barrier to success. Broader hardware, soft- ware, and personnel issues need to be addressed and overcome, and a closer examination of successful strat- egies would serve the transit industry well. Exploration of new technologies that may improve APC • data collection accuracy. As ITS technologies evolve, new hardware and software options that improve the accuracy of APC data are likely to emerge. What are the most promising options to achieve improved count accuracy, enhanced data quality, and reliable data loca- tion matching? Investigation of alternative techniques, algorithms, • and methodologies that can improve the state of the art of APC systems. As more agencies implement APC systems, the market for innovation grows larger. Using existing technology, what improvements can address the needs of transit agencies? Identification of business intelligence and data report-• ing tools that can be used with APC data. As data sys- tems are integrated and downstream users begin to rely on APC data, new approaches and innovative analyti- cal strategies can be expected. Additional uses of APC data will continue to emerge as users become more knowledgeable and will affect data needs or the pri- ority afforded to the APC system. Establishing a data warehouse can provide an opportunity to take advan- tage of many business intelligence techniques such as data mining. Institution of new methods of disseminating informa-• tion on APC systems. This synthesis has provided a snapshot of the state of passenger counting systems in 2008. An APC forum or workshop, webinars on APC implementation and the use of APC data, and an elec- tronic mailing list devoted to APC-related issues are all possibilities to extend the findings of this report and to provide a continuing means for agencies to share information and learn from each other’s experi- ences. The TCRP panel for this project strongly sup- ports this initiative.

42 reFerences 1. Boyle, D.K., TCRP Synthesis 29: Passenger Counting Technologies and Procedures, Transportation Research Board, National Research Council, Washington, D.C., 1998. 2. Baltes, M.R. and J.R. Rey, “The ‘Ins and Outs’ of APCs: An Overview of Automatic Passenger Counters,” Jour- nal of Public Transportation, Vol. 2, No. 2, 1999, pp. 47–64. 3. Rakebrandt, A., “Transit Tracking: Automatic Passen- ger Counting Systems and Tracking Ridership,” Mass Transit, Vol. 33, No. 1, Feb. 2007, pp. 28–34. 4. Jasmin, T. and J. Vicente, “Advanced Transportation Management System: A Metro ‘Smart’ Bus System,” 2005 Bus and Paratransit Conference Proceedings, American Public Transportation Association, Washing- ton, D.C., 2005. 5. Furth, P.G., B. Hemily, T.H.J. Muller, and J.G. Strath- man, “Using Archived AVL–APC Data to Improve Transit Performance and Management,” Transit Coop- erative Research Program Report 113, Transportation Research Board, National Research Council, Washing- ton, D.C., 2006. 6. Furth, P.G., B. Hemily, T.H.J. Muller, and J.G. Strath- man, “Uses of Archived AVL–APC Data to Improve Transit Performance and Management: Review and Potential,” TCRP Web Document 23 (appendices to TCRP Report 113), 2003 [Online]. Available: gulliver. trb.org/publications/tcrp/tcrp_webdoc_23.pdf. 7. Furth, P.G., J.G. Strathman, G. James, and B. Hemily, “Making Automatic Passenger Counts Mainstream: Accuracy, Balancing Algorithms, and Data Structures,” Transportation Research Record 1927, Transportation Research Board, National Research Council, Washing- ton, D.C., 2005, pp. 207–216. 8. Hammerle, M., M. Haynes, and S. McNeil, “Use of Automatic Vehicle Location and Passenger Count Data to Evaluate Bus Operations: Experience of the Chicago Transit Authority, Illinois,” Transportation Research Record 1903, Transportation Research Board, National Research Council, Washington, D.C., 2005, pp. 27–34. 9. Herrscher, K., “How Data Warehouse Technology Enables Transit Agencies to Make Informed Decisions with Superior Data,” 2006 Bus and Paratransit Confer- ence, American Public Transportation Association, Washington, D.C., 2006. 10. Nokel, K. and K. Schweiger, “Closing the Loop: Feed- ing Back Operational Performance Indicators into Sup- ply Planning and quality Control,” in Competition and Ownership in Land Passenger Transport 9th Interna- tional Conference (R. Macario, J.M. Viegas, & D.A. Hensher, eds.), Elsevier, Amsterdam, Netherlands, 2007, pp. 577–587. 11. Bertini, R.L. and A. El-Geneidy, “Generating Transit Performance Measures with Archived Data,” Transpor- tation Research Record 1841, Transportation Research Board, National Research Council, Washington, D.C., 2003, pp. 109–119. 12. Paliska, D. and J. Kolenc, “Analyzing the Effect of Pas- senger-Requested Unscheduled Stops on Demand,” Pro- met Traffic Traffico, Vol. 19, No. 4, 2007, pp. 213–220. 13. Golani, H., “Use of Archived Bus Location, Dispatch, and Ridership Data for Transit Analysis,” Transporta- tion Research Record 1992, Transportation Research Board, National Research Council, Washington, D.C., 2007, pp. 101–112. 14. Strathman J.G., T.J. Kimpel, and S. Callas, Headway Deviation Effects on Bus Passenger Loads: Analysis of TriMet’s Archived AVL–APC Data, TransNow/Univer- sity of Washington, Seattle, Jan. 2003. 15. Kimpel, T.J., J.G. Strathman, D. Griffin, S. Callas, and R.L. Gerhart, “Automatic Passenger Counter Evalua- tion: Implications for National Transit Database Reporting,” Transportation Research Record 1835, Transportation Research Board, National Research Council, Washington, D.C., 2003, pp. 93–100. 16. Dueker K.J., T.J. Kimpel, J.G. Strathman, and S. Callas, “Determinants of Bus Dwell Time,” Journal of Public Transportation, Vol. 7, No. 1, 2004, pp. 21–40. 17. Rajbhandari, R, S.I. Chien, and J.R. Daniel, “Estimation of Bus Dwell Times with Automatic Passenger Counter Information,” Transportation Research Record 1841, Transportation Research Board, National Research Council, Washington, D.C., 2003, pp. 120–127. 18. Hwang M, J. Kemp, E. Lerner-Lam, N. Neuerberg, and P. Okunieff, Advanced Public Transportation Systems: The State of the Art Update 2006, Federal Transit Administration, Washington, D.C., 2006 [Online]. Available: www.fta.dot.gov/documents/APTS_State_ of_the_Art.pdf. 19. Chen, M., J. Yaw, S.I. Chien, and X. Liu, “Using Auto- matic Passenger Counter Data in Bus Arrival Time Pre- diction,” Journal of Advanced Transportation, Vol. 41, No. 3, 2007, pp. 267–283. 20. Chien, S.I., M. Chen, and X. Liu, Use of Neural Net- work/Dynamic Algorithms to Predict Bus Travel Times

43 31. Strathman J.G., T. J. Kimpel, and S. Callas, “Validation and Sampling of Automatic Rail Passenger Counting for National Transit Database and Internal Reporting at TriMet,” Transportation Research Record 1927, Trans- portation Research Board, National Research Council, Washington, D.C., 2005, pp. 217–222. 32. Marx, E. and E. Bruun, “OmniLink: Case Study of Suc- cessful Flex Route–Capable Intelligent Transportation System Implementation,” Transportation Research Record 1971, Transportation Research Board, National Research Council, Washington, D.C., 2006, pp. 91–98. 33. Schweiger, C.L., “The Challenge of Deploying Transit ITS: Gaining Stakeholder Consensus,” 8th World Con- gress on Intelligent Transport Systems, ITS America, 2001. 34. Monahan, P., C.L. Schweiger, and T. Buffkin, Evalua- tion of the Metropolitan Atlanta Rapid Transit Authority Intelligent Transportation System, Federal Transit Administration Research and Special Programs Admin- istration, Washington, D.C., 2000. 35. Sun, D., M. Zhao, L. Fu, W. Liu, and W. Song, “Video- Based Automatic Passenger Counting Technology for Transit Routes with High Passenger Volumes,” Paper No. 07-1045, Transportation Research Board 86th Annual Meeting, Washington, D.C., Jan. 21–25, 2007. 36. Navick, D.S. and P.G. Furth, “Estimating Passenger Miles, Origin–Destination Patterns and Loads with Location-Stamped Farebox Data,” Transportation Research Record 1799, Transportation Research Board, National Research Council, Washington, D.C., 2003, pp. 107–113. 37. Zhao J., A. Rahbee, and N.H.M. Wilson, “Estimating a Rail Passenger Trip Origin–Destination Matrix Using Automatic Data Collection Systems,” Computer-Aided Civil and Infrastructure Engineering, Vol. 22, No. 5, July 2007, pp. 376–387. 38. Barry, J.J., R. Newhouser, A. Rahbee, and S. Sayeda, “Origin and Destination Estimation in New York City with Automated Fare System Data,” Transportation Research Record 1817, Transportation Research Board, National Research Council, Washington, D.C., 2002, pp. 183–187. 39. Transit Technology Fact Sheets, Federal Transit Admin- istration, Washington, D.C., 2008 [Online]. Available: www.pcb.its.dot.gov/factsheets/factsheets.asp. Under Congested Conditions, New Jersey Institute of Technology, New Jersey Department of Transportation, and Federal Highway Administration, Nov. 2003. 21. Patnaik J., S. Chien, and A. Bladikas, “Estimation of Bus Arrival Times Using APC Data,” Journal of Public Transportation, Vol. 7, No. 1, 2004, pp. 1–20. 22. Chu, X., Validating T-BEST Models with 100% APC Counts, Research and Special Programs Administra- tion, Florida Department of Transportation, Tallahas- see, 2007. 23. Kim, C. and J. Bhiromkaew, “A Comparison Study of Aggregate and Disaggregate Trip Distribution Model- ing,” 12th World Congress on Intelligent Transport Sys- tems, ITS America, 2005. 24. Shalaby, A. and A. Farhan, “Prediction Model of Bus Arrival and Departure Times Using AVL and APC Data,” Journal of Public Transportation, Vol. 7, No. 1, 2004, pp. 41–61. 25. Rucker, D. “Automatic Passenger Counting Systems Expanding Beyond Just Counting People,” 2003 Bus and Paratransit Conference Proceedings, American Public Transportation Association, Washington, D.C., 2003. 26. Bolden, T., T. Woods, & J. Vicente, “Bus Data Fusion— Getting Systems and People Working Together to Reach Their Full Potential,” Bus and Paratransit Conference, American Public Transportation Association, Washing- ton, D.C., 2007. 27. Yu, D., S. Mishra, and J. Lin, “Visualization of Bus Schedule Adherence Using GIS,” Applications of Advanced Technology in Transportation, Proceedings of the Ninth International Conference, American Soci- ety of Civil Engineers, Reston, Va., 2006, pp. 159–164. 28. Rossetti, M.D., “Design and Testing of a Transit Inte- grated Monitoring System,” 9th World Congress on Intelligent Transport Systems, ITS America, 2002. 29. Gordon, M. “Automatic Passenger Counters: Optimiz- ing a Configuration to Meet Transit Agency Needs,” Proceedings of 1999 APTA Bus Conference, American Public Transportation Association, Washington, D.C., 1999. 30. Jeng, J.H., “Bus Transit ITS System Deployment in the U.S.—Trends and Lessons Learned,” 9th World Con- gress on Intelligent Transport Systems, ITS America, 2002.

44 acronYMs APC automatic passenger counter APTA American Public Transportation Association APTS advanced public transportation systems AVL automatic vehicle location CAD computer-aided dispatch CTA Chicago Transit Authority (Chicago, Illinois) FTE full-time equivalent GIS geographic information systems GPS global positioning system IT information technology ITS intelligent transportation systems MARTA Metropolitan Atlanta Rapid Transit Authority (Atlanta, Georgia) NFTA Niagara Frontier Transportation Authority (Buffalo, New York) NTD National Transit Database OC Transpo Ottawa–Carleton Regional Transit Commission (Ottawa, Ontario, Canada) PCMCIA Personal Computer Memory Card International Association PRTC Potomac and Rappahannock Transportation Commission RFP request for proposals RTC Regional Transportation Commission of Washoe County (Reno, Nevada) RTD Regional Transportation District (Denver, Colorado) SAS Statistical Analysis System SPSS Statistical Package for the Social Sciences SqL Structured query Language SSR spread spectrum radio TCRP Transit Cooperative Research Program TRIS Transportation Research Information Services TriMet Tri-County Metropolitan Transportation District of Oregon (Portland, Oregon)

45 appendiX a Tcrp sYnThesis sUrVeY: passenGer coUnTinG TechnoLoGies

46

47

48

49

50

51

52

53

54

55

56

57 appendiX B Tcrp sYnThesis sUrVeY resULTs passenGer coUnTinG sYsTeMs respondenT inForMaTion 1. Date: 2. Name of Respondent: 3. Title of Respondent: 4. Agency Name: 5. Agency Size (note: this was entered after survey responses were received, based on FY 2006 NTD data) Small (<250 peak buses)…… _________________ 43 50.0% Medium (250–1,000 peak buses)…… ___________ 32 37.2% Large (1,000+ peak buses)…… ________________ 11 12.8% 6. Respondent Telephone Number: 7. Respondent E-mail Address: pUrposes 8. For what purposes are ridership data collected and used at your agency? (check all that apply) Track system-wide ridership totals…… _________ 76 88.4% Compile ridership by route…… _______________83 96.5% Compile boardings/alightings by stop…… _______68 79.1% Monitor passenger loads at max load point…… ___64 74.4% Monitor schedule adherence and …… running times __________________________56 65.1% Other (please describe):…… __________________25 29.1% Other includes: NTD reporting; ridership by fare category; ridership by trip; ridership by route segment; service evaluation/performance reports; prioritization for bus shelters; evaluation of business initiatives; identify discrepancies in bus stop database; forecast equitable placement of vehicles; specific counts related to employer bus pass programs and targeted demographic analysis; develop screenline counts; model and estimate origin-destination patterns; monitor pricing and fare patterns; monitor individual driver performance in such categories as on-time performance and excessive layover; passenger miles and rural service statistics; calculate variances compared to farebox data; determine where additional resources are warranted; estimate revenue and help determine cost-sharing arrangements with other agencies; ridership by time period; ridership by direction; answer inquiries from businesses re passenger activity at stops near potential development sites; route productivity; contract-specific requirements with universities. 9. How does your agency use the data collected? (check all that apply) Calculate performance measures…… ___________77 89.5% Adjust schedules (add/delete trips, …… change headways) ______________________ 75 87.2% Adjust running times/select or …… change timepoints ______________________62 72.1% Revise routings…… _________________________69 80.2%

58 Assess changes in ridership…… _______________80 93.0% Determine locations for bus shelters and …… other facilities _________________________63 73.3% Compile NTD reports…… ___________________ 71 82.6% Other (please describe): …… _________________ 8 9.3% Other includes: revenue calculation for third-party services (e.g., to universities); evaluation of demand from passengers using mobility devices and potential for additional service or wheelchair stations on the bus; fare modeling and pricing analysis; growth projections and marketing. TechnoLoGies 10. How does your agency collect ridership data? Automatic passenger counters …… ____________12 14.0% Other automated methods such as handheld …… data collection units or registering fareboxes ____________________12 14.0% Manually (paper and pencil)…… ______________ 18 20.9% A combination of automated and …… manual methods ________________________44 51.2% 11. If your agency collects ridership data manually, what are the reasons that you have not switched to an automated technology? (check all that apply, then you are finished) Cost…… _________________________________ 10 71.4% Satisfied with manual data collection…… ________4 28.6% Data collection/analysis procedures fully …… developed and tested _____________________1 7.1% Awaiting broader ITS purchase that will …… include APC ____________________________4 28.6% Tried APC in the past but it didn’t work out…… ___1 7.1% Low priority at the agency…… _________________6 42.9% Other (please specify) …… ____________________6 42.9% Other includes: planning to change but have not yet (4); lack of staff time and expertise to maintain additional data and electronic systems; GFI fareboxes damaged by Hurricane Katrina. 12. If your agency uses a combination of manual and automated methods, please describe how each method is used. APC plus manual…… _______________________12 29.3% Farebox plus manual…… _____________________8 19.5% APC plus farebox…… ________________________4 9.8% APC plus farebox plus manual…… _____________4 9.8% APC plus handheld devices…… ________________2 4.9% APC plus farebox plus handheld…… ____________2 4.9% Handheld plus manual…… ____________________2 4.9% AMTD plus AVL plus APC…… ________________1 2.4% APC plus handheld plus manual…… ____________1 2.4% AVL plus farebox plus manual…… _____________1 2.4%

59 Farebox plus farecard plus manual…… __________1 2.4% Farebox plus handheld…… ____________________1 2.4% Farebox plus manual plus on-board survey…… ____1 2.4% Farebox plus on-board survey…… ______________1 2.4% 13. If other automated methods are used, please describe these. Responses include: investigating APCs; registering fareboxes as our primary means; fareboxes and turnstiles used for most ride counting, supplemented by APCs, farecards, handheld devices, and video; APCs plus registering fareboxes; drivers manually pressing a button for non-pass riders plus pass swipes; registered turnstile entries; APCs as supplemental; farebox counts; farebox and handheld units; palm pilot with portable GPS capabilities; PDAs. 14. What APC equipment does your agency use (including sensor type—infrared, treadle, etc.), and who is the manufacturer? All except one use infrared. See Appendix E for manufacturers. 15. Does your agency’s APC system include a GPS element? Yes…… __________________________________ 47 94.0% No…… ____________________________________3 6.0% 16. What percentage of your agency’s bus fleet is equipped with APC? 100%…… ________________________________12 26.7% 50%–99%…… _____________________________5 11.1% 20%–49%…… ____________________________ 11 24.4% 10%–19%…… _____________________________ 11 24.4% 1%–9%…… ________________________________6 13.3% 17. If APC equipment is not on all buses, who prepares the daily assignments of APC buses by route and trip? Planning/service planning…… _________________8 30.8% Operations…… _____________________________5 19.2% Randomly assigned…… ______________________3 11.5% Schedules…… ______________________________3 11.5% APC staff…… ______________________________2 7.7% Data collection…… __________________________2 7.7% Other…… _________________________________3 11.5% Other includes: randomly unless special needs, then senior planner; UTA software; randomly for first half of booking, then planning technician with computer program. 18. Is this process automated within the APC software system? Yes…… ___________________________________6 16.2% No…… ___________________________________29 78.4% Don’t know…… _____________________________2 5.4% 19. What percentage of daily assignments are completed as scheduled? Average is 80%. Range is from 40% to 100%. 20. How often within one year is a particular weekday trip successfully counted, on average? Responses vary widely, from once a year to nearly every day.

60 21. Is APC equipment used on any modes other than bus? No, only bus…… ___________________________42 85.7% Yes, light rail…… ___________________________4 8.2% Yes, other (please describe)…… ________________3 6.1% Other includes: heavy rail; at two light rail stations; light rail procurement in process 22. Is your agency’s APC system a stand-alone system, or is it part of a larger project? Stand-alone system…… _____________________ 16 32.7% Purchased as part of a larger ITS project…… _____24 49.0% Don’t know…… _____________________________1 2.0% Other (please specify)…… ____________________8 16.3% Other includes: light rail stand-alone, bus as part of ITS; APCs preceded AVL, but now integrated; some are stand- alone, others part of ITS; smaller legacy stand-alone system being replaced by new integrated system; mostly stand-alone but gets GPS from DRI talking bus; also purchased Ride Check Plus software; currently stand-alone but capable of downstream integration. 23. If your agency also has an AVL system, is there a preferred source for time-based information at timepoints? Yes, we primarily use APC time data…… ________3 6.1% Yes, we primarily use AVL time data…… _______28 57.1% No preference: either is acceptable…… __________9 18.4% We do not have an AVL system…… _____________9 18.4% apc daTa: processinG, ManaGinG, VaLidaTinG, and UsinG 24. What standards did your agency use for the initial acceptance of APC (e.g., level of accuracy)? 85%…… __________________________________1 3.0% 90%…… __________________________________8 24.2% 95%…… _________________________________ 13 39.4% 97%…… __________________________________1 3.0% 95% + 10%…… _____________________________2 6.1% 95% + 5%…… ______________________________1 3.0% Varies by level…… __________________________7 21.2% 25. Does your agency use these standards on an ongoing basis? Yes…… __________________________________30 71.4% No…… ___________________________________12 28.6% 26. How does your agency transfer ridership data from the APC units? Direct downlink (probe) of APCs with a …… physical connection ______________________4 8.5% Retrieval of APC data at garage without a …… physical connection _____________________23 48.9% Real-time dynamic or periodic remote …… retrieval of APC data ____________________ 13 27.7% Other (please specify)…… ____________________7 14.9% Other includes: combination of real-time and wireless; radio; PCMCIA card for bus, wireless for light rail; diskettes; WLAN.

61 27. Please describe what steps are taken to edit and validate APC ridership data. (check all that apply) Compare ridership and revenue totals…… _______ 18 39.1% Look for unexplained variations across trips…… __27 58.7% Compare ridership totals across days …… for reasonableness ______________________25 54.3% Rely on the professional judgment of …… planners/schedulers _____________________24 52.2% Use an automated program to analyze …… APC data _____________________________24 52.2% Compare on/off totals by trip and adjust …… as needed _____________________________ 14 30.4% Compare with manual counts…… _____________ 32 69.6% Other (please specify)…… ____________________7 15.2% Other includes: automated program, users identify anomalies, and ongoing manual counts; examine data quality score for each chunk of APC data; use a business intelligence solution with pre-set tolerances, compare with farebox, and spot-check against manual counts; compare to farebox; none on a regular basis; compare with video counts; exception reports from daily diagnostics.28. If your agency uses an automated program to analyze APC data, please describe it briefly in terms of what it looks for and how it decides the validity of the data. See summary table below for examples of validation tests, thresholds, and actions. Test Threshold Action Boardings vs. alightings by block and/or by trip 5% 10% 20% 30% Discard block or trip data if exceed threshold Loads Less than 0 Adjust boardings/alightings at heavi- est use stops Bus stop location Within 200 feet of actual bus stop Flag stop data if exceed threshold Actual vs. scheduled block miles/kilometers 10% Discard if data exceed threshold 15,000 Actual vs. scheduled block pull out/pull in times 30 minutes Actual vs. scheduled trip start/end times 20 minutes “significantly off-schedule”” Observed vs. “expected” results at the route, block, trip, and stop levels Not specified Assign quality code to data Geographic information vs. computerized schedul- ing software data Look for match Assign probable route/block Block data No data Discard block data 29. Are any special steps required to validate ridership data for NTD reporting purposes? Yes (describe below)…… ____________________ 17 32.7% No…… ____________________________________5 9.6% We do not use APCs to collect NTD data…… ____30 57.7% 30. Please describe how your agency validates ridership data for NTD reporting purposes. Responses include: follow FTA guidelines; software developed by consulting statistician; manual validation; reasonable checks and management review; use APC data in very limited fashion for NTD; compare with farebox data.

62 31. What proportion of raw data collected by APCs at your agency is converted into useful information that can be used by service planning, scheduling, and other departments? Average 74%; median 80%; range 10% to 100%. 32. Were any changes required for existing agency data systems to provide the data needed for APCs to work? (check all that apply) Yes, creating or updating the bus …… stop inventory _________________________23 53.5% Yes, identifying GPS coordinates…… __________25 58.1% Yes, other changes (please describe below)…… ___ 13 30.2% No changes required…… ____________________12 27.9% Other includes: complete rewrite of ridership estimation program for APCs (previously for farebox data); have route changes as far in advance as possible; automated bus assignments; bus stop inventory and GPS coordinates previously developed for another application, but needed to share with APC system; updating schedules and formatting for use with APC system; creating a template of stops, signposts, and timepoints for each bus; creating bus routes for the system to track; created defined interfaces with computerized scheduling software package; formalize bus stop change procedures; create schedule file; internal program developed to import schedule data. 33. Were any changes required for existing agency data systems to store and analyze APC data? Yes (please specify)…… _____________________ 19 46.3% No changes required…… ____________________22 53.7% Changes include: data storage changes; switch to Oracle database and in-house software to clean and schedule-match APC data; separate server; additional server; scrap vendor-supplied matching software and write our own; hardware and network connections to host APC software and data servers; installation of hardware and related software; new servers; developing reports and GIS access; in-house application to correlate APC data with bus stop database; purchased Ridecheck Plus, vendor software incapable of generating needed reports; vendor software unable to analyze data or perform diagnostic tests to validate data and make needed adjustments; new servers for data storage; third-party solution being considered to address this issue; new servers and vendor-supplied software as part of larger ITS program; network upgrade; installation of SPSS; integrated database; whole new large software package as part of AVL purchase; separate server; creation of Crystal Reports queries/reports for additional analysis. 34. What types of reports are routinely generated from APC data? Please also indicate the approximate frequency for each type of report. Annually quarterly Monthly Weekly Daily As needed System ridership 9.1% 15.2% 27.3% -- 21.2% 27.3% Route-level ridership 5.3% 26.3% 15.8% 2.6% 18.4% 31.6% Route segment ridership 10.5% 10.5% 5.3% 2.6% 7.9% 63.2% Stop-level board- ings/alightings 2.4% 14.6% 9.8% 2.4% 9.8% 61.0% Performance measures 6.1% 27.3% 12.1% 3.0% 12.1% 39.4% Schedule adherence -- 15.6% 12.5% -- 15.6% 56.3% Running times -- 12.9% 3.2% 3.2% 12.9% 67.7% Other (please specify) -- 20.0% 20.0% -- -- 60.0% Other includes: ridership for special events (rail); ad hoc request response within 24 hours; manual means still primary for generating reports; percentage of trips sampled and how often during current schedule; daily trip-level information; report by bookings instead of by quarter and include linked-trips estimate each year.

63 35. How did your agency develop data processing and report generation software? In-house, by information systems or …… computer services department _____________ 13 27.7% In-house, by end users of data…… _____________ 16 34.0% Through the hardware vendor…… _____________26 55.3% Through another outside vendor…… ___________12 25.5% Other (please specify)…… ___________________ 3 6.3% Other includes: plan to use another outside vendor; occasional help from IT department; in-house by a technical person hired to support end users of the data; hardware vendor or end users; part of hardware package; two outside programs; user developed for farebox, computer services department test-processing for APC data. 36. If software was developed through an outside vendor, did the process include customization or modification of the software to meet the agency’s specific needs? Yes, considerable customization…… ____________5 10.6% Yes, moderate customization…… ______________12 25.5% Yes, minor customization…… _________________4 8.5% No…… ____________________________________8 17.0% Not applicable…… _________________________ 18 38.3% 37. Does your agency have the capability of generating ad hoc, specialized ridership reports from the APC system? Yes, through information services or …… computer services department _____________ 16 35.6% Yes, directly by end users…… ________________29 64.4% Yes, through the outside vendor…… ____________ 11 24.4% No…… ____________________________________4 8.9% 38. Does your agency archive ridership data for previous year comparisons or future analytical needs? Yes…… __________________________________ 35 85.4% No…… ____________________________________6 14.6% 38a. If yes, how long do you keep APC data in the archive? Average and median length is 5 years. 39. Most new technologies require an implementation or “debugging” period in which agencies become familiar with the new equipment and start-up problems are ironed out. If your agency implemented APC within the last five years, how long did this period last? Less than 6 months…… ______________________3 9.7% 6–11 months…… ____________________________4 12.9% 12–23 months…… ___________________________8 25.8% 24 months or more…… _______________________6 19.4% Ongoing…… ______________________________ 10 32.3% Average (excluding ongoing) is 17 months; median is 18 months

64 orGaniZaTion and daTa inTeGraTion 40. Which departments were involved in the decision to purchase APCs at your agency? (check all that apply) Planning…… ______________________________38 90.5% Scheduling…… ____________________________24 57.1% Budget/Finance…… ________________________22 52.3% Operations…… ____________________________26 61.9% Computer Services/Information Services…… ____28 66.7% Maintenance…… ___________________________ 18 42.9% Marketing/Market Research…… ______________ 10 23.8% Other (please specify)…… ____________________3 7.1% Other includes executive/senior management. 41. Which department takes primary ownership of management and operation of the APC system? Planning…… ______________________________ 19 42.3% Scheduling…… _____________________________3 6.8% Budget/Finance…… _________________________1 2.3% Operations…… _____________________________9 20.5% Computer Services/Information Services…… _____7 15.9% Maintenance…… ____________________________1 2.3% Marketing/Market Research…… _______________0 0.0% Other (please specify)…… ____________________4 9.1% Other includes combinations of: IT, maintenance, and operations; maintenance and IT (joint department); planning and maintenance; planning and IT 42. Which departments are downstream users of APC data? (check all that apply) Planning…… ______________________________40 90.9% Scheduling…… ____________________________36 81.8% Budget/Finance…… ________________________ 15 34.1% Operations…… ____________________________ 32 72.7% Computer Services/Information Services…… _____6 13.6% Maintenance…… ____________________________6 13.6% Marketing/Market Research…… ______________26 59.1% Senior management…… _____________________23 52.3% No downstream users…… _____________________1 2.3% Other (please specify)…… ____________________3 6.8% Other includes: transit priority group within city government; local businesses, Federal and local governments, Board of Directors, local government planners 43. How do downstream units access APC data? (check all that apply) Hard copy…… _____________________________22 50.0% Electronically via standard reports…… _________ 35 79.5% Electronically via dynamic queries…… _________ 19 43.2% Other (please specify)…… ____________________8 18.2%

65 Other includes: reports run by APC staff and e-mailed to users with 24-hour turnaround; GIS tools; Ridecheck Plus; schedulers and planners can run dynamic queries; still working out the process. 44. If there are multiple users of APC data, please describe the interaction among the different groups and any synergy or tensions/conflicts that have arisen. Examples could include: greater value placed on ridership data; better work- ing relationships between departments; difficulties in ensuring that daily assignments are completed successfully; demands for new and/or reformatted reports posiTiVe Improved communication between departments…… 7 20.6% Greater value placed on ridership data…… _______7 20.6% Better data leading to improved …… decision-making ability ___________________5 14.7% Greater responsiveness to public/others…… ______3 8.8% Ability to provide data to end users…… __________3 8.8% neGaTiVe Difficulty with bus assignments…… ____________7 20.6% Constant/increased demands for …… new/reformatted reports __________________5 14.7% Low priority for APC maintenance…… __________4 11.8% Unrealistic expectations re turnaround time …… and data quality _________________________4 11.8% resoUrce reQUireMenTs 45. How many staff positions (full-time equivalents [FTEs]) are assigned to carry out your agency’s passenger counting program? <1 FTE 1-1.9 FTEs 2-3.9 FTEs 4+ FTEs Don’t Know Managers/ professionals 47.7% 29.5% 20.5% 2.3% -- Support (e.g., equip- ment maintenance) 54.1% 27.0% 13.5% 5.4% -- Clerical 72.0% 20.0% -- -- 8.0% Traffic checkers 44.4% 11.1% 7.4% 29.6% 7.4% Other (please specify) 42.9% -- 14.3% 42.9% -- Other includes: data retrieval person; data editing and analysis plus report production; traffic checkers ad hoc. 46. Has the APC program resulted in changes in number of staff? Consider a change of more than 2 FTEs a “major” change. Major Decrease Minor Decrease No Change Minor Increase Major Increase Professional staff -- 2.8% 72.2% 22.2% 2.8% Support staff 3.1% -- 81.3% 12.5% 3.1% Clerical staff 3.1% 6.3% 87.5% 3.1% -- Maintenance staff -- -- 71.9% 28.1% -- Traffic checkers 20.0% 28.6% 48.6% -- 2.9% Other (please specify) 10.0% -- 70.0% 10.0% 10.0% Other includes: we needed more IT support and maintenance at first; data retrieval person; eliminated two positions in Treasury branch; but it should!

66 47. Has the APC program resulted in changes in skill levels required by staff? Yes, in software/computer skills…… ___________29 69.0% Yes, in analytical skills…… __________________23 54.8% Yes, in hardware maintenance skills…… ________23 54.8% Yes, in other skills (please specify)…… __________5 11.9% No…… ___________________________________ 10 23.8% Other skills include: learning how to use the data properly, what it is good for, and its limitations; we have had APCs for so long, it is part of our ongoing fabric; training for operators 48. What is the capital cost associated with your agency’s passenger counting program? For capital costs, list approxi- mate purchase cost and year purchased. If multiple purchases were involved (e.g., bus one year, rail the next), list bus information in the boxes and add other information in the next question. You do not need to use a dollar sign; enter a number for each box. Overall cost:…… _____________________________ Cost per APC unit:…… ________________________ Year purchased:…… __________________________ Cost data from the survey should be interpreted cautiously. Respondents varied in their ability to break down cost data (especially for older systems or for APC systems purchased as part of a larger ITS procurement). As one example, reported capital costs for the agency’s APC system ranged from $90,000 to $40,000,000. The average capital cost per APC unit was $7,500, with a range from $450 to $26,700. The median capital cost per APC unit was $6,638, with 26 agencies responding. See below for breakdown (Table 21 in Chapter 3). APC Median Capital Cost and Median Capital Cost per Unit by Number of Vehicles Equipped No. Vehicles with APCs Median Capital Cost ($) Median Capital Cost per APC Unit Installed ($) No. Systems < 100 200,000 7,500 13 100 to 400 500,000 2,700 7 > 400 1,800,000 1,100 3 Total sample 490,000 6,638 26 NOTES: Three systems reported total cost only; three systems reported unit cost only. All three systems in the over 400 category had at least 1,450 vehicles with APCs. 49. Add any additional information on capital costs here. See above. 50. What is the annual operating/maintenance cost associated with your agency’s passenger counting program? If mul- tiple purchases were involved (e.g., bus one year, rail the next), list bus information in the boxes and add other informa- tion in the next question. You do not need to use a dollar sign; enter a number for each box. Overall cost:…… _____________________________ Cost per APC unit:…… ________________________ Cost data from the survey should be interpreted cautiously. Respondents varied in their ability to break down cost data (especially for older systems or for APC systems purchased as part of a larger ITS procurement). Responses regarding annual operating and maintenance costs also showed a huge variation, from $0 (everything is under warranty) to $15,000,000. Average annual operating and maintenance cost per APC unit was $1,458, with a range from $0 to $6,500. The median annual operating and maintenance cost per APC unit was $600, with 11 agencies responding. 51. Add any additional information on operating/maintenance costs below. See above.

67 assessMenT 52. How satisfied has your agency been with the performance of its APC system in terms of counting passengers? Very satisfied…… __________________________ 16 40.0% Somewhat satisfied…… ______________________ 18 45.0% Somewhat dissatisfied…… ____________________2 5.0% Very dissatisfied…… _________________________4 10.0% 53. What have been the primary benefits of APC for your agency? Finer level of detail (stop/segment/trip)…… _____ 14 36.8% quality of data…… _________________________ 11 28.9% Running time data to adjust schedules…… ______ 10 26.3% Better basis for decision making…… ____________6 15.8% quantity of data…… _________________________6 15.8% Timeliness of data…… _______________________5 13.2% 54. Have there been any problems encountered with the APC system? None/usual start-up issues…… ________________ 10 25.6% Reports/reporting software…… ________________5 12.8% Data processing/analysis…… __________________4 10.3% Data validation…… __________________________4 10.3% Hardware problems…… ______________________4 10.3% 55. If you could go back in time and change ONLY ONE aspect in the process of purchasing, installing, and using your APC system and associated methodology, what would you change? Contract/procurement…… ____________________8 25.0% Additional APCs…… ________________________7 20.6% Approach…… ______________________________7 20.6% Testing…… ________________________________4 11.8% Hardware…… ______________________________3 9.4% Training…… _______________________________2 5.6% 56. Please describe any “lessons learned” that would benefit other transit agencies that are considering changes to their passenger counting methods. Data processing/use/reporting…… _____________ 14 41.2% Purchase/implementation…… _________________9 26.5% Data validation…… __________________________7 20.6% Maintenance…… ____________________________7 20.6% Staff/resource needs…… ______________________5 14.7% Time frame…… _____________________________5 14.7% Testing…… ________________________________5 14.7% Experience of peers…… ______________________4 11.8% Training…… _______________________________4 11.8%

68 Other: procedures…… _______________________6 17.6% Other: staff/management…… __________________3 20.6% Other: APC system inputs…… _________________2 17.6% 57. Is there another transit system that you suggest we contact for this synthesis project? If you know of a contact at that system, please list the name also. Various responses. 58. Would you be willing to participate further as a case study, involving a telephone interview going into further detail on your forecasting methodology, if selected by the TCRP panel for this project? Yes…… __________________________________28 68.3% No…… ___________________________________ 13 31.7%

69 passenGer coUnTinG sYsTeMs Albany, N.Y. Capital District Transportation Authority1. Allentown, Pa. Lehigh and Northampton Transportation Authority2. Ann Arbor, Mich. Ann Arbor Transportation Authority3. Anoka, Minn. Anoka County Transit4. Arlington, Ill. PACE5. Atlanta, Ga. Metropolitan Atlanta Rapid Transit Authority6. Austin, Tex. Capital Metro7. Baltimore, Md. Maryland Transit Administration8. Bay City, Mich. Bay Metropolitan Transportation Authority9. Blacksburg, Va. Blacksburg Transit10. Boone, N.C. AppalCART11. Boston, Mass. Massachusetts Bay Transportation Authority12. Bremerton, Wash. Kitsap Transit13. Bryan, Tex. Brazos Transit District14. Buffalo, N.Y. Niagara Frontier Transportation Authority15. Burlington, Vt. Chittenden County Transportation Authority16. Butler, Pa. Butler Transit Authority17. Calgary, Alberta Calgary Transit18. Champaign–Urbana, Ill. Champaign–Urbana Mass Transit District19. Chicago, Ill. Chicago Transit Authority20. Cincinnati, Ohio Metro/Southwest Ohio Regional Transit Authority21. Cleveland, Ohio Greater Cleveland Regional Transit Authority22. Colorado Springs, Colo. Mountain Metropolitan Transit23. Columbus, Ohio Central Ohio Transit Authority24. Dallas, Tex. Dallas Area Rapid Transit25. Davis, Calif. ASUCD Unitrans26. Dayton, Ohio Greater Dayton Regional Transit Authority27. Delano, Calif. City of Delano28. Denver, Colo. Regional Transportation District29. Duluth, Minn. Duluth Transit Authority30. Elk Grove, Calif. e-tran31. Eugene, Ore. Lane Transit District32. Fairfield, Calif. Fairfield-Suisun Transit33. Fresno, Calif. Fresno Area Express34. Fort Myers, Fla. Lee County Transit35. Gainesville, Ga. Hall Area Transit36. Hartford, Conn. Connecticut Transit37. Honolulu, Hawaii City and County of Honolulu Department of Transportation38. Houston, Tex. Metropolitan Transit Authority of Harris County39. Ithaca, N.Y. Tompkins Consolidated Area Transit40. Jacksonville, Fla. Jacksonville Transportation Authority41. Knoxville, Tenn. Knoxville Area Transit42. Lancaster, Calif. Antelope Valley Transit Authority43. Las Vegas, Nev. Regional Transportation Commission of Southern Nevada44. Livermore, Calif. Livermore/Amador Valley Transit Authority (WHEELS)45. Louisville, Ky. Transit Authority of River City46. Madison, Wis. Metro Transit, City of Madison47. Milwaukee, Wis. Milwaukee County Transit System48. Minneapolis, Minn. Metro Transit49. appendiX c LisT oF parTicipaTinG TransiT aGencies

70 Muskegon, Mich. Muskegon Area Transit System50. Nashville, Tenn. Nashville Metropolitan Transit Authority51. New Orleans, La. Regional Transit Authority52. New York, N.Y. MTA New York City Transit53. Newark, N.J. New Jersey Transit54. Newark, N.J. Port Authority of New York and New Jersey55. Oakland, Calif. Alameda–Contra Costa Transit District (AC Transit)56. Orange, Calif. Orange County Transportation Authority57. Orlando, Fla. Lynx58. Ottawa, Ontario OC Transpo59. Oxnard, Calif. Gold Coast Transit60. Peoria, Ill. qC Metrolink61. Port Angeles, Wash. Clallam Transit District62. Portland, Ore. Tri-County Metropolitan Transit District of Oregon63. Providence, R.I. Rhode Island Public Transit Authority64. Redondo Beach, Calif. Beach Cities Transit65. Reno, Nev. Regional Transportation Commission of Washoe County66. Rockville, Md. Montgomery County Ride On67. Salem, Ore. Cherriots–Salem/Keizer Transit68. San Diego, Calif. San Diego Association of Governments (SANDAG)69. San Francisco, Calif. San Francisco Municipal Transportation Agency70. San Mateo, Calif. SamTrans71. Santa Cruz, Calif. Santa Cruz Metropolitan Transit District72. Santa Monica, Calif. Santa Monica’s Big Blue Bus73. Seattle, Wash. King County Metro Transit74. State College, Pa. Centre Area Transportation Authority75. Syracuse, N.Y. CNY Centro, Inc.76. Tacoma, Wash. Pierce Transit77. Tallahassee, Fla. Star Metro78. Toledo, Ohio Toledo Area Regional Transit Authority79. Topeka, Kans. Topeka Metropolitan Transit Authority80. Toronto, Ontario Toronto Transit Commission81. Washington, D.C. Washington Metropolitan Area Transit Authority82. West Covina, Calif. Foothill Transit83. Wilmington, Del. Delaware Transit Corporation84. Winnipeg, Manitoba Winnipeg Transit System85. Woodbridge, Va. Potomac and Rappahannock Transportation Commission86.

Next: Appendix D Agencies and Automatic Passenger Counter Manufacturers »
Passenger Counting Systems Get This Book
×
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB's Transit Cooperative Research Program (TCRP) Synthesis 77: Passenger Counting Systems explores analytical tools and technologies for collecting transit ridership and other subsidiary data. The report also examines issues of potential concern to transit agencies considering automatic passenger counter systems.

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!