ITS Transit Standards Professional Capacity Building Program

Module 6: Traveler Information, Part 1 of 2

HTML of the Student Supplement

(Note: This document has been converted from the Student Supplement to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included, plus additional text descriptions for the images, photos and/or diagrams have been provided below.)

Module 6: Traveler Information, Part 1 of 2

Table of Contents

Introduction/Purpose - 2

Samples/Examples - 3

Reference to Other Standards - 10

Case Study - 10

Glossary - 11

References - 15

Study Questions - 16

Module Description

This module (Traveler Information Standards, Part 1 of 2) is the first of two course modules on traveler information using standards. It provides the background for understanding traveler information systems and the standards that facilitate the implementation of these systems by:

  1. Briefly explaining traveler information systems within the context of National ITS Architecture;
  2. Describing the basic taxonomy that will help define where standards should be considered within the functions; and
  3. Discussing the functions of traveler information systems to conceptualize technology implementation at an agency so that participants understand where the standards can be used.

Also explained in this module is how to best adapt the state-of-the-practice, such as systems engineering, for those functions within traveler information where standards do not exist. Knowing how traveler information systems fit within the National ITS Architecture framework will provide participants with the context necessary to consider those standards that will facilitate data exchange among various technologies within or external to a transit agency.

1. Introduction/Purpose

Traveler information systems cover customer-facing technologies that provide the public with information such as trip planning and real-time operational information. Traveler information can be generated by on-board and central systems that are typically used to monitor and manage operations (discussed in the Transit Management modules), as well as those systems that facilitate providing traveler information (e.g., itinerary planning software). Traveler information can be provided to the public through a variety of dissemination media including electronic signage located at stops/stations, mobile devices, the Internet, 511 systems, and interactive voice response (IVR) systems. Agencies can provide traveler information directly to the public and indirectly by making the underlying data readily available under open standards. Developers can use open data to create traveler information applications that are accessed by the public on mobile devices and the Internet.

Traveler information can be defined by two primary categories: static data (e.g., from schedules) and dynamic data (e.g., real-time vehicle arrival times). In addition, traveler information can be defined by where in the trip chain individuals seek the information (e.g., pre-trip, en route) and the dissemination media used to provide the information.

2. Samples/Examples

Traveler information systems cover customer-facing technologies that provide the public with information regarding trip planning and real-time operational information. Traveler information can be generated by on-board and central systems that are used typically to monitor and manage operations (discussed in the Transit Management modules [2 and 5]), as well as systems that facilitate providing Traveler information (e.g., itinerary planning software).

The Transit Traveler Information Service Package in the National ITS Architecture provides transit users at transit stops and on board transit vehicles with ready access to transit information. The information services include transit stop annunciation, imminent arrival signs, and real-time transit schedule displays that are of general interest to transit users. Systems that provide custom transit trip itineraries and other tailored transit information services are also represented by this service package.

Figure 1 shows the Transit Traveler Information Service Package, which provides transit users at transit stops and on board transit vehicles with ready access to transit information. This service package shows five entities: The Transit Management Center, which is connected to and exchanges data with four other entities, namely, Personal Information Access, Remote Traveler Support, Information Service Provider (ISP), and Transit Vehicle. Four other entities outside of the architecture (called terminators) are also part of this Service Package: Other ISP, and the Traveler, Media, and Other Transit Management Centers.

The traveler information taxonomy includes four major categories of technologies: pre-trip systems, onboard systems, wayside systems, and third-party smartphone applications and social media. The pre-trip category covers technologies that provide information before taking a trip. The on-board category covers those technologies that provide en route transit users with static and real-time travel-related information on board a transit vehicle. The wayside category covers technologies that provide both real-time and static information. The third-party applications and social media category covers using a third party to develop static and real-time applications, and providing real-time information via social media.

