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.

SUMMARY Project Description This research was conducted to assess the exchange of (computer based) data between transportation providers, brokers, customers and human service agencies for successful mobility management undertakings. For decades, communities have been pursuing mobility management to improve transportation options for older adults, individuals with disabilities, individuals with low incomes, and, more recently, veterans. The success of mobility management requires effective exchange of information among transportation providers, service brokers, customers, and agencies that provide health, social, education, and other services. Events have converged in the last decade resulting in a need to examine how technology can be used to enhance mobility management and coordination activities. The goal of this research is to identify opportunities for the standardization of data relevant to mobility management systems, focusing on realistically achievable objectives that can be attained in the near-term, including possible specifications, and which can also contribute to more ambitious outcomes over a longer time frame. Data standards will provide a foundation for important advancements including: • enabling transportation brokers or providers to efficiently share trip records regardless of the brand of scheduling software they use, • developing a means for customers (whether individuals, mobility managers, or human service agencies) to obtain information on trip availability and cost, and • allowing software developers to build applications that use the data for both transportation agency use and customer use. (For example, we are now seeing applications using the fixed route data available for transit systems that have put their data into General Transit Feed Specifications format, including applications to assist people with disabilities. As the availability of standardized data becomes widespread, the benefits of such standardization will be increasingly manifest.) While there are challenges to developing data standards in such a diverse industry, the expected advancements illustrate how the public sector can benefit from improved communications between software programs and the investment of private sector industries, whether large companies or individual software developers. The federal commitment to improving mobility management, as demonstrated programs such as United We Ride (UWR), Mobility Services for All American (MSAA), and The Veterans Transportation and Community Living Initiative (VTCLI), provides further impetus for moving forward. Leadership and a clear vision will be needed to establish data standards. 1

This research examined the types of data that are used in technologies that are part of mobility management systems as well as the environment in which these software systems function. The recommendations address: • Where data standards will provide value for mobility managers; • The specific data and related protocols needed for improved functionality; and, • Guidelines for procurement specifications for agencies purchasing new technology for mobility management. This report presents the research findings and conclusions. It includes a survey of both private vendors of scheduling and dispatch software and a range of transportation agencies considered to be on the advance edge of standardized data and/or are Veterans Transportation and Community Living Initiative (VTCLI) grantees. Audience of This Report This report is intended to be read both by individuals with a technical background and by planners and managers with more limited understanding of technology, but whose organizations make use of the technologies that are relevant for mobility management initiatives. While data standards and the specifications that implement them of necessity involve technical elements, in this context the purpose of standardized data is to improve the feasibility of achieving organizational objectives. Planners and managers need to understand how the absence of data standards is constraining their ability to develop effective mobility management systems. At the same time, those whose focus is on software systems need to understand the data relevant to mobility management and the data standardization needed for interoperability to become feasible. Both audiences need to understand the process necessary to advance data standards for mobility management services. Problem Understanding As the research team explored the problem, we found that it contained multiple components. There are two basic aspects to consider: • The functional aspect of understanding what data needs to be transferred among different organizations and software applications to improve ease of use and enhance productivity • The context in which the software vendors and transportation providers conduct their businesses. Developing a clear understanding of the problem and its components is critical for identifying potential solutions. We found a useful framework to be consideration of two different activities, that of information discovery and that of service transactions, each with its own characteristics and data requirements. 2

The discovery tasks have a customer focus, and cover both fixed route and demand response transportation. How does the customer find out what service options exist? 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. Trip planners that may be found on transit agency or 5-1-1 websites are an important tool in the discovery phase. The transactional activities are the primary content of scheduling and dispatch software, although such software is generally focused on an individual transportation provider’s trips and not on how such data is exchanged among multiple transportation providers. Transactional data is of primary concern to transportation providers. The transaction phase occurs not with the end- user or passenger, but rather with the transportation providers 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 job it out to another transportation provider, and verify the trip was made. The problems that need to be addressed are oriented around two topics: • Standardizing data for both the discovery data, as used both by transit systems and information and referral services and transactional data for demand response services to promote the efficient exchange of information among service providers. • Developing a means to engage software vendors and the entire industry of transportation providers in developing and maintaining data standards for mobility management, and providing a mechanism to support their evolution over time. Current Environment At present there are less than a dozen companies that provide reservations and scheduling software for demand response transportation providers, with two or three major firms and a variety of other firms with smaller market share. Some scheduling software products are part of a complete suite that can address all modes; others are directed at demand response transportation services. Some are best suited for small or medium-sized systems; others are suitable for large systems as well. When transportation providers who are purchasing such software request that it be able to exchange data with a transportation provider using a different brand of scheduling software, vendors typically create a “translator” that is specific to the two programs. This includes a data dictionary for the software programs and a user-friendly interface for the schedulers. For the discovery data, trip planners are the primary relevant type of software used in the information and referral (I&R) function. Today most medium-to-large size transit systems include trip planners on their web pages. Trip planners have become more effective over time, 3

