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.

III. DATA FRAMEWORK AND STATE OF THE PRACTICE Framework Effective mobility management requires a system that facilitates 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. A useful mobility management system in today’s world will be one that is based on information technology and which takes full advantage of the inter-connectedness made possible by web-based technologies and data flows. The scope of such a mobility management system can encompass some or all of the following functional areas: • Trip information—including origin to destination trip planning for fixed route and demand response services • Trip booking—actually securing a seat on a vehicle trip when a reservation or other pre-arrangement is required • Service planning—determining what types of services need to be provided, including when and where • Scheduling and routing of vehicles to meet traveler requirements • Real-time vehicle tracking (using GPS-based AVL) to assist in dispatching, routing and operational control of vehicles delivering services • Fare payment via electronic (non-cash) methods • Financial management of the flows of funds among travelers, service providers, and funding sources Discovery and Transactional Data This framework discussion is organized into discovery and transactional data, as described in Chapter II. The type of data needed for each facet is different, although related. Table 1 identifies and illustrates some of the key differences between discovery and transactional data. Because of these differences, the approach to and process of standardization will be quite different for these two types of data. The problems associated with standardizing such data also vary, inasmuch as discovery and transactional processes have developed in different contexts. 25

TABLE 1: Characteristics of Service Discovery and Transactional Data Discovery Data Transactional Data Where Used: Transit websites, 2-1-1 and 5-1-1 services, other information and referral services Where Used: Providers of demand response services, either within a single organization or among brokers or providers Tasks: • Service type and characteristics: what type of service is available for a given trip; accessibility, and if reservations are taken/needed (fixed route or some form of demand response) • Temporal factors: when service is offered, how long a trip takes, the timing of transfer connections • Eligibility factors: General public or some subgroup (seniors, Veterans, etc.) • Cost factors: Fares, how to purchase tickets Tasks for demand response services: • Passenger record data • Trip origin, destination, time of travel, and return trip information • Eligibility and fare information • Special conditions: accessibility equipment, service animals, aides, special instructions for pick-up or drop-off • No show or changes in reservation • Verification of trip completion (time, date, mileage, etc.) • Program billing information Development: 2-1-1 Social Service information and 5-1-1 Traveler information services started as telephone only services, later transitioning to web pages. • 2-1-1 services generally use summary level information, not adequate for the detail needed for individual trip planning activities. A comprehensive taxonomy and set of procedures have developed to enable these services to provide broad-based and accurate information. Some have developed more extensive services in particular areas (child care, Veterans, etc.) • 5-1-1 services in many states are limited to roadway information. As they transitioned to web services and mobile applications, more extensive services could be provided. The San Francisco Bay area was a pioneer in providing ridesharing, fixed route and demand response transit, and bicycle information. San Diego is another example of comprehensive services. http://511.org http://transit.511sd.com Development: The primary work in this area has been through private software developers. Some products evolved from: • Companies that were also involved with fixed route services (primarily run cutting software). • Individuals involved in the community transportation sector, with a strong focus on demand response services, developed others. • Software for taxi dispatching has developed at the same time, with some cross. There are examples where extensive software systems have been developed largely in-house. An important example is in Oregon where TriMet has significant investment in the development of open source software. Size, complexity, and cost are one set of the differentiators between products. Some are designed and priced for small providers – often less than 10 vehicles. Others are suited to providers with hundreds of vehicles. 26

