Standardizing Data for Mobility Management (2013)

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.

II. CONTEXT There are several important aspects to the problem context; each will be discussed in this section. They are: • A functional understanding of the problem • Perspectives of software vendors and developers • Perspectives of transportation providers and human service agencies In addition to understanding the perspectives of these key groups, it is useful to understand the environment in which they function. This is discussed in the individual sections on perspectives. In addition, the last part of this section describes the data used in information and referral applications and the unique impact of Google Transit. A Functional Understanding of the Problem The consulting team began by gaining an understanding of the research problem from the perspective of the end users – transportation providers, human service agencies, and the clientele or community residents they serve. We view the research problem as having two facets: • An operational focus, concentrating on data that helps two or more agencies arrange the delivery and payment for trips • A customer focus, concentrating on data that helps customers to access information about how to meet their mobility needs. Figure 1 on the following page is a schematic developed to describe these two perspectives. Begin with the customer focus. A customer (individuals or a case worker for a human service agency or other representative) needing to arrange transportation may use a call center or information and referral service, a web-based trip planner, or simply a set of bus schedules to figure out how a particular trip can be made. If the trip can be made using a fixed route bus, the passenger will have enough information from these sources to make the trip. If the trip will be made using a demand response service, additional steps will be needed to assure the rider is eligible (except for general public demand response services) and to schedule the trip. The operational focus takes place once passengers who are eligible for trips schedule the trip. At this point, data that supports reserving a trip, scheduling it on a vehicle, reporting on trips taken, and the billing and payment related to the trip are needed. Demand responsive transit (DRT) services typically utilize software for reservations and automated scheduling of trip requests. There are several different software applications that command a significant market share among providers of DRT services and these applications do not currently have common data structures nor are they capable of true interoperability. Even relatively basic data sharing among such scheduling systems has proven to be difficult to achieve. This makes it difficult for transportation providers to communicate with each other or with their subcontractors. 12

Figure 1: Schematic of Transportation Agency and Customer Functions as Related to Data 13

Discovery and Transactional Data As the research continued, we found a useful framework to be breaking the trip down into two different phases, each with its own characteristics and data requirements. The first is the discovery phase and this relates to the customer focus common to mobility management activities. How does the customer find out what options exist? Is there fixed route or demand response service available at the time the trip is needed? Does it go between the origin and destination? Are transfers needed? Can it accommodate the passenger’s wheelchair, service animal, or other needs? What is the cost? Is there space available? The customer may need to have a variety of questions answered in order to make the trip. Many riders of demand response services could use fixed route services for all or part of their trip, so discovery data that links the two is valuable. Discovery tasks cover both fixed route and demand responsive services, including those services for persons with disabilities. Discovery data is of primary concern to information and referral centers, individual passengers, one-call/one- click transportation centers, or mobility managers concerned with assisting passengers with finding the most appropriate and cost-effective means of transportation for a particular trip. Computerized trip planners that may be found on transit agency websites or 5-1-1 websites are an important tool in the discovery phase. The second type of data is transactional data. This is the primary content of scheduling and dispatch software, although such software is generally focused on an individual transportation agency’s trips and not on how such data is exchanged between multiple transportation agencies. Transactional data is of primary concern to transportation providers and service sponsors. The transaction phase occurs not with the end-user or passenger, but rather with the transportation providers (and non-provider service sponsors) involved in delivering a trip on a demand responsive service. The transactional data is that which is needed to schedule a particular trip on a vehicle, provide the trip or subcontract it out to another transportation provider, and verify the trip was made. In the process of delivering the trip, information such as time of pick-up, delivery, and drop-off; trip mileage; and fare paid, trip cost, and other billing information is gathered and becomes a part of the trip record. Service Discovery Tools The VTCLI project in San Bernardino County, CA has a strong focus on the available fixed route services that Veterans can use to access the VA Medical Center. The 2-1-1 system, an information and referral agency, is a key partner. Key tools are: • the trip planning software to enable Veterans and 2-1-1 information and referral staff to identify available services and • a listing of transportation services by facility The website can be fouind at: http://www.ie511.org/veterans- transportation.aspx 14

