Open Data: Challenges and Opportunities for Transit Agencies (2015)

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.

9 basic principle that the data are free to use, reuse, and redis- tribute. According to the Open Data Institute (2), Open data is information that is available for anyone to use, for any purpose, at no cost. Open data has to have a license that says it is open data. Without a license, the data can’t be reused. The license might also say: • that people who use the data must credit whoever is publish- ing it (this is called attribution); and • that people who mix the data with other data have to also release the results as open data (this is called share-alike). In addition, the Open Data Institute describes what consti- tutes “good” open data: • Can be shared easily; • Is available in a standard, structured format; • Has guaranteed availability and consistency; and • Is traceable, through processing, back to where it originates. Finally, the conditions of open data are defined as fol- lows (3): • Complete—taking privacy into consideration; • Primary—being as close as possible to the source; • Actual—as automatic as possible in the exchange; • Accessible—in digital format for as many users as pos- sible and as many purposes as possible; • Readable machine to machine; • Free—mostly accessible for no cost and with no restric- tions for use; and • In an open format and to follow a standard [e.g., Exten- sible Markup Language (XML)]. Organizations that provide guidance about making a busi- ness case for open data; how to open the data; engaging with data consumers and reusers; licensing; and the effects of open data include: • Open Knowledge Foundation • Sunlight Foundation • Open Data Institute • The Open Data Foundation • Project Open Data • The Open Data Center Alliance • Open Mobile Alliance • Public Data Transit Community The literature review revealed that a wide variety of reports, papers, articles, and press releases have been written about open data in transit. The literature review is divided into the following sections, including the five elements identified in chapter one: • Characteristics of open data, including standard(s) used for open data • Legal and licensing issues • Uses of open data, including customer and other applications • Costs and benefits • Opportunities and challenges, including: – Engaging existing and potential data users and reusers – Impacts of open data The first step of the literature review was to conduct an online Transport Research International Documentation (TRID) search. This TRID search yielded 30 documents, the most relevant of which were reviewed and used as input for this report. The second step was to obtain and review articles, press releases, and website information directly from agen- cies and open data organizations across the world. The third step was to review research reports from the FTA, FHWA, and TCRP. Finally, other papers and articles were obtained from a variety of sources, including the following: • TRB Annual Meetings; • APTA conferences and publications; • Intelligent Transportation Society of America (ITSA) Annual Meetings; • Intelligent Transportation Society World Congresses; • Open Data Organizations; • European Commission project documentation; and • Internet searches. The sources used in this synthesis are listed in the Refer- ences section. Supplemental information regarding confer- ences, meetings, and agency events dedicated to open transit data can be found in Appendix C. INTRODUCTION TO OPEN TRANSIT DATA Before describing the types of data that are being released by transit agencies according to the literature, it is important to define the term “open data.” Many definitions include the chapter two LITERATURE REVIEW

10 On January 21, 2009, President Obama issued an Open Government Directive, which directed executive depart- ments and agencies to take actions that support transparency, participation, and collaboration: Transparency promotes accountability by providing the public with information about what the Government is doing. Participa- tion allows members of the public to contribute ideas and exper- tise so that their government can make policies with the benefit of information that is widely dispersed in society. Collaboration improves the effectiveness of Government by encouraging part- nerships and cooperation within the Federal Government, across levels of government, and between the Government and private institutions (4). In 2003, the Digital Agenda for Europe, Public Service Information Directive was issued, significantly affecting the release and “re-use of public sector information,” includ- ing open public transport data (5). Through this directive, open data are “obligatory for all [European Union] member states.” In February 2012, Claudia Schwegmann reported that developing countries are just now beginning to open their data, including public transport data (6). The U.S. DOT supports and promotes open transportation data, as evidenced in its Open Government Plan for 2012 to 2014 (7). As shown in Figure 1, five initiatives in this plan include several open transit data-related activities. The literature reviewed for this synthesis included several other concepts that are directly related to open transit data, including “open data movement” and “open transport.” The open data movement and its relationship to public transit is defined by Eros et al. as coming from philosophical principles of open government, transparency, and accountability, and practical motivations related to increased returns on public investment, downstream wealth creation, more potential brainpower brought to examining complex problems, FIGURE 1 U.S. DOT Open Government initiatives.

11 and enhanced public policy and service delivery. For transpor- tation, the open data movement has fundamentally shifted how agencies communicate with users as an increasing number move from tightly controlling data and the products derived from them, towards generating and releasing data with minimal control over the end products. In transportation, the confluence of open data, GTFS [General Transit Feed Specification] (originally developed by Google and containing static schedule information for tran- sit agencies, including stop locations, route geometrics, and stop times), and increasingly ubiquitous mobile computing, sensing, and communication technologies (epitomized by the ‘smart- phone’), has spurred numerous technical innovations from a range of actors. Tools include applications that assist with trip planning, ridesharing, timetable creation, data visualization, planning analy- sis, interactive voice response, and real-time information provi- sion. Together, GTFS and GTFS-RealTime (containing real-time information related to vehicle positions, service alerts, and trip updates such as delays, cancellations, etc.) enable transit agen- cies and operators to engage the power of the software developer community and citizenry more generally to create new forms of information services about public transportation (8). Open transport, according to the World Bank Open Trans- port Team, defines the next generation of tools and methodologies for man- aging and planning transport systems in resource-constrained environments. Open Transport is defined by three principles: Open data standards, open source software and open data. Open data standards are freely and publicly available, with no required use agreements. Open source software features universal access and redistribution rights via free licenses to a product’s design, code, or blueprint (9). From the open transit data perspective, “while not all transport data lends itself to be open, there are benefits to releasing some data, such as public transit service informa- tion, to achieve economies of scale in generation of third- party applications to support wider and more efficient use of a transit network” (9). An overall history of the open data movement between 2006 and 2011 is shown in Figure 2, which shows “the evo- lution and role of [application] API in building influential and essential tools and applications for web users, plus the demographics of public data usage around the world” (10). This evolution had a significant impact on the introduction of open transit data. A timeline of transit open data between 2005 and 2012, as detailed by Francisca Rojas, is shown in Figure 3. As agencies saw that disseminating transit information by elec- tronic means was valuable to their customers, they began to create FIGURE 2 Open data movement 2006–2011 (10).

12 the points of interaction, or Application Programming Inter- faces (APIs), needed for third-party software developers to access dynamic, real-time data feeds of bus and train location informa- tion. The solid-line boxes in Figure 3 indicate when agencies made available real-time data feeds to the public. This process gained momentum in 2009 and by the end of 2011 all major transit agencies in the United States had 1) posted their routes and schedules on Google Maps, 2) publicly released GTFS files of static transit information, and 3) created APIs for access to real-time information by third-parties (11). Because this timeline ends in 2012, it does not display events in 2013 or 2014, such as Metropolitan Transportation Author- ity’s (MTA’s) completion of the Bus Time implementation and release of GTFS-realtime data. Rojas suggests that TriMet, one of the U.S. transit agen- cies to pioneer the release and use of open data, started the spread of open transit data to some of the largest transit agen- cies because of the following factors (11): • A de facto data standard offered by the GTFS format facilitated the process for agencies to integrate sched- ules and routes into Google Maps (now Google Tran- sit), and for broader public disclosure of those same data sets; • Demand from technologically savvy, networked tran- sit riders for customized transit information because of the wide adoption of short message service (SMS)- enabled cell phones and location-aware smartphones, which enabled riders to view real-time information while traveling; • Software developer communities that were eager to learn how to code mobile applications and sought available data sets to develop technical skills, and improve and expand access to transit information; • Agencies willing to adapt intelligent transportation sys- tems used for internal management of operations into data formats suitable for public disclosure; and • Open data champions who built networks within agen- cies to share experiences and seek advice on technical and policy aspects of data disclosure. The literature reviewed presented the questions that many transit agencies ask as they are determining whether or not to open their data (12): 1. What data should we provide? 2. How do we get the data? 3. Will the app developers use our data? 4. Will the developers provide a reliable service? 5. What are good examples of apps? 6. Do we need to produce an app ourselves? 7. What standards should we use? 8. How should we ensure data quality? 9. Should we preprocess our data? 10. Can we charge for our data? A tool developed by the Center for Technology in Gov- ernment at the University of Albany “provides a series of questions that take agencies through a review of their exist- ing and proposed open government plans to quickly assess the public value of their open government initiatives” (13). This tool, called the Open Government Portfolio Public Value Assessment Tool (PVAT), evaluates each open gov- ernment initiative using a “multistep question process, which FIGURE 3 Transit open data timeline 2005–2012 (11).