Discovery Data Transactional Data • A variety of trip planners have been developed over the past decade, with substantial improvements over time. The 5- 1-1 websites tend towards more comprehensive trip planners oriented to the diversity of services they provide. • The General Transit Feed Specifications (GTFS) allow transit services to be included in its general mapping software. • A variety of mobile applications have been developed to provide information on access to and from transit stops or for individuals with disabilities. Transportation providers began sharing data with other providers, either because they were vendors or they found that coordination improved their ability to provide mobility. • Early-on transactions were accomplished via faxes • Email was the next step As providers requested vendors to develop an electronic means of sharing data, a variety of on-off solutions have developed. Generally these are based on some form of “translator” that uses a “data dictionary”. There is interest in web or cloud based systems as many small providers do not have the IT staff capacity to maintain a complex system. Business Context: State Departments of Transportation and Metropolitan Planning Organizations have been leaders in the traveler information systems and have been responsible for a good deal of the development of software solutions. Business Context: Transportation providers generally do not own the systems they use. They rely on the private firms to make changes or adapt the system. The interest of private firms in investing is such changes is based on customer demand. Data Standardization: GTFS has provided a promising approach to standardizing data for service discovery. • GTFS may prove to be useful in establishing standards for addressing in the demand response side. • Google has shown interest in developing base data for demand response services. Data Standardization: Standardized data for service transactions represents a more challenging situation. • There are many data elements in use, but it is important to start small and then build up. • Translators will continue to be needed until a high level of standardization is achieved. • Leadership and education will be key elements in a process to begin standardizing data. Discovery Data. For I&R systems, there is a need to devise and implement systems which provide customers with the ability to “discover” transportation services in a consistent format, and to provide as much useful information as possible about the services. For fixed route transit services, this need has essentially been fulfilled by the Google Transit standard for data which “describes” fixed route services, GTFS. GTFS-based data can be used by trip planning applications (most notably Google Transit itself) and other software applications to present information to consumers interested in taking trips on transit. Regional 2-1-1 systems can consolidate information about all transit services in a metropolitan region on a single web site 27

using GTFS-based data from the transit agencies in the region, and as such offer a highly relevant model for I&R systems targeted at veterans. However, as discussed previously, there is currently no analogous GTFS data for DRT services, which leaves a major gap in what I&R systems are able to accomplish without special data generation activities aimed at remedying this deficiency. Within trip planners, the addressing function is important. It has evolved in response to common ways in which people put in addresses, at the same time that users have learned how to identify addresses in a way machines can read accurately. Many trip planners now allow one to put in an address, pick a location from a list of landmarks by type (schools, office buildings, etc.), or indicate an intersection. The adoption of widely used mapping software applications has been an important part of the transition in trip planners. GTFS is used by many transit systems to code routes and stops so they are available in online maps, not just the transit system map. They link bus routes and stops to other points or businesses on area maps. They also enable people to plan trips across more than one transit system, if each provides its data using the GTFS. The success of the GTFS, as measured by its widespread use, has resulted in de facto standards for fixed route bus information, including routing, stops, and trip time. Virtually all third party trip planner software applications use this specification. Some large transit agencies still continue to promote their own trip planner software, but even they typically provide data in the GTFS format. Because of the development of trip planners and the GTFS, the development of standards for discovery data is proceeding apace. The inclusion of DRT service information, currently lacking in these standards, is clearly desirable, but as indicated previously there are signs that this lack may be remedied to at least some extent in the near future. Transactional Data. There is an even greater gap between the needs for standardized data and current reality for transactional data. As noted previously, there are several different software packages used by providers of DRT services for the core functions of reservations and scheduling, and currently none of these software applications share common data definitions or data structures or are interoperable with each other. The only way a mobility management system could currently guarantee that all service providers would be able to share data is if they all use the same software package, and that package enables different providers to “see” each other’s data and to work against a common database. In a situation where there are several different software packages used by service providers, however, data exchange is only possible if additional software is developed specifically for this purpose. This is typically an expensive, time consuming task which acts as a major barrier to the realization of any significant interoperability for the different software packages. While standardized data would not itself solve this problem—the software producers would still need to 28