Figure 2 illustrates a typical screen showing the use of transactional data for a DRT system. Discovery and transactional data will be explored in more detail later in the report. Source: Transportation Research Board Transit IDEA Project 50 Final Report "Developing Regional Mobility Management Centers"; original screen shot courtesy of Mobilitat Software. Figure 2: Typical Scheduling Software – Use of Transactional Data within a System Software Used for Discovery and Transactional Data The software used for discovery and transactional functions are fundamentally different from each other. It is useful to begin with a description of each. Scheduling and Dispatch Software (Transactions) There are a small number of private firms that have developed scheduling and dispatch software for DRT providers. These various products are differentiated on a variety of factors; some are geared towards small systems and others towards larger more complex systems; they may have different levels of emphasis on developing a suite of related products, customer service, or specific features; and they developed out of different backgrounds and this is reflected in their structure. The backgrounds from which these systems developed include community transportation, fixed route transportation, human service transportation and even the taxi industry. In other industries, such as the airline industry, the airline companies themselves initially developed and maintained ownership of the primary software used for transactional data. In 15

contrast, the vast majority of DRT providers (or non-provider service sponsors) do not own the software they depend on for transacting business. This is largely a consequence of the size of the individual businesses needing such software as most could not justify the information technology staff to develop or maintain the software. As a result, most DRT providers have not gained the desirable levels of experience that would make them informed purchasers of software. Another result of this situation is that a partnership between the private software vendors and the transportation providers is needed. The involvement of DRT providers is needed to define what is needed to support efficient business activities; the involvement of the private software vendors is needed to develop products that meet the needs of the market. It is worth noting that there are some examples of transportation agencies that have developed their own software platforms (typically via contracts with software development companies or by hiring software developers for this purpose). In the state of Oregon, considerable work has occurred in this area. Tri-County Metropolitan Transportation District of Oregon (TriMet) has been actively involved in developing and maintaining open source software both for transactional data for DRT systems and for their fixed route trip planner. The Oregon Department of Human Services has long worked with transportation brokers for scheduling Non- emergency Medical Transportation trips (NEMT) under the Medicaid program and its state-level counterpart. Oregon’s software is the basis for this open source scheduling and dispatch software. Ride Connection in Portland is at the forefront of developing software using open source formats. In addition, Lane Transit District in Eugene, OR has developed its own software platform that supports order taking, scheduling, service brokerage, billing, and other functions for multiple types of DRT services in its area of jurisdiction, including DRT services operated by other (human service) organizations. The Denver RTD is another example of an organization that developed its own technology platform, in this case for its general public DRT services. Information and Referral Software Used for Discovery Data There are three basic relevant types of software used in the information and referral function: • Trip planners (an application that shows a user how to get from point A to point B at a specified time by using public transit, often via a map-based interface). • Databases that provide standard information about a wide range of social services, and transportation, through the 2-1-1 networks or long-term care options (through Aging and Disability Resource Centers). • Databases that are client-focused and provide broad information about the needs of clients in a community, such as that developed through the Robert Woods Johnson Foundation and used in community-based volunteer programs. While the latter two are important to be aware of, the focus at this point is on trip planning software applications. 16

Transit networks of bus and rail services are complex; they have many routes, each with different schedules that vary by the time of day or day of the week. Efficient networks are often fine-tuned, with limited stop service on busy routes or in peak periods, deviations at certain times, and frequency of service based on demand. Some transit systems include general public demand response services (DRT) in areas of low demand. In small cities and semi-rural areas, DRT may be the only form of transit service available. The extensive data makes it challenging for an information and referral staff person to provide the variety of data needed to persons calling in for travel information. Rather than trying to answer such questions, callers may be simply referred to a transit system call center. If a trip requires more than one transit system, not uncommon in urbanized areas, additional calls are needed. Years ago, riders primarily obtained information on services through schedules and a system map. Using these tools it is possible to figure out the options that exist using different routes or at different times of day, but this can be challenging for many people. Telephone information lines grew in popularity, with prospective riders calling for information on how to make a particular trip. Agents ask callers for trip origin, destination, and the time of day the trip will be made; they tell the caller where to catch the bus and at what time, often giving information on the next bus (20, 30 or 60-minutes later). As web sites were developed over the past decade, it became possible for riders to either look up schedules and maps online or to use a trip planner to obtain the needed route and schedule information. Today most medium-to-large size transit systems include trip planners on their web sites. Web sites for 5-1-1 include trip planners, or may connect directly to the transit system trip planner. These trip planners function much like the telephone information lines: users enter the origin, destination, and desired time of travel. The trip planner application responds with information on how to make the trip using transit including specific bus route, location of stop, time the bus will arrive at the stop, and time scheduled to arrive at the destination. Trip planners have become more effective over time, especially in improving the accuracy of identifying both desired origin and destination locations. They often have the flexibility to provide alternate itineraries, provide directions and/or a map, and print the itinerary in reverse for the return trip. A rider may be able to choose between multiple trip planner applications, and use a help function for hints on how to use it or to troubleshoot. There are trip planners available through Google Transit, Open Source platforms, and, in large metropolitan areas, also through a variety of private software vendors. Perspectives of Software Vendors and Developers The project team contacted DRT software vendors with a significant U.S. market share to determine their perspective on data standardization for mobility management systems. The software companies were contacted by telephone and/or email and requested to participate in an interview with one or more members of the project team. A total of seven companies were 17