The following four tables show the relationships between travel characteristics and dissemination media: Table 1 shows the relationships between travel characteristics and dissemination media highlighting media for pre-trip information; Table 2 shows the relationship between travel characteristics and dissemination media highlighting media for on-board information; Table 3 shows the relationship between travel characteristics and dissemination media highlighting media for wayside traveler information; Table 4 shows the relationship between travel characteristics and dissemination media highlighting media for third-party applications and social media.

Figure 1. Transit Traveler Information Service Package

Transit Traveler Information Service Package Example. Please see the Extended Text Description below.

(Extended Text Description: Author’s relevant notes: Transit Traveler Information Service Package Example: This graphic has a rectangular box in the center which is labeled Transit Management and is purple in color. Within Transit Management is another smaller rectangle labeled Transit Center Vehicle Tracking and is white in color. Above the Transit Management box is a rectangle labeled Personal Information Access, which is purple in color. Within Personal Information Access is another smaller rectangle labeled Personal Interactive Information Reception and is white in color. There is a line with an arrow from Transit Management to the Personal Information Access box, which is labeled "personal transit information." There is a line with an arrow from the Personal Information Access box to Transit Management, which is labeled "transit information user request." To the right of Transit Management is a rectangle labeled Transit Vehicle, which is purple in color. Inside Transit Vehicle is another smaller rectangle labeled On-board Transit Information Services, which is white in color. Above the Transit Vehicle box is an oval labeled Traveler, which is yellow in color. There is a line with an arrow from the Transit Vehicle box to the Traveler oval, which is labeled "traveler interface updates." There is a line with an arrow from Transit Vehicle to Transit Management, which is labeled "transit traveler request." There is a line with an arrow from Transit Management to Transit Vehicle, which is labeled "transit traveler information." Below the Transit Management box is a rectangle labeled Remote Traveler Support, which is purple in color. Within Remote Traveler Support is another smaller rectangle labeled Remote Transit Information Services and is white in color. There is a line with an arrow from Transit Management to the Remote Traveler Support box, which is labeled "transit traveler information." There is a line with an arrow from the Remote Traveler Support box to Transit Management, which is labeled "transit information user request." To the right of the Transit Management box is an oval labeled Media, which is yellow in color. There is a line with an arrow from the Transit Management box to the Media oval, which is labeled "transit information for media." To the left of Transit Management is a rectangle labeled Information Service Provider, which is purple in color. Inside Information Service Provider are two other smaller rectangles labeled ISP Traveler Data Collection and Infrastructure Provided Trip Planning, which are white in color. There are two lines with arrows from Transit Management to the Information Service Provider box, which are labeled "transit and fare schedules" and "transit schedule adherence information." There is a line with an arrow from the Information Service Provider box to Transit Management, which is labeled "transit information request." Above the Information Service Provider box is an oval labeled Other ISP, which is yellow in color. There is a line with an arrow to and from Information Service Provider to Other ISP, which is labeled "transit service information." To the left of the Transit Management box is an oval labeled Other Transit Management, which is yellow in color. There is a line with an arrow to and from the Transit Management box to the Other Transit Management oval, which is labeled "transit traveler information coordination." This service package provides transit users at transit stops and on-board transit vehicles with ready access to transit information. The information services include transit stop annunciation, imminent arrival signs, and real-time transit schedule displays that are of general interest to transit users. Systems that provide custom transit trip itineraries and other tailored transit information services are also represented by this service package.)

Table 1. Pre-Trip Traveler Information

Pre-Trip Traveler Information. Please see the Extended Text Description below.

