ISO/TS 21219-13:2025

Technical
Specification
ISO/TS 21219-13
First edition
Intelligent transport systems —
2025-01
Traffic and travel information via
transport protocol experts group,
generation 2 (TPEG2) —
Part 13:
Public transport information
service (TPEG2-PTS)
Systèmes intelligents de transport — Informations sur le trafic
et le tourisme via le groupe expert du protocole de transport,
génération 2 (TPEG2) —
Partie 13: Service d'informations sur les transports publics
(TPEG2-PTS)
Reference number
© ISO 2025
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Abbreviated terms . 4
5 Application specific constraints . . 4
5.1 Application identification .4
5.2 Version number signalling .4
5.3 Ordered components . .4
5.4 Extendibility .5
5.5 TPEG Service Component Frame .5
6 PTS Structure . 5
7 PTS message components . 7
7.1 PTSMessage .7
7.2 MMCSwitch .8
7.3 MessageManagementLink .8
7.4 MasterMessageLink .8
7.5 MessagePartLink .8
7.6 GeoLocation .8
7.7 PtRequest .8
7.8 AlertRequest .9
7.9 StopEventRequest .9
7.10 TripInfoRequest .9
7.11 Alert . .10
7.12 DiversionLink .10
7.13 StopEvent .10
7.14 StopEventForPlace.10
7.15 StopEventForLine .11
7.16 TripInfoResponse .11
8 PTS Datatypes .11
8.1 AlertFor .11
8.2 LineIdentity . 12
8.3 CallAtStopForLine. 12
8.4 CallAtStopForPlace . 12
8.5 CallAtStopInfo . 12
8.6 OperatorContact. 13
8.7 PtServiceDescription . 13
8.8 Route . . 13
8.9 StopPlace .14
8.10 StopPoint .14
8.11 TimeInfo .14
8.12 TripLegStructure . 15
8.13 TripPreferences. 15
9 PTS Tables . 16
9.1 pts001: ModeOfTransport . .16
9.2 pts017: ServiceDeliveryPointType.17
9.3 pts030: ContactType .17
9.4 pts036: AlertForType .18
9.5 pts037: AlertEvent .18
9.6 pts038: AlertCause.18

iii
9.7 pts039: AdviceType . 22
9.8 pts040: AccessFeatureType . 22
9.9 pts041: StopPlaceType . 23
9.10 pts042: FacilityType . 23
9.11 pts043: ServiceStatus .24
9.12 pts044: StopPlaceUsage. 25
9.13 pts045: Occupancy . 25
9.14 pts100:SubmodeOfTransport . 26
9.15 pts101: AirService . 26
9.16 pts102: GondolaCableCarService .27
9.17 pts105: RailwayService .27
9.18 pts106: UrbanRailwayService . 28
9.19 pts110: BusService . 28
9.20 pts112: CoachService . 29
9.21 pts115: WaterTransportService . 29
Annex A (normative) TPEG application, TPEG-Binary Representation .31
Annex B (normative) TPEG application, tpegML Representation .43
Annex C (informative) PTS usage examples .55
Bibliography .73

iv
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO document should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
A list of all parts in the ISO 21219 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

