prEN 12896-6

SLOVENSKI STANDARD
01-februar-2026
Javni prevoz - Referenčni podatkovni model - 6. del: Informiranje potnikov
Public transport - Reference data model - Part 6: Passenger information
Öffentlicher Verkehr - Referenzdatenmodell - Teil 6: Information an Reisende
Transports publics - Modèle de données de référence - Partie 6 : Information des
usagers
Ta slovenski standard je istoveten z: prEN 12896-6
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

DRAFT
EUROPEAN STANDARD
NORME EUROPÉENNE
EUROPÄISCHE NORM
November 2025
ICS 35.240.60 Will supersede EN 12896-6:2019
English Version
Public transport - Reference data model - Part 6:
Passenger information
Transports publics - Modèle de données de référence - Öffentlicher Verkehr - Referenzdatenmodell - Teil 6:
Partie 6 : Information des usagers Information an Reisende
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee
CEN/TC 278.
If this draft becomes a European Standard, CEN members are bound to comply with the CEN/CENELEC Internal Regulations
which stipulate the conditions for giving this European Standard the status of a national standard without any alteration.

This draft European Standard was established by CEN in three official versions (English, French, German). A version in any other
language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC
Management Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.

Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2025 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 12896-6:2025 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
1 Scope . 4
2 Normative references . 4
3 Terms, definitions and abbreviations . 4
3.1 Terms and definitions . 4
3.2 Abbreviations . 8
4 General information . 9
5 Passenger information domain. 9
5.1 General overview . 9
5.2 Passenger information . 10
5.2.1 Provision of information . 10
5.2.2 Types of passenger information . 15
5.2.3 Timetable information . 18
5.2.4 Passenger trip planning . 22
5.2.5 Estimation of Trip Duration . 25
5.2.6 Information on fares . 28
5.2.7 Other information . 29
5.3 Use cases for the Passenger Information Model . 31
5.3.1 Purpose . 31
5.3.2 Business context . 31
5.3.3 Actors and use case types . 32
5.3.4 Use cases . 33
5.4 Public Transport Passenger Information – Conceptual MODEL . 34
5.4.1 General . 34
5.4.2 Trip description . 34
5.4.3 Trip description details . 37
5.4.4 Functional Requests for Passenger Information . 48
5.4.5 Mapping with Open API for Distributed Journey Planning and to SIRI . 82
(normative) Data dictionary . 84
(informative) Data model evolution . 124
(informative) Significant technical changes between this document and the
previous edition . 127
Bibliography . 128

European foreword
This document (prEN 12896-6:2025) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, the secretariat of which is held by NEN.
This document is currently submitted to the CEN Enquiry.
This document will supersede EN 12896-6:2019.
Annex C provides details of the significant technical changes between this document and
EN 12896-6:2019.
This document is part of the European Standard series EN 12896, known as “Transmodel”. This is a series
of documents that comprises the following parts:
— EN 12896-1, Public transport - Reference data model - Part 1: Common concepts
— EN 12896-2, Public transport - Reference data model - Part 2: Public transport network
— EN 12896-3, Public transport - Reference data model - Part 3: Timing information and vehicle
scheduling
— EN 12896-4, Public transport - Reference data model - Part 4: Operations monitoring and control
— EN 12896-5, Public transport - Reference data model - Part 5: Fare management
— EN 12896-6, Public transport - Reference Data model - Part 6: Passenger information
— EN 12896-7, Public transport - Reference data model - Part 7: Driver management
— EN 12896-8, Public transport - Reference data model - Part 8: Management information and statistics
— EN 12896-10, Public transport – Reference data model – Part 10: Alternative modes
Together these documents create Transmodel version 6.2 and thus replace Transmodel V6.0.
In addition to the nine normative Parts of this European Standard, a Technical Report (Public Transport
– Reference Data Model – Informative Documentation) was published in 2016 under the reference
CEN/TR 12896-9. It provides additional information to help those implementing projects involving the
use of Transmodel. It is intended that this Technical Report will be extended and republished as soon as
all the normative parts are revised.
The split into several documents is intended to ease the task of users interested in particular functional
domains. It corresponds to the modularisation of Transmodel into functionally related parts, each made
up of distinct UML packages and subpackages that describe a particular aspect of public transport. The
NeTEx UML model follows the same modularisation, allowing a direct mapping from the conceptual
model to the implementation.
For information on the conventions, methodology and notations for conceptual modelling, for a clear
overview to help understand the core principles, structure and purpose of Transmodel, and for
information on the Functional domains and Modes of Operation, refer to EN 12896-1.
1 Scope
The document incorporates the following main data packages:
— Trip Description;
— Passenger Information Queries.
It is composed of the following parts:
— main document representing the data model for the concepts shared by the different fare domains
covered by Transmodel (normative);
— Annex A, containing the data dictionary and attribute tables, i.e. the list of all the concepts presented
in the main document together with the definitions (normative);
— Annex B presenting the model evolution (informative).
— Annex C, providing details of the significant technical changes between this document and
EN 12896-6:2019 (informative).
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.
EN 12896-1:2016, Public transport — Reference data model — Part 1: Common concepts
3 Terms, definitions and abbreviations
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in EN 12896-1 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:

