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.

36 The survey results show that almost all agencies provid- ing open data see it as a way to maintain or increase rider- ship. Fifty-four or more than 96% of responding agencies that provide open data did not use any evaluation measures to assist them in deciding to open their data. The major factor in agencies deciding which data to open is based on the ease of releasing the data. The next major decision is based on observing what other transit agencies have done regarding open data, and the third most frequent decision was done internally without asking any groups out- side their agencies. All the survey responses are shown in Table 7 and Figure 27. UNDERLYING TECHNOLOGY In terms of the underlying technology that is generating the open data, the survey results indicate that scheduling soft- ware is the primary system being used. The next most used is GIS. The third most used is computer-aided dispatch (CAD)/ automatic vehicle location (AVL). All survey responses about underlying technologies used to generate open transit data are shown in Figure 28. The “other” category includes the following responses: • AVL/CAD vendor-supplied • GTFS generated in Microsoft (MS) Excel • Manually entered data • Schedules. Scheduled information only • Trapeze • Trillium Transit • We collect and host data from transit operators in the region • All auto-generated from our enterprise relational data- base management system (RDBMS) • Open source editing tool (https://github.com/conveyal/ gtfs-editor) • Ride checks • Clever Devices (CD) BusTime Developer’s API, data- base script to convert scheduling information in Hastus and CD Bustools to GTFS • Ontologies (protégé) SPARQL. The synthesis survey covered several key characteristics of open transit data, including the justifications and rea- sons for choosing to provide or not provide open data; the underlying technology being used to generate the data; and the standards, protocols, and formats used in providing the data. Table 4 and Appendix B list the 67 responding agen- cies. Before examining these characteristics, the study team noted the overall annual ridership and modes operated by each respondent. U.S. responses represent agencies that carry a total of just more than 5.4 billion passengers annually (annual unlinked trips), with U.S. agencies’ annual ridership ranging from 1.8 million (a county transit system in Florida) to 2.6 billion (MTA). The total annual ridership for each agency is shown in Appendix D. JUSTIFICATIONS AND REASONS FOR PROVIDING OPEN DATA The first question in the survey was “Has your agency pro- vided open data?” Of the 69 (two agencies provided two responses each from different departments of the agency) responding agencies, 57 (82.6%) provide open data and 12 (17.4%) do not. Half of the agencies began providing open data in the 2010 to 2012 time frame. One agency started pro- viding open data in 1981, two in the mid-1990s, 21 in the 2000 to 2009 time frame, and three in 2013. Fifty-one agencies (almost 90% of those agencies that pro- vide open data) provide it to increase information access to transit riders. The next most prevalent reason (49 responses, almost 86%) is to improve upon existing customer informa- tion and customer service or create new customer informa- tion services. The next most prevalent reason for providing open data is to foster a more positive perception of transit or encourage more people to try public transit. Table 5 shows all of the reasons agencies provide open data. The most prevalent reason transit agencies are not provid- ing open data is that it is too much effort to produce the data or the agency does not have the time or people to do the work required. The next most prevalent reason is that it takes too much effort to clean the data. All of the reasons are shown in Table 6. chapter three SURVEY RESULTS: CHARACTERISTICS OF OPEN TRANSIT DATA

37 TABLE 4 RESPONDING AGENCIES Agency Name City State/Province/ Country Alameda–Contra Costa Transit District (AC Transit) Oakland CA Ann Arbor Area Transportation Authority (AAATA) Ann Arbor MI Arlington Transit (ART) Arlington VA AtB AS Trondheim Norway Atlanta Regional Commission Atlanta GA Bangor Area Comprehensive Transportation System Brewer ME Bay Area Rapid Transit (BART) Oakland CA Bilbao City Council Bilbao Bizkaia, Spain Blacksburg Transit Blacksburg VA Chittenden County Transportation Authority Burlington VT Capital Metropolitan Transportation Authority Austin TX Central Florida Regional Transportation Authority Orlando FL Central New York Regional Transportation Authority Syracuse NY Champaign–Urbana Mass Transit District (CUMTD) Urbana IL Charlotte Area Transit System (CATS) Charlotte NC Chicago Transit Authority (CTA) Chicago IL Consorcio Regional de Transportes de Madrid Madrid Spain Des Moines Area Regional Transit Authority (DART) Des Moines IA Delaware Transit Corporation (DTC) Wilmington DE Empresa Municipal de Transportes de Madrid, S.A. Madrid Spain Fairfax County DOT/Fairfax Connector Fairfax VA Grand River Transit (Region of Waterloo) Kitchener Ontario, Canada Greater Bridgeport Transit Bridgeport CT Greater Cleveland Regional Transit Authority (GCRTA) Cleveland OH Helsinki Regional Transport Authority Helsinki Finland Interurban Transit Partnership (ITP) Grand Rapids MI Kansas City Area Transportation Authority (KCATA) Kansas City MO King County Metro Seattle WA Los Angeles County Metropolitan Transportation Authority Los Angeles CA Manatee County Area Transit (MCAT) Bradenton FL Massachusetts Bay Transportation Authority (MBTA) Boston MA Metrolinx Toronto ON Metropolitan Atlanta Rapid Transit Authority (MARTA) Atlanta GA Metropolitan Transportation Authority (MTA) New York NY Metropolitan Transportation Commission (MTC) Oakland CA Monterey–Salinas Transit District Monterey CA NJ Transit Newark NJ Norwegian Public Roads Administration (NPRA) Trondheim Sør-Trøndelag, Norway New Hampshire DOT Concord NH North County Transit District (NCTD) Oceanside CA Norwalk Transit District Norwalk CT Orange County Transportation Authority (OCTA) Orange CA Oregon DOT Rail + Public Transit Division Salem OR Pennsylvania Public Transportation Association Harrisburg PA Pace Suburban Bus Arlington Heights IL (continued on next page)

38 TABLE 4 (continued) Agency Name City State/Province/ Country Pinellas Suncoast Transit Authority St. Petersburg FL Roaring Fork Transportation Authority Aspen CO Regional Transportation Commission of Washoe County Reno NV Regional Transportation District (RTD) Denver CO Stark Area Regional Transit Authority Canton OH Suburban Mobility Authority for Regional Transportation Detroit MI Samenwerkingsverband Regio Eindhoven (SRE) Eindhoven Brabant, Netherlands Syndicat des transports d'Île-de-France (STIF) Paris France San Mateo County Transit District San Carlos CA Société de transport de Laval Laval Quebec, Canada Sound Transit Seattle WA Tampere City Public Transport Tampere Pirkanmaa, Finland Transport for London (TfL) London United Kingdom Transport for Greater Manchester Manchester United Kingdom Tri-County Metropolitan Transportation District of Oregon (TriMet) Portland OR Organization of Urban Transportation of Thessaloniki Thessaloniki Greece Urban Transport Administration Gothenburg Vastra Gotaland, Sweden Utah Transit Authority Salt Lake City UT Votran South Daytona FL Wiener Linien Vienna Austria Worcester Regional Transit Authority (WRTA) Worcester MA York Region Transit Richmond Hill Ontario, Canada TABLE 5 REASONS FOR PROVIDING OPEN DATA Reason for Providing Open Data Number of Respondents Percent of Agencies Providing Open Data Increase information access to transit riders 51 89.5 Improve upon existing customer information and customer service or create new customer information services 49 86.0 Foster a more positive perception of transit/encourage more people to try public transit 44 77.2 Foster/encourage innovation around the agency’s data or help third parties develop skills and services (e.g., with which the agency can contract) 36 63.2 Facilitate information sharing within the agency and with partners and customers 34 59.6 Agency transparency 33 57.9 Availability of data standard(s) for transit information (e.g., GTFS) 33 57.9 Improve effectiveness of the agency and its services 32 56.1 Increase customization for customer information 31 54.4 There was demand for us to open our data/we were requested to provide open data 29 50.9

39 TABLE 6 REASONS FOR NOT PROVIDING OPEN DATA Reasons for Not Providing Open Data Number of Respondents Percent of Agencies Not Providing Open Data Too much effort to produce the data/we do not have the time or people to do the work required 5 38.5 Too much effort to clean the data 4 30.8 We cannot control what someone will do with our data 3 23.1 We do not know the accuracy of our data 3 23.1 2 15.4 It will put a strain on our systems 2 15.4 Proprietary vendor contracts preclude us from sharing data with third parties 2 15.4 Our agency is too small 2 15.4 Our data could be misused or misinterpreted Our agency will be liable if erroneous data are provided to the public 2 15.4 Our agency does not know how to open our data 2 15.4 There is a lack of interest internally 1 7.7 There is a risk-averse culture within our agency 1 7.7 Other (please specify) We are in the planning phases of opening our data, but the above have been our roadblocks. We plan on it, need to verify accuracy. Working with vendor to make data available through GTFS–realtime interface. Our software doesn’t have a secure location for customers to access the data. The regional transit authority uses another software module to provide real-time information to the public. We are in process of having an API created by a third party since we are restricted by our vendor from dealing with an agency that has experience with creating an API for Transit. Due to limited staff resources, information has not been shared. This will change with AVL/GPS project in process. Governor’s office has requested datasets for a statewide effort. We will provide, but it is taking time due to staff constraints. Have been requested to provide select open data sets by the Governor’s Office. We will do so but it is taking a long time due to staff constraints. From survey responses. TABLE 5 (continued) Reason for Providing Open Data Number of Respondents Percent of Agencies Providing Open Data Help achieve other agency goals (e.g., by providing a wider audience for published information) 27 47.4 Provide ways to better understand and use transit information within our agency 26 45.6 Participate in the latest trend in the transit industry 26 45.6 Improve or provide new private products and services 25 43.9 An information gap existed that could be bridged by better public data 20 35.1 Cut costs to our agency 12 21.1 Provide incentives for others to help maintain data sets, reducing the maintenance cost for the agency 12 21.1 Other (only one respondent specified that their “other” response meant “part of agency culture, esp. information technology.” 6 10.5 Measure the impact of transit on the community(ies) that are served 6 10.5 From survey responses.

40 TABLE 7 FACTORS IN DECIDING WHICH DATA TO OPEN Decision Factor Number of Respondents Percent Based on the ease of releasing the data 33 58.9 Based on observing what other transit agencies have done regarding open data 21 37.5 Decided internally without asking any groups outside our agency 17 30.4 Asked potential users of the data 11 19.6 Based on the cost associated with producing or cleaning the data 11 19.6 Asked the community in which your agency operates service 8 14.3 Asked riders 1 1.8 Other: Approached by Google. Approached by transit enthusiast. Based upon what our AVL/CAD vendor provided. I don’t know. Open Government Data (OGD) Vienna. Requests to access data. Some in the developer community encouraged us to release items. User demands. Based on demand. Defaults to GTFS and availability of Clever Devices Bustime API. Worked with developers. We were already using web services for internal purposes, we merely exposed it with documentation for the third party developers; a no brainer. Supported University of Washington graduate study project to provide scheduled data to the public via third-party application (One Bus Away). Based on requests from third party service providers. Asked experts in the University field. Decided both internally, and from developer community. From survey responses. FIGURE 27 Factors in deciding which data to open (from survey responses).

41 FIGURE 28 Underlying technologies that generate open transit data (from survey responses). Types of Information Number of Respondents Percent Route data 51 89.5 Schedule data 50 87.7 Station/stop locations 49 86.0 Real-time information 33 57.9 Park-and-ride locations 17 29.8 Fare media sales locations 14 24.6 Ridership data 14 24.6 Other 12 21.1 Budgetary data 10 17.5 Performance data 8 14.0 From survey responses. TABLE 8 TYPES OF OPEN TRANSIT DATA TYPES AND STANDARDS/FORMATS OF OPEN DATA The types of open transit data provided by survey respon- dents are shown in Table 8. The frequency with which the open data are updated or modified is shown in Figure 29. The following responses are in the “other” category: • Three times a year • As needed • At least every quarter • According to the Board period • Major service changes (three times a year) plus peri- odic, significant bi-weekly adjustments • On demand • On request • Real-time data are “real time”; route updates are every 2 weeks • Schedules are updated when changes occur • On average bimonthly • Every time there is a change in the data based on its significance. For example, the tiniest changes might not be updated every time they are noticed. The degree to which the data are open was examined from four different perspectives, as shown in Figure 7. The survey results for each of these four characteristics are shown in Fig- ures 30 through 33. GTFS is the format most commonly used to provide open transit data. The survey results indicate that a number of other standards and formats are being used, as shown in Table 9. The agency’s website is the outlet used most frequently through which open transit data are provided. The GTFS Exchange website is the next most commonly used, followed by APIs. All survey responses to this question are shown in Table 10.

42 FIGURE 29 Frequency with which open data are updated or modified (from survey responses). FIGURE 30 Degree of access of open data for percentage of survey respondents (from survey responses). FIGURE 32 Cost of open data for percentage of survey respondents (from survey responses). FIGURE 31 Machine readability of open data for percentage of survey respondents (from survey responses). FIGURE 33 Rights to open data for percentage of survey respondents (from survey responses).

43 How Agencies Make Data Available Number of Responses Percent Via your agency’s existing website 39 69.6 GTFS Data Exchange website 18 32.1 As an application programming interface (API) 18 32.1 Via a separate agency website 12 21.4 Via a third-party site 11 19.6 Via a single regional centralized site 9 16.1 Public Feeds Wiki page on Google Transit Data Feed Google Code project 8 14.3 Providing data in bulk 7 12.5 Via an ftp site 3 5.4 Other: CD Bustools API IN-TIME platform (Co-Cities project) OGD Vienna Really Simple Syndication (RSS) and XML Feeds XML files through agency firewall Printed schedule as well as website Private web service. From survey responses. TABLE 10 WHERE OPEN TRANSIT DATA ARE MADE AVAILABLE Standards and Formats Number of Respondents Percent General Transit Feed Specification (GTFS) 47 83.9 eXtensible Markup Language (XML) 26 46.4 Comma Separated Values (CSV) 18 32.1 General Transit Feed Specification-realtime (GTFS-realtime) 15 26.8 Geographic information system (GIS) software 14 25.0 Keyhole Markup Language (KML) 10 17.9 Service Interface for Real Time Information (SIRI) 10 17.9 TXT 7 12.5 DATEX2 2 3.6 Transit Communications Interface Profiles (TCIP) 2 3.6 Other: Developed our own—real-time owing to performance required. Excel GIRO HASTUS proprietary format IN-TIME (Intelligent and efficient travel management for European cities) Platform, Traffic Management Data Dictionary (TMDD) INIT–Trapeze special interface JavaScript Object Notation (JSON) JSON—service-oriented architecture (SOA) services MS Word and Excel Network Exchange (NeTEx) Scheduled information only Web services XML and Simple Object Access Protocol (SOAP) Web services/APIs Linked Data, Resource Description Framework (RDF), GeoJSON (Geospatial data interchange format based on JSON. From survey responses. TABLE 9 STANDARDS AND FORMATS USED BY SURVEY RESPONDENTS