v
Introduction
0.1  History
TPEG technology was originally proposed by the European Broadcasting Union (EBU) Broadcast
Management Committee, who established the B/TPEG project group in the autumn of 1997 with a brief to
develop, as soon as possible, a new protocol for broadcasting traffic and travel-related information in the
multimedia environment. TPEG technology, its applications and service features were designed to enable
travel-related messages to be coded, decoded, filtered and understood by humans (visually and/or audibly
in the user’s language) and by agent systems. Originally, a byte-oriented data stream format, which can be
carried on almost any digital bearer with an appropriate adaptation layer, was developed. Hierarchically
structured TPEG messages from service providers to end-users were designed to transfer information from
the service provider database to an end-user’s equipment.
One year later, in December 1998, the B/TPEG group produced its first EBU specifications. Two documents
were released. Part 2 (TPEG-SSF, which became ISO/TS 18234-2) described the syntax, semantics and
framing structure, which was used for all TPEG applications. Meanwhile, Part 4 (TPEG-RTM, which became
ISO/TS 18234-4) described the first application for road traffic messages.
Subsequently, in March 1999, CEN/TC 278, in conjunction with ISO/TC 204, established a group comprising
members of the former EBU B/TPEG and this working group continued development work. Further parts
were developed to make the initial set of four parts, enabling the implementation of a consistent service.
Part 3 (TPEG-SNI, ISO/TS 18234-3) described the service and network information (SNI) application used
by all service implementations to ensure appropriate referencing from one service source to another.
Part 1 (TPEG-INV, ISO/TS 18234-1) completed the series by describing the other parts and their relationship.
It also contained the application IDs used within the other parts. Additionally, Part 5, the public transport
information application (TPEG-PTI, ISO/TS 18234-5), was developed. The so-called TPEG-LOC location
referencing method, which enabled both map-based TPEG-decoders and non-map-based ones to deliver
either map-based location referencing or human readable text information, was issued as ISO/TS 18234-6
to be used in association with the other applications of parts of the ISO 18234 series to provide location
referencing.
The ISO 18234 series has become known as TPEG Generation 1.
0.2  TPEG Generation 2
When the Traveller Information Services Association (TISA), derived from former forums, was inaugurated
in December 2007, TPEG development was taken over by TISA and continued in the TPEG applications
working group.
It was about this time that the (then) new Unified Modelling Language (UML) was seen as having major
advantages for the development of new TPEG applications in communities who would not necessarily have
the binary physical format skills required to extend the original TPEG TS work. It was also realized that the
XML format for TPEG described within the ISO 24530 series (now superseded) had a greater significance
than previously foreseen, especially in the content-generation segment, and that keeping two physical
formats sychronized, in different standards series, would be rather difficult.
As a result, TISA set about the development of a new TPEG structure that would be UML-based. This has
subsequently become known as TPEG Generation 2.
TPEG2 is embodied in the ISO 21219 series and it comprises many parts that cover the introduction, rules,
toolkit and application components. TPEG2 is built around UML modelling and has a core of rules that
contain the modelling strategy covered in ISO 21219-2, ISO 21219-3 and ISO 21219-4 and the conversion to
two current physical formats: binary (Annex A) and XML (Annex B); others can be added in the future. TISA
uses an automated tool to convert from the agreed UML model XMI file directly into an MS Word document
file that forms the annex for each physical format.
TPEG2 has a three-container conceptual structure: message management (ISO 21219-6), application (several
parts) and location referencing (ISO 21219-7). This structure has flexible capability and can accommodate

