National Academies Press: OpenBook
« Previous: CHAPTER FIVE Contribution of Mobile Messaging to Agency Communications Strategy
Page 40
Suggested Citation:"CHAPTER SIX Case Studies." National Academies of Sciences, Engineering, and Medicine. 2011. Use and Deployment of Mobile Device Technology for Real-Time Transit Information. Washington, DC: The National Academies Press. doi: 10.17226/13323.
×
Page 40
Page 41
Suggested Citation:"CHAPTER SIX Case Studies." National Academies of Sciences, Engineering, and Medicine. 2011. Use and Deployment of Mobile Device Technology for Real-Time Transit Information. Washington, DC: The National Academies Press. doi: 10.17226/13323.
×
Page 41
Page 42
Suggested Citation:"CHAPTER SIX Case Studies." National Academies of Sciences, Engineering, and Medicine. 2011. Use and Deployment of Mobile Device Technology for Real-Time Transit Information. Washington, DC: The National Academies Press. doi: 10.17226/13323.
×
Page 42
Page 43
Suggested Citation:"CHAPTER SIX Case Studies." National Academies of Sciences, Engineering, and Medicine. 2011. Use and Deployment of Mobile Device Technology for Real-Time Transit Information. Washington, DC: The National Academies Press. doi: 10.17226/13323.
×
Page 43
Page 44
Suggested Citation:"CHAPTER SIX Case Studies." National Academies of Sciences, Engineering, and Medicine. 2011. Use and Deployment of Mobile Device Technology for Real-Time Transit Information. Washington, DC: The National Academies Press. doi: 10.17226/13323.
×
Page 44
Page 45
Suggested Citation:"CHAPTER SIX Case Studies." National Academies of Sciences, Engineering, and Medicine. 2011. Use and Deployment of Mobile Device Technology for Real-Time Transit Information. Washington, DC: The National Academies Press. doi: 10.17226/13323.
×
Page 45
Page 46
Suggested Citation:"CHAPTER SIX Case Studies." National Academies of Sciences, Engineering, and Medicine. 2011. Use and Deployment of Mobile Device Technology for Real-Time Transit Information. Washington, DC: The National Academies Press. doi: 10.17226/13323.
×
Page 46
Page 47
Suggested Citation:"CHAPTER SIX Case Studies." National Academies of Sciences, Engineering, and Medicine. 2011. Use and Deployment of Mobile Device Technology for Real-Time Transit Information. Washington, DC: The National Academies Press. doi: 10.17226/13323.
×
Page 47
Page 48
Suggested Citation:"CHAPTER SIX Case Studies." National Academies of Sciences, Engineering, and Medicine. 2011. Use and Deployment of Mobile Device Technology for Real-Time Transit Information. Washington, DC: The National Academies Press. doi: 10.17226/13323.
×
Page 48
Page 49
Suggested Citation:"CHAPTER SIX Case Studies." National Academies of Sciences, Engineering, and Medicine. 2011. Use and Deployment of Mobile Device Technology for Real-Time Transit Information. Washington, DC: The National Academies Press. doi: 10.17226/13323.
×
Page 49

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.