especially in improving the accuracy of identifying both desired origin and destination locations. They may have the flexibility to provide alternate itineraries, provide directions and/or a map, and print the itinerary in reverse for the return trip. Fortunately for 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. With the GTFS data specification, trip planners and other web applications are able to use standards-based data and 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. Survey of Software Vendors and Transportation Providers The research team canvassed two key stakeholder groups: software vendors and transportation providers. We contacted all of the demand response software vendors with a significant market share to determine their perspective on data standardization for mobility management systems. In addition, the team contacted transportation providers and others, focusing on those: (1) actively exploring the issues around how to exchange data, and (2) VTCLI grantees using this particular funding opportunity to advance the exchange of data related to either discovery or transactional functions. Both groups were contacted by telephone and/or email and requested to participate in an interview and almost all participated. These interviews helped to develop the problem understanding, illuminated the context within which the software vendors and transportation providers function, and helped to identify the types of solutions that would be viable. Interest in Standardized Data Among both the software vendors and transportation providers whom the research team interviewed for this project there was general consensus that standardized data for demand response scheduling software is desirable. Transportation providers have a different perspective on this than private software vendors. Transportation providers are aware of how exchanging data with other transportation providers is key to sharing trips among transportation providers, opening up opportunities to operate service more efficiently and provide more mobility. At the same time, only a few transportation providers have enough experience to understand the impact of data standards on what they do (or wish to do) or to have opinions on different approaches. Although transportation providers express the desire to be able to have their software applications communicate with those of other transportation providers, across varied software systems, there is considerable distance between their vision and the reality of what must occur in 4

order to make possible the easy and reliable exchange of data. Individual transit providers can request that software vendors create a means for them to share data with another system, and the result is a unique software solution that enables these two particular systems to communicate electronically. However, the solution is not transferrable and may need adjustment anytime either of the software applications go through an upgrade. There is not yet a unified approach to creating data standards. Software vendors expressed varied opinions, but with an overall consensus of support for standardized data. At present, when vendors respond to a Request for Proposals that specifies interoperability between two or more transportation systems, a unique software solution using some form of “translator” and “data dictionary” is created for that application. The more data that follows agreed upon standards, the less translation is needed. There was also a general consensus that the approach of starting small, with a minimum number of data elements, is preferred. The minimum data set can be expanded over time based on what is most useful. It is important to note that some degree of translation will continue to be needed, especially until the set of standardized data is robust. Having a base set of standardized data would allow software vendors to focus on enhancements to the basic data, in the translation process, to distinguish their products. Some concerns noted by software vendors included: • The competition among software vendors is an important aspect of the market economy. Therefore, it is important that standards be neutral, not giving an advantage to any vendor. • The process of establishing and maintaining standards. Who will be responsible? What will be the role of software vendors? • Who is going to take a lead role in this process? What if only some software vendors participate? Lessons Learned from Transportation Providers Interviews with transportation providers converged around the following points. • Customer knowledge is limited. Customers often have a clear picture of the outcomes desired, however they do not have the sufficient expertise to assure that the software products they purchase will achieve these results. • Mismatch with Technical Knowledge of Software Vendors. Transportation providers are not on even footing with private software vendors when they go to purchase scheduling and dispatching software and related products. Few transportation providers have sufficient IT knowledge to ask all the right questions and evaluate the responses. • RFPs are Often Generated by Consultants. The use of consultants is effective at bringing together two complex fields: technology and the delivery of demand 5