vi
many differing use cases that have been proposed within the TTI sector and more broadly for hierarchical
message content.
TPEG2 also has many location referencing options as required by the service provider community, any of
which may be delivered by vectoring data included in the location referencing container.
The following classification provides a helpful grouping of the different TPEG2 parts according to their
intended purpose. Note that the list below may be incomplete, as it is possible that new TPEG2 parts will be
introduced after the publication of this document.
— Toolkit parts: TPEG2-INV (ISO 21219-1), TPEG2-UML (ISO 21219-2), TPEG2-UBCR (ISO 21219-3), TPEG2-
UXCR (ISO 21219-4), TPEG2-SFW (ISO 21219-5), TPEG2-MMC (ISO 21219-6), TPEG2-LRC (ISO 21219-7).
— Special applications: TPEG2-SNI (ISO 21219-9), TPEG2-CAI (ISO 21219-10), TPEG2-LTE (ISO/TS 21219-24).
— Location referencing: TPEG2-OLR (ISO/TS 21219-22), TPEG2-GLR (ISO 21219-21), TPEG2-TLR
(ISO 17572-2), TPEG2-DLR (ISO 17572-3).
— Applications: TPEG2-PTS (ISO 21219-13 – this document), TPEG2-PKI (ISO 21219-14), TPEG2-TEC
(ISO 21219-15), TPEG2-FPI (ISO 21219-16), TPEG2-SPI (ISO 21219-17), TPEG2-TFP (ISO 21219-18),
TPEG2-WEA (ISO 21219-19), TPEG2-RMR (ISO/TS 21219-23), TPEG2-EMI (ISO 21219-25), TPEG2-VLI
(ISO/TS 21219-26).
TPEG2 has been developed to be broadly (but not totally) backward compatible with TPEG1 to assist in
transitions from earlier implementations, while not hindering the TPEG2 innovative approach and being
able to support many new features, such as dealing with applications with both long-term, unchanging
content and highly dynamic content, such as parking information.
This document is based on the TISA specification technical/editorial version reference:
SP19008/1.0/001.
vii
Technical Specification ISO/TS 21219-13:2025(en)
Intelligent transport systems — Traffic and travel information
via transport protocol experts group, generation 2 (TPEG2) —
Part 13:
Public transport information service (TPEG2-PTS)
1 Scope
This document describes the “public transport information service” (PTS) application, which is intended
to cover all modes of public (i.e. collective) transport, both for inter-urban and intra-urban travel. The
PTS application is designed to allow the efficient and language-independent delivery of public transport
information directly from a service provider to end-users.
The PTS application design is based on three main use cases.
— Provision of alert information: an alert is a warning that indicates an emergency situation. This case is
specifically relevant for broadcast/push mode, for major deviations or disruptions which are relevant
for a large number of travellers. A dedicated alert request is also defined and can be used if a backchannel
is available.
— Timetable information, both scheduled and real time: this information is in some cases relevant for
broadcast, e.g. in case of large events for the transport modalities to/from the event site. A dedicated
timetable request is also defined and can be used if a backchannel is available.
— Individual requests for trip information (backchannel is required).
The PTS application focuses on providing core information regarding public transport in order to ensure the
compactness of the TPEG application. Specific information as provided in typical public transport apps (e.g.
fare information) is not in the scope of this document.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO 21219-1, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol experts
group, generation 2 (TPEG2) — Part 1: Introduction, numbering and versions (TPEG2-INV)
ISO 21219-7, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol experts
group, generation 2 (TPEG2) — Part 7: Location referencing container (TPEG2-LRC)
ISO 21219-9, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol experts
group, generation 2 (TPEG2) — Part 9: Service and network information (TPEG2-SNI)
ISO 21219-14, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 14: Parking information (TPEG2-PKI)
ISO 21219-15, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 15: Traffic event compact (TPEG2-TEC)

3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
AccessFeature
facility providing access to a StopPlace, StopPoint or vehicle
EXAMPLE Elevator, stairs, ramp.
Note 1 to entry: This description is close to the Open API for Distributed Journey Planning term "AccessFeatureType",
specified in CEN/TS 17118:2017, Table 119. The meaning is similar, but harmonized to the PTS (public transport
information service) application context.
3.2
Destination
place to where the user is heading
Note 1 to entry: In the PTS (public transport information service) application context, this can be StopPlaces or
StopPoints only. PTS additionally uses Destination to describe the End of a VehicleJourney as specified by CEN/
TS 17118:2017, Table 92.
3.3
Line
aggregation of similar VehicleJourneys which are published under the same name
EXAMPLE Bus line 100, or airport shuttle.
Note 1 to entry: This PTS description is close to the Open API for Distributed Journey Planning term "Line", specified
by CEN/TS 17118. The meaning is similar, but harmonized to the PTS application context.
3.4
ModeOfTransport
type of a VehicleJourney or Line
EXAMPLE Bus service, railway service, air service.
Note 1 to entry: This PTS description is close to the Open API for Distributed Journey Planning term "Mode", specified
by CEN/TS 17118. The meaning is similar, but harmonized to the PTS application context.
3.5
CallAtStop
meeting of a VehicleJourney with a specific scheduled StopPoint
[SOURCE: CEN/TS 17118:2017, 3.1.123]
3.6
operator
company providing public transport services
[SOURCE: CEN/TS 17118:2017, 3.1.71]