— ISO Online browsing platform: available at http://www.iso.org/obp/
— IEC Electropedia: available at http://www.electropedia.org/
3.1.1
API
application programming interface, usually used to exchange public transportation data between
passenger information services
3.1.2
attribute
property of an entity
3.1.3
conceptual data model
description of a real-world domain in terms of entities, relationships and attributes, in an implementation
independent manner, which should provide a structure on which the rest of the development of an
application system can be based
3.1.4
conceptual level
conceptual data model in the context of data modelling
3.1.5
database
collection of data; often used in the sense of the physical implementation of a data model
3.1.6
data domain
data structure (in this document, a part of the reference data model for public transport) made up of data
related to each other, through the fact that there is a functional area or group of functions using this data
set as a whole
3.1.7
data model
description of a real-world domain in terms of data and relationships
3.1.8
entity
object (data) that has its own existence (as opposed to an attribute)
3.1.9
fare management
all activities related to the collection of money from passengers
3.1.10
function
activity or, in this document, sub-activity of a functional area
3.1.11
functional area
arbitrarily defined set of activities used, in this document, to define the objectives and limits of the data
model
3.1.12
geographical data files
GDF
standard defining the contents and format of geographical data files, used for the description,
classification and encoding of road networks and road environment features
3.1.13
GDF database
database containing geographical information on the road network in a particular application area,
possibly including information on the location of public transport points, links and services (routes)
3.1.14
interoperability
ability of (sub)systems to interact with other (sub)systems according to a set of predefined rules
(interface)
3.1.15
logical data model
data design that takes into account the type of database to be used, but does not consider means of
utilization of space or access
3.1.16
logical denormalized model
relational data model that is not fully normalized, i.e. does not completely follow the normalization rules
and thus may be redundant
3.1.17
logical level
logical data model in the context of data modelling
3.1.18
management information
all activities allowing the company management to collect the information necessary to meet problem-
solving needs
3.1.19
object-oriented data model
data structure expressed according to principles that allow for a direct implementation as an object-
oriented database, where information is represented in form of objects, i.e. respecting the principle of
encapsulation meaning in particular that each data is accessed or modified through operations (methods)
belonging to it
3.1.20
operations monitoring and control
real-time control
all activities related to the transportation process, i.e. real-time functions related to the driving and
transportation of passengers according to given instructions, including the monitoring of the driving
process and its control in case of deviations, as well as all activities that support the driving process
(traffic light priority, track switching, bay selection, advance/delay advice, etc.)
Note 1 to entry: Such functions are often assisted by computer-aided tools, known as Automated Vehicle
Monitoring (AVM).
3.1.21
planned and actual services
public transportation services are planned in advance, but can be changed before or during the actual
service is in operation
3.1.22
passenger information
all activities related to informing the users either about the planned or about the actual transportation
services
3.1.23
personnel disposition
all activities related to the mid-term and short-term management of drivers
3.1.24
relational data model
type of logical data model giving the information as series of tables (relations) and attributes
3.1.25
tactical planning
scheduling
all activities related to the tactical planning of transportation, split into vehicle scheduling, driver
scheduling, rostering
Note 1 to entry: The following terms specific to the passenger information domain are used. Terms which are
also data entity names are defined in the data dictionary in Annex A and are not repeated here.
3.1.26
distributed journey planner
trip planner that computes its results by delegating planning to other systems for those parts of the trip
covering specific areas or modes
3.1.27
exchange point
agreed handover point for linking distributed journey planning systems
3.1.28
observer
someone who looks at Passenger Information
3.1.29
repeated trip
same trip made over the same route multiple times, for example to commute to work or school
3.1.30
single journey
planned movement of a vehicle from a start point to an end point in a journey on a specified route
3.1.31
single trip
trip that goes direct from an origin to a destination without breaks in the journey
3.1.32
text to speech
automatic generation of speech from a textual representation
3.1.33
trip repair
activity of looking for travel advice regarding a specific trip in order to recover from a disruption to
services
3.1.34
travel
sequence of passenger trips
3.1.35
ride
passenger performing a trip while riding any public transport vehicle
3.1.36
connection
passenger movement while transferring from one to another public transport service
3.1.37
monitoring
recording of a public transport operational data, usually in real-time, for operational statistics and better
passenger experience
3.1.38
wait time
time duration a vehicle waits for passengers at a stop point
3.1.39
run time
travel duration between two stop points
3.1.40
interchange time
time for a passenger to transfer between two public transport services
3.1.41
call
real-time notice for a passenger that individual vehicle is arriving or departing a stop point
3.2 Abbreviations
ABT Account Based Ticketing
API Application Program Interface
AVM Automated Vehicle Monitoring
DJP Distributed Journey Planner
FQ Fare Query
GIS Geographic Information System
GTFS General (sometimes “Google”) Transit Feed Specification
IFM Interoperable Fare Management
FM Fare Management
IFOPT Identification of Fixed Objects in Public Transport
ISO International Organization for Standardization
IT Information Technology
NeTEx Network and Timetable Exchange
NFC Near Field Communication
OADJP Open API for Distributed Journey Planner
PI Passenger Information
PT Public Transport
QR Query Request
TD Trip Description
TTS Text to Speech
SIRI Service Interface for Real-time Information
UML Unified Modelling Language
URL Universal Resource Locator
WGS World Geodetic Standard
4 General information
The following standards are based on the Transmodel conceptual data model for public transport domain
to provide a harmonized, interoperable, and consistent approach for public transport data, service
interfaces, and journey planning across Europe:
— EN 15531 series [10] to [16] – Service interfaces for real-time public transport operations.
— CEN/TS 16614 series (NeTEx) [17] to [22] – Network and timetable data exchange, including
passenger information and accessibility.
— CEN/TS 17118 [23] – Open API for distributed journey planning.
5 Passenger information domain
5.1 General overview
The passenger information part of Transmodel describes the data which are presented to passengers by
applications that can interact with passengers. This covers both data on the planned and actual services,
but also data resulting from the operations monitoring and control processes which may result in service
modifications.
Classically, passenger information was published as printed timetables or shown on electromechanical
boards in stations. Earlier generations of electronic displays were typically available only in stations
using localized systems.
Modern passenger information systems are generally provided through service interfaces that access
online data and may be used anywhere with internet enabled devices such as mobile phones.
Applications providing data to passengers typically use an optimized API to fetch the data from a back-
end system. The standard does not aim to define an actual API for such services, but rather to provide a
mapping that shows how the data elements of the reference model relate to the different possible types
of passenger information service.
Two other European Standards provide concrete API’s:
— SIRI (Server Interface for Real Time Information - EN 15531-1, EN 15531-2, EN 15531-3,
CEN/TS 15531-4 and CEN/TS 15531-5), which provides real-time status information; and
— OADJP (Open API for Distributed Journey Planning - CEN/TS 17118) describes stop place finding, trip
planning, schedule, and related APIs, and thus enables linking of distributed journey planning
services.
All of the following are relevant for delivering passenger information:
— passenger information facilities and their utilization for passenger queries;
— detailed descriptions of all the conceptual components of a passenger trip, as possibly needed by an
interactive passenger information system when answering a PI REQUEST;
— basic definitions of run times and wait times needed to calculate trip duration;
— planned, predicted, and actual passing times of journeys at individual stops;
— service modifications decided by the schedulers or the control staff, resulting in changes of the
vehicle journeys and blocks, compared to the original plan;
— fare structures, fare products and prices along with distribution and fulfilment options;
— vehicle types, deck plans and seating layouts for vehicles.
Most types of passenger information make use of many underlying elements from the topological
network definition, such as the lines and journeys which form the service offer, the definition of run and
wait times, and other fundamental definitions. Geographical information may possibly be provided in
some cases if corresponding application systems are available, for example, to show the route of a bus.
Specific types of passenger queries may be related to fares, where the relevant information elements are
included in the fare collection sub-model of the reference data model.
Thus, the information basis for passenger information systems is widely spread over the whole reference
data model, and the genuine passenger information data model covers only those elements which cannot
be derived from, and are not explicitly included in, other parts of the model. It is also useful to indicate
how such data may be assembled into specific services corresponding to commonly made passenger
queries.
5.2 Passenger information
5.2.1 Provision of information
5.2.1.1 General
In early generations of information systems used for public transport, the passenger information
functions were often designed as sub-functions of other systems. For instance, printed timetables were
simply an end product of the scheduling process, dynamic displays at stop points were incorporated in
monitoring and control systems, etc. Today, data likely to be used for passenger information functions
are typically stored into specific databases, independent of the operation and control systems. The
required data are then made available to information applications interfaced with such databases, which
make appropriate requests to collect the data. This approach gives the necessary scalability and security
needed to support mass consumer applications without compromising the operation of the transport
network.
It is therefore necessary to distinguish the data handled by passenger information functions from the
management of the operation and control systems and the distribution of information to in-station and
onboard devices. Besides all the data forming the basis for passenger information (e.g. network
description, planned schedules, monitored passing times, etc.), some data structures are necessary to
organize the distribution of this information. The present part describes important concepts referring to
the ways of delivering such information to the customers.
5.2.1.2 Passenger information types
Information for passengers can be communicated to the passengers using a large variety of equipment
and media, such as:
— printed material such as leaflets at stops, information booklets, etc.;
— passive terminals, such as displays at stop points or onboard vehicles, delivering information on
planned or actual service, e.g. information on the arrival or departure times;
— interactive terminals, delivering information on request regarding planned or actual service, such as
internet terminals, personal mobile devices, an information desk terminal operated by the staff, etc.
Data for the last two will be obtained from servers that aggregate and distribute data.
In spite of this variety of equipment, media and techniques, some common data features exist to describe
the characteristics of the provided information. For instance, the location of a display (e.g. at a stop point)
or the list of routes about which information is provided does not depend on the type of equipment that
is used to present the information.
5.2.1.3 Passenger information equipment
This subsection summarizes the delivery elements for in-station displays, found in EN 12896-2.
Delivery of passenger information through any form of device is described by the entity PASSENGER
INFORMATION EQUIPMENT, a generic class of information device, which can be classified by the entity
TYPE OF PASSENGER INFORMATION EQUIPMENT according to the common functional capabilities. It
may be passive (for example a printed timetable), active (for example a display), or interactive (for
example a kiosk terminal supporting trip planning).
PASSENGER INFORMATION EQUIPMENT may be located at a POINT in the network. Such a POINT will
often be at a STOP POINT. The STOP PLACE model can be used to specify the exact locations of displays
within a stop or interchange.
PASSENGER INFORMATION EQUIPMENT may also be located at a place that is not on the PT network
(e.g. at a central place in the city, in a shopping centre, or an office lobby); here, the SITE model can be
used to locate displays outside of stations.
Onboard terminals (e.g. dynamic displays) may also be described as PASSENGER INFORMATION
EQUIPMENT, located using an ACTUAL VEHICLE EQUIPMENT.
At-stop and onboard systems will show a subset of data relevant to the transport available at their
location. A DISPLAY ASSIGNMENT to a LOGICAL DISPLAY associated with the PASSENGER
INFORMATION EQUIPMENT is used to indicate which specific services (e.g. LINES, or services following
a specific JOURNEY PATTERN) should be included.
Figure 1 — Passenger Information Display
5.2.1.4 Internet based information services
Data may also be distributed to customers on their own devices using web and mobile applications, either
directly or via an intermediary. These may be specifically orientated to PT transport or may include PT
data among other data. The selection of relevant types of data can be regarded as a passenger information
query composed of a pair of PI REQUEST and PI DELIVERY.
5.2.1.5 Transactions and queries
Operators that provide information for interactive services will often log the parameters of transactions
made against their services. For instance, the time and the duration of a request and response may be
stored along with the locations sought, allowing statistical analysis, and in some cases also for invoicing.
In interactive systems the results of one query may be used to obtain input for another; for example,
having found a possible trip a customer may then enquire as to the available fares. The entity PI REQUEST
describes any elementary request, being part of a PI DELIVERY.
Figure 2 — PI Common Query Model
Each PI REQUEST refers to a precise topic and is therefore classified by the entity TYPE OF REQUEST. The
main types, modelled as sub-types of PI REQUEST, are:
— ORGANISATION REQUEST, a request for information about an organization, for example service
operator;
— EXCHANGE POINTS REQUEST, a request between journey planning systems for information about
POINTs that can be used in distributed trip planning as common boundary SCHEDULED STOP POINTs
between adjacent regions of separate data coverage;
— SITUATION REQUEST, a request to obtain information about extraordinary situations (events)
related to a LINE, POINT, or MODE;
— VEHICLE TYPE REQUEST, a request for a specific vehicle type belonging to TRANSPORT
ORGANISATION operating FLEET with VEHICLE MODELs;
— MOBILITY SERVICE REQUEST, a request for information about alternative mode transport service
available over a widespread area, for example, car-pooling, rental, etc. The service may be accessible
at designated SITEs and operated by a TRANSPORT ORGANISATION;
— SINGLE JOURNEY REQUEST, a request for a trip proposal of possible SINGLE JOURNEYs, according to
a specified SINGLE JOURNEY TRIP REQUEST POLICY and constrained by an OPERATING DAY;
— SCHEDULE REQUEST, for which a passenger asks for schedules (public timetables), arrival,
departure or passing times on certain lines and stop points;
— LOCATION REQUEST, for which a passenger asks for details of a location;
— TRIP REQUEST, a request for which a passenger asks for a journey plan between an origin and a
destination to follow on the public transport network;
— SERVICE JOURNEY REQUEST, a request for which a passenger asks for details about a specific
journey;
— STOP EVENT REQUEST, a request for which a passenger asks about arrivals and departures at a
specific stop;
— FARE PRODUCT REQUEST, a request for information on the fare structure, or on the amount of fare
for a particular trip; this may be either for a single trip (SINGLE TRIP FARE REQUEST) or repeated
travel (REPEATED TRIP FARE REQUEST) on a route;
— TRIP FARE REQUEST, a request for fares with filter for parameters like traveller characteristics (age,
number of travellers, etc.). Variations of the request are possible for REPEATED TRIP FARE REQUEST
(best fare products to use for repeated similar trips) and SINGLE TRIP FARE REQUEST (single trip or
return trip);
— STOP FARE REQUEST, a request to find fares products for a stop (SCHEDULED STOP POINT) and
constrained by a TARIFF ZONE.
The methods of selecting a trip proposal in response to a TRIP REQUEST can use a variety of selection
and optimization criteria, which can be expressed using a TRIP REQUEST FILTER and a TRIP REQUEST
POLICY on the query. For instance:
— preference for a particular OPERATOR;
— preference for one transport mode (bus, metro…);
— whether to select a journey by arrival or departure time;
— maximum duration or distance of the whole trip;
— maximum walking distance;
— maximum access leg time;
— maximum connection leg time;
— maximum number of interchanges;
— maximum amount of fare;
— maximum number of travellers;
— etc.
5.2.1.6 Push services
Some delivery systems use a publish/subscribe or request/response interaction to deliver data. The
client subscribes to receive particular data, and this is then sent to them at regular intervals. For example,
the SIRI framework allows for the same delivery types to be fetched both by direct request/response and
by subscription. The content of a publish/subscribe service can also be described by a PI REQUEST and
PI DELIVERY. Push, or notification, services are suitable for particular types of data where there is a
suitable entity to which to subscribe, for instance arrivals at a given stop or disruptions to a given line or
service.
5.2.2 Types of passenger information
5.2.2.1 Spatial information
5.2.2.1.1 General
The reference model includes spatial data suitable for providing different sorts of map visualizations of
routes and fare zones. These may include both visualization of specific PASSENGER TRIPs and general-
purpose visualization of a line or the whole network.
5.2.2.1.2 Network maps
The network is often represented on a background map, which describes the area served by public
transport (e.g. city map). It is also common to show a projection of various parts of a PASSENGER TRIP
on a map. The map with its layers or spatial features is typically provided separately by a map server that
integrates and renders geographical information system (GIS) data.
To display the PT layer data onto the map layer a projection as a sequence of spatial coordinates has to
be provided to the application. This can be done, for instance, by LINK PROJECTION (see EN 12896-2) of
the ROUTE LINKs on INFRASTRUCTURE LINKs. ROUTE LINKs will in turn bear by projection the other
required information (e.g. STOP POINTs). Another solution is to project only the ROUTE POINTs (and
possibly some other POINTs) on the infrastructure network, the shape of the ROUTE LINKs between such
POINTs being given by LINE SHAPEs, specific to this map representation layer.
As such a mapping of information may be represented on various scales, the required level of detail may
be different, depending on the chosen scale. An important station may be represented, on a small-scale
map, by a point (or an icon), whereas the different STOP POINTs will be represented on medium scale
maps, or the details of platforms will be shown on a large-scale map. This will require other types of
projection, particularly the COMPLEX FEATURE PROJECTION targeting a POINT.
A very simple representation of a PT network consists in drawing a schematic description of each
SERVICE PATTERN on a straight line, with all STOP POINTs marked on that line at the same distance from
each other (“thermometer”). This is a purely topological representation of the basic definition of a
JOURNEY PATTERN (or a SERVICE PATTERN) as an ordered sequence of points.
Some additional information may be added to this simple representation of a SERVICE PATTERN. The
LINEs (or ROUTEs or SERVICE PATTERNs) with which an interchange is proposed at particular STOP
POINTs may be indicated. This will require a request on either:
— other SERVICE PATTERNs serving the represented STOP POINTs, or those related to them by a
CONNECTION link; or
— other SERVICE PATTERNs related to the represented one by any SERVICE JOURNEY PATTERN
INTERCHANGE.
The FARE SECTIONs (see EN 12896-2) may also be represented on this schema. This will require a LINK
PROJECTION of each FARE SECTION on either the JOURNEY PATTERN or the ROUTE it covers.
The actual distances between STOP POINTs (e.g. stored as attributes of SERVICE LINKs) may be
proportionally represented on the schema, instead of equal distances.
Such representations are useful for showing a single service in a given direction, as for a passenger trip.
Where multiple service patterns or services need to be shown as a line, then a simple projection, while
useful for some trip planning and management purposes, is not generally sufficiently detailed. Typically,
the two ROUTEs of opposite DIRECTIONs will be drawn, including every minor variant.
If the LINE includes more than two ROUTEs, when there are diverging branches, other linear forms are
necessary. A SCHEMATIC MAP (see EN 12896-1) can be used to provide a coloured line-based
representation, including branches. Every feature on the map (SCHEDULE STOP POINTS, TARIFF ZONES,
LINE SECTIONS, etc.) is linked to an underlying entity to enable direct interaction by the user to drill
down to get further details.
5.2.2.2 Line and Destination Information
Most of the lines will have an advertised destination, generally known by the passengers and displayed
on the vehicle (for example, on the head sign). This destination will also be used in most of the information
material.
This information is not necessarily the name of the final destination (e.g. the name of the last POINT IN
JOURNEY PATTERN). Any exception may be described by the entity DESTINATION DISPLAY.
A DESTINATION DISPLAY is advertised for one or several JOURNEY PATTERNs (if several, they are often
operated on the same ROUTE or LINE). The DESTINATION DISPLAY may change along the route and so
be shown differently at different stops.
This entity may also be used for online modification of the destination information. With some
modifications due to control actions, it may be more useful to display other indications on the bus (e.g.
“shortened route”, “depot”, “out of service”, etc.). This is possible thanks to the unique identifier (an
attribute ‘id’) of the entity, which could be completed by a VALIDITY CONDITION (e.g. a simple time limit).
The information on the final destination will usually be coupled with a public “line number”. According
to local usage, such a number may be attached to a LINE (or a GROUP OF LINES) or, more precisely, to
each ROUTE or JOURNEY PATTERN. In the case of diverging branches, for instance, the number may be
different for each branch (i.e. to each ROUTE), even if they belong to the same LINE. However, two
ROUTEs following the same path in opposite DIRECTIONs usually bear the same number. To cope with
this variety of practices, an attribute ‘name’ is attached to each of those entities.
5.2.2.3 Footnotes and other Notices
For passenger information (or sometimes driver information) purposes, it is often useful to attach
remarks to various parts of the public transport supply (a point, a line, a section, etc.). For instance, the
fact that a shortened journey pattern is used exceptionally may be emphasized. Such remarks are usually
printed as footnotes on public timetables at stops, timetable booklets or, for driver information, on driver
cards.
The entity NOTICE describes such remarks. It may concern a whole LINE, or a GROUP OF POINTs (e.g.
one or several STOP AREAs). See Part1 for a full definition.
More frequently, a NOTICE will be assigned to a JOURNEY PATTERN, a COMMON SECTION, or even a
specific VEHICLE JOURNEY. In such cases, the same NOTICE will be often assigned to several objects (e.g.
to several consecutive VEHICLE JOURNEYs).
Moreover, the validity of a NOTICE, for instance on a JOURNEY PATTERN or a COMMON SECTION, may
be restricted from a POINT IN JOURNEY PATTERN, or to another POINT IN JOURNEY PATTERN.
The entity NOTICE ASSIGNMENT describes these spatial or operational assignments.
A NOTICE ASSIGNMENT may be subject to various other conditions of validity (such as DAY TYPE, TIME
BAND), represented by VALIDITY CONDITIONs.
Figure 3 — Notices and footnotes
A NOTICE is different from a DESTINATION DISPLAY. The first is designed to specify some characteristics
of a journey or a journey pattern, likely to evolve. They are, in most cases, printed in leaflets but may also
be queried by dynamic trip planning tools. A DESTINATION DISPLAY corresponds to stable information
attached to a JOURNEY PATTERN, for instance the destination announcement displayed on bus head signs
or other on-board equipment. A single announcement is prepared with DISPLAY ASSIGNMENT coupling
data about a SCHEDULED STOP POINT, a JOURNEY PATTERN or a LINE and presented on a PASSENGER
INFORMATION EQUIPMENT (a public transport information piece of equipment, for example an
information desk terminal or printed material (leaflets displayed at stops, booklets, etc.).
Figure 4 — Passenger information display
5.2.3 Timetable information
5.2.3.1 General
The basis for almost all passenger information functions is a ‘timetable’. A timetable is an end product of
the scheduling process. It gives the scheduled passing times (in general, arrival and departure times) for
all VEHICLE JOURNEYs, on all STOP POINTs, for one or possibly several DAY TYPEs.
The timetable information may be published in many different forms. A physical way of providing
timetable information is the booklet with the complete timetable for a certain operator or area. At stops,
a selection from the complete timetable is often displayed, for instance the departure times of all lines
that pass by the stop. An electronic display may provide variable timetable information. The answer to a
SCHEDULE REQUEST will be composed of a subset of timetable data, etc.
The displayed times may refer to all departures times from a certain stop point, or all departure times at
any stop point served by a line, etc. A timetable may provide information on one or, more frequently,
several day types, for a certain calendar period.
Although the ‘timetable’ is a very well-known and important concept, it is not described in the data model
as an inherent entity, because it contains only derived data; a TIMETABLE FRAME represents such an
assembly and can be used to organize journeys into named sets with a particular validity that can be
rendered in tabular form. The GROUP OF SERVICE element can be used to indicate subgroupings for the
purposes of presentation; for example, there might be separate groups for outbound and inbound
journeys of a route, or for weekdays and weekends. The process of computing timetable information (in
particular the passing times) is described in detail in EN 12896-3.
5.2.3.2 Passing times
Although any theoretical passing time at a point may be derived from the underlying scheduling
information, this data will, in real implementations, often be pre-calculated and stored. For instance, it
would be a waste of time to re-compute passing times for each occurring SCHEDULE REQUEST, or for
each time an AVM system needs to position a PT vehicle against its schedule.
Moreover, information exchanges between a PT company information system and the outside world are
increasingly prevalent. Systems such as route guidance systems for private cars or park and ride systems
request data about the planned and actual arrival and departure times. In places where several PT
companies operate, passenger information may be provided by an authority, without any access to the
detailed scheduling data of each operator. In such exchanges, the concept of timetable is often used
(although almost never accurately specified) and arrival and departure times at points are the core
information.
These theoretical passing times are likely to evolve during an operating day, producing target passing
times. In addition, forecasts may be made on estimated passing times and actual observed passing times
may be recorded by a monitoring system.
Finally, the concept of passing time may be extended to support specific properties attached to the period
spent at the stop
...