responsive transportation. However, much of the expertise for defining how technology can be used to address these complex transportation problems is not being developed by transportation providers. • Early Adopters Have Few Models. As in most industries, there are a few individuals who are seeking to make the most of available technology to meet the needs of their region. These efforts have resulted in the development of useful approaches, and are leading the way. The TCRP IDEA Project 50 report, “Developing Regional Mobility Management Centers”, identifies how TransPro of Tacoma, Washington has used a translator and the value of this approach. Ride Connections in Portland, Oregon is developing open-source software that uses a “trip ticket” approach to exchanging data. Framework for Data Standards Effective mobility management requires the efficient exchange of information among the multiple parties who are involved in organizing, providing, consuming, and financing local transportation services when the process of obtaining and delivering such transportation crosses organizational boundaries. The recommended framework is organized into discovery and transactional data. The type of data needed for each facet is different, although related. There are significant differences in discovery and transactional data, so the approach to and process of standardization will be quite different for each set of data. The problems associated with standardizing such data also vary as discovery and transactional processes have developed in different contexts. Approaches to Standardized Exchange of Transactional Data Many industries or vertical business segments have a need for the major software systems that organizations use to exchange data with other organizations. In the past decade, three major approaches to standardized data exchange have become commonplace. 1. Explicit data standards, whereby a core set of data is designated. 2. Data hubs, which provide a mechanism for applications to exchange data without directly communicating with one another. 3. Application programming interface (API) mechanisms, which are essentially a bi-lateral mechanism that enables collaborating systems to exchange data. Each of these approaches has advantages and disadvantages, and all are potentially relevant for mobility management activities. The focus in this project is on the first approach, in which an “industry” group of some type agrees on data formats and a mechanism for data communication and publishes these as the standards for data exchange. Processes for Developing Specifications and Standards 6

When the public and private sectors develop standards, there are several commonalities. All such processes take time and are iterative in nature. Leadership is a key element although these processes are essentially collaborative activities. The individuals who work on the effort may be volunteers or employees of companies that believe it is valuable to invest their employees’ time in the development of standards. Proposed Approach and Core Elements Achieving any level of data standardization, particularly for service transactions, is likely to be a challenging process that will probably occur incrementally and iteratively. This suggests that a “walk before we run” approach to agreeing on standardized data is more likely to be successful than trying to obtain agreement on comprehensive data standards and data exchange protocols as the initial objective. Accordingly, the research team’s assessment of the core data elements that need to be included in the initial data standards follow. Data Elements for Service Transactions The data needed to support service transactions include: 1. Trip data 2. Passenger data 3. Organization data 4. Financial data 5. Vehicle data The two primary data records are the: (1) passenger record, consisting of 16 data elements, eight of which are mandatory; (2) the trip record, consisting of 18 data elements, 16 of which are mandatory. The other record types—organization, financial, and vehicle—have a total of 17 data elements, of which 14 are mandatory. Overall, there are a total of 51 data elements, of which 38 are mandatory. It is our understanding that all of the data fields specified are present in the software applications currently being used for demand response services. They may have different names than those used in this study, but the data itself are present in the databases used by the existing applications. 7

Data Elements for Service Discovery The data elements needed for service discovery are of a different character than those necessary to support transactions. Information and referral systems need data that describes fixed route transit, demand response and other flexible transit services that operate within the service area of the I&R system. As discussed previously, the GTFS specification has successfully standardized the data that are used to describe fixed-route transit services, but no such standards currently exist for demand responsive services. The proposed core data elements for service discovery for demand responsive services are also presented in the report. Conclusion There are concrete benefits to developing data specifications for mobility management functions. These include direct cost benefits as (1) agencies with different demand response scheduling systems are able to save staff time daily by transferring data electronically between systems rather than re-entering it; (2) States or regions will be able to avoid locking-in with one vendor, allowing individual DRT providers to purchase scheduling software that best suits their size and type of organization rather than a program that is more than they need; and (3) informed purchasers of software will be more likely to purchase the appropriate product for their agency, including specifications for interoperability across technology platforms. More importantly, such data specifications will enable transportation providers to adapt to current technology and continue to innovate as technology changes and improves. It will enable transportation agencies to easily subcontract with smaller service providers who may have available capacity, reducing the cost of service and improving productivity. The recommended approach is to actively involve transportation providers and scheduling software developers in a collaborative process to define specifications. Both bring important perspectives to the process. Further, it is recommended that the effort start small with a minimal set of data items, growing over time. 8