3.7
Origin
Place from where the user wants to start
Note 1 to entry: In the PTS (public transport information service) application context, this can be StopPlaces
or StopPoints only. PTS additionally uses Origin to describe the Start of a VehicleJourney, as specified by CEN/
TS 17118:2017, Table 92.
3.8
PublishedLineName
name which is used for a Line in public
EXAMPLE Bus line 100, or airport shuttle.
Note 1 to entry: This PTS description is close to the Open API for Distributed Journey Planning term
"PublishedLineName", specified by CEN/TS 17118:2017. The meaning is similar, but harmonized to the PTS application
context.
3.9
Route
ordered list of located points defining one single path through the road (or rail) network
[SOURCE: EN 12896-1:2016]
3.10
StopEvent
departure or arrival event or both
[SOURCE: CEN/TS 11718:2017, 3.1.115]
3.11
StopPlace
one or more locations where vehicles may stop and where passengers may board or leave vehicles or prepare
their trip, and which will usually have one or more well-known names
EXAMPLE Station, airport, harbour.
Note 1 to entry: This PTS description is close to the Open API for Distributed Journey Planning term "StopPlace",
specified by CEN/TS 17118. The meaning is similar, but harmonized to the PTS application context.
3.12
StopPoint
location with an identifier and name where passengers can board or alight from vehicles
EXAMPLE Platform, gate.
Note 1 to entry: This PTS description is close to the Open API for Distributed Journey Planning term "StopPoint",
specified by CEN/TS 17118. The meaning is similar, but harmonized to the PTS application context.
3.13
Trip
whole journey from a passengers Origin to passenger Destination in one or more TripLegs
Note 1 to entry: This PTS description is close to the Open API for Distributed Journey Planning term "Trip", specified
by CEN/TS 17118. The meaning is similar, but harmonized to the PTS application context.
3.14
TripLeg
single stage of a Trip that is made without change of ModeOfTransport or VehicleJourney
Note 1 to entry: This PTS description is close to the Open API for Distributed Journey Planning term "TripLeg",
specified by CEN/TS 17118. The meaning is similar, but harmonized to the PTS application context.

3.15
VehicleJourney
description of a journey of a vehicle from its Origin to its Destination
Note 1 to entry: This PTS description is close to the OJP term VehicleJourney specified by CEN/TS 17118. The meaning
is similar, but harmonized to the PTS application context.
4 Abbreviated terms
For the purposes of this document, the abbreviated terms in ISO 21219-1, ISO 21219-9, ISO 21219-14,
ISO 21219-15 and the following apply.
OJP Open API for distributed Journey Planning
5 Application specific constraints
5.1 Application identification
The word “application” is used in the TPEG specifications to describe specific subsets of the TPEG structure.
An application defines a limited vocabulary for a certain type of messages, e.g. parking information or road
traffic information. Each TPEG application is assigned a unique number, called the AID. An AID is defined in
ISO 21219-1 whenever a new application is developed.
[3]
The AID number is used within the TPEG2-SNI application to indicate how to process TPEG content. It also
facilitates the routing of information to the appropriate application decoder.
5.2 Version number signalling
Version numbering is used to track the separate versions of an application through its development and
deployment. The differences between these versions could have an impact on client devices.
The version numbering principle is defined in ISO 21219-1.
Table 1 shows the current version numbers for signalling PTS within the SNI application.
Table 1 — Current version numbers for signalling of PTS
Major version number 1
Minor version number 0
5.3 Ordered components
TPEG2-PTS requires a fixed order of TPEG components. The order for the PTS message component is shown
in Figure 1; the first component shall be the Message Management Container (MMC). This shall be the only
component if the message is a cancellation message. Otherwise, the MMC component shall be followed by the
one or more Application Data Container component(s) which includes the application-specific information.

Figure 1 — Composition of TPEG messages
5.4 Extendibility
The requirement of a fixed component order does not affect the extension of TPEG2-PTS. Future application
extensions may insert new components or may replace existing components by new ones without losing
backward compatibility, i.e. a TPEG2-PTS decoder shall be able to detect and skip unknown components.
5.5 TPEG Service Component Frame
TPEG2-PTS shall make use of the "Service Component Frame with dataCRC and messageCount" according to
ISO 21219-5.
6 PTS Structure
The structure of a PTS message is shown in Figure 2. This structure conforms to the UML modelling
rules defined in ISO 21219-2. The binary format and XML format of the TPEG2-PTS application for use in
transmission shall be in accordance with Annexes A and B, respectively. Examples of TPEG2-PTS use cases
are shown in Annex C.
Figure 2 — PTS message structure
The structure of the TripLegStructure is shown in Figure 3.