(Extended Text Description: This table contains the following content::

  When/Where What How
  Pre-trip Wayside/En route On-board Mobile Trip planning Static information Real-time information Proactive Interactive Custom
Printed Material X X X     X   X    
Telephone X       X X X   X  
Mobile Phone X X X X   X X X X X
Smartphone X X X X X X X X X X
E-mail X X X X   X X X   X
Short message service (SMS) X X X X     X X   X
Other mobile devise (e.g., iPad) X X X X X X X X X X
Internet/Website X       X X X   X X
Kiosk X X     X X     X  
Television X         X X X    
Dynamic message sign   X X     X X X    
Annunciator   X X       X X    
Social media X     X     X X    
Interactive voice response X     X X X X   X X

Within this table, specific cells are highlighted that show the relationship between the types of information and dissemination media. The following cells in the table are highlighted:

Table 2. On-Board Traveler Information

On-Board Traveler Information. Please see the Extended Text Description below.

(Extended Text Description: This table is the same as Table 1, above, but with different highlighting. The following cells in the table are highlighted:

Table 3. Wayside/En route Traveler Information

Wayside/En route Traveler Information. Please see the Extended Text Description below.

(Extended Text Description: This table is the same as Table 1, above, but with different highlighting. The following cells in the table are highlighted:

Table 4. Third-Party Applications and Social Media

Third-Party Applications and Social Media. Please see the Extended Text Description below.

(Extended Text Description: This table is the same as Table 1, above, but with different highlighting. The following cells in the table are highlighted:

Figure 2. Traveler Information Data Exchanges

Figure 2 shows an example of the relationships on board a transit vehicle. To provide more information about how these technologies are related to each other, Table 5 summarizes the dependencies between traveler information and transit management and other technologies.

Traveler Information Data Exchanges. Please see the Extended Text Description below.

(Extended Text Description: Author’s relevant notes: Traveler Information Data Exchanges: This flowchart provides context for Traveler Information data exchanges. Generally, this diagram shows the collection of data from individual transit vehicles and data management centers, feeding data to customer information servers which process and disseminate specific traveler information to the end users. On the far left of the diagram, CAD/AVL systems that monitor the operations of each mode (in the diagram, the modes that are represented are subway, bus, commuter rail, light rail transit, bus rapid transit and boat) provide real-time information to the Information Reconciliation process, which takes input from other databases as shown: scheduling, planning, marketing and customer databases. Once all of the information is compiled and reconciled, information is sent through the Data Feed Layer to a Real-time Customer Information Server, which interfaces with the Monitoring/Feedback Layer, which interfaces with Performance Standards and Surveys/Feedback. Then, information is sent through the Dissemination Layer to various end user media, including travelers’ devices (smartphone, mobile phone, other mobile device and personal computer), information service providers (511, Satellite Radio and news outlets), third-party developers (applications and visualizations) and within the transit agency to various media (e.g., interactive voice response, dynamic message signs, website, alerts, automated voice announcements, social media and customer service).)

Table 5. Dependencies between Traveler Information and Transit Management and Other Technologies

Category System/Technology Dependent on
Traveler Information On-board automated voice announcements (AVA)
  • AVL system
  • Route and vehicle schedule data
En route/wayside traveler information, including real-time arrival/departure information in a variety of dissemination media
  • Route and vehicle schedule data
  • AVL system
  • CAD system
  • Data communications technologies
On-board Internet access for passengers Data communications technologies
511, 311, and 211 systems, and Google Transit Open data
Third-party smartphone applications Open data

3. Reference to Other Standards

N/A. References will be made in Module 7: Traveler Information Standards, Part 2 of 2.

4. Case Study: Example of Relating Requirements to Specific Standards

To demonstrate how functional requirements for traveler information systems can be related to specific standards, an example is provided: requiring a real-time information system to export data for use with the Google Transit Trip Planner. This requirement could be written as follows:

General Transit Feed Specifications Export (GTFS Feed) for Google Transit Trip Planner

1. The system shall provide an interface to Google Transit using the GTFS. The interface shall allow for the export and delivery of data fields necessary (per the transit agency’s needs) for fixed-route trip planning on Google. The contractor shall work with the transit agency to decide which of the data fields described in the GTFS shall be included in the export.

2. The contractor shall perform or help the transit agency with the following processes required to deliver its fixed-route data to Google Transit:

3. The contractor shall coordinate with the transit agency to ensure that any abnormal situations in trip planning, including but not limited to the following, are resolved:

5. Glossary

Term Definition
Comma-Separated Values (CSV) A file format used as a portable representation of a database. Each line is one entry or record and the fields in a record are separated by commas. Agencies using GTFS have committed to producing and maintaining their schedule data in standardized CSV tables to display their system on Google Transit’s trip planner and, increasingly, opening this data to other third-party application developers.
Communications Layer One of three layers (along with the transportation and institutional layers) defined by the National ITS Architecture. The communications layer includes all of the communications equipment (e.g., wireline and wireless transmitters and receivers) and the information management and transport capabilities necessary to transfer information among entities in the transportation layer. The application data content and the transportation application requirements are generally transparent to the communications layer. The communication layer’s view of ITS is that of many distributed users, some of them mobile, which require communication services.
Equipment Package The building blocks of the subsystems of the physical architecture subsystems. Equipment packages group similar processes of a particular subsystem together into an implementable package. The grouping also takes into account the user services and the need to accommodate various levels of functionality.
extensible Markup Language (XML) The XML format is more robust than GTFS in its abilities to represent large complex models, but the approach is more common in Europe and raises standardization challenges in the face of hyper flexibility.
General Transit Feed Specification (GTFS) The General Transit Feed Specification, originally developed by Google, contains static schedule information for transit agencies including: stop locations, route geometries, and stop times. "GTFS consists of a package of comma-delimited text files, each of which contains one aspect of the transit information and a set of rules on how to record it: six mandatory files (agency, stops, routes, trips, stops times, and calendar) and seven optional files (calendar dates, fare attributes, fare rules, shapes, frequencies, transfers and feed info)" (8, page 1).
Geo JavaScript Object Notation (GeoJSON) GeoJSON is a format for encoding a variety of geographic data structures. Geospatial data interchange format based on JavaScript Object Notation (JSON)
GTFS-realtime GTFS-realtime contains real-time information related to vehicle positions, service alerts, and trip updates (delays, cancellations, etc.)
Identification of Fixed Objects in Public Transport (IFOPT) IFOPT defines a model and identification principles for the main fixed objects related to public access to Public Transport (e.g., stop points, stop areas, stations, connection links, entrances, etc.). The IFOPT Standard builds on the TransModel Standard to define four related submodels.
Institutional Layer An integral component of the National ITS Architecture that represents the existing and emerging institutional constraints and arrangements that are the context for all ITS deployments. The transportation layer and communications layer together provide the technical framework within which interoperable systems may be implemented. The institutional layer introduces the policies, funding incentives, working arrangements, and jurisdictional structure that support the technical layers of the architecture. This institutional layer provides the basis for understanding whom the stakeholders will be and the roles these implementers could take in implementing architecture-based ITS systems.
JavaScript Object Notation (JSON) JSON is a data-interchange and text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages (https://www.json.org/json-en.html).
Logical Architecture The part of the National ITS Architecture that defines what has to be done to support the ITS user services. It defines the processes that perform ITS functions and the information or data flows that are shared between these processes.
Network Exchange (NeTEx) NeTEx is intended to be a general-purpose format capable of exchanging timetables for rail, bus, coach, ferry, air, or any other mode of public transport.
Protocol Buffers GTFS-realtime data exchange format is based on Protocol Buffers. Protocol buffers are a language- and platform-neutral mechanism for serializing structured data (think XML, but smaller, faster, and simpler). The data structure is defined in a GTFS-realtime.proto file, which then is used to generate source code to easily read and write structured data from and to a variety of data streams using a variety of languages.
Physical Architecture The part of the National ITS Architecture that provides agencies with a physical representation (though not a detailed design) of the important ITS interfaces and major system components. It provides a high-level structure around the processes and data flows defined in the logical architecture. The principal elements in the physical architecture are the subsystems and architecture flows that connect these subsystems and terminators into an overall structure.
Really Simple Syndication or Rich Site Summary (RSS) RSS is a format for delivering regularly changing web content.
Representational State Transfer (REST) REST is a distributed system framework that uses web protocols and technologies (40)
Resource Description Framework (RDF) RDF is a standard model for data interchange on the web (39)
Service Interface for Real Time Information (SIRI) SIRI is a real-time data standard predominant in Europe, but making significant inroads into the U.S. market, notably at [Metropolitan Transportation Authority] MTA in New York. Recent change proposals to the SIRI standard include the definition of a structure for SIRI web services. The SIRI standard includes a component for schedule data, but is designed for real time and is therefore more complex than some other standards.
Service Package The service packages, formerly known as market packages, provide an accessible, service-oriented perspective to the National ITS Architecture. They are tailored to fit, separately or in combination, real-world transportation problems and needs. Service packages collect together one or more equipment packages that must work together to deliver a given ITS service and the architecture flows that connect them and other important external systems. In other words, they identify the pieces of the physical architecture that are required to implement a particular ITS service. Service packages are implemented through projects (or groups of projects, aka programs) and in transportation planning, are directly related to ITS strategies used to meet regional goals and objectives.
Simple Object Access Protocol (SOAP) SOAP is a method of transferring messages, or small amounts of information, over the Internet. SOAP messages are formatted in XML and are typically sent using HTTP (hypertext transfer protocol).
Systems Engineering An interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation while considering the complete problem. Systems engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.
TransModel TransModel is the European Reference Data Model for Public Transport. It provides an abstract model of common public transport concepts and structures that can be used to build many different kinds of public transport information systems, including for timetabling, fares, operational management, real-time data, etc. (43)
TransXChange (TxC) TxC is the UK nationwide standard for exchanging bus schedules and related data. TxC provides a means to exchange bus routes and timetables between different computer systems, together with related operational data.
Transportation Layer One of three layers (along with the communications layer and the institutional layer) defined by the physical architecture. The transportation layer shows the relationships among the transportation-related elements. It is composed of subsystems for travelers, vehicles, transportation management centers, and field devices, as well as external system interfaces (terminators) at the boundaries.

6. References

7. Study Questions

1. Which one of these components is NOT in the Transit Traveler Information Service Package (SP)?

  1. On-board systems
  2. Wayside systems
  3. Dynamic ridesharing
  4. Pre-trip systems

2. When on the Transit Traveler Information Service Package web page in the National ITS Architecture literature, you can click on the architecture flow and it will show you the standards associated with that data exchange.

  1. True
  2. False

3. In which location is Pre-Trip Traveler Information NOT provided?

  1. Via a mobile device
  2. On devices in dedicated locations
  3. On devices at transit stops/stations
  4. On board vehicles

4. Which type of dissemination media is NOT used to provide traveler information at the wayside/en route?

  1. Dynamic message sign (DMS)
  2. Kiosk
  3. Television
  4. Smartphone

5. Can an on-board automated voice announcement (AVA) system be used to comply, in part, with the Americans with Disabilities ACT (ADA)?

  1. Yes
  2. No

6. En route/wayside information NOT dependent on which system?

  1. Data communications technologies
  2. Open data
  3. Route and vehicle schedule data
  4. AVL system

7. Which one of these is not a basic element of a typical communication network?

  1. Backbone
  2. Local
  3. Regional
  4. Distribution

8. Which location criterion for DMS is the most prevalent amongst transit agencies?

  1. Safety considerations
  2. Availability of communication
  3. Number of transfers at stops/stations
  4. Boarding counts at stops/stations

9. Which one of these is an SAE standard?

  1. National Transportation Communications for ITS Protocol (NTCIP)
  2. Service Interface for Real Time Information (SIRI)
  3. eXtensible Markup Language (XML)
  4. International Traveler Information Systems (ITIS)

10. The systems engineering process (SEP) does not include considering user needs.

  1. True
  2. False