13 includes making public value judgments, identifying stake- holders and uncovering the impacts that initiative will have on those stakeholder interests” (13). Several pieces of literature covered the reasons transit agencies opened their data (7, 14–16). These justifications include the following: • Improved customer service • Increased and equal information access • Fostered innovative, diverse, and free apps • Improved agency transparency • Supported concept that public transit data are publicly owned • Allowed information to proliferate, extending the reach of public transit information considerably • Facilitated the development of technology enterprises, generating employment, a highly skilled workforce and wealth for the community, and prompting innovation • Facilitated grassroots standards such as GTFS • May result in increased ridership and increased revenue as the result of better passenger information • Gave developers opportunities to make applications more easily with publicly accessible data, as well as realize a potential economic gain • Supported better use of personal time for current and future riders because riders will have more information • Contributed better transit data to help inform regional decision making To provide some context into how many transit agencies provide open data, the GTFS Data Exchange reports that data are available for 726 transit agencies worldwide (17). City-Go-Round, supported by The Rockefeller Foundation, reports that of 866 U.S. transit agencies, 248 (28.64%) have open data in 2014 (18). Another point of reference is that, at the time of TCRP Synthesis 91 (1, pp. 38, 52), on May 6, 2010, City-Go-Round reported 107 U.S. transit agencies of 780 (13.72%) were providing open data. This difference between 2010 and 2014 shows the rapid growth of open tran- sit data. Yet another reference (see Figure 4) shows the num- ber of unlinked passenger trips served by agencies with open transit data from 2009 to 2013 (19, p. 3). The Open Knowledge Foundation developed an Open Data Index that reports on the following characteristics of open transit data (and many other types of open government data) by country and, in the United States, by major metro- politan area (20): • Do the data exist? • Are the data in digital form? • Are the data publicly available? • Are the data free of charge? • Are the data online? • Are the data machine-readable? • Are the data available in bulk? • Are the data openly licensed? • Are the data up to date? Figure 5 shows a sample of this list by country. Figure 6 shows a sample by U.S. city. The transit portion of the index is shown on the far right. The transit index is based on answers to the nine questions listed. A variety of events focusing on open transit data are being held around the world. These events are described in Appendix C. CHARACTERISTICS OF OPEN DATA In guidance written in 2012 for transportation agencies inter- ested in providing open data, the types of data that agencies should consider releasing include schedule data in GTFS format (see the following section for a definition of the de facto GTFS standard), route information in GTFS format, and “infrastructure locations, including stations, roadways and landmarks [from a geographic information system (GIS)]. For enhanced transparency, these data sets should be released [as well]: budgetary data, performance data and ridership data” (23), all in comma-separated values (CSV). Young-Jae Lee mentions two additional categories of data: real-time and origin-destination data (24). From a developer’s perspective, there are two types of open transit data: (1) static (e.g., transit schedules, routes, and stops), which changes only a few times a year, and (2) real-time (e.g., estimated arrival times, vehicle positions, and service alerts), which changes every few seconds (25). Fur- ther, there are “two magnitudes of open data,” as follows: • “Fire hose,” which is a dump of the complete state of the transit system and is not directly suitable for mobile FIGURE 4 Growth of transit agencies with open data by passenger miles served (19).

14 devices. In this magnitude, static data are all transit schedules/routes/stops, and real-time data are all esti- mated arrivals/vehicle positions/service alerts; and • “Faucet,” which is a precise subset of transit data and is suitable for mobile devices. In this magnitude, the data are specific. For example, static data could be “Stop ID 10 is served by Route 5,” and real-time data could be “It is 2 minutes until Route 5 bus arrives at Stop ID 10.” The McKinsey Global Institute characterizes open data in terms of four characteristics (26): • Accessibility: A wide range of users is permitted to access the data; • Machine readability: The data can be processed auto- matically; • Cost: Data can be accessed free or at negligible cost; and • Rights: Limitations on the use, transformation, and dis- tribution of data are minimal. Figure 7 shows how data are open or closed based on these four characteristics. According to the McKinsey Institute, Open data sets also are defined in relation to other types of data, especially big data. ‘Big data’ refers to data sets that are volu- minous, diverse, and timely. Open data are often big data, but ‘small’ data sets can also be open. We view open and big data as distinct concepts. ‘Open’ describes how liquid and transferable data are, and ‘big’ describes size and complexity of data sets. The degree to which big data is liquid indicates whether or not the data are open (26, p. 4). The New Zealand government described a five-level model for open data. The World Wide Web Consortium (W3C) has developed a five star model to describe different characteristics of open data, and its usefulness for people wishing to reuse it. It is being used glob- ally as a model for assessing data readiness for re-use. Apply- ing this five star data model along with metadata standards will result in well understood and ‘mashable’ datasets (datasets easily joined together to create a new dataset). The three star level is considered the minimum standard for release of government’s FIGURE 5 Open Knowledge Foundation’s ratings of open transit timetables (21).

15 FIGURE 6 U.S. City Open Data Census—State of Open Transit Data (22). FIGURE 7 How data are open or closed (26, p. 3).