Figure 3 — TripLegStructure component structure
7 PTS message components
7.1 PTSMessage
Table 2 defines the PTSMessage component, i.e. the overall PTS message container.

Table 2 — PTSMessage
Name Type Multiplicity Description
Ordered components
mmc MMCSwitch 1 n.a.
ptRequest PtRequest 0.1 Component to transmit a request for public transport
information.
alert Alert 0.1 Component to transmit alert information.
stopEvent StopEvent 0.1 Component to transmit information for a departure/
arrival events (timetable) at a stopPlace or for a Line.
tripInfoResponse TripInfoResponse 0.1 Component to transmit the response to a
TripInfoRequest.
location GeoLocation 0.1 Map-related location referencing information for this
PTS message.
7.2 MMCSwitch
The MMCSwitch component is an abstract component, allowing the flexible use of monolithic or multi-part
message management.
7.3 MessageManagementLink
The MessageManagementLink is a placeholder for the MessageManagementContainer as defined by
ISO 21219-6. It assigns the PTS application-specific local component ID for the MMC container (see Annex A).
7.4 MasterMessageLink
The MMCMasterLink is a placeholder for the Master-Message MMC for multi-part message management, as
defined by ISO 21219-6. It assigns the PTS application-specific local component ID for the MMC container
(see Annex A).
7.5 MessagePartLink
The MMCPartLink is a placeholder for the external partial-Message MMC (MMCMessagePart) for multi-part
message management, as defined by ISO 21219-6. It assigns the PTS application-specific local component ID
for the MMC container (see Annex A).
7.6 GeoLocation
The GeoLocation component is a placeholder for the LocationReferencingContainer (LRC). It assigns the PTS
application-specific local component ID for the LRC container. All component IDs within the LRC container
shall be taken from the LRC toolkit specified by ISO 21219-7.
The LocationReferenceLink component is a placeholder for the LocationReferencingContainer (LRC). It
assigns the PTS application-specific local component ID for the LRC container. All component IDs within the
LRC container shall be taken from the LRC toolkit specified by ISO 21219-7.
The GeoLocation describes the location for which the information is intended. e.g. airport, railway station,
area, city, line.
7.7 PtRequest
Component to transmit a request for public transport information. This component can contain one of the
following: AlertRequest, StopEventRequest or TripInfoRequest.

7.8 AlertRequest
Table 3 defines the AlertRequest component, i.e. the component to transmit a request for one or more alerts.
Table 3 — AlertRequest
Name Type Multiplicity Description
allAlerts Boolean 1 True if an AlertRequest is issued for all available
alerts; false otherwise. If false, the remaining
attributes specify the AlertRequest.
stopPlaceName LocalisedShortString 0.1 Well-known name of the StopPlace for which an
AlertRequest is issued.
ptMode pts001:ModeOfTransport 0.* List of the public transportation modes for which
an AlertRequest is issued.
lineIdentity LineIdentity 0.1 Description of the Line for which an AlertRequest
is issued.
7.9 StopEventRequest
The StopEventRequest component is used to transmit a request for stop-centric arrivals/departures (a
timetable or departure board):
— either for one or more Lines at a stopPlace, or
— for all StopPlaces on a Line.
Table 4 defines the StopEventRequest component.
Table 4 — StopEventRequest
Name Type Multiplicity Description
departure Boolean 1 True if a StopEventRequest is issued for
departures; false if a StopEventRequest is issued
for arrivals.
stopPlaceName LocalisedShortString 0.1 In the case of a StopEventRequest for a StopPlace,
describes the well-known name of the StopPlace.
ptMode pts001:ModeOfTransport 0.* In the case of a StopEventRequest for a StopPlace,
lists the modes of transport to be considered for
the request.
lineIdentity LineIdentity 0.* In the case of a StopEventRequest for a Line,
description of the Line to be considered for the
request.
startTime DateTime 0.1 Start of the timeframe for which the request is
issued.
endTime DateTime 0.1 Stop of the timeframe for which the request is
issued.
7.10 TripInfoRequest
Table 5 defines the TripInfoRequest component, i.e. the component to transmit a request for trip information.