38 CHAPTER SIX CASE STUDIES Several of the transit agencies that responded to the synthe- sis survey were interviewed by telephone to obtain more detailed information on their provision of real-time transit information on mobile devices. The results of the interviews are presented in this section as case studies. TRI-COUNTY METROPOLITAN TRANSPORTATION DISTRICT OF OREGON (PORTLAND, OR) TriMet’s operations department began to consider provid- ing real-time information using DMSs at nearly 100 bus and rail stops throughout the service area several years ago. The cost associated with operating the DMSs was signifi- cant (e.g., it cost $50 per month for a telephone connection to each sign not on the agency’s wide area network). DMSs display real-time information generated by TriMet’s CAD/ AVL system. Although customers who were surveyed liked the new DMSs, TriMet realized that deploying more DMSs at bus stops throughout the service area might not be sustain- able. Further, in 2005, TriMet conducted an on-street sur- vey of riders and determined that 70% of riders had mobile phones. In 2009 and 2010, 73 digital flat-screen displays with real-time arrival information were installed. DMSs will be programmed and designed into all future light-rail stations. The focus of providing real-time information to custom- ers shifted to the IT department to support placing real-time information on TriMet’s website and on an IVR system. The IT department developed and tested the necessary applica- tions, and then put the new real-time applications in place. TriMet did not advertise these new customer information services, but in the first month, the IVR application received 40,000 calls. Its usage has steadily increased since then, with 1.7 million calls received in May 2010 (compared with 8.4 million boardings). Part of the evolution of providing real-time information at TriMet was the result of a creative developer and IT man- ager, who recognized that there were only a few software companies that could provide appropriate software. If one of these companies supplied the software, TriMet would have to pay an ongoing maintenance fee. TriMet estimated that these kinds of maintenance fees would have been half of the IT budget; therefore, TriMet took a lead role in the U.S. tran- sit industry to explore open data and open source. “Open data” is considered to be “a philosophy and practice requir- ing that certain data are freely available to everyone, without restrictions from copyright, patents or other mechanisms of control” (66). According to the City-Go-Round website (67), currently, TriMet is one of the 107 transit agencies that pro- vide open data. “Open source” refers to “an approach to the design, development, and distribution of software, offering practical accessibility to a software’s source code” (68). At the same time TriMet embraced an open-data approach and open-source philosophy, it was focusing on ensuring that its data (including real-time information) were in good shape to be used by others. Its work on using a centralized data approach, which TriMet calls a centralized enterprise data system, led to the ability to easily extract data for almost any purpose. Not only did it help in providing customer information, but it also was being used to make decisions about where to place shelters, what services to provide, and so forth. When TriMet shared its ideas regarding open data with other U.S. transit agencies at an APTA TransITech con- ference, it discovered that many U.S. transit agencies had data that were not in good shape. The open-source and open-data philosophy at TriMet allowed the creation of an application that populates sched- ules on the Internet. This application is available to anyone for no charge. Currently, several transit properties are using it. This application provided the opportunity for other develop- ers to add to it. “Since TriMet made its schedule and arrival data available to the public several years ago, independent programmers have created a number of useful transit tools for riders” (69). TriMet’s website lists “some of the free and com- mercial applications that are available from third-party devel- opers using TriMet’s open data” (69). Further, TriMet was the first transit agency in the United States to be on Google Transit (Google Transit was launched in December 2005). Just prior to making its data open, TriMet recognized that there were developers who could create innovative mobile applications at no cost to TriMet. For example, before the release of the first iPhone, a local Portland resident had an interest in knowing the next two arrivals of the bus and streetcar that he rode on a regular basis. He was able to do a “screen scrape,” which meant he took data from TriMet’s website and created a website for himself that displayed the arrival times for the next two buses and streetcars.

39 At this time these resources include a schedule published in the General Transit Feed Specification (GTFS) format as well as web services from TriMet’s TransitTracker and trip plan- ner systems” (70). Developers of TriMet mobile applications must register for an “AppID,” meaning that they “acknowledge the web services Terms of Use, will be notified of upcoming changes to the API [application programming interface] and must limit the usage of the web services to 100,000 requests a day.” The terms of use are shown in Figure 38. Thus, in recognizing the value of both “good” data and these developers of mobile applications, TriMet created a developer’s website. Therefore, rather than requiring a large IT staff to develop such applications (and stay current with all the new mobile devices and operating systems), TriMet created an environment in which developers could use TriMet’s data. TriMet’s developer resources, shown in Figure 37, state that “TriMet has made resources available to software developers, to promote the use of transit and information related to transit. FIGURE 37 TriMet developer resources. [Source: (70, p. 14).] FIGURE 38 TriMet’s Developer Terms of Use. [Source: (71).]