16 public data for re-use: non-proprietary, machine-readable, and accessible via the web, and licensed for reuse (27). Those five levels are as: 1. Data are visible and licensed for reuse but require con- siderable effort to reuse: 1 star, on the web with an open license. 2. Data are visible, licensed, and easy to reuse but not necessarily by all: 2 star, machine-readable data. 3. Data are visible and easy to reuse by all (not restricted to using specific software): 3 star, nonproprietary formats. 4. Data are visible, easy to use, and described in a stan- dard fashion: 4 star, Resource Description Framework (RDF) standards. 5. Data are visible, easy to use, and described in a stan- dard fashion, and meaning is clarified by being linked to a common definition: 5 star, linked RDF. In describing how Bay Area Rapid Transit (BART) creates value with open transportation data, Timothy Moore, web ser- vices manager, uses the graphic in Figure 8 to “demonstrate the flow of information in an open data ecosystem. Informa- tion flows in a continuous path clockwise from Customers to BART to Data to Developers” (and back to customers) (28). Rojas further defines these entities: the transit agency is the “discloser”; the developers are the “intermediaries”; and the customers are the “end users” (11, pp. 28, 32, and 33). Hans Nobbe suggests the data can be provided at different levels of service, while still being open and free (29): • Bronze: data is supplied with a limited bandwidth. There is no guarantee that data is supplied in time. The capacity of the system is maximized. • Silver: data is supplied with a high bandwidth and guaranteed delivery. The extent of this level is determined unilaterally but in consultation with end users. For this service, a fixed fee will be charged. • Gold: data is supplied by a mutual agreement. The fee is dependent on the contents of the mutual agreement. Which may be higher than in silver (for example, because 24 * 7 service requested) or lower cost (for instance as the end user guarantees transmission of safety related information). A more multimodal perspective on open data types was dis- cussed by Lee et al. (30). “Organizations of the government are recently supporting the common use of public information by preparing plans about information opening. Therefore, if public information is open and OPEN-API technology is intro- duced, then it would help promote the use of public informa- tion and improve the quality of information.” The open data they included covered the following: • Traffic flow information • Traffic control information • Incident information • Closed-circuit television (CCTV) information • Static and real-time transit information • Bus arrival prediction information • Bus transfer information • Parking lot location operating information • Parking lot guidance information STANDARDS AND FORMATS USED FOR OPEN DATA The use of standards in providing open transit data is critical and discussed in many pieces of literature. Kaufman identi- fies the basic standards and file formats for open transit data, as shown in Table 1 (23). Barbeau reports that successful open data formats are: • Organic: Created and improved by the people actually pro- ducing and consuming the data; • Open: Open process for evolution and data/documentation not hidden behind log-ins; and • Easy-to-use for app developers: Is documentation simple to understand and are there existing open-source software tools? (25, p. 18) Various sources define these and other standards used in open transit data are as follows: • GTFS (https://developers.google.com/transit/gtfs/ reference)—The General Transit Feed Specification, originally developed by Google, contains static schedule information for transit agencies, including stop locations, route geometries and stop times. “GTFS consists of a package of comma-delimited text files, each of which contains one aspect of the transit information and a set of rules on how to record it: six mandatory files (agency, stops, routes, trips, stops times, and calendar) and seven optional files (calendar dates, fare attributes, fare rules, FIGURE 8 Open data ecosystem (28).

17 shapes, frequencies, transfers and feed info)” (8, p. 1). “The market success of GTFS has led to an unprec- edented adoption rate by transit agencies as shown by total unlinked passenger trips for agencies with GTFS” (32, p. 1). For schedule data, GTFS adoption has substan- tially outpaced the Transit Communications Interface Protocols and Service Interface for Real Time standards in North America due to its relative ease of use for transit agencies to describe, implement and maintain data feeds (34, p. 3). GTFS has evolved over the years to meet expand- ing requirements. The group that collaborates on these changes is the GTFS Changes Group (https://groups. google.com/forum/#!forum/gtfs-changes). The rules governing this group and how it is managed can be found at https://groups.google.com/forum/#!searchin/ gtfs-changes/welcome/gtfs-changes/C5dgsKGkpDA/ kyxN1DCS-dQJ. • GTFS-realtime (https://developers.google.com/ transit/gtfs-realtime/)—GTFS-realtime contains real-time information related to vehicle positions, service alerts, and trip updates (including delays and cancellations). • SIRI (http://www.kizoom.com/standards/siri/)—The Ser- vice Interface for Real Time Information is a real-time data standard predominant in Europe and making signifi- cant inroads into the U.S. market, notably at the Metro- politan Transportation Authority (MTA) in New York. Recent change proposals to the SIRI standard include the definition of a structure for SIRI web services. The SIRI standard includes a component for schedule data (see later) but is designed for real time and thus is more com- plex than some other standards (33). • TCIP (http://www.aptatcip.com/)—The Transit Com- munications Interface Protocols is an APTA standard with components that deal with passenger information and scheduling, as well as a host of other business divi- sions in transit. This standard was developed in the early stages of the transit information systems era; early stud- ies encouraged its use for static and real-time data stan- dardization. The standard’s complexity results from its attempt to account for all the various operational proce- dures and service types offered by all transit agencies (33). “Some of the data elements needed for TCIP have since become part of the GTFS specification, including items such as agency name, block, route identifiers, trip identifiers and other similar information” (33, p. 3). • NextBus (http://www.nextbus.com/xmlFeedDocs/Next BusXMLFeed.pdf)—A number of transit agencies use the NextBus XML API to deliver real-time arrival information. Other formats reported in the literature that are being used for open transit data are as follows: • Comma-separated values (CSV)—a file format used as a portable representation of a database. Each line is one entry or record, and the fields in a record are separated by commas (34). Agencies using GTFS have commit- ted to producing and maintaining their schedule data in standardized CSV tables to display their system on Source: Kaufman (23, p. 4). TABLE 1 COMMON DATA STANDARDS AND FILE FORMATS

18 Google Transit’s trip planner and, increasingly, opening these data to other third-party application developers (32, p. 1). • Geo JavaScript Object Notation (GeoJSON) is a format for encoding a variety of geographic data structures. It is a geospatial data interchange format based on Java- Script Object Notation (JSON). • Identification of Fixed Objects in Public Transport (IFOPT) defines a model and identification principles for the main fixed objects related to public access to pub- lic transport (e.g., stop points, stop areas, stations, con- nection links, entrances, etc.). IFOPT Standard builds on the TransModel Standard to define four related sub- models (35). • JavaScript Object Notation (JSON) is a data-interchange and text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages (http://json.org/). • Network Exchange (NeTEx) is intended to be a general purpose format capable of exchanging timetables for rail, bus, coach, ferry, air, or any other mode of public transport. It includes full support for rail services, and can be used to exchange (36). • Protocol Buffers—GTFS-realtime data exchange format based on Protocol Buffers. Protocol Buffers are a language- and platform-neutral mechanism for serializing struc- tured data (think XML, but smaller, faster, and simpler). The data structure is defined in a GTFS-realtime.proto file, which then is used to generate source code to easily read and write your structured data from and to a variety of data streams, using a variety of languages (37). • Resource Description Framework (RDF) is a standard model for data interchange on the web (38). • Representational state transfer (REST) is a distributed system framework that uses web protocols and tech- nologies (39). • Really Simple Syndication or Rich Site Summary (RSS) is a format for delivering regularly changing web con- tent (40). • Simple Object Access Protocol (SOAP) is a method of transferring messages or small amounts of information over the Internet. SOAP messages are formatted in XML and are typically sent using HTTP (hypertext transfer protocol) (41). • TransModel is the European Reference Data Model for Public Transport; it provides an abstract model of com- mon public transport concepts and structures that can be used to build many different kinds of public transport information systems, including for timetabling, fares, operational management, real time data, and so forth (42). • TransXChange (TxC) is the U.K. nationwide standard for exchanging bus schedules and related data (43). TxC provides a means to exchange bus routes and time- tables between different computer systems, together with related operational data (44). • Extensible Markup Language (XML) is more robust than GTFS in its abilities to represent large complex models, but the approach is more common in Europe and raises standardization challenges in the face of hyperflexibility (33). Wong et al. said of GTFS: The GTFS, first introduced in 2005, is the result of a project between Google and TriMet in Portland to create a transit trip- planner using the Google Maps web application. Because of the collaborative approach to its development, the specification was designed specifically to be simple for agencies to create, easy for programmers to access and comprehensive enough to describe an intricate transit system. GTFS identifies a series of comma separated files which together describe the stops, trips, routes and fare information about an agency’s service. Google opened the feed for general use in mid-2007 and it propagated widely as agencies translated their transit schedules into the format. The feed is the most used standard for static transit data exchange in the United States today (33, pp. 2–3). As mentioned, according to data from the GTFS Data Exchange, as of March 11, 2014, data are available for 726 worldwide transit agencies (http://www.gtfs-data-exchange. com/agencies), and 239 agencies’ feeds are available on http:// code.google.com/p/googletransitdatafeed/wiki/PublicFeeds, a guide to GTFS data that was written by Wong (45). A GTFS tool that can be used by small transit agencies was prepared by Williams and Sherrod (46). Pioneering Open Data Standards: The GTFS Story describes TriMet’s experience in helping develop GTFS and the effects that it has had on the transit industry (47, pp. 126–128). In summary, this story recounts the combined efforts of TriMet and Google in developing what would become a de facto standard for anyone to use to conduct transit trip planning anywhere in the world. The impact of GTFS was far reaching; 8 months after Google Transit was launched, five more transit agencies were added. “Within a year, Google Transit launched with fourteen more transit agencies in the United States and expanded internationally to Japan” (47, p. 128). Those agencies that release their data through GTFS are required to provide the following data, at a minimum (48): • Name or identification of the transit agency(ies) provid- ing the data; • Individual locations where vehicles pick up or drop off passengers; • Routes, which are defined as groups of trips that are displayed to riders as single services; • Trips for each route, which are sequences of two or more stops that occur at specific times; • Times that a vehicle arrives at and departs from indi- vidual stops for each trip; and • When service starts and ends, as well as days of the week when service is available.

19 Optional data types that can be provided through GTFS are as follows: • Exceptions for when service starts and ends, and days of the week when service is available; • Fare information for a transit organization’s routes; • Rules for applying fare information for a transit orga- nization’s routes; • Rules for drawing lines on a map to represent a transit organization’s routes; • Headway (time between trips) for routes with variable frequency of service; • Rules for making connections at transfer points between routes; and • Additional information about the feed itself, including publisher, version, and expiration information. Use of GTFS-realtime dictates that the following data, in addition to what is provided through GTFS (static informa- tion), are released (49): • Real-time update on the progress of a vehicle along a trip (this is required information). This can specify a trip that proceeds along the schedule; a trip that pro- ceeds along a route but has no fixed schedule; and a trip that has been added or removed with regard to schedule; • Timing information for a single predicted event, either arrival or departure (this is optional). Timing consists of delay and/or estimated time, and uncertainty; • Real-time update for arrival and/or departure events for a given stop on a trip (optional); • Real-time positioning information for a given vehicle (optional); • An alert, indicating some sort of incident in the public transit network (including cause and effect) (optional); • Geographic position of a vehicle (required); and • Identification information for the vehicle performing the trip (optional). The SIRI standard (50) contains the following data ele- ments (D.A. Laidig, Systems Engineering Manager, Metro- politan Transportation Authority, personal communication, June 18, 2014): • SIRI-PT (Production Timetable): Exchanges planned timetables • SIRI-ET (Estimated Timetable): Exchanges real-time updates to timetables • SIRI-ST (Stop Timetable): Provides timetable informa- tion about stop departures and arrivals • SIRI-SM (Stop Monitoring): Provides real-time infor- mation about stop departures and arrivals • SIRI-VM (Vehicle Monitoring): Provides real-time information about vehicle movements • SIRI-CT (Connection Timetable): Provides timetabled information about feeder and distributor arrivals and departures at a connection point • SIRI-CM (Connection Monitoring): Provides real-time information about feeder and distributor arrivals and departures at a connection point. Can be used to support “connection protection” • SIRI-GM (General Message): Exchanges general infor- mation messages between participants • SIRI-FM (Facility Monitoring): Provides real-time infor- mation about facilities • SIRI-SX (Situation Exchange): Provides real-time infor- mation about incidents. MTA and the Utah Transit Authority (UTA) use open SIRI feeds. Of the list of SIRI messages, MTA Bus Time only sup- ports VM, SM, and SX. UTA supports SM and VM (D.A. Laidig, Systems Engineering Manager, Metropolitan Trans- portation Authority, personal communication, June 18, 2014). APTA conducted a survey of member agencies in 2013 to determine how transit agencies are providing static and real-time information to customers (51). The survey results show that GTFS was the most common format used by agen- cies, followed by proprietary formats from companies that provide scheduling software. Four out of ten agencies use a variety of other formats, and nearly two out of ten are using an internal agency format. Only two out of the 75 respondents said they did not use formats and standards. These tools and standards help agencies organize their routes and schedules internally, but they can also be used to create value for customers. The data organized by these standards can drive tools that customers can use to plan a trip, or they can create data streams that feed information to apps so customers can access this information on the go (51, p. 8). Figure 9 shows the standards used by respondents to pro- vide static information. The 25 respondent agencies that pro- vided more than 25 million trips in fiscal year (FY) 2010 are classified as large agencies, and those providing fewer than 25 million trips are smaller agencies. According to APTA, Looking at the split between large and smaller agencies, large agen- cies were more likely to use most of the listed formats, because those agencies were more likely to use multiple formats than the smaller agencies. A big majority—88%—of large agencies used multiple formats for static data. Only 58% of smaller agencies did so. Large agencies were much more likely to use tools from [technology companies] than smaller agencies. Smaller agencies were more likely to use a format in the ‘other’ category—these agencies used a variety of platforms provided by smaller soft- ware companies (51, p. 8). The use of both GTFS and SIRI is exemplified in OneBus- Away, an application whose “primary function is to share real-time public transit information with riders across a vari- ety of interfaces” (52). Iley [in OneBusAway Application Suite (53)], describes OneBusAway as an open-source transit information software system, including sev- eral mobile apps, that was originally developed at the University of

20 Washington and deployed in the Puget Sound area of Washington state. OneBusAway leverages the GTFS data format for sched- ule transit data, but the original Puget Sound deployment did not use a standardized interface for sharing real-time transit data with mobile apps. As part of their real-time Bus Time API pilot project in early 2011, Metropolitan Transportation Authority (MTA) in New York leveraged the OneBusAway software to build their own transit information system. MTA implemented a modified ver- sion of SIRI in their OneBusAway server to share their data with mobile app developers. In 2012, MTA [moved] on to the second step of deploying the same technology to other NYC boroughs. In 2014, MTA completed its full five-borough rollout. Cur- rently, OneBusAway provides real-time transit information in the Atlanta, New York City, Puget Sound, and Tampa regions. Hazarika (54) describes the characteristics of two stan- dards, SIRI and TransXChange (TxC), that are used in the United Kingdom to integrate various sources of public transit data. This is based on a survey conducted of “Local Authori- ties (LA’s), Passenger Transport Executives (PTE’s) and bus operators about their understanding, experiences and invest- ment plans for these standards.” This reference describes “the future growth/usage of the key features of TxC and SIRI against their customer’s industry segments” (54, p. 4), and shows the key success factors (KSF), strengths, and weak- nesses of SIRI and TxC (54, p. 33). STANDARDS FOR OPEN PARATRANSIT DATA One issue associated with using GTFS is how to portray para- transit services within this format because it was developed primarily for fixed-route transit service. Chambers, with Ride Connection in Portland, Oregon, addresses this issue in his pre- sentation (55). He answers “yes” to his statement on page 7: “If a transit service can’t be described in the GTFS, does it exist?” Further, two other cases show how to use GTFS to describe paratransit or demand-response service. First, Klopp et al. (56) describe, in their Nairobi study, how paratransit networks can be mapped along with the collection of important transit data using off-the-shelf mobile phone technol- ogy. We also demonstrate the utility of the GTFS format when adapted for paratransit data collection. We found that GTFS allows for the incorporation of rich and useful metadata in a structured way. By using the GTFS data with Open Street Maps or Google maps, we created some of the first comprehensive visualizations of the Nairobi matatu paratransit system for the public and plan- ners. By trying to fit aspects of the paratransit system into a GTFS format, however, it also became more clear where the fit is often hard to make because the standard was developed for planned for- mal transport system with fixed stops and schedules (even if they are not always strictly adhered to) and not the demand responsive and flexible paratransit system. Overall, it appears that modifica- tions need to be made to GTFS to account for key differences between paratransit and more formal, planned systems. Eros et al. (8, pp. 13 and 14) state that many cities across Latin America, Africa and Asia share this predicament; research indicates that flexible transport services constitute more than 90% of transit trips in cities such as Algiers. In Mexico a work-around was found by creating a variant to the GTFS feed based on defining fixed stops at regular intervals combined with the possibility for users to assess travel times and connections from any point between stations. Headway esti- mates, based on existing knowledge (including vehicle counts and speed data) substituted for schedules. Teams working in two cities, Manila and Dhaka, also had to deal with this challenge. Like Mexico City, Manila chose to avoid schedules, instead pro- viding headway estimates for their jeepneys. In terms of stop locations, the Dhaka team included stop location based on where the bus stopped during the data collection ride. Manila’s stops were interpolated every 500 meters along the route. This discussion of standards for incorporating paratransit data directly relates to the use of GTFS for integrated trip plan- ning. York Region Transit outside Toronto, Ontario, “is saving significant money having customers use fixed route for a por- tion of their paratransit trip” (information from Rajeev Roy, Manager, Transit Management Systems, The Regional Munic- ipality of York-Transportation and Community Planning). APPLICATION PROGRAMMING INTERFACES Before leaving the standards discussion, it is important to draw the distinction between standards and an API. Accord- ing to Open Data Handbook Documentation, an API is “A way computer programs talk to one another. [It c]an be understood in terms of how a programmer sends instructions between programs” (57). FIGURE 9 Results of APTA survey: Standards used to provide static data (51, p. 8).

21 As discussed, APTA’s survey examined the use of APIs. Two-thirds of those agencies with real-time information provide an interface so app developers can utilize that information inde- pendent from the agency. Providing an interface for third-party applications allows developers to find innovative ways to pro- vide this information to transit customers. Just more than one- third [37%] of all agencies provide an application programming interface (API) for third-party developers. APIs allow third- party applications to read and display data provided by transit agencies. The most common API used is NextBus, followed by GTFS-realtime (51, p. 1). Real-time information is provided using the APIs, as shown in Figure 10. LEGAL AND LICENSING ISSUES In the Intelligent Transportation Systems (ITS) community, dis- cussions regarding open data started 10 years ago at the 2004 ITS World Congress with “An Open Platform for Telematics” (58). Although the paper describes the technical aspects of telematics (defined as “the wireless provision of information and services to vehicles”), it raises issues about the functions and responsibilities among vehicle manufacturers, wireless carriers, information service providers, and call centers. These issues lead the reader to consider the legal and licensing rami- fications of the development and implementation of the open platform. When transit agencies began to consider providing their data openly, some became concerned about legal issues, including “misrepresentation of the agency, logo usage and brand identity” (33). In addition, agencies releasing data often are concerned about lawsuits and bad press (59). Other risks cited in the literature include “legal exposure due to the lack of accuracy of data, loss of advertising revenue on the agency home page (if Internet traffic is directed to other sites, such as Google Transit, that provide transit services), and loss of control of dissemination of transit service informa- tion” (60, pp. 5–6). For example, of the 50 reasons public agencies do not release data, there are several related to legal, privacy, and misuse issues (61), including the following. • We can’t legally do that. • It will be misunderstood/misused. • If we share our data/code, we’ll be hacked. • It might be presented in ways that result in people mis- understanding it. The media will misreport. • People don’t understand my data. It’s complex/magical/ for experts. • The data source is a mess. • The data might have errors or mistakes and could mis- inform the public. • Privacy. As shown in the discussion of the survey results, only one survey respondent (of 67) has experienced a legal issue aris- ing from providing open transit data. McCann addresses a few of these legal concerns (61). For example, the concern that “people might sue us” can be addressed by making “a policy that balances the public interest in accessing the data with the privacy concerns and stick[ing] to it.” Another example is “we don’t think it would be good PR to open this.” This can be addressed by being “more pro- active about good PR. Explain what the data means and why you are opening it.” Several open data organizations provide guidance regard- ing legal issues and licensing samples. For example, Open Data Commons presents sample legal tools and licenses in “Open Data Commons Public Domain Dedication and License (PDDL)” on http://opendatacommons.org/licenses/pddl/. The Open Knowledge Foundation provides numerous legal and licensing resources on http://opendefinition.org/licenses/. In terms of open transit data, many agencies have devel- oper license agreements and terms of use on their websites. Several examples are shown in Appendix E. FIGURE 10 Results of APTA survey: APIs used to provide real-time information (51, p. 5).

22 Timothy Moore, with BART, suggests that a simple license may be the most appropriate for open transit data (62). BART’s license has the following characteristics: • Short + sweet: 258 words • We reserve the trademark • Data provided ‘as is’ and ‘as available’ • You don’t have to sign anything (62). Antrim and Barbeau (60), and The Finnish Transport Agency (63) report that open transit data agreements gen- erally contain the following statements: • The agency reserves the rights to its logo and all trade- marks. These marks are an indicator used for official information from the agency only. • The data are provided without warranties. • No availability guarantees are expressed or implied. • The agency retains full rights to the data (60). • The license is free of charge and is made between the [agency] and a licensee. • The licensee may freely copy and deliver; modify and use (e.g., for a commercial purposes); and combine and use as part of an application or service. • It is not mandatory, but we highly recommend, that the name of the licensor (e.g., Finnish Transport Agency) is shown (63). APPLICATIONS The literature has numerous examples of open data applica- tions. Examples of applications related to customer informa- tion that are driven by open data are rapidly evolving, and are available on agency websites or can be found on developer sites. Examples are provided in Appendix F. An application that provides real-time information for MTA buses in New York City is called Bus Time. The applica- tion was piloted with route B63 on February 1, 2011, and was fully deployed citywide in 2014. Bus Time displays bus loca- tion and distance from stops, not time-based arrival predic- tions, on mobile platforms (64, 65). Bus Time provides open data between the MTA and software developers and custom- ers, is based on open standards [between hardware compo- nents, between bus and server, and between server and other MTA/New York City Transit (NYCT) systems], and uses open source software (software code [OneBusAway] and APIs). Figure 11 shows how Bus Time works. Bus Time has had a positive impact on developers, with several apps developed: interactive phone application, arrival time predictions, and smartphone apps. Samtrafiken, a nonprofit organization owned by 34 pub- lic transport operators and authorities in Sweden, has been a champion in open transit data. Their innovation manager, Elias Arnestrand, recognized that when developers started screen-scraping public transport data from various websites to create apps, agencies that “own” that data needed to con- sider releasing it. In addition, he realized that agencies could not keep up with the number of platforms that mobile devices were using. Further, apps that used screen-scraping technol- ogy could bring an agency’s information systems to a halt because of the volume of data requests. [In] 2009 [we] created Trafiklab [http://www.trafiklab.se/]. It was formulated as an initiative to start to work with open data and open APIs. We wanted to make it simple to access this data FIGURE 11 Bus Time concept (65, p. 4).

23 and even make it fun for our industry and third party develop- ers to discuss these issues. [T]his industry initiative [was] all together on one site instead of each public transport entity cre- ating their own channel, data sources, set of agreements, and different types of APIs. This would have created a huge burden on third parties that wanted to access the complete set of public transportation data and services in Sweden. We looked at the external drivers that motivate developers [and recognized] that developers were driven by finding challenge, the satisfaction of getting their app to work, and the ability to showcase their work to the greater public. [W]e focused on [these drivers] to help get this initiative successfully off the ground. Today, our open APIs are a very important part of our strat- egy in providing customers with relevant public transport infor- mation and services. For example, for public transportation in Stockholm, more than 50% of the requests come from services created by third parties. APIs are a marketing and distribution channel for our public transportation information and services. We’ve realized that APIs are the cheapest and fastest way to build applications. And most importantly, APIs let third parties extend our products and services (66). Another application that is based on open data is Open- TripPlanner (OTP), which was developed by OpenPlans. OTP “provides a robust multi-modal, multi-agency trip planner. This tool allows for multi-modal travel as one of the trip plan- ning options for those looking to travel to transit via walking or bike” (67). This type of application greatly facilitates multi- modal/multiagency coordination. It also uses crowdsourcing; OTP uses OpenStreetMap (OSM), a crowd-source open data set designed for routing. TriMet’s customization of OTP “uti- lizes all open data including OpenStreetMap, GTFS, and the USGS National Elevation Dataset” (68, p. 10). As mentioned, in 2012, APTA conducted a survey of its membership regarding customer information. A portion of this survey related to open transit data (51). Overall, a large percentage of agencies (80%) are providing static data such as schedules, routes, and fares to customers in some fashion. Around two-thirds participate in Google Transit, and a similar number make their data available to third-party develop- ers. Just over six in ten agencies said that they make their static data available to third party apps. Large agencies were more likely to encourage third-party activities—88% of those agencies make their data available (51, pp. 10–11). Figure 12 shows the percentage of APTA survey respon- dents that provide static data to third-party applications. Overall, just more than 40% of APTA survey respondents had developers using their open static data; 68% of large agencies reported developers using their static data. “Around one-quarter of agencies surveyed indicated that app develop- ers are using their real-time data. Forty-four percent of large agencies indicated that developers use their data and fourteen percent of smaller agencies indicated that this is the case [see Figure 13]” (51, p. 5). FIGURE 12 APTA survey results: Percent respondents that provide open static data (51, p. 10). FIGURE 13 App developers using real-time data (51, p. 6).

24 Antrim and Barbeau describe some of the types of appli- cations that use open transit data (60): • Trip planning and maps—applications that assist a transit customer in planning a trip from one location to another using public transportation. Examples include Google Maps, OpenTripPlanner, Bing Maps, HopStop, MapQuest, and rome2rio. • Ridesharing—applications that assist people in con- necting with potential ridesharing matches. Examples include Parkio and Carma (formerly known as Avego). • Timetable creation—create a printed list of the agency’s schedule in a timetable format: TimeTable Publisher. • Mobile applications—applications for mobile devices that provide transit information. Examples include Google Maps, Transit App for iOS 6 and beyond, Nokia Transport, RouteShout, and Tiramisu. • Data visualization—applications that provide graphic visualizations of transit routes, stops, and schedule data. Examples include Walk Score, Apartment Search, and Mapnificent. • Accessibility—applications that assist transit riders with disabilities in using public transportation. Examples include: Sendero Group BrailleNote GPS and Travel Assistant Device (TAD). • Planning analysis—applications that assist transit pro- fessionals in assessing the current or planned transit network. Examples include: – OpenTripPlanner: Analyst Extension – Graphserver – Regional Public Transportation GIS Architecture and Data Model – Transit Boardings Estimation and Simulation Tool (TBEST) – TransCAD 6.0 – GTFS-based Planning and Research • Interactive Voice Response (IVR)—applications that provide transit information over the phone by means of an automated speech recognition system. • Real-time transit information—applications that use GTFS data along with a real-time information source to provide estimated arrival information to transit riders. Examples include OneBusAway, NextBus, and TransLo¯c. As mentioned in TCRP Synthesis 104 (69), open data are being used to power electronic signs that display real-time information (see Figure 14 for an example). The digital signs originally developed by Mobility Labs have become com- mercially available. That synthesis reported, The widening world of open data availability is generating a deluge of mobile apps designed to deliver transit information to people on the move. But there is still an active—and growing— market for static displays, linked—among other factors in the United States—to the increasing importance of transit-accessible location in real estate markets. The system is for use by building owners—typically in lobbies—in any large metropolitan area pro- viding open transit data. It draws together data streams from dis- tinct agencies for presentation on large screens in multi-occupied residential and commercial properties. In Europe, another vendor provides real-time transport dis- plays (see Figure 15) in private homes and commercial proper- ties (70). Another example of information displays driven by open transit data is shown in Figure 16 (70). Wong described the use of GTFS to conduct several transit planning analyses (18). Table 2 “summarizes the fixed-route transit service measures from the [Transit Capacity and Quality of Service Manual] TCQSM and identifies those where GTFS feeds can be used as a data source. Two of the six measures can be calculated exclusively with GTFS feeds and three others can be calculated using GTFS feeds with supplemental data” (18, pp. 3–4). FIGURE 14 TransitScreen display in a commercial building in Washington, D.C. (70).

25 Figures 17 and 18 show the results of TCQSM analyses using GTFS data. Antrim and Barbeau (60) provided other examples using GTFS applications, as follows: • “The Delaware Valley Regional Planning Commission (DVRPC) used GTFS in developing their regional fore- casting model; • The Brookings Study of Transit and Jobs in America used GTFS data to determine how well transit connects people with their jobs; and • The National Center for Transit Research identified opportunities to use GTFS data to support service planning and operational activity and developed a pro- totype application that integrated GTFS data with an automatic passenger counter (APC) for analysis and visualization.” Google Transit provides a real-time information applica- tion through Live Transit Updates for those agencies using GTFS-realtime and Google Maps (https://developers.google. com/transit/google-transit#LiveTransitUpdates). The cities covered by Google Maps can be found at https://www.google. com/landing/transit/cities/index.html. The Transport Innovation Deployment for Europe (TIDE) project provides several examples of applications in Appen- dix G (72). An application that calculates the average time it takes to travel between two stations of Capital Bikeshare is shown in Figure 19. This application examines trips between any two stations, comparing the average Capital Bikeshare rider’s trip duration to estimated times for driving, transit, biking, and walking from Google Map’s algorithms. VISUALIZATIONS The literature covers numerous visualizations using open data. The term visualization means “representing abstract business or scientific data as images that can aid in understanding the meaning of the data” (73). The literature also covers tools that assist in visualization, such as OpenTripPlanner (OTP) Analyst (74). FIGURE 15 In-home portal (70). FIGURE 16 Sample digital sign in Silver Spring Metro Station (71, p. 6). TABLE 2 DATA REQUIREMENTS IN TCQSM ANALYSES

26 FIGURE 17 Distribution of stop-route level daily headways for the SEPTA bus system (18, p. 9). FIGURE 18 Length and number of stops for SEPTA bus routes (18, p. 9).

27 Mapping and data visualizations are effective tools for commu- nicating the robust data and information within the GTFS by providing clarity to service levels which the data doesn’t natu- rally produce. This can help articulate the impact of an agency’s service changes and service cuts (75). Open transit (and other types of) data allow many differ- ent types of visualizations that graphically display data to be easily interpreted. One example is showing the accessibility of Welsh schools by public transport using a program called Mapumental (76). In 2013, there was an interest in showing the shortest time using public transit to get to any secondary school in Wales from any point in the country. Figure 20 shows this visualization. Time bands are in 15-minute increments, with red areas being those where schools are accessible within a 15-minute journey (the centres of the red dots therefore also represent the positions of the schools). Purple areas are those where journey time is between 1.75 and 2 hours, and the colours in between run in the order you see bottom right of the map. White areas (much of which are mountainous and sparsely populated) are outside the two-hour transit time (77). There are several visualizations using open data from the Washington, D.C., area’s Capital Bikeshare (78) shown in Figures 21 and 22. Catalá et al. (75, pp. 32–41) provide several visualizations using GTFS data, including a Marey graph that shows the distribution of PATH trips and vehicles per hour at a particu- lar stop (see Figure 23). The report also describes how GTFS data can be used to calculate service and performance evalu- ation metrics. Finally, the report describes opportunities to combine GTFS data with performance-related information (e.g., APCs). There are many other articles and reports about using open data to conduct analysis and provide customer information (79–94), including an article about a visualization (see Fig- ure 24) that shows access to jobs on public transit. “Specifically, it tells us how many jobs are accessible within 30 minutes— using the key at right—from each location by public transit, during the 7–9 a.m. peak morning window. The darker green areas have the greatest accessibility to jobs; the lighter green areas have the least. The red lines show transit routes” (80). Further, an initiative funded by Virginia Department of Rail and Public Transportation, is based on three factors: (1) open transport data standards such as GTFS and OpenStreetMap; (2) multimodal trip planning engines such as OpenTripPlan- ner; and (3) web-based visualization tools such as the D3 (Data-Driven Documents; e.g., https://github.com/mbostock/ d3/wiki/Gallery) library (82). FIGURE 19 Bikeshare trip timer (http://rausnitz.com/bikesharetimer/ results.php?stationstart=31223&stationend=31267).

28 FIGURE 20 Transit times by public transport to secondary schools in Wales, with an arrival time of 9:00 a.m. (77).

29 There are examples of nontransit visualizations using open data, such as the one shown in Figure 25, which displays the problem areas in the United States for flying, displaying air- ports with delays and flight cancellations. COSTS AND BENEFITS The costs associated with providing open transit data have been documented in a limited number of documents. Lee (24, p. 5) and Wong et al. (33) identified the costs as follows, based on the size and complexity of an agency’s operations: • Converting data to mainstream formats (e.g., GTFS), which may include an additional cost to purchase pro- prietary scheduling software (which has modules that FIGURE 21 Capital Bikeshare DashBoard. FIGURE 22 Three-dimensional visualization of trip history Capital Bikeshare data. FIGURE 23 Port Authority Trans-Hudson (PATH) vehicles per hour at Hoboken.

30 automatically generate GTFS feeds) but allows for mini- mal human input which minimizes errors in data transla- tion to GTFS; • Web service for hosting data; • Personnel time to update and maintain data as needed; and • Personnel time to liaise with data users One example of costs is provided in Wong et al. (33). Staff at BART discussed creating the original GTFS feed as an internal staff project, originally in less than one day. Since then, the agency reported spending less than $3,500 over the lifetime of a software product that was commissioned to specifically output GTFS from their existing scheduling database. This information is consistent with consultant estimates from the literature sug- gesting a cost for small agencies on the order of $3,000–5,000 based on simple networks with limited stops. Several free tools exist for agency use to generate and edit GTFS feeds including a project funded by the Transportation Research Board’s IDEA program (33). However, the benefits of open transit data are cited in sev- eral pieces of literature. Open transit data are often mentioned as having some of the most significant benefits because of the relationship of such data to riders. For example, Maltby (95) states that one of the most successful and prolific areas where open data has gone into mass public use has been through the multitude of transport information apps that allow citizens to better plan FIGURE 24 Job accessibility by transit (80).

31 their rail, tube or bus travel, find a parking space, or evade road works, or which through Google Now even help predict plan- ning for journeys you are about to take. The Deloitte report for Stephan Shakespeare’s independent review of Public Sector Information found there had been more than 4 million down- loads of apps using transport data in London alone. Beyond the services delivered directly to the public, companies such as Placr are developing a thriving business aggregating transport data from a variety of sources and providing this as a service for app developers and organisations including Transport for London. TCRP Legal Research Digest 37 (96), Traveline Informa- tion Ltd (TIL) (a partnership of transport operators and local authorities formed to provide impartial and comprehensive information about public transport in Scotland, England, and Wales) (97), and Lee (23, p. 14), identified the following ben- efits of open data: • Perception that an agency is more “open” and transpar- ent than other agencies that do not share their data; • “Halo effect” of being involved in innovative third-party platforms and uses; • Partnerships between agencies and their local devel- oper communities; • Higher quality (including accuracy) information for customers, resulting in improved customer service and experience, and potentially increased ridership; • No customer confusion about the origin or location of “official” (agency) information; • No additional customer services complaints; • Third parties have developed applications that an agency: – may not have thought of; – did not know that customers wanted; and – could not afford to procure or develop; • Time saved by agencies in developing customized applications; • Crowdsourcing of data quality checking; • Better understanding of the demand for data and cus- tomers’ needs; and • Better understanding of what services can be made avail- able commercially, and those that cannot and need to be funded to ensure inclusion and accessibility. The Polis Position Paper (98) reports that in addition to transparency, open data offers local authorities an opportunity to meet other local transport policies, notably to pro- mote sustainable travel choices, by enabling them to: • Relook at their own business and improve internal pro- cesses, notably (i) seeking to understand which data a pub- lic body holds/gathers, (ii) thinking strategically about the value of data, (iii) improving the quality of data through feedback from the developer community. • Improve the quality of service to users by harnessing the cre- ativity of the apps developer community to produce innova- tive services based on one or more data feeds. • Reduce the cost of service provision, by allowing the local authority to focus on data acquisition and management while the private sector takes on some of the burden of disseminating information to users. • Promote economic development, especially for local infor- mation services providers (see previous point). FIGURE 25 FlightAware’s Misery Map (http://flightaware.com/miserymap/).

32 TCRP Synthesis 91 discusses some of the benefits just being realized by open transit data (1, pp. 16–17). . . . Jay Walder, the New York Metropolitan Transportation Authority (MTA) Chief Executive Officer, stated that he hoped ‘that the tools that might be developed using the agency’s data would help transform the city’s transit system into an even more useful resource for residents much faster and cheaper than it could do so itself.’ Further, at the end of 2009, the Massachusetts Depart- ment of Transportation (MassDOT) launched the first phase of its open data initiative by releasing real-time information for five bus routes. The data released to software developers included real- time GPS locations of buses and arrival countdown information for every bus route. Within just one hour of releasing these data, a developer built an application showing real-time bus positions. Within two months, more than a dozen applications had been cre- ated including websites, smart phone applications, SMS text mes- sage services, and 617 phone numbers. All of these applications were created at no cost to MassDOT or the Massachusetts Bay Transportation Authority (MBTA). One important set of benefits for the transit industry results from MTA’s Bus Time project, as shown in Table 3. Transit agencies have traditionally procured proprietary solutions rather than open solutions, which is what Bus Time is based on. McHugh (47, p. 130) notes that at TriMet, our process is automated, so there is very little over- head. TriMet has four major service changes a year, in addition to minor changes and adjustments in between. We may update and publish our GTFS data as frequently as twice a month. Tri- Met has not incurred any direct costs for this specific project, except resource time, which is a very small investment in com- parison to the returns. Now that agencies have made GTFS freely available as open data, hundreds of applications have spawned worldwide. We found that by making our data easily and openly accessible, developers are getting very creative and expanding its use. This is not only beneficial because it expands the number of product offerings available, but it can also have emergent economic benefits for developers and the communities that they live in. In addition, because the standard allows for interoperability between cities, applications built to serve one city can be readily deployed to serve other cities for a much lower cost and effort than if the data wasn’t standardized. ENGAGING EXISTING AND POTENTIAL DATA USERS AND REUSERS Lewis (99) describes a number of engagement strategies being used by transit agencies, as follows: • MTA sponsors contests and hackathons, such as the MTA App Quest, which was their second challenge; • SEPTA has sponsored three hackathons; and • Madison Metro has developed “strong relationships with the local software community and universities.” . . . Our advice would be to do your best to work with the devel- opers ahead of time. Tell them your concerns and make sure to impress upon them the needs of your riders and the need for it to be accurate. After all, third-party developers aren’t public transit employ- ees or vendors, so system employees need excellent communica- tion and a shared understanding of the goals and considerations in public transit if the project is to succeed. One of the students who developed a Madison Metro app continues to maintain it even though he’s been hired by Google and moved to California, Rusch said. ‘It’s about fostering relationships with these people because they don’t work for you directly and you’re not purchas- ing a service from them,’ he said. As mentioned earlier in the report, APTA’s survey regard- ing real-time information reported that app contests were held by 8% of the APTA survey respondents. Twenty percent of larger agencies used this engagement technique, as shown in Figure 26. BART suggests that meeting with data users and reusers encourages discussing their needs and generating ideas. BART has used 10 engagement techniques (62): • Meetups • One-on-ones • Google groups • RSS feeds • E-mail lists Source: “Bus Customer Information Systems” (65, p. 7). Note: HW = hardware; SW = software. TABLE 3 PROPRIETARY VERSUS OPEN SOLUTION

33 • Developer challenges • Hack days • Media events • Transit camps • “Find a politician willing to get in front of a camera!” Barbeau (100) and Wong et al. (33) also discussed engage- ment approaches. First, the relationship with developers should be created using five steps: (1) open your GTFS data and share on GTFS Data Exchange; (2) share real-time data, too; (3) create a “developer page” with access to resources (e.g., GTFS license, data); (4) create a developer e-mail list/ group for announcements, questions and answers, and col- laboration; and (5) announce resources on “transit develop- ers” group. Wong et al. discussed various outreach strategies used in working with developers. “Agency interviewees reported that most developers seemed to have civic-minded motiva- tions, aiming to provide travelers with better or more easily interpreted information. One staff member noted that agen- cies and developers were serving essentially the same peo- ple, and that an agency that supports developers with open data indirectly serves its own ridership and potential future customers” (33). Other examples of engaging developers included: • Full description of GTFS and any other available data includ- ing limitations, service area and any non-standard data included; • Participation in, preferably, agency-hosted e-mail groups or online forums to answer basic questions on or address issues in the data feed; • Developer conference or “hackathon” where agencies describe major needs in traveler information and encourage developers to create software concepts that address those needs in a concentrated effort (sometimes held simultane- ously with the release of agency data and/or in conjunction with other municipal datasets); and • App ‘showcase’ where agency staff allows developers to pre- sent about their products to the staff to generate internal sup- port for the projects (33). There are a few disadvantages to using app contests to develop apps because conditions can change after the contest is held, and the winning apps may not be maintainable. For example, in 2012, the winning entry in an MTA app con- test was later purchased by Apple. Thus, offering a reward to maintain an app for at least a certain period of time may be helpful. IMPACTS OF OPEN DATA An appropriate introduction to a discussion of the impacts of open transit data is to note a statement made in “Project Open Data: Open Data Policy—Managing Information as an Asset” (101): “When the U.S. Government released weather [in 1980] and [global positioning system] GPS data [in 1983] to the public, it fueled an industry that today is valued at tens of billions of dollars per year. Now, weather and mapping tools are ubiquitous and help everyday Americans navigate their lives.” Stephen Goldsmith discusses the fact that “amid nation- wide public-sector budget cuts, open data are providing a road map for improving public transit and engaging an increasingly tech-savvy citizenry” (102). From a local perspective, Kurt Raschke sees open transit data as a way to meet the Washing- ton Metropolitan Area Transit Authority’s strategic goals set forth in the agency’s latest strategic plan, called Momentum (http://www.wmata.com/Momentum/), . . . without the cost, delay, and dysfunction traditionally asso- ciated with government IT procurement. With open data, open source, and open architecture, we can deliver a cutting-edge product, while saving money and putting a better product in riders’ hands faster. But to do this, we need the region’s transit authori- ties to fully embrace open data and open system architectures. Breaking free from the cost, inflexibility, and data silos tradi- tionally associated with transit passenger information systems means fully considering open-source products alongside their proprietary counterparts, and demanding that agencies work with and alongside—not against—open-source developer communi- ties, both locally and across cyberspace. Leveraging open stan- dards such as SIRI and GTFS-realtime, publishing high-quality open data, and collaborating with developers to enhance the quality and utility of data products all contribute to a better end product, and, ultimately, help advance the strategic goals which WMATA [Washington Metropolitan Area Transit Authority] has outlined in Momentum (103). FIGURE 26 Number of agencies that held App contests (51, p. 6).

34 An example of open data creating a positive impact is the District of Columbia DC Circulator Dashboard (circulator- dashboard.dc.gov) (104), which was created to: • Advance government transparency and accountability • Facilitate data-driven decision-making • Improve information availability to the community • Engage the public on operations, routing, and safety • Identify areas needing improvement • Highlight success for replication. The cost to develop the dashboard was minimal ($5,000 and two part-time staff over 6 months) and users need only a basic Internet browser and free plug-in to access it. Other impacts are discussed by Eros et al., including the potential to . . . lower the barrier to innovation and enhance cross-fertilization of tools, approaches and ideas. In Mexico City, for example, almost immediately after the release of the GTFS feed, a number of apps made use of these data to provide value to users. The suite of apps is already growing; all have been created by American, Canadian, and Israeli developers as transfers of previously existing apps into the Mexico City environment. The nature of the GTFS format facilitates easy innovation transfers between different problems and contexts; as one city develops apps around a particular prob- lem, others can benefit with relatively little additional investment. This is not limited to public-facing apps—it includes data collec- tion as well as analysis and planning tools. However, more must be done, particularly in expanding the reach of this open-data culture to ‘traditional’ transport planning tools (8, p. 13). Additional impacts wee noted by Suzanne Hoadley in her presentation at the 2013 Annual Polis Conference held in Brussels, Belgium, on December 3 and 4, 2013: “Opening Up Transport Data” (105). Polis is a network of European cities and regions working together to develop innovative technologies and policies for local transport. Since 1989, European local and regional authorities have been working together within Polis to promote sustainable mobility through the deployment of innovative transport solutions. See http://www.polisnetwork. eu/about/about-polis.) In some cities, the practice of opening up data has . . . helped create a relationship of trust with app developers; improved the quality of data itself; and genuinely harnessed the creativity of developer community (105, p. 3). . . . Further, the perceived benefits are improve[d] internal processes, including data inventory, data value and data quality; improve[d] quality of service by harness[ing the] creativity of developer community; reduce[d] cost of information service provision; and promot[ion of] local economic development (105, p. 4). However, many challenges in opening data were mentioned and will be covered later. The value of open data in the transportation area was described as follows by Barbeau (25). There are three major levers for unlocking value with open data in transportation: • Improved infrastructure planning and management. Open data on passenger flows and door-to-door travel times allows network operators (including municipal transit systems) to improve capacity and throughput. Open data already has been used to improve the design of transpor- tation networks. For example, when Moscow’s transit authority was modernizing its public transit system in 2012, it depended on open or shared data to determine where commuters lived and where they worked in the Russian capital. Officials used mobile phone location data along with government information on the ages, pro- fessions, and home neighborhoods of workers who com- muted to specific business districts. Moscow then used this information to determine if greater investment was necessary in rail networks or if other services could do a better job of meeting demand. Based on the research, the city decided not to make a costly investment in a new rail line and instead met transportation needs by redrawing 100 bus routes. This limited Moscow’s upfront invest- ment costs and ensured that services could be flexible enough to meet the needs of a shifting population. In addition to avoiding more than $1 billion in infrastructure costs, the new bus routes reduced average morning com- mute times by three minutes per trip, saving ten hours of travel time for each rider every year. In New Jersey, NJ Transit released data on passenger flows to the public in 2012. Third parties quickly analyzed ridership at differ- ent times of day and were able to pinpoint underutilized rail stops, which led to more express trains and a saving of six minutes from the average commuting time during rush hour. • Optimized fleet investment and management. Real-time open data about vehicle location and condition and bench- marking of vehicle cost and maintenance information can help operators purchase, deploy, and maintain fleets more efficiently. • Better-informed customer decision making. Detailed open data about costs, reliability, environmental impact, and other factors can allow customers to make better deci- sions about which mode of travel to use and when (25, p. 32). . . . Based on our analysis, we estimate the global potential eco- nomic value that could be unlocked through these open data levers in transportation to be $720 billion to $920 billion per year. Optimized fleet operations (fuel savings, more effec- tive maintenance, higher utilization) could enable as much as $370 billion a year in value. Improved infrastructure planning and management and improved consumer decision making can each lead to value of as much as $280 billion per year (25, p. 32). The challenges associated with opening public transit data are covered extensively in the literature. In “Open Data Pre- sents Opportunity, Challenge for Public Transit Systems” (99), many challenges were noted. The innovation potential of open source data brings with it associated challenges, not the least of which are cost and devel- oping a sound process for releasing data and maintaining over- sight of its use. Any public transit system interested in jumping on the bandwagon of open data—or expanding existing open data programs—could learn valuable lessons from the experi- ences of other agencies making the transition. ‘You want to be in a position where you’re giving information, you’re support- ing ideas, and you’re encouraging creativity,’ said Ron Hop- kins, assistant general manager of operations for Philadelphia’s Southeastern Pennsylvania Transportation Authority (SEPTA), which collects 1.5 million data points each month to measure on-time performance. ‘The concern was, how do we manage all that?’ (99).

35 In terms of challenges, James Wong, Landon Reed, Kari Watkins, and Regan Hammond discuss data integrity and maintenance as critical issues (33). In terms of data integrity, because open data can be used as input to traveler information tools, such as trip planners, “any inaccuracies in the GTFS cascade down to inaccuracies among [these] tools. Data main- tenance relies on not only the agency maintaining a public file with up-to-date information, but also software developers who commit to update the information on their own proj- ects when the data is updated” (33, pp. 6–7). Antrim and Barbeau (60) discuss the challenges in terms of resource requirements as follows. Transit agencies must make the decision whether to format and maintain a GTFS dataset using their own personnel, or if they are going to outsource this task. It is important to consider that a new GTFS dataset will need to be produced every time there is a change to the schedule to keep the transit services based on GTFS data up-to-date. Major schedule changes can occur 3 to 4 times a year for large agencies, although, depending on the impact on the transit rider, the agency may want to update their GTFS data more frequently to reflect smaller changes in ser- vice on a weekly or monthly basis. Therefore, when identifying a GTFS creation process, the maintenance and sustainability of the process must be considered (60, p. 4). Additional challenges are discussed in the Polis Position Paper (98), by the Finnish Transport Agency (106), by Marples et al. (107), by Traveline Information Limited (TIL) (108), in the McKinsey report (25), by Beasley of the Reading Borough Council (12), and by Watkins (14, pp. 27–30, 40–42): • Opposition from information service providers, due in some cases to the fear of the threat of competition. Deployment of open data principals for data exchange between private sector firms and service providers could alleviate this challenge. • Data control and ownership, for instance where data are owned by a cross-agency institution (e.g., passenger transport authority) or data are provided by a contractor. Some concerns cited by contractors include “competitor or commercially sensitive,” “fear of use for measuring operational performance,” and “extra burden on opera- tions.” Usage agreements could be helpful in expressing agency concerns. • Organizational in the sense that there may not be a clear process/practical framework to guide transport authori- ties in opening their data. In addition, there may be a lack of understanding of the value of open data to improve performance and a lack of capability/expertise to implement an open data program. Also, having staff- level champions and strong leadership often leads to successful deployments. • Architectural in that some systems are not designed for publishing open data. Further, they may have been devel- oped ad hoc for a single operator, making it challenging to integrate the data among multiple agencies. Integrat- ing data from multiple sources requires consideration of system capacity, load and response time, frequency of updates, nonstandard feed formats, different interpreta- tions of standard protocols, nonstandard referencing, and data complexity. An example is where location references between one mode and another may differ. In addition, a gap in data standards may challenge release and use of open transit data. • Data coverage, quality, privacy/confidentiality, accu- racy, and timeliness: data may need significant amounts of “cleansing” or anonymizing before publication. One way to overcome this challenge is for agencies to take no responsibility for the data or information provided. However, having processes in place to report problems, see progress, and achieve fixes helps address this issue. Definitions for minimum quality of service requirements also would help. • Unrealistic expectations or dependency from the pub- lic around the authority’s capacity to provide consis- tent, convenient, and reliable data all the time (e.g., data latency following the detection of an incident). This challenge includes managing public reactions and expec- tations about changes in the transportation system that arise from the use of open data. Further, the data may not be what is desired by the public, which highlights the fact that the determination of which data to open should be based on the data users’ needs. Sometimes “the private sector is better placed to provide the end user services and can help advise on what data [an agency] should focus on” (12). • Cost of opening up data, which is pertinent in the current climate of public sector cuts and in view of the fact that most authorities do not have a dedicated budget for their open data activity. This cost does not just relate to build- ing and providing the open data facility but also relates to the ongoing costs of maintaining open data (ensuring that authorities have the resources to update/refresh the data once it is published) as well as the support that must be provided to the developer community (98). • Developer relationships need to be at different levels of engagement and promote support for mutual customers. • Working with app developers should be sustainable and holistic, and include open communication lines. • Performance measures are to be used to track success, including number of app downloads, number of apps developed, an app accessibility inventory, and market research surveys. • Consider accessibility and equity.