Table 5 — TripInfoRequest
Name Type Multiplicity Description
tripDetails Route 1 Description of the origin and destination of a trip with
potentially one or more vias.
time DateTime 1 Contains either Departure time at origin or Arrival time
at destination.
departure Boolean 1 True to indicate that time attribute contains Departure
time at origin, false to indicate that time attribute
contains Arrival time at destination.
numberOfResults IntUnTi 0.1 Attribute to control the number of trip results before/
after a point in time. May not be used when departure
time at origin AND arrival time at destination are set.
tripPreferences TripPreferences 0.1 User preferences to be considered in trip calculation.
7.11 Alert
Table 6 defines the Alert component, i.e. the component to transmit alert information, typically to be used
for the use case where major alerts are being sent by broadcast.
Table 6 — Alert
Name Type Multiplicity Description
alertFor AlertFor 1.* Describes the StopPlace, Line, Route, Area, etc. for which
the alert is issued.
alertEvent pts037:AlertEvent 1 Information on the actual event (e.g. closure of a line,
long delays of a line, cancellation of a stop).
alertCause pts038:AlertCause 0.1 Information on the cause of the event.
delay Duration 0.1 In the case of a delay, this component can be used to
inform about its duration (in min).
alertText LocalisedLongString 0.* Free text option to provide additional description of the
alert.
diversionAdvice pts039:AdviceType 0.1 Information on a potential diversion, e.g. to use an
alternative route.
Ordered components
diversionLink DiversionLink 0.1 Map-related location referencing information for a
potential diversion.
7.12 DiversionLink
The DiversionLink component contains map-related location referencing information for a potential
diversion.
7.13 StopEvent
The StopEvent component is used to transmit information for departure/arrival events (departure board or
timetable):
— either for one or more Lines at a stopPlace, or
— for one or more StopPlaces on a Line.
7.14 StopEventForPlace
Table 7 defines the StopEventForPlace component, i.e. the component to transmit information for departure/
arrival events departure board or timetable, for one or more Lines at a StopPlace.

Table 7 — StopEventForPlace
Name Type Multiplicity Description
callAtStops CallAtStopForPlace 1.* Provides information on departure/arrival events for
each relevant Line (a stop timetable).
stopPlace StopPlace 0.1 Describes a place comprising one or more locations
where vehicles may stop and where passengers may
board or leave vehicles or prepare their trip, and which
will usually have one or more well-known names.
7.15 StopEventForLine
Table 8 defines the StopEventForLine component, i.e. the component to transmit information for departure/
arrival events (departure board or timetable) for a Line or VehicleJourney.
Table 8 — StopEventForLine
Name Type Multiplicity Description
callAtStops CallAtStopForLine 1.* Provides information on departure/arrival events for
each relevant StopPlace (along the Line).
line LineIdentity 0.1 Description of a Line.
7.16 TripInfoResponse
Table 9 defines the TripInfoResponse component, i.e. the component to transmit a response to a
TripInfoRequest.
Table 9 — TripInfoResponse
Name Type Multiplicity Description
tripLegs TripLegStructure 1.* Describes one or more TripLegs for the trip.
A TripLeg being a single stage of a Trip that
is made without change of
ModeOfTransport or Line (i.e. between
each Transfer).
tripDescription LocalisedShortString 0.* Descriptive text for a Trip.
timeInformationForTrip TimeInfo 0.1 Describes scheduled and/or actual
departure and/or arrival times for a Trip.
8 PTS Datatypes
8.1 AlertFor
Table 10 defines the AlertFor datatype that describes the entity (StopPlace, Line, Route, PT service, Area
etc.) for which the alert is issued (one such entity per Alert message).
...