40 As of May 2010, there were 32 third-party applications developed for TriMet, 26 of which were for mobile devices. TriMet provides route-based service alerts, but it is examining the possibility of providing stop-based alerts, which it believes will be more useful to customers. Further, it is looking at formatting and writing the service alerts so that they will comply with SMS restrictions (e.g., number of characters allowed). In terms of information equity, TriMet recognizes that it has more choice riders than any other major city in the United States and that these riders have certain expectations for access to information. The choice riders examine a variety of factors when making the choice to ride transit, including whether the service goes where they need to go, whether or not they have to pay for parking, the frequency of service, the reliability of the service, the amenities available at the stop or station, and the customer information available. In addition, younger riders want to use text messaging to obtain information about transit, but text mes- saging has a cost to both TriMet and the customer. However, on August 16, 2010, TriMet (working with a contractor) introduced a text message service (called TransitTracker by Text) that pro- vides real-time information by means of SMS. As of September 17, 2010, TriMet had received 35,000 texts. This service is sup- ported by advertising, keeping it free to the customer (except for the carrier’s standard text messaging/data rates, if applicable). TriMet provides real-time information and trip planning on mobile phones through http://m.trimet.org (see Figure 39). However, TriMet recognizes that its core, frequent riders are low income and often do not have mobile devices. TriMet assesses the information that the core riders need along with the point at which they need the information. In terms of pre-trip planning, TriMet still provides a call center that has 20,000 calls per month. The call center allows TriMet to pro- duce fewer print materials and better serve low-income and older riders. In terms of information at the stop, riders are informed about the span of service rather than the schedule. The span of service rarely changes, so TriMet does not have to replace the print information at the stop as often as if the schedule were posted. Schedules are posted at high-volume boarding areas. TriMet covers all riders by providing the call center and information on the Internet (TriMet determined that many low-income riders do have access to a computer). Overall, TriMet’s philosophy is that customer informa- tion is part of its core business, not just a nice thing to do. Further, it sees providing real-time information on mobile devices as a way to maintain or increase ridership. BAY AREA RAPID TRANSIT DISTRICT (OAKLAND, CA) In the late 1990s and early 2000s, BART developed its own applications for the Palm operating system. At this time, BART was providing transit information to MTC in a comma- separated format—there were no open data. Also, there was no support within the agency to develop and sustain additional mobile applications. There was an e-mail list of 95,000 people who wanted to be notified of transit advisories. Shortly after this time, the Palm was no longer the mobile device of choice. Since then, BART has determined that it is much more cost-effective to focus its efforts on the data, not develop- ing mobile applications. Currently, its website is managed by two staff; it would be challenging for such a small staff to develop applications for the myriad mobile devices on the market. Further, the IT department is focused on operating and maintaining internal business systems, not the website or mobile applications. Thus, third-party application devel- opers have access to BART’s data as they are now open, and unlike TriMet, developers do not have to register. However, each developer is subject to a developer’s license agreement. And if a developer wants an API validation key, it must apply for one. Figure 40 shows BART’s developer website and Fig- ure 41 shows BART’s developer license agreement. BART has provided open data services to third party developers since 2007, which power 26 separate FIGURE 39 TriMet TransitTracker for wireless devices. [Source: (72).]

41 BART provides a menu of mobile options (see Figure 42) in addition to the 31 third-party applications (as of May 2010) available either free or for a small fee. The BART mobile website (see Figure 43) provides access to real-time information, as does the SMS application (see Figure 44). applications on more than 20 platforms including Google and Google Maps, iPhone, BlackBerry, Android, Palm Pre, Mac OSX, Twitter, Facebook and more. There are more than 1,200 BART developers subscribed to [BART’s] opt-in list, and some BART apps, such as iBART for iPhone, have nearly 150,000 users (73). FIGURE 40 BART’s developer’s website. FIGURE 41 BART’s developer license agreement.

