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.

54 The MBTA independently opened its schedule data and some real-time information, but initially did not share the real-time information. They wanted to put the real-time information in a data feed on a trial basis before opening it to the public. Further, the market was right for developers— they could use open data for web applications, phone apps, and electronic signs. Before the open data revolution, there were far fewer options available to developers. The MBTA got a positive response after opening its data, and that pro- vided the momentum for continuing the open data program. The choice of standards used for the open data was based on what was needed within the API and what was available in the marketplace. When the MBTA reviewed potential stan- dards, agency personnel wanted to support GTFS-realtime and wanted to be on Google. (The MBTA was one of the first transit agencies in the United States to provide real-time information on Google Transit.) They looked at SIRI but found it to be ver- bose and somewhat complicated, so they decided against using it. However, if SIRI does become more prevalent among devel- opers, they could support it. TCIP was well-suited for commu- nications within an agency, but not for communications with developers, so it was not selected for use with the open data. The MBTA developed an API in order to retrieve smaller sets of information than what is contained in GTFS-realtime (GTFS-RT) and include some information that is not in GTFS-RT. The MBTA selected XML format for its API because it is an industry standard for APIs. The documenta- tion describing the MBTA’s real-time open data can be found in MBTA and IBI Group (111). MBTA’s engagement with developers consists of doing a survey of developers and having a newsgroup in which devel- opers can ask and answer questions. The MBTA received a better response from the survey than the newsgroup. In addi- tion, the MBTA suggests running an event (developer’s con- ference) when an agency has something to announce that is related to open transit data. Although the MBTA has not conducted a survey that directly addresses the effects of the agency’s open data program, a sur- vey was conducted by the MIT examining the impacts of real- time information displayed on the electronic signs in MBTA subway stations. The data displayed on the signs, the arrival times of the next two subway trains, are driven by the same open data available to developers (112, 113). The conclusions of the impact study were as follows. Several of the transit agencies and organizations that responded to the synthesis survey were interviewed by telephone to obtain more detailed information on their deployment of electronic signage. The results of the interviews are presented in this section as case examples. MASSACHUSETTS BAY TRANSPORTATION AUTHORITY (BOSTON) In July 2009, the Executive Office of Transportation (now Massachusetts Department of Transportation) began an open transportation data program by creating a developer’s web page that contained a variety of transportation information, including route and schedule data for the Massachusetts Bay Transportation Authority (MBTA) and Massachusetts regional transit authorities (109). On November 14, 2009, the First Annual MassDOT Developers Conference was held at the Massachusetts Institute of Technology (MIT) to encour- age the development of applications based on the newly opened transportation data. Two important announcements were made at this conference: (1) the winners of the 2009 MassDOT Developers Challenge were announced; and (2) the MBTA announced the availability of real-time bus informa- tion for selected routes (110). Laurel Ruma referred to the MBTA opening its data at Ignite 2010, where she presented “Better than Winning the World Series: Boston Opens Real- Time Transit Data” (http://igniteshow.com/videos/better- winning-world-series-boston-opens-real-time-transit-data). Her speech covered the eight steps that led to the successful opening of the MBTA’s data: (1) build a community, (2) learn the lingo, (3) open data, (4) hold a contest, (5) be prepared to be blown away, (6) award unique prizes (e.g., subway pass for a year), (7) tell the world, and (8) repeat. According to David Barker, there were three primary reasons the MBTA opened its data (D. Barker, manager of operations technology for the MBTA, personal communica- tion, March 10, 2014): 1. The MBTA wanted to get its schedule and real-time data out to customers, realizing that this information is the ultimate in advertising MBTA services; 2. Customers wanted real-time information; and 3. There was enthusiasm for open government ideas and for trying something new (the MBTA wanted to be on the forefront). chapter seven CASE EXAMPLES

55 Countdown signs have significantly altered how passengers view their wait for public transit in Boston. Passengers reduce estimates of wait time on average by 0.85 minutes. After control- ling for service disruptions (when the countdown predictions are less accurate), passengers reduce wait time estimates by 1.3 min- utes. This corresponds to a reduction of approximately 17% in total passenger wait time estimation, and a 50% reduction in wait time overestimation. This coincides with improved wait satisfaction for headways lower than 5 minutes, but decreased for headways greater than 9 minutes. Wait time overestimation remained high at 34% even with countdown timers (112, p. 9). As of early April 2014, the MBTA’s next steps were integrat- ing with Twitter and taking steps to reduce message volume to customers who subscribe to T-Alerts. The agency considered moving from e-mailing alerts to providing them by means of text messages (SMS), but the cost was too high. The improvements in message formatting, which have been implemented, were: • The long subject lines will be replaced with auto- generated information from meta-data that summarizes the subject; and • A message needs to fit within Twitter length requirements—automated abbreviations. Further, the MBTA is interested in conducting another contest or hackathon. In addition, the agency wants to lever- age its API internally. For example, the agency is interested in placing a real-time information sign in one station show- ing the time until the next bus(es). Currently, there is a sign like this in Ruggles Station, but the data come directly from a vendor’s product rather than the MBTA’s API. The agency wants to replace this sign, and place signs in other stations, with signs that use the MBTA’s own feeds and include alerts for services leaving that station, including real-time bus and subway times, and elevator outages. The more the MBTA uses its own API, the more the agency will discover improve- ments that developers might not think of and the more it will reduce vendor lock-in. In a discussion about opportunities and challenges related to open transit data, Mr. Barker mentioned the following: • There is less development in the open data area currently. The original open data products are being maintained. • Adding staff to handle open data is challenging. One way this has been overcome is being able to refer to “good press”—that is helping to get support to add staff. In terms of costs and benefits, the NextBus contract costs $20 per bus per month to make and publish predictions. Fur- ther, the public address/two-display countdown signs have to be maintained. However, the ROI is “fantastic,” and many customer applications are free. The MBTA reports six lessons learned regarding open data: 1. Start small and iterate; 2. Listen to and interact with developers; 3. Know that when you first release the data, there will be a grace period during which you will discover issues; 4. Plan for how you will sustain an open data program; 5. Capitalize on good press. Although it is hard to mea- sure improvements resulting from open data, positive press helps to demonstrate the value of open data; and 6. It is important to maintain the momentum and dem- onstrate an open data project’s performance. In addition to numerous customer applications, several visualizations have been developed using MBTA open data. One visualization, shown in Figure 36, “shows a bit more FIGURE 36 MBTA bus speeds (http://bostonography.com/wp-content/uploads/2011/11/mbta_1104_labels.jpg).

56 FIGURE 37 Visualization of MBTA Orange Line ridership for August 12, 2009 (http://vanderlin.cc/projects/mbta_visualizations: accessed on April 3, 2014). than 24 hours’ worth of bus location data [on November 4, 2011] with colored lines representing the speed of each vehi- cle. Red indicates speeds less than 10 miles per hour, yellow is 10–25 mph, and blue is faster than 25 mph. It’s drawn from 2,058,574 data points in all” (114). Bostonography.com contains several visualizations based on MBTA open data, as shown in Figures 37 through 40. Figure 40 shows the MBTA Orange Line as a 24-hour clock. Each ring is a train station, and the thickness of the line rep- resents the amount of people on the train at that time. Another visualization (Figures 41 and 42) shows “24 hours of MBTA ticket swipes. The color represents the train line and the thickness represent[s] the amount of people riding at that hour” (http://thunderhead.esri.com/readonlyurl/MBTA/ MBTA1.html). A visualization shown in Figures 43 and 44 displays the patterns of MBTA commuters across all subway lines and stations, or for a particular line or station over a single day. In June 2014, another visualization of MBTA data was published in http://mbtaviz.github.io/. This visualization is an in-depth analysis of how MBTA subways operate using a Marey diagram and a heat map that shows the average num- ber of people who enter and exit subway stations for every hour throughout the month of February 2014. TRANSPORT FOR LONDON—LONDON, UNITED KINGDOM As discussed in TCRP Synthesis 91 (1), Transport for London (TfL) began providing open data in June 2010. According to Phil Young, Head of Online at TfL (P. Young, personal com- munication, Feb. 25, 2014), the chronology of events leading to providing open data through early April 2014 is: • 2007—Launched embeddable “widgets” for live travel news, map, and Journey Planner • 2009—Special area for developers launched on TfL website • 2010 – Additional real-time feeds launched, with hundreds of developers registered – Greater London Authority (GLA)—digital advisory board, mayoral and deputy mayor support, mayor’s live event, London Datastore

57 FIGURE 38 Visualization of MBTA Silver Line ridership for August 12, 2009 (http://vanderlin.cc/projects/mbta_visualizations: accessed on April 3, 2014). FIGURE 39 Snapshot of MBTA subway traffic for 24 hours in 5 minutes (James Kebinger “MBTA in Motion,” August 30, 2009: http://www.youtube.com/watch?v=0tuzjxEBto4).

58 FIGURE 40 MBTA Orange Line over 24 hours (http://vanderlin. cc/projects/mbta_visualizations). – U.K. government—Public Sector Transparency Board 2010—central government launch of data.gov.uk to drive forward the release of “machine readable” data • 2011 – London Underground train location and Journey Planner APIs launched. Registered developers rise to more than 1,000. FIGURE 41 MBTA ticket swipe visualization at midnight. – Launch of U.K. Open Data Institute 2011—U.K. government-funded body to promote the social and economic benefits of open data – EU Open Data Strategy 2011—establishing a principle of open data as a rule across the EU • 2012—Bus departures API launched, full London 2012 Olympic and Paralympic Games transport data portal. More than 4,000 developers registered. • 2013—More than 5,000 developers, 30 data feeds, and hundreds of apps on the market serving millions of cus- tomers. New accessibility and road feeds added. At the same time, demand on the TfL website grows: 8 million unique users a month, 250 million annual visits, 2 billion annual page views TfL’s overall strategy is ‘free and open data by default.’ [TfL] works proactively with developers so that a range of apps are developed by the market where possible. Apps will only be developed by TfL itself where the market cannot deliver business objectives or required lev- els of security. We make all of our information feeds freely and openly available to more than 5,000 apps developers who then produce products—more than 200 in the case of London—which we would never have produced ourselves (P. Young, personal communication, Feb. 25, 2014). TfL’s Digital Strategy covering 2011 to 2014 describes how (15, p. 3) • TfL will achieve an integrated, coherent, relevant pres- ence across digital media, including – Online presence—web, tablet, mobile – On-system digital information – Open data – Social media – Digital marketing.

59 FIGURE 42 MBTA ticket swipe visualization at 7:50 a.m. FIGURE 43 Visualization for MBTA Orange Line over 24 hours (“A Day of MBTA” http://adayofmbta.com/).

60 • For open data, TfL will deliver “Data openly syndicated to third parties, where commercially, technically and legally feasible, while TfL engages developers where necessary to meet our business objectives.” Examples of developers’ products include the following: • London’s Nearest Bus—allows users to find the nearest buses and live departure times from their location. Users can also set individual bus alerts to trigger when a bus is due; • Station Master—offers detailed accessibility informa- tion for every London Underground station; • Tube Tracker—a multiservice app that finds the nearest station to the user with directions. Provides automati- cally updated live departure information, a journey plan- ning function, first/last Tubes, and Tube status alerts; • Colour Blind Tube Map—This displays the London Underground map in various formats for easier viewing by people with all forms of vision impairment. Young reports that a global survey of transport companies by the International Association of Public Transport (UITP) shows that 54% of transport operators are now making their data openly available, with only 6% levying any charge to developers. The industry is also seeing it as an important way in which to demonstrate openness and transparency to cus- tomers and stakeholders. At the same time, TfL is experiencing continued and rapid growth in visits to the agency’s other information services. For example, the agency’s website is getting 8 million unique users a month, and the number of people following the agency’s Twitter feeds has risen to more than 1 million. The reasons TfL opened its data are as follows: 1. Public data—as a public body funded by fares and tax- payers, the agency’s transport information is seen to be owned by the public. 2. Reach—the agency’s goal is to ensure persons needing travel information can get it wherever and whenever they wish in any way they wish. Open data allows them to extend the reach of their information. 3. Optimal use of transport network—by enabling cus- tomers to make more informed choices, TfL makes the most efficient use of the capacity of the transport network. FIGURE 44 Visualization for all MBTA subway lines over 24 hours (“A Day of MBTA” http://adayofmbta.com/).

61 4. Economic benefit—open data saves customer time (up to £58 million per annum, according to a recent study) and facilitates the growth of small and medium technology companies, generating employment and a highly skilled workforce. 5. Innovation—by having thousands of developers build- ing applications, services, and tools with TfL data and APIs, the agency stimulates innovation through competition. Each developer must register with TfL to gain access to feeds and APIs. This ensures that the agency can maintain a relationship with them and provide information about changes, maintenance, or new services. In summary, the TfL license states the following. • Data are free to access and use, including for commer- cial purposes. • Applications can be created from the data and commercialized. • The developer must not pretend to be TfL or use the TfL brand. • The developer must not “screen-scrape” login-based services. TfL’s open data are presented in three main ways: (1) Static data files (which rarely change); (2) feeds (data files refreshed at regular intervals); and (3) API, which enable a query from an application to receive a bespoke response. Data are presented as XML when possible. In addition, TfL is moving toward the use of U.K. standards NaPTAN and TransXChange. Young describes five lessons learned related to open data. 1. Transport data are in great demand—particularly real-time information, such as bus and train status and arrivals/departures. 2. Developers need support—processes and resources are needed to support, answer queries, and engage to deliver improvements to data and services. 3. Something is better than nothing—developers are highly creative and would prefer the feeds and data to be released early even if not perfect. They can still do great things with it. 4. Open data can improve data quality—By opening up data, feedback is produced, which refines the data quality and can be used to improve source systems. 5. Open data are good value—emerging research indi- cates that open data provide ROI of up to 50 times the sums invested in terms of customer benefit. TfL’s next steps in open data are as follows: • New TfL website in early 2014—built upon the prin- ciple of APIs, making integration, build, and open data better and easier to deliver. • Single TfL API—A single TfL API consolidating all existing and new APIs into a single normalized model. • App Garden—to showcase applications “powered by” TfL data. This will give consumers choice and ensure apps meet minimum standards. Aspects of the Garden are: – Draw in customer ratings from app stores; – Improve branding guidelines so customers can see which are “powered by TfL”; – Improve control of app developer access through a new access portal; and – Minimum standards check before applications are added to the App Garden. A wealth of TfL open data is available from the London Data- store (http://data.london.gov.uk/taxonomy/organisations/tfl), as shown in Appendix H. Many applications have been developed using TfL open data. One of the earliest applications was a live map of the London Underground, London’s subway system. This app, which won second place at the 2011 Open Data Challenge competition that featured 430 entries from 24 European Union member states, is shown in Figure 45 (115). The same app developer created a similar real-time map showing bus locations (see Figure 46) (116). The app uses OpenStreetMap and open data from TfL. Another visualization, shown in Figure 47, is described by Hargreaves: “It takes live position data from the 100s of buses that travel through the TFL network. The lines are the routes and the dots are the individual buses. The contours of the landscape have been exaggerated to emphasise the sense of space within the visualisation” (117). Another visualization uses smartcard (called the Oyster card) data from TfL to show a day’s worth of transactions, as shown in Figure 48. Green indicates the number of passengers in the transit system, whether on a bus or in one of several rail modes. Blue indicates the presence of riders prior to their first transaction of the day or after their last: it is assumed that the location of a rider’s first or last transaction approximates their place of residence. Red indicates cardholders who are between transit trips, whether transferring, engaging in activities, or traveling outside the transit system (118). Several additional visualizations using TfL data are shown in Reades (119). BAY AREA RAPID TRANSIT—OAKLAND, CALIFORNIA BART’s open data initiative was first reported by TRB (1). In 1998, BART was approached by students from the Uni- versity of California at Berkeley who wanted to develop one website with schedules for all 26 transit agencies in the Bay Area. At the time, there was no single source of transit

62 information. BART knew that it would be virtually impos- sible to manage schedules for all agencies, so this request was a compelling value proposition. The students could have “scraped” the schedules. So BART gave the students sched- ules in .csv format. The site built by the students eventually grew and became the Bay Area’s 511.org. It was positive for BART to support a third-party initiative that led to a sustain- able regional initiative. Another request for data came when the Westfield Mall above Powell Street wanted to install a touch-screen kiosk with BART schedules on it. They requested the schedules in a specific format. BART agreed to provide the schedule data. At this point, BART did not consider making anyone sign a contract to access the data on the kiosk or use schedule data in general. This point is critical to understanding BART’s simple use agreement that does not need to be signed. Because other people began to ask for schedules, fulfilling all of these requests would have been “one-offs” if BART had not opened their data. For example, trying to do an embed- ded quick planner or electronic displays was not the agency’s core business. Then BART saw GTFS and recognized that using GTFS was a way to solve these problems. The thinking was that if the agency published data in this format, it could take care of requests. So it solved the challenges associated with responding to the data requests. BART was one of the few agencies to pilot GTFS-realtime, but the agency had already been providing real-time feeds in XML format (the first real-time feed was provided in 2008). This XML feed was updated every 30 seconds and has since been retired. Currently, the use of the agency’s API allows more granular calls that provide data such as car lengths. Several data items of interest are not in GTFS or GTFS-RT, such as station information and load factors. There are more requests about entries and exits with as much granularity as possible. The overall chronology of BART’s open data program, which has been in existence more than 15 years, is as follows (28, p. 6): • 1998—Schedules provided in .csv format • 2005—Embedded Quick Planner (iframe format) (retired November 2013) • 2006—DIY display [in HyperText Markup Language (html) format] (retired in November 2013) • 2007—Delay, elevator advisories (RSS) • 2008—Real-time estimated times of arrival (ETAs) (XML format) (retired in November 2013) • 2010—Trip plans, station info (API) • 2011—Real-time ETAs, advisories (GTFS-realtime) • 2012—App Map + Geospatial (KML format) One key aspect of BART’s open data program, according to Timothy Moore (interview, March 20, 2014), is that BART used an organic process to open the agency’s data. BART’s universe of data is manageable because of the agency’s size and because there is only one pick (operator signup) per year. FIGURE 45 Real-time train locations in London (http://traintimes.org.uk/map/tube/).

63 FIGURE 46 Live London bus map.

64 FIGURE 47 Snapshot of video visualization of London buses. FIGURE 48 Visualization using Oyster Card Data over a 24-hour period.

65 As of December 2013, BART had 115 apps and open data services, 2,700 developers, and 40 million monthly API calls. Moore reported that the value of open data to develop- ers is as follows (28, p. 7): • Focus on new functionality • Easier to combine/mash-up • Add value to an existing play • Some revenue potential (beyond BART’s reach) • Pride, fun, competition, and experience. Moore also described the value for BART (28, p. 8): • Cost savings • Labor reallocation (one BART full-time equivalent) • Increased ROI from existing web services • Scale, improved market reach/time to market • Empowered customers (choice, competition) • Innovation and “trickle up” • Increased awareness of BART’s service • Positive perception: openness/transparency. BART’s lessons learned regarding open data include the following: • Releasing the data and adopting standards that gain traction are critical. • Make the license readable by non-lawyers, and do not require that the license be signed. • Create multiple paths into using the data: – Provide simple tools to the casual user – Provide RSS feeds to the medium-level user – Provide GTFS-RT and geospatial and the agency’s API to the advanced user. • Open data are to be documented and released using a transmission format that is accessible. • Do not play favorites in the market. Do not interfere in determining the most effective apps—the public should be trusted to do that. • Stay responsive to customer needs and developer needs. • Provide information to developers to ensure that cus- tomers’ needs are being met—synchronizing customer needs and developer skills are critical. • Promoting data and apps by using free advertising and car cards promoting that data are available. • Open data needs to be part of the agency’s culture. It helps customers understand that BART is not respon- sible for every app. • Hackathons can be good for launching an open data pro- gram, but they may not be effective on an ongoing basis. Now BART participates in more organized events, such as TransportationCamp West, and uses Google Groups and an e-mail list to stay engaged with developers. Of the transit agencies in major metropolitan areas, BART has the smallest number of riders per app, as shown in Figure 49. BART will be releasing a new multiplatform, free, smart- phone app to report crimes and take pictures of and report suspicious items or hazards. Riders have been asking for a safe, silent and discreet way to communicate with BART when they are on a train or in a station. BART will be the first transit agency to offer both Spanish and Simplified Chinese options for the app. The app will feature a silent photo and flash-free feature and is GPS enabled. Several visualizations have been developed using BART open data. One example, which was funded by the Knight Foundation, is shown in Figure 50 (http://barthood.news21. com/). The source for this visualization was mainly BART’s station profile study (the raw data can be found at http:// www.bart.gov/about/reports/profile). Several data visualizations related to the BART strike in 2013, including ridership and regional traffic impacts (http:// enjalot.github.io/bart/). Figure 51 shows one of the visualiza- tions related to ridership by station. Figure 52 shows the pas- senger trips between Balboa Park and other stations. Figure 53 shows ridership from a different perspective at BART stations. WORCESTER REGIONAL TRANSIT AUTHORITY— WORCESTER, MASSACHUSETTS The Worcester Regional Transit Authority (WRTA) in Worces- ter, Massachusetts, is a transit authority in central Massachu- setts with 48 fixed-route buses and 50 paratransit vehicles. Beginning in 2009, the WRTA embarked on a program to implement technology on all of the agency’s vehicles, result- ing in, among other things, providing real-time informa- tion to the public. Once the technology implementation was completed, the agency’s information technology consultant, Christopher Hamman, began working on opening the agency’s data. The reason the WRTA decided to open data was to show transparency and encourage developers to create new and bet- ter applications for their riders (Interview with Christopher Hamman on March 20, 2014). In addition, the administrator of the agency is visionary and fully supported opening the data to the public to get applications in the hands of customers. The WRTA pursued developers who had created apps for the Sources: APTA 3O2013 Public Transportation Ridership Report and agency websites, November 2013. Note: iOS and Android apps are counted once (not once per platform). FIGURE 49 Apps per rider (28, p. 5).

66 FIGURE 50 Visualization of ridership by BART station. FIGURE 51 BART ridership visualization (http://enjalot.github.io/bart/#chapter-05).

67 FIGURE 52 BART ridership to/from Balboa Park Station (http://vudlab.com/bart/). FIGURE 53 BART ridership by station (http://enjalot.github.io/bart/ #chapter-05).

68 Chicago Transit Authority (CTA) to build apps for Android and iOS platforms because CTA has the same technology ven- dor. This pursuit consisted of the following steps: • Conducting a survey of what CTA did (the agency has the same real-time system); • Down-selecting and contacting the top five developers for Android and top five for Apple; • Because no funding was available, eliminating from discussion developers who requested funding to move forward were eliminated from discussion; • Finding that several developers were willing to extend their product (developed for the CTA) to the WRTA (in addition to making changes for CTA); and • Continuing development of CTA apps means so that they are rolled out to WRTA afterward. WRTA’s initial research to identify developers started with a spreadsheet developed by the ITS consultant. This spreadsheet contained the following fields: • App name • Transit agency • Platforms (e.g., iPhone, SMS, Android, Website) • App cost • Link Android (e.g., to Google Play) • Link iTunes • Developer name (company or individual) • Company’s contact (e.g., e-mail address, website) Now there are two Android apps [WRTA Bustracker and Just another transit app (JATA) and one for iOS (TransitStop)]. In addition, WRTA learned from the “best practices” in open data employed by BART, MTA, and CTA. WRTA used the following techniques to develop the agency’s programs: • Use a registration process to provide a key. • Vet a developer by trying out the app and testing it in- house before releasing it to the public, and conduct a question-and-answer session with the developer, • Use an official promotion “seal of approval” by the agency once a good relationship develops and there is proof of diligence by the developer. • Rely on user reviews—let the market and comments be open, shared, and promoted by the agency. • Create a web page for developers to formalize the pro- cess (this is under development). The WRTA is using Clever Devices BusTime Developer’s API. WRTA staff think that CTA’s markup of the Developer’s API is an excellent product, so they are using this instead of the vendor’s document (http://www.transitchicago.com/ assets/1/developer_center/Bus Time_Developer_API_Guide. pdf). WRTA staff are waiting for a leader to emerge among these standards: SIRI, TCIP, NextBus, Clever Devices, and GTFS-realtime. Eventually, they would like to create a truly universal vendor-agnostic translator to make it easier for peo- ple to get the data they want. Further, WRTA staff would like to see a service that could translate between vendor APIs to GTFS-realtime. Although the WRTA has not surveyed developers or cus- tomers about their open data, they are hoping to increase developer activity and create a rewards/incentive system for developers that will, in turn, foster increased options for con- sumers. In addition, they would like the riding community to promote, test, use, and comment concerning which apps are most effective. In the future, the WRTA personnel are think- ing about using these techniques: • Regular customer surveys would include a technology piece that might ask about the use of apps. • WiFi connectivity—require that a user provide demo- graphic information to connect for the first time on a WRTA bus. Then the WRTA would monitor this media access control address (no personal information would be collected) to determine usage and travel patterns. • For app development, developers would be required to provide customer survey questions as part of their license. One challenge associated with initiating and maintaining the open data program is that a system with frequent updates requires constant revision and updates to the open data. The updating process has become more stabilized over time—it is now predictable. It is challenging when schedules are vola- tile. The WRTA started a “developer’s center,” but this will be modified because it has not been published or promoted. For smaller agencies, the WRTA suggests reusing work from other developers when possible to minimize the resources required to clean the data. Currently, the labor time needed to maintain the open data is 5 to 15 hours for Mr. Hamman and an occasional intern each time a schedule is changed. In addition to using developers to indicate if there is a problem with the data, the WRTA has Ridecheck to match with Hastus data, to match with GTFS data, to match with data from the agency’s CAD/ AVL vendor, so it is easy to check for issues. In terms of best practices, the WRTA recommends pro- viding as much information as possible in as many ways as possible while balancing the amount of effort required. With most of the agency’s database update processes being auto- mated, agency staff think that their open data practice has high quality with low overhead. Some of the open data pro- vided by the WRTA includes: • Branding—.css, colors, logos, etc. • IVR prompts—every street name, intersection, stop ID, and so forth, which can be reused by developers to make their apps more accessible • GTFS schedule data provided on the MassDOT devel- oper’s website, GTFS exchange, and other sites

69 • Excel timetable format for each route • Microsoft Access table • Images and maps • Schedules in portable document format (pdf). Other techniques used by the WRTA include the following: • Using source control, such as GitHub, to provide qual- ity assurance and control for each release. • Modifying the website to publish to RSS, Twitter, Face- book, and Wordpress automatically. These free broadcast media expand the reach of real-time updates to riders. • Using developer’s API. • Implementing a do-it-yourself (DIY) kiosk program with nine community partners, including schools and social services (e.g., Quinsigamond Community College, Fam- ily Health Center, etc.). The WRTA licenses the asset (e.g., electronic sign showing both WRTA and partner’s infor- mation) to each community partner. This allows partners to show their internal stakeholder information and WRTA bus times and transit-related information. Further, it is a less expensive way of getting WRTA information dis- seminated. So far, 15 kiosks have been deployed. • WRTA’s Open Checkbook initiative (http://www.therta. com/about/open-checkbook/). The Worcester Regional Transit Authority is committed to providing citizens with open and transparent government. As part of this proactive approach to civic engagement, the WRTA has developed this Open Checkbook webpage. Open Checkbook is meant to be a window into the authority and to provide the public with access to the authority’s spending information. Open Checkbook will detail vendor payments, identifying who was paid and when, how much was paid, and what was the purpose of the payment.