contacted; six agreed to participate in an interview. The interviews were conducted by telephone and typically lasted 60 to 90 minutes. While the project team had developed questions and topics to guide the interviews, the actual interviews tended to be wide-ranging as the subject of data standards was not something that many of these organizations had given a great deal of attention or thought to. The DRT software companies come in two distinct categories. There are three relatively large companies (one quite large) and several smaller competitors. The larger companies have many installations of their software or at least a number of very large installations. The smaller companies are focused on smaller demand response systems and may have a limited number of installations as well. In addition, whereas the larger companies have many technical staff, the smaller companies may have only a few technical staff, and possibly no more than a single senior software developer, who is often a key executive of the organization. As a result, both the situations these organizations have been exposed to in terms of needs/desires for data exchange, and the level of resources available to modify their core software applications in response to any data standards, are quite different between the two classes of software providers. Major Software Vendors Perspective Two of the three major software vendors have considerable understanding of mobility management systems and some level of involvement with such systems. One was selected to provide the software for some of the FTA-funded United We Ride demonstration projects for mobility management. The other’s software applications have been used in several multiple organization systems that bear some resemblance to mobility management systems, and the company has experience with a number of transportation brokerage systems. In contrast, the third major vendor has not been as involved in mobility management or brokerage systems, although its software does have some integration with fixed route trip planning software to be able to determine fixed route transit ride times as part of the ADA Complementary Paratransit trip scheduling process. All three of these software companies expressed a willingness to participate in a process that could lead to data standards for DRT software applications. At the same time, two of the firms have developed - and continue to develop - products that represent proprietary approaches to data standardization. One company has developed a product that enables different organizations that are using its core demand response software application to exchange trips and service capacity; transportation agencies can post trips that they do not have the capacity or other resources to provide themselves and would like to have other transportation agencies provide, and transportation providers can view and select the trips from this “white board” that they wish to transport. While this product contains functionality that is core to the needs of mobility management systems, it works only with the company’s own software applications, and not applications from other DRT 18

scheduling software vendors. This product currently does not include “connectors” or “adaptors” that would enable other software applications to post trips to or select trips from the white board. The other major company has also recently developed a new product that promises data integration and data exchange, and appears to have a number of features that are central to a mobility management system. In contrast to the system described in the paragraph above, this other application contains a mechanism for third party software systems to connect to the vendor’s hub application and includes a dictionary-type mechanism to facilitate data translation. But while this other major company is currently promoting this product, and the data dictionary approach to data translation embedded in it, as a mobility management system solution, it has also indicated to this study’s researchers that it supports the development of data standards for application interoperability. It has further indicated, moreover, that it would prefer the standards- based approach to its current data dictionary approach as the mechanism for enabling multiple applications to interoperate and exchange data. Other Software Vendors Perspective The software vendors with smaller market shares have much less experience with situations involving some form of mobility management initiative, and in some cases essentially none. Only one of these vendors interviewed appears to have given much consideration to data standards or application interoperability. As one of the contributors to the TCRP IDEA-50 study, this firm has also developed a software tool that enables data to be translated from a source system’s format into a format where it is compatible with its own software. The larger vendors also have developed such translators. These vendors view data standards as a generally good thing and are supportive of efforts to develop such standards. They would be willing to participate in a standards-setting exercise, but may have little conception of what that would mean in practice. Whether they have the internal resources to develop additions to their own software to produce standardized data to the external world, and to create adaptors/connectors that would facilitate data exchange between running software systems is a question not easily answered in advance. The level of effort needed to enable real-time data exchange - using standardized data - among these vendors’ applications and those of another vendor or a central data hub is likely to be significant, measured in person months. This will include the planning, design, and implementation work, including participating in some measure in demand response industry-focused planning as well as the design of the standards and approaches. The Influence of Market Dynamics on Software Vendors Potential Responses The current situation in the DRT software industry, where 2 companies have the dominant market share and the other software companies are smaller and mostly focused on smaller systems (although two of the smaller firms have recently been awarded a contracts by two different states--Pennsylvania and Illinois--that makes their software available to most of the 19

small-medium demand response systems in the state), poses challenges to incentivizing collaboration on data standards by industry participants. The two largest software companies do not have strong incentives to support data standards or non-proprietary data exchange approaches. They are likely to derive limited value from data standards and standards-based data exchange mechanisms, since an alternative is for all of the providers in the mobility management system to use these large companies own software, which can now support multiple separate operating entities with nominally separate fleets but with the capability of automated or at least semi-automated trip exchange. For the large software companies, supporting data standards and application interoperability probably means providing a more even playing field for their smaller competitors vis-a-vis the initial structuring of a mobility management system. The two software companies with the largest installed base understand that there is potential benefit to them as well from data standards, since they may facilitate the development of mobility management systems in which there is a need for the products developed by these companies specifically for this market. But it is also clear that neither of these companies currently perceives that a non-proprietary approach to data standards/application interoperability is essential for expanding their business. In the course of this study, one of the two largest software companies moved from a position of lukewarm support for data standards to one in which they indicated they are now prepared to assume a leading role in helping move data standards forward. Like all of the software companies, they were not sure how that process might unfold, but it is significant that this company, which by all indications has the largest installed base, expressed a willingness to take an active leadership role a data standards development process for mobility management. Perspectives of Transportation Providers and Human Service Agencies The project team contacted a range of transportation providers with an emphasis on those either exploring the issues around how to exchange data and/or are VTCLI grantees using this particular funding opportunity to advance the exchange of data related to either discovery or transactional functions. Interviewees were identified by panel members, by other interviewees, by the project team’s knowledge in the field, and through a review of VTCLI grantees conducted for TCRP Project B-42. The transportation providers were contacted by telephone and/or email and requested to participate in an interview with one or more members of the research team. Four of these transportation agencies were contacted and participated in an interview. The interviews were conducted by telephone and typically lasted 60 to 90 minutes. As with the interviews of software vendors, these were guided by prepared questions and topics, again the actual interviews tended to be wide-ranging as each transportation provider had some unique perspectives on the issues. 20