42 FIGURE 42 BART’s mobile options. FIGURE 43 BART mobile website. FIGURE 44 BART real-time information by means of SMS.

43 BART continued its foray into open data and providing real-time information on mobile devices by surveying cus- tomers in 2009 regarding the mobile “space.” This survey “of BART riders who use mobile devices has found strong demand for new and existing applications. The survey was initiated by BART’s website team to evaluate the market for new mobile services.” BART shared the survey findings with the developer community. “Without in-house developers to create new applications, and in a time of extremely limited budget resources, it’s a way for BART to foster the kind of innovation that ultimately will benefit customers. ‘We’re try- ing to give our developer network the information it needs to build the kind of applications that our customers want,’ said Timothy Moore, BART website manager.” BART’s moving from being the primary application provider to data provider has facilitated this shift in focus. The results of this survey, to which more than 6,500 cus- tomers responded, included the following: • “Smartphones such as the iPhone and BlackBerry were the mobile devices most frequently used by those sur- veyed, followed by iPods, other media players, regular cellphones and PDAs such as Palm OS. Other devices noted by survey respondents included portable video game players such as the Sony PSP and ebook readers such as the Amazon Kindle.” • “Existing mobile applications—both those created by BART and those from third-party developers—are not widely known and have much potential for greater use.” • “Most survey respondents would prefer not to pay for trip planning or other transit applications but are will- ing to use ad-supported free programs.” • “More than a third of respondents plan to purchase a new mobile device within one year.” BART examined how customers using mobile devices obtain their information: • “Printed schedules on brochures and wall signs in stations.” • “Electronic messages on overhead platform signs and station announcements, both of which contain real- time information.” • “The BART mobile website, which has real-time information.” • “Native applications that passengers download in advance to their devices, and which do not require an Internet connection.” There have been some notable successes, such as the free iBART application for iPhone developed by two college stu- dents, which has received positive customer reviews. The day the iPhone application store opened, there was a BART application. Real-time applications came just a few months after that. In addition, BART has partnered with Google to make its data available for applications developed around Google Maps, including Google Maps for Mobile (74). Also, BART recognizes that there is a gap between cus- tomer needs and developer skills. BART’s frame of reference is how customers look at BART versus BART’s competitors. The expectation within that frame of reference is that, for example, a customer can find out when there is congestion on the road—this will influence the decision to ride BART. Fur- ther, although the developers are striving for a successful ven- ture to support customers, the developers may not be meeting customers’ needs. BART continues to be aware of all custom- ers, recognizing that there are many different kinds of riders of (e.g., different cultures and those with cognitive and literacy issues). This awareness of customers is BART’s philosophy. BART has used social networking, primarily in response to the market in San Francisco. During regular business hours, BART supplies a Twitter feed with real-time delay advisories. As mentioned earlier in the report, BART is the first U.S. transit agency to partner with Foursquare (75). This partnership creates a way to push real-time informa- tion in a unique way. Foursquare users “check in” in real time to a particular BART station, affording them the oppor- tunity to become a “mayor” of that station. Checking into specific venues allows users to earn “badges.” As part of the partnership, Foursquare is offering a BART-themed badge. This type of LBS may legitimize the BART experience for a certain set of riders. In an April 2010 survey to determine the value of the Foursquare application (76), almost 70% of the respondents indicated they ‘check in’ when using BART and just over 40% recall recommending places near BART to Foursquare friends. Almost 20% of respondents recall making a BART trip because of a Foursquare recommendation and 14% indicated they ride BART more often because of Foursquare. Over half of respondents indicated that Foursquare has a positive impact on their BART riding experience (76, p. 2). Another unique application based on BART’s API is a partnership with junaio, which is an augmented reality appli- cation (77): BART and junaio have partnered to integrate transit data, such as station locations and estimated arrival times, into a BART channel on the junaio 2.0 augmented reality platform. With mobile augmented reality technology, users can see digital content such as text or graphics overlaid on real objects on their mobile phones. Junaio lets users tag photos, audio and text in the real world and leave digital “crumbs” behind at particular locations for others to explore. For example, a rider coming out of the Montgomery BART Station in San Francisco could see recommendations left by friends for restaurants or shops to try that are nearby that station. Or, simply by pointing the camera on her phone, a user could find the direction of the nearest BART station and get a list of estimated arrivals for the next several trains to her destination (77).

