The National Academies Press

Currently Skimming:

Pages 33-93

The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.

From page 33... ... 5-1 5. Itinerary Planning Systems Eight case studies were developed from detailed Web site reviews and extensive telephone interviews with transit agencies that have automated itinerary planning systems (AIP) Read the entire page →
From page 34... ... 5-2 transit, highway, airport, seaport, railroad, bicycle, and pedestrian services. The telephone interview was conducted primarily to obtain information about MTC's Webbased TakeTransit itinerary planner. Read the entire page →
From page 35... ... 5-3 Figure 5.1: MTC TakeTransit Input Page Figure 5.2: TakeTransit Coverage Area Link As discussed later in the report, an important part of AIP systems is how they handle landmarks. The MTC's landmark error trapping feature, shown in Figure 5.3, allows a customer to re-specify a landmark location if the AIP system does not recognize the Read the entire page →
From page 36... ... 5-4 Figure 5.3: TakeTransit Landmark Correction Page initial input. MTC staff indicated during the telephone interview that the landmark interface is very important. Read the entire page →
From page 37... ... 5-5 Figure 5.4: TakeTransit Itinerary Output Figure 5.5: MTC Walking Map Read the entire page →
From page 38... ... 5-6 Figure 5.6: Detail of the Relevant Bay Area System Map (MUNI) 5.1.2 Project Objectives The MTC's itinerary planner was designed to provide transit customers with consistent trip itinerary information across modes and transit service providers. Read the entire page →
From page 39... ... 5-7 The other "market" MTC considers constantly is its member transit agencies. MTC works closely with these agencies and considers their needs when planning changes to the AIP system. Read the entire page →
From page 40... ... 5-8 MTC must justify its utility to partnership agencies by analyzing the costs and benefits of the system. Start-up and Growth While planning the first phase of the AIP system, four agencies – BART, MUNI, AC Transit, and the County Connection – pushed to add the itinerary planner and were first to be included in the AIP system. Read the entire page →
From page 41... ... 5-9 When new data is entered into the system, MTC requires agencies to plan and validate a series of itineraries to ensure that they are consistent with the new schedules. The MTC also checks some itineraries itself, particularly for inter-agency trips, and receives assistance from individual agencies, particularly in checking that critical transfers are working correctly. Read the entire page →
From page 42... ... 5-10 (Visual Basic and C++) Read the entire page →
From page 43... ... 5-11 CRM The MTC is currently developing a program to implement aspects of CRM (previously defined in Section 4.1) that will be called My Take Transit. Read the entire page →
From page 44... ... 5-12 Figure 5.7: VCTC Itinerary Planning Input Page Figure 5.8: VCTC Spanish Language Itinerary Planning Input Page Read the entire page →
From page 45... ... 5-13 On the trip criteria input form, customers can also define the day of their trip (today, tomorrow, two days from now, etc.) , departure time, and other options, including: • Itinerary preference (fastest itinerary, fewest transfers, or minimal walking distance) Read the entire page →
From page 46... ... 5-14 Figure 5.9: VCTC Itinerary Planning Output Page, Part 1, Directions (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) 25 Figure 5.10 VCTC Itinerary Planning Output Page, Part 2, Options (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Read the entire page →
From page 47... ... 5-15 Therefore, if the customer misses a particular bus, the expanded schedule allows him/her to see when the next bus will be arriving at the particular stop of interest. However, the schedule page is static and the customer cannot choose a different departure time to have the system automatically recalculate the itinerary. Read the entire page →
From page 48... ... 5-16 5.2.2 Project Objectives The primary objective of VCTC implementing its AIP on the Web was to attract new customers to the transit system by making it more accessible and easy to use. While the agency realized that it might reduce telephone inquiries as well, its main motivation was to provide a greater public service. Read the entire page →
From page 49... ... 5-17 schedules up-to-date and maintains data required to compute itineraries, such as landmarks. VCTC paid $20,000 to a Web services vendor to convert the TranStar system into a Web application. Read the entire page →
From page 50... ... 5-18 Impact on Call Centers VCTC's AIP also reduced telephone inquiries. As mentioned earlier, the call centers also use the TranStar system, although their interface is slightly different. Read the entire page →
From page 51... ... 5-19 5.3 Washington Area Metropolitan Transit Authority WMATA reported during the project telephone interviews that it was one of the early pioneers of itinerary planning via customer service agents. It now provides AIP service on the Web via its RideGuide system. Read the entire page →
From page 52... ... 5-20 Figure 5.12: WMATA RideGuide 1-2-3 Start Page Figure 5.13: RideGuide Input Screen 1 – Origin/Destination Read the entire page →
From page 53... ... 5-21 Figure 5.14: RideGuide Origins/Destinations Examples Pop-up Screen Figure 5.15: RideGuide Input Screen 2 – Trip Criteria (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Read the entire page →
From page 54... ... 5-22 Figure 5.16: RideGuide Output Screen (3) (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Read the entire page →
From page 55... ... 5-23 Figure 5.17: New WMATA Home Page with Itinerary Planning Frame While the original itineraries produced provide only brief walking directions, the customer has the option to obtain more detailed walking directions if desired WMATA's AIP system does not provide maps because the agency believes this feature would considerably slow down the performance of RideGuide (see Section 7 for a discussion of performance and mapping.) The agency considered offering mapping by processing maps on a dedicated server, but since customers have not asked for maps, the agency has little motivation to add them. Read the entire page →
From page 56... ... 5-24 • Provide customers with an automated alternative that would give them access to information 24 hours per day, seven days per week; • Provide customers with the ability to do seamless trip planning; • Introduce technology blending (i.e. so they would not have stand-alone systems. Read the entire page →
From page 57... ... 5-25 correct. WMATA also check complaints from customers concerning incorrectly generated itineraries. Read the entire page →
From page 58... ... 5-26 CRM WMATA has considered developing a personalized customer interaction feature for RideGuide (i.e., what the project team would call CRM) , but is not planning to pursue the project in the near future. Read the entire page →
From page 59... ... 5-27 Figure 5.18: San Diego Transit's Itinerary Planning Input Page • Itinerary preference - Itineraries can be formulated based on fastest way, fewest transfers, or minimal walking distance. In the telephone interview, the project team learned that the "fastest way" itinerary preference is set as the default because MTS believes it is the most frequently used preference. Read the entire page →
From page 60... ... 5-28 Figure 5.19: SDMTS Origin or Destination Error-Trapping Screen (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Figure 5.20: Maximum Walking Distance Error-Trapping Screen (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Read the entire page →
From page 61... ... 5-29 Figure 5.21 shows the itinerary output information customers are given. Like some of the other itinerary planners included in this study, San Diego's AIP provides multiple itinerary options for the customer. Read the entire page →
From page 62... ... 5-30 Figure 5.22: Detours Page on the SDMTS Web Site the telephone interview, it appears that the trip planner does not consider route detours when calculating optimal itineraries. Therefore, customers would have to check if a route on their itinerary might be affected by a detour and, if so, choose an alternate itinerary. Read the entire page →
From page 63... ... 5-31 5.4.3 Implementation Issues Designing the System Development of the Web-based Itinerary planner was a joint venture between the transit agency and their parent agency, the Metropolitan Transit Development Board (MTDB) Read the entire page →
From page 64... ... 5-32 agency offers some very nice maps on their Web site, as shown in Figures 5.23 and 5.24, but these maps are not linked to the AIP. The regional transit map shown in Figure 5.23 is interactive, allowing the customer to move to different geographic areas, return to the larger regional map (by clicking on the "M") Read the entire page →
From page 65... ... 5-33 Figure 5.23: San Diego Regional Transit Map Figure 5.24: San Diego Route Map Read the entire page →
From page 66... ... 5-34 transit Web sites in order to better shape their idea of what Metro's itinerary planner should look like. The result is a tool that is user-friendly and provides a high level of functionality and responsiveness for the customer. Read the entire page →
From page 67... ... 5-35 Figure 5.25: Twin Cities Metro Transit's Itinerary Planning Input Form Figure 5.26: Alternate Version of Itinerary Planning Input Form (Note: Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Read the entire page →
From page 68... ... 5-36 Figure 5.27: Twin Cities Metro Transit's Itinerary Planning Output Page (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Figure 5.28 shows the walking directions provided by the automated itinerary planner. Read the entire page →
From page 69... ... 5-37 Figure 5.28: Detailed Walking Directions from Twin Cities Metro AIP (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Figure 5.29: "Schedule Adjust" and "Plan Return Trip" Features produce completely different itineraries than those originally created. Read the entire page →
From page 70... ... 5-38 original input form in the event that they would like to plan a trip in which parameters other than the time of travel are changed. For example, if they wanted to plan a trip from a different origin or to a different destination, this button would quickly return them to the original input form and allow them to re-start the itinerary planning process. Read the entire page →
From page 71... ... 5-39 Figure 5.30: Metro Transit's Personalized Bus Schedule Maker, Step 1 (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Figure 5.31: Metro Transit's Personalized Bus Schedule Maker, Step 2 (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Read the entire page →
From page 72... ... 5-40 Figure 5.32: Results of Constructing a Personalized Bus Schedule (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) 5.5.3 Implementation Issues Designing the System As stated earlier, Metro managers visited a number of other AIP sites when designing their system. Read the entire page →
From page 73... ... 5-41 destination input to be as simple and error-free as possible for the customer. For example, by design, origins and destinations cannot include an ampersand. Read the entire page →
From page 74... ... 5-42 5.5.4 Outcomes / Benefits Metro feels that its trip planning program gives people information and creates a good image for transit. It gives customers the impression that the transit system is "forwardlooking, current, and part of the technology age," a sentiment also expressed by managers in San Diego. Read the entire page →
From page 75... ... 5-43 Figure 5.33: TransitQuest Input Form Figure 5.34: SEPTA's Error-Trapping Mechanism for Origins and Destinations (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program) Read the entire page →
From page 76... ... 5-44 discussed above) Read the entire page →
From page 77... ... 5-45 Figure 5.35: Result of Clicking on TransitQuest's "Means of Transport" Button (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Figure 5.36: TransitQuest Help Screen Read the entire page →
From page 78... ... 5-46 Figure 5.37: SEPTA's Station Schedule Request Form Figure 5.38: Result of Station Schedule Request Read the entire page →
From page 79... ... 5-47 Figure 5.39: Initial Output from TransitQuest (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Figure 5.40: TransitQuest Itinerary Details (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Read the entire page →
From page 80... ... 5-48 schedule feature. One drawback of the detailed screen is that the legend does not include a description of the mode symbols. Read the entire page →
From page 81... ... 5-49 Figure 5.41: TransitQuest Trip Guide (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Figure 5.42: TransitQuest Connection Graphics (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Read the entire page →
From page 82... ... 5-50 The agency will be fixing this aspect of the system (to have it recognize addresses) in their next phase of development. Read the entire page →
From page 83... ... 5-51 5.6.4 Outcomes / Benefits Managers at SEPTA feel that the AIP feature gives the agency a good reputation. While they do not necessarily think the short-run benefit is greater than the cost of developing the system, they do believe the benefit will be realized in the long-term. Read the entire page →
From page 84... ... 5-52 • Total fare will be calculated for each itinerary; and • The interface will be redesigned to be more intuitive and user-friendly. Real-time Information, E-mail Notification, and CRM SEPTA does not currently have an AVL system, but recently received the funding for one. Read the entire page →
From page 85... ... 5-53 Figure 5.43: APT's Dynamic Route Generator Input Form • Travel Day - the customer can choose to travel on a weekday, Saturday, or Sunday; • Transfers - the customer can either choose to accept one transfer or can specify that only trips without a transfer are acceptable; • Sorting of Results - results can either be sorted by arrival time, departure time, or total travel time; and • Maximum results - this field is where the customer specifies the number of itineraries to show. The AIP can show 5, 10, 15, or all itineraries generated. Read the entire page →
From page 86... ... 5-54 Figure 5.44: APT's Dynamic Route Generator Results (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) 5.7.2 Objectives / Promise According to APT, usage statistics show that 80% of customers are local and 20% are from out-of-town. Read the entire page →
From page 87... ... 5-55 customer-service oriented and provides them with a tool to increase communication with their customers. Usage Patterns APT's trip planner gets approximately 50 to 100 hits per day. Read the entire page →
From page 88... ... 5-56 5.8 Greater Manchester Public Transport Executive The Greater Manchester Public Transport Executive's (GMPTE's) Web site offers automated itinerary trip planning, but neither real-time information, nor programs to notify customers of system conditions are available. Read the entire page →
From page 89... ... 5-57 Figure 5.45: GMPTE's Itinerary Planning Input Form Figure 5.46: Error Trapping for Origin or Destination (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Read the entire page →
From page 90... ... 5-58 Figure 5.47: GMPTE's Journey Planner Output Screen (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) Figure 5.48: Link to Mapping Page from GMPTE's Journey Planner Read the entire page →
From page 91... ... 5-59 Figure 5.49: Aerial Photos Showing Location of Transit Stop (Note: This Figure cannot be hyperlinked because it is produced by a dynamic interface program.) 5.8.2 Project Objectives As explained to us in the J-09 interview, the trip planner allows customers to find their way around the network and look at different ways of getting from point A to point B Read the entire page →
From page 92... ... 5-60 Maintaining Data Accuracy The agency maintains a transit database – in this database, routes are set up as a series of stops, which are geocoded into the system. This information is what they had to give the contractor – the trip planner feeds off this database. Read the entire page →
From page 93... ... 5-61 actual company that did their trip planner is called Action Information Management. Action Information Management won the contract in a competitive process – the company is a provider of map-based software and telecom software and is just moving into supplying trip planners. Read the entire page →

From page 33...

... 5-1 5. Itinerary Planning Systems Eight case studies were developed from detailed Web site reviews and extensive telephone interviews with transit agencies that have automated itinerary planning systems (AIP)