Customer and Other Perspectives. Interviews with transportation providers illustrate the knowledge and awareness among those who depend on the exchange of data to improve mobility, or to provide more—or more efficient-- service to their constituents. A limited number of providers were interviewed, but the results converged around the following points. Customer knowledge is limited. While customers often have a clear picture of the outcomes desired, they do not have the level of knowledge needed to assure that the products they buy will achieve these results, much less do so in a way that considers the unique situation in their region or positions them for the future. Mismatch with Technical Knowledge of Software Vendors. Transportation providers are not on even footing with private software vendors when they embark on the process of purchasing scheduling and dispatching software and related products. Few transportation providers have enough IT knowledge to ask all the right questions much less evaluate the responses. This is compounded by the fact that the product(s) needed to meet their vision is quite possibly not available. RFPs are Often Generated by Consultants. Because of the transportation providers’ limited knowledge of information technology, they often rely on consultants to prepare both minor and major RFPs for software and related equipment. In major procurements, the vendor may be a third party IT developer or consultant in the IT field. However, much of the expertise for defining how technology can be used to address these complex transportation problems is not being developed among transportation providers – the organizations and individuals who often best understand the idiosyncrasies of delivering trips and managing mobility – and who must live with the results. Early Adopters Have Few Models. As in most industries, there are a few organizations who are seeking to make the most of available technology to meet the needs of their region. Those organizations who wish to try work with an existing vendor to exchange data efficiently with other transportation providers have few models of how to achieve this. Nonetheless, such efforts have often resulted in the development of useful approaches, and provide potentially replicable examples. Examples of what has been tried include various “translators” or development of “data dictionaries” to import, export, and use data generated by other systems in an efficient manner. The TCRP IDEA-50 report identifies how TransPro of Tacoma, Washington has used a translator and the value of this approach. Ride Connections in Portland, OR is developing open- source software that uses a “trip ticket” approach to exchanging data. No Industry Standards to Drive Project Objectives. Industry standards that could set expectations for various functions and products do not currently exist. Such standards would support transportation providers in building a common understanding of their options for addressing the question of “How can I efficiently share data with the small providers in my 21