44 LEETRAN (LEE COUNTY/FORT MYERS, FL) LeeTran operates service in Lee County, Florida, with 61 fixed-route vehicles, 44 demand-response vehicles, and seven vanpool vehicles. Its 18 fixed routes provide over 3 million trips per year. LeeTran’s fixed-route services are divided into two categories: traditional fixed-route ser- vice and trolley resort services provided during winter and spring. LeeTran provides real-time information on mobile devices using an ASP only for its trolley resort services. It is considering expanding the current mobile information to its regular fixed-route service. The system that provides real-time information on mobile devices consists of a GPS receiver, a GPS antenna, and a mobile data terminal (through which vehicle operators log into the system) on each of the 11 vehicles that operate the beach trolley service. The ASP’s software uses data col- lected as the vehicles operate to estimate when each vehicle will arrive at each stop on the trolley routes. These real-time arrival time estimates are disseminated by means of SMS or the ASP’s mobile website. In addition, DMSs displaying the same real-time information are located at four key stops along the trolley routes: Summerlin Square, Bowditch Park, Lynn Hall Park, and the Main Street parking lot. There is interest in expanding the number of signs to other locations within the beach zones where the trolley service operates. Although this system is primarily for providing real- time information to customers, dispatchers use it to monitor service. Dispatchers can see where there is congestion and mitigate potential service issues by using the information generated by the system. LeeTran pays the ASP an annual fee of $18,150 for the service. This price is based on the number of equipped vehicles and the number of DMSs in the field. In the initial deployment of the system, LeeTran considered the portion of the annual fee that went toward cellular communications (which the ASP uses to communicate vehicle location and other operational data to a central system and communicate real-time information to the DMSs) too high. Two years after the initial deployment of the system, LeeTran deployed an AVL system for its demand-response fleet and found a cel- lular carrier with lower prices. LeeTran negotiated with the ASP to obtain a lower cost cellular carrier, thus reducing the annual fee that LeeTran paid the ASP. The initial deployment of this system was accomplished in 2004–2005 in partnership with the town of Fort Myers Beach, which is an island community and one of the larg- est destinations in Lee County. The town was interested in using public transportation as a solution to the congestion problems on the island. The town and LeeTran developed a menu of strategies to try to mitigate the beach and on-island congestion. At the same time the strategies were being devel- oped, there was a desire to improve service headways and implement a marketing campaign to get beach and island travelers out of their cars. The town then procured the ASP’s real-time information system with the intent to pay for the capital expense, but then turned the system over to LeeTran to operate and maintain. The town of Fort Myers Beach provided the capital needed to purchase the system, and now Lee Tran is responsible for the system’s operation (and pays annually for the system’s operation using 100% county funds). In the second year of operation, the real-time informa- tion system was expanded because, initially, not all the beach trolley vehicles had been equipped. Although LeeT- ran already had “choice” riders in the area where the beach trolley service was provided, the implementation of the real-time information system definitely attracted even more choice riders. Further, ridership on the trolley service dou- bled after the implementation of the system, but it is hard to isolate the real-time information as directly contributing to that increase in ridership. There were two primary challenges in implementing this system. First, once everything in the system was installed, initial tests yielded inaccurate real-time information. Obser- vations were made in the field of actual times and compared with the arrival times being calculated by the system. The initial deployment coincided with the winter high tourist season, which was when there were high levels of traffic congestion on the island. LeeTran worked with the ASP to solve the problem, which was done by eliminating the system’s use of timetables. During the height of the tour- ist season (winter and early spring), the system uses vehicle location and speed to compute the arrival times at each stop, rather than using the schedule to calculate “schedule adher- ence” and subsequently calculate arrival times. This solution has been employed ever since it was developed—at nonpeak times of the year, the system goes back to calculating sched- ule adherence to estimate arrival times. Second, initially, it was challenging for customers to use mobile devices to obtain the real-time information. This was because tourists were often not familiar with the actual stop from which they wanted to use the trolley service. LeeTran eliminated that problem by adding a four-digit number to each bus stop sign so that customers could identify by num- ber the stop for which they were obtaining real-time infor- mation. Further, several of the resorts began publishing the stop number on their check-in literature; as soon as travelers checked into the hotel, they would know immediately which stop was closest to the hotel and the number of that stop. Ongoing operations and maintenance of the system are the responsibility of the principal planner for LeeTran, with the marketing division, service planners, and maintenance staff