develop external interfaces to their products that would enable such standardized data to be exchanged with other applications—it is an essential pre-requisite to true data interoperability. As a result, those transportation providers intending to implement interoperable scheduling and dispatch systems are currently confronted by a choice between adopting a single software package for all participants—in a situation where there may already be a multiplicity of software packages used by the participating organizations—or commissioning the relatively expensive unique or “one-off” development of customized software to enable data exchanges among the different software applications. The process of developing standards for transactional data will need to bring together individuals from private sector software development firms and the end users, the transportation providers. Current State of Practice in Data Standards Standards. At the present time, almost no data standards exist for DRT software. This lack of data standards encompasses both service “discovery”—such as data needed for I&R systems—and service operation, where the need is for software systems to exchange “transactional” data. To the extent that any data standards do exist, it is for information that must be collected for Medicaid reimbursement of non-emergency medical transportation trips. There are both federal standards and specific state implementation of standards for the data that service sponsors must submit to a state in order to receive financial reimbursement for trips provided to Medicaid recipients. But these standards bear only minimally on the data standardization and exchange needs of software applications that would be the centerpiece of mobility management systems. Translators. Several DRT software companies have developed data translators which enable passenger and trip records to be transformed from the format used by their software application to that of another demand response software application. While such translators are clearly useful tools, a translator does not represent a data standard, nor does it appear to be usable for real-time data exchange. A translator does not have the durability that data standards provide. Translators may require adjustments each time either vendor does an upgrade. One major demand response software company has developed a product, targeted in part at mobility management systems, which features multiple “dictionaries” to enable data to move between their own software application and other software applications (from other software providers) that may be part of a larger, multi-organizational system. These dictionaries, depending on how well they are accepted by other software vendors for use as to system to system data interfaces, could serve as a substitute for data standards. At the same time, an important issue is that these dictionaries represent a proprietary approach to developing a data exchange mechanism. In most industries, data standards emerge from a proprietary application 29

only if that application has dominant market share, and no single demand response software vendor appears to have that level of dominance. In addition, without more in-depth understanding of this specific dictionary approach, it is not clear that it encompasses all of the desirable functionality for data exchange standards. The TCRP IDEA-50 project proposed the need for universal “translator” software that would enable data to be exchangeable among different software applications, albeit not necessarily in real-time with running systems. In a small number of projects, sponsors have requested software vendors to develop unique software modules that would enable two software packages to exchange data so that they can both be used in a larger “coordination” system that encompasses multiple service providers who are concerting their activities. For example, in the Longmont area of the Denver region, the Denver RTD and a large human services transportation provider, Via Mobility Services, have been progressively implementing a coordinated service project that enables both RTD and Via operated vehicles to be used by customers of either system, even as different software applications are used to accomplish reservations and scheduling for each agency’s fleet. In north central Massachusetts, two large regional service sponsors in adjacent regions are in the early stages of implementing data interoperability between the—different— software systems used to operate their DRT systems, which collectively manage scores of vehicles. Inclusion of DRT in GTFS. A notable area of deficiency in data standards is the absence of any coverage of DRT services in the GTFS. Google Transit appears open to extending GTFS to DRT services. This would largely address data standardization for service discovery purposes for mobility management initiatives or information and referral services. It also would be helpful for transit systems operating general public dial-a-ride services as part of their service network. While the time during which service is available is similar for fixed route and demand response services, discovery data for demand response services must address the area where service is available as a polygon rather than a line. It must also identify if reservations are required. Capacity is quite different for demand response service than fixed route service as additional vehicles must be assigned once the fairly low capacity limits are reached on the demand response vehicle. Additional pick-ups and drop-offs affect travel time, so the itinerary information would be less certain. Software Development Initiative. While no data standards currently exist for transactional data, at least one organization has taken the initiative to develop software that could help motivate the development of common data elements for data exchange in mobility management systems. RideConnection, an organization based in Portland, OR, chartered the development of an open source trip exchange software application that is based on the concept of “trip tickets”. The Ride Connection software enables organizations to establish a “hub” or “clearinghouse” which permits software applications to exchange data on trip requests and available trip capacity. The clearinghouse enables software applications to both post requests for service and to offer to provide rides in response to trip requests. In order for this functionality to work well, the 30

clearinghouse defines certain data that both service requesters and service producers must provide. This includes information about the trip itself, the passenger, and the costs of the service. The software used by service requesters and producers will need to develop “connectors” to the Ride Connection clearinghouse software in order to exchange data and inter- operate in real-time. Initially, the software will rely primarily on users to complete transactions via its user interface—both requests and offers can be viewed, and matching accomplished manually. But eventually automated processes could handle many transactions, although that might require additional data exchange. As this brief review indicates, there has been limited progress toward data standards for mobility management, but much ground remains to be covered until data exchange among different software systems can become routine. The absence of service description data standards for DRT services is a notable deficiency, although there is the definite possibility that the GTFS process may develop data specifications in this area in the near future. 31