region who operate with different or manual scheduling systems?” Knowing the available options would help to drive project objectives and assist in measuring success. Challenges and Opportunities While contemporary information technologies clearly enable the development of potentially powerful mobility management systems, a key potential barrier to the realization of such systems is the current absence of data standardization among the various software applications and systems used by organizations and individuals that will be part of such initiatives. The different software applications that command a significant market share among providers of DRT services do not currently have common data structures nor are they capable of true interoperability. Even relatively basic data sharing among such systems has proven to be difficult to achieve in practice. Standard data definitions and protocols that guide the exchange of data are core requirements for software applications to achieve higher levels of functionality and interoperability. Without such data and protocol standardization, applications and systems from different software providers cannot “talk” to one another, restricting opportunities to construct more comprehensive systems than are provided by any one software vendor or type of application. Mobility management initiatives will clearly be facilitated by data standardization. For example, in the airline industry there is a standard format for an electronic record of an airline ticket (the “passenger name record” or “PNR”) that allows multiple airlines to exchange information when a passenger travels on 2 or more airlines in the course of an itinerary. This enables each airline to extract the information relevant to its portion of the itinerary—including how much of the total fare it should receive. If a comparable standard “trip ticket” existed for local transportation as part of a mobility management system, then each organization involved in the process of arranging for and delivering the transportation of the passenger—service provider, funding agency, service organizer, service broker, call center, etc.—would be able to obtain the information it needed from this trip ticket without concern about which reservation and scheduling system was used to book and manage the trip, or which funding source was paying for the trip. Such data standardization would remove an important technological impediment to the establishment of mobility management systems that involve multiple organizations and diverse software applications used by those organizations. Information and Referral Systems and the Google Transit Situation A substantial portion of the VTCLI projects do not plan to go beyond information provision in their initial program implementations. According to an analysis of VTCLI grant information performed as part of TCRP Project B-42, over 60% of the grant recipients intend to focus on information and referral systems initially. While some of these grantees may eventually evolve to a more transactionally-oriented mobility management system, many may not move beyond information and referral functionality. 22

Information and referral (I&R) systems generally (and most One-Call/One-Click services) are in their essence service discovery applications. A client contacts an information resource and that resource provides information specific to the client’s needs about the services that are available, including helping the client navigate through whatever organizations and their processes that they must interface with in order to obtain the needed service. I&R systems for mobility management must inform the client of what transportation services are available, and then provide them with information that will enable them to make use of these services for one or more specific trips that the client needs to take. This may include information about fixed route transit routes and schedules and information about demand responsive services, including where and when DRT services are available and their eligibility requirements and fares. It may also include information about services provided via human service agencies, including those that may rely on volunteer drivers or other semi-formal arrangements. A trip planner application may assist the client in showing them how to get from their origin to their destination, particularly useful for trips on fixed route transit that involve multiple transit routes. By using the I&R system the client “discovers” their transportation service options and how well they fit with their trip needs, and can then make a choice as to which service(s) to utilize. For service discovery applications to work effectively, it is very useful for the data that describes the different available services to be in a common format. Otherwise, the organization that provides the I&R service faces the daunting problem of sourcing data in many different formats from many different organizations, and then transforming it into a consistent, comprehensive data set. Without common data standards, the result is likely to be inconsistent and incomplete information on the services available. Fortunately for those organizations sponsoring I&R services who need information on public transit services, a common format for fixed route transit data does exist, courtesy of Google, which developed the General Transit Feed Specification (GTFS) for its Google Transit product (which works in the context of its Google Maps product). The GTFS is a published data specification for fixed route transit initially developed by Google, but now open to input for modifications and extensions from a larger community of interested parties who use GTFS data. As a result of the GTFS data specification, which has become the industry standard for the public transportation industry, web applications, including trip planning applications, are able to “consume” standards-based data that describe the fixed route transit services in an area and use those data to display map-based user interfaces that show transit routes and stops and service timetables. These applications thus enable potential transit users to discover their travel options and to plan their trips. The GTFS specification is the key to the usefulness of Google Transit, trip planning applications, and other web-based applications that provide information on fixed route transit services. Since data about transit services is “published” in a common, consistent format, applications can be developed with the assurance that the data they “consume”—which is published by another organization—will be in a known format and hence will have the same 23

meaning from service to service and from system to system. This has led to the development of many applications, including mobile applications running on smartphones, for transit users in a number of large cities. The GTFS specification has essentially solved the problem of service discovery for fixed route transit services, but this specification does not currently encompass demand responsive services and other forms of flexible transit. An initiative is now under way, stimulated in part by this study, to develop initial GTFS specifications for DRT and other flexible transit services. It is conceivable that the flexible transit specification will be added to GTFS within the next several months, which would be extremely valuable for mobility management I&R systems. If a DRT/flexible transit specification is indeed added to the GTFS in the near future, the data will be quite different than for fixed route transit. Because some flexible transit services include features similar to fixed route transit, such as points that are visited regularly on a schedule, there will be some overlap between the fixed route data elements and those for DRT/flexible transit. Nonetheless, many of the data elements for the flexible transit specification will have no counterpart in the fixed route specification. The data elements that appear to be most important to include in a DRT/flexible transit extension to the GTFS are set forth later in this report. 24