45 responsible for specific aspects of the system, such as sched- ule changes (which then have to be input into the system). LeeTran staff observe the system in the field on a spot-check basis to determine the system’s accuracy and reliability, and input is provided also by customers who use the system. No one is regularly assigned to perform the system spot checks. TRANSPORT FOR LONDON (LONDON, UNITED KINGDOM) TfL’s approach to providing real-time information on mobile devices was different from those described in the TriMet and BART case studies up until June 2010. Although TriMet and BART embrace open data and open source, TfL did not offi- cially release its data to the public. (Some data were made available to the public but required that developers obtain permission to use the data.) Prior to June 2010, real-time information on mobile devices was limited to travel alerts, which could be received through e-mail or SMS. Alerts are based on incident information that is entered into the system in the respective control room where the incident is being managed. The same information is available on the TfL and London Underground websites (http://www.tfl.gov.uk/ and http://www.tfl.gov.uk/modalpages/2625.aspx). “Once an incident is listed, it’s available to the public over the web and mobile internet (WAP) in a few seconds” (78). SMS alerts are limited to two per day because “Mobile operators charge us [TfL] for every message that we send, and this limit is imposed to keep everyone’s costs down” (79). TfL provides other mobile services, such as trip planning (through SMS or mobile web), live travel news by means of mobile web, time- tables, and other information such as congestion charging. In June 2010, TfL opened much of its data to the public. Initially, “information on planned weekend Tube works, the location of stations, licensed taxi operators, Oyster card top- up points and piers on the River Thames” (80) was provided to developers. As of September 2010, the following types of public transport data were available on London’s DataStore (http://data.london.gov.uk/), which was established by the Greater London Authority (GLA) to provide access to data held and generated by the GLA and other public sector orga- nizations in London: • TfL station locations, • TfL timetable listings, • 2008 public transport accessibility levels, • TfL cycle hire locations, • 2009 TfL origin and destination survey, • TfL bus stop locations and routes, • Oyster ticket stop locations, • London Underground signals passed at danger, • TfL pier locations, • River boat timetables, and • Accessibility of London Underground stations. TfL has stated that it “hope[s] that our announcement [of opening data in June 2010] will result in new relation- ships between the open data community and TfL/London’s DataStore. We know from international experience that the majority of smartphone apps built on public data are focused around the reuse of public transport data” (80). TfL conducted demonstrations several years ago to test the potential for introducing mobile applications using real-time information. First, from December 2006 through November 2007, TfL conducted a demonstration called Visualisation of Real-Time Transport Interchange (VORTIX). VORTIX used NFC technology embedded in 19 “touchpoint” posters in the Blackfriars London Underground station: When a NFC-enabled mobile phoned is placed against the smart poster, even if deep underground, it will pinpoint the exact location of the passenger and then transmit detailed information including where to go to make the next stage of the journey, how to get there, how long the transfer will take and when the next service will arrive. This information includes all modes of transport in the vicinity of Blackfriars: Tube; National Rail; buses and river services (81). VORTIX, funded by the Department for Trade and Industry, was a collaboration among TfL, Imperial College of London, and Kizoom. This was the first demonstration of providing en-route customer information using NFC tech- nology (see Figure 45). Second, there were seven real-time mobile demonstration projects: The projects [were] demonstrations of potential mobile usage of a future real-time integration programme (RTIP) system that will set the vision of the programme and attempt to innovate regarding end-customer information solutions (staff and passengers). The demonstrators [were] installed to work in the RTIP data lab and scale[d] to up to 100 users (82). The demonstrations were not pilot projects—they were just meant to demonstrate innovative real-time services that could be delivered by means of mobile devices. The demon- strations had four primary objectives: • Examine the content that TfL already had and how it could be disseminated, • Examine the form or format in which the content would be presented, • Assess the usefulness of providing the content, and • Determine the feasibility of developing such applications. Several of the demonstration projects of note were • Visual scene analysis—Underground platform con- gestion: The demonstration used visual scene analysis

46 techniques to gauge the level of congestion on the St. James’ Park Underground station. Important features include the following: – Reduction in data from visual image to a low-band- width data item such as a count of the number of people on the platform; and – Employment of image recognition systems to moni- tor crowding. • Converged personalized “countdown” service for mobiles: The converged personalized “countdown” service enabled passengers to view the countdown information for both buses and tubes on their mobiles/ PDAs for a limited number of selected stops. For both buses and tube lines, passengers could select desired stops/stations into a personalized monitor in which they could see the real time for the selected platforms/ stops. There was a limit to the number for stops/sta- tions that each user could monitor. • Mobile avatar solution—“Journey Angel”: This proj- ect demonstrated a mobile avatar system prototype to assist the passenger throughout the trip chain: pre-trip, en route, and post-trip. The avatar can be expanded to perform all advisory/decision support actions for TfL on the mobile client including actions such as incident alerting, zone entry/exit, agreements to pay, delay alerting, and planning support. It included the dynamic monitoring of the user’s location, voice rendering of text, and if there are service disruptions, the system will dynamically replan the trip. • London mapping demonstration: Showcase of London mapping for the following purposes: – Superimposing TfL real-time data on a map, – Superimposing planned routes/route suggestions on a map, – Placing points of interest on a map, – Placing stops/stations on a map, – Placing user objects on a map, and – Placing events on a map (location/time duration). • Converged personalized service delivery: A framework for TfL services that operates in delivering novel ser- vices to mobile, PC, and set-top box environments. The framework assisted in the seamless communication of informational, application, and presence information across users’ personal wide area network, enabling all of users’ devices to participate in TfL applications. Unfortunately, owing to funding issues, none of these demonstrations was considered for full-scale deployment. TfL’s philosophy regarding providing real-time informa- tion on mobile devices can be described as follows: • TfL has a desire to shape the data that would be used to provide information to customers using certain rules, thus influencing the behavior of the customers using the information. • TfL considers customer relationship management as one of the most important factors in building trust among customers as well as in determining the nature of real-time information that could be provided on mobile devices. • Information dissemination should focus on the logical design, not the technical design (suppliers/vendors are capable of providing the technical design). • A toolkit that provides information governance to ensure that information is properly categorized, pro- tected, managed, and disseminated is a catalyst for making it easier to provide the most timely and perti- nent information to each customer. In terms of shaping the data and customer behavior, TfL provided the following example: If there were severe con- gestion at Victoria Station, one of the busiest stations in London (containing National Rail, London buses and Lon- don Underground, and taxi service), it would be ideal for customers to react in a variety of different ways so that the congestion does not become more severe. To control 30% to 40% of the customers using Victoria Station, real-time information could be tailored using certain rules and person- alization so that 10% of the customers would decide to con- tinue their journey with no interruption, 10% would decide to interrupt their journey by getting off the train they are FIGURE 45 VORTIX handset display. [Source: (83).]

47 on, and 10% would decide to get coffee. This “control” of the mitigation strategies to relieve congestion requires a high degree of personalization and integration of real-time infor- mation, intimate knowledge of customers’ behaviors when provided with specific information, and knowledge of how the overall system will react when real-time information is disseminated. Currently, TfL is subject to local legislation and the origi- nal U.K. Citizen’s Charter (which defines a quality of ser- vice), which promotes the release of public information and making public content available. The Citizen’s Charter has been replaced with the Customer Service Excellence stan- dard, which— is to encourage, enable and reward organisations that are delivering services based on a genuine understanding of the needs and preferences of their customers and communities. The foundation of this tool is the [U.K.’s] Government’s Customer Service Excellence standard which tests in great depth those areas that research has indicated are a priority for customers, with particular focus on delivery, timeliness, information, professionalism and staff attitude. There is also emphasis placed on developing customer insight, understanding the user’s experience and robust measurement of service satisfaction (84). Indeed, the U.K. Customer Service Excellence standard and TfL’s philosophy regarding information governance and customer relationship management are closely aligned. But until an information governance toolkit and funding are available to make the business case, providing real-time information by means of mobile devices will continue to be somewhat limited. In the meantime, TfL is focusing on continually strengthening its relationships with customers to ensure an appropriate level of interaction (a well-informed customer requires less manual customer service) and trust. In terms of information equity, TfL provides elevator and escalator status updates, as well as quality of service informa- tion. There are either manual or electronic boards in each sta- tion that show the status of the whole system. Further, system status is provided on TfL’s website (see Figure 46). There are onboard voice announcements as a result of the iBus proj- ect. The majority of service information is provided through nonmobile channels. The majority of information access is the use of TfL’s journey planner—100 million journey plans are created every month. The journey planner is available for mobile devices, but it has somewhat limited capability. Lim- ited service bulletins are available by means of SMS. FIGURE 46 TfL service status.

Next: CHAPTER SEVEN Findings, Lessons Learned, and Conclusions »
Use and Deployment of Mobile Device Technology for Real-Time Transit Information Get This Book
×
MyNAP members save 10% online.
Login or Register to save!
Download Free PDF

TRB's Transit Cooperative Research Program (TCRP) Synthesis 91: Use and Deployment of Mobile Device Technology for Real-Time Transit Information examines the use and deployment of real-time transit information on mobile devices.

The report explores the underlying technology required to generate the information to be disseminated, the mobile technology used for dissemination, the characteristics of the information, the resources required to successfully deploy information on mobile devices, and the contribution of mobile messaging to an overall agency communications strategy, including "information equity."

  1. ×

    Welcome to OpenBook!

    You're looking at OpenBook, NAP.edu's online reading room since 1999. Based on feedback from you, our users, we've made some improvements that make it easier than ever to read thousands of publications on our website.

    Do you want to take a quick tour of the OpenBook's features?

    No Thanks Take a Tour »
  2. ×

    Show this book's table of contents, where you can jump to any chapter by name.

    « Back Next »
  3. ×

    ...or use these buttons to go back to the previous chapter or skip to the next one.

    « Back Next »
  4. ×

    Jump up to the previous page or down to the next one. Also, you can type in a page number and press Enter to go directly to that page in the book.

    « Back Next »
  5. ×

    To search the entire text of this book, type in your search term here and press Enter.

    « Back Next »
  6. ×

    Share a link to this book page on your preferred social network or via email.

    « Back Next »
  7. ×

    View our suggested citation for this chapter.

    « Back Next »
  8. ×

    Ready to take your reading offline? Click here to buy this book in print or download it as a free PDF, if available.

    « Back Next »
Stay Connected!