prEN 12896-2

SLOVENSKI STANDARD
01-februar-2026
Javni prevoz - Referenčni podatkovni model - 2. del: Omrežje javnega prevoza
Public transport - Reference data model - Part 2: Public transport network
Öffentlicher Verkehr - Datenreferenzmodell - Teil 2: Netzwerk des öffentlichen Verkehrs
Transports publics - Modèle de données de référence - Partie 2: Réseau de transports
en commun
Ta slovenski standard je istoveten z: prEN 12896-2
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-2:2016
English Version
Public transport - Reference data model - Part 2: Public
transport network
Transports publics - Modèle de données de référence - Öffentlicher Verkehr - Datenreferenzmodell - Teil 2:
Partie 2: Réseau de transports en commun Netzwerk des öffentlichen Verkehrs
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-2:2025 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
1 Scope . 5
2 Normative references . 5
3 Terms, definitions and abbreviations . 5
3.1 Terms and definitions . 5
3.2 Abbreviations . 6
4 General information . 7
5 Network topology domain . 7
5.1 Introduction . 7
5.2 Model and document structure . 7
5.3 Network description model . 8
5.3.1 Model overview . 8
5.3.2 Infrastructure network. 8
5.3.3 Network restriction . 12
5.3.4 Lines and routes . 15
5.3.5 Line Networks . 20
5.3.6 Flexible network . 23
5.3.7 Activation . 28
5.3.8 Vehicle and crew point. 29
5.4 Fixed object model . 31
5.4.1 Model overview . 31
5.4.2 Site . 32
5.4.3 Stop place . 36
5.4.4 Flexible stop place . 45
5.4.5 Point of interest . 47
5.4.6 Parking . 51
5.4.7 Taxi place . 52
5.4.8 Equipment description . 53
5.4.9 Path links and navigation paths . 67
5.4.10 Accessibility coverage . 77
5.4.11 Vehicle stopping . 79
5.4.12 Vehicle recharging point assignment . 79
5.5 Tactical planning components model . 80
5.5.1 Model overview . 80
5.5.2 Journey pattern . 81
5.5.3 Timing pattern . 85
5.5.4 Service connection . 89
5.5.5 Service pattern . 91
5.5.6 Common section . 97
5.5.7 Routing constraints . 98
5.5.8 Time demand type . 100
5.5.9 Passenger stop assignment . 100
5.5.10 Navigation path assignment. 104
5.5.11 Passenger information display assignment . 105
5.5.12 General. 105
5.6 Explicit frames . 106
5.6.1 General . 106
5.6.2 Infrastructure frame . 107
5.6.3 Service frame. 107
5.6.4 Site frame . 108
Annex A (normative) Data dictionary . 110
Annex B (informative) Data model evolution . 183
Annex C (informative) Significant technical changes between this document and the previous
edition . 185
Bibliography . 186

European foreword
This document (prEN 12896-2: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-2:2016.
Annex C provides details of the significant technical changes between this document and
EN 12896-2:2016.
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
This document incorporates the following main data packages:
— Network Description;
— Fixed Object;
— Tactical Planning Components;
— Explicit Frame.
It is composed of the following parts:
— main document representing the data model for the concepts shared by the different 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 their definitions (normative);
— Annex B presenting the model evolution (informative).
— Annex C, providing details of the significant technical changes between this document and
EN 12896-2:2016 (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, 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 https://www.iso.org/obp/
— IEC Electropedia: available at https://www.electropedia.org/
3.1.1
accessibility
characteristic of a public transport asset (equipment or location) describing the ability to be physically
accessed with respect to passengers with various types of mobility impairment
3.1.2
graph
set of vertices and a set of edges (also called arcs)
Note 1 to entry: Transmodel defines the public transport network as a graph where the vertices are points and
edges are links between the points.
3.1.3
navigation path
route that can be used by pedestrians, wheelchairs, cyclists, etc. (i.e. passengers who are not in a transport
vehicle) to access or transfer between two places / or transport access points
Note 1 to entry: In Transmodel, a NAVIGATION PATH made up of discrete PATH LINKs.
3.1.4
run time
time taken for a vehicle to go between two points
Note 1 to entry: In Transmodel a run time may be specified for the individual SERVICE LINK between two stops
and for the whole journey pattern.
3.1.5
stop
dedicated place where a vehicle may stop in order to allow passengers to get on and off
3.2 Abbreviations
API Application Programming Interface
AVM Automatic Vehicle Monitoring
GIS Geographical Information System
GPS Global Positioning System
HTTP Hypertext Transfer Protocol
IFOPT Identification of Fixed Objects in Public Transport
ISO International Organization for Standardization
IT Information Technology
NeTEx Network and Timetable Exchange
PT Public Transport
PTO Public Transport Operator
OJP Open API for Distributed Journey Planning
OpRa Operating Raw Data and statistics exchange
SIRI Service Interface for Real-time Information
TM Transmodel
UML Unified Modelling Language
URI Uniform Resource Identifier
URL Universal Resource Locator
VDV Verband Deutscher Verkehrsunternehmen (Germany)
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 Network topology domain
5.1 Introduction
The reference data model includes entity definitions for different types of points and links as the building
elements of the topological network. Stop points, timing points and route points, for instance, reflect the
different roles one point may have in the network definition: whether it is used for the definition of
(topological or geographical) routes, as a point served by vehicles when operating on a line, or as a
location against which timing information like departure, passing, or wait times are stored in order to
construct the timetables.
The line network is the fundamental infrastructure for the service offer, to be provided in the form of
vehicle journeys which passengers may use for their trips. The main entities describing the line network
in the reference data model are the line, the route and the journey pattern, which refer to the concepts of
an identified service offer to the public, the possible variants of itineraries vehicles would follow when
serving the line, and the (possibly different) successions of stop points served by the vehicles when
operating on the route.
The model delivers also a detailed geographical representation of stopping locations and related
concepts, such as equipment, access and navigation paths taken from the former IFOPT standard, and
now within the NeTEx standard, including the description of:
— the stops and stations at which transport is accessed together with accessibility characteristics;
— the points of interest from/to which passengers are travelling;
— the detailed navigation paths between the various locations and associated constraints;
— the equipment and services relevant for public transport actors;
— the parking locations relative to both stops and points of interest.
5.2 Model and document structure
The Network Topology models split into the following main sub-models.
a) Network description model (ND);
b) Fixed object model (FO);
c) Tactical planning components model (TP);
d) Explicit frame model (NT)
Network description model: description of infrastructure elements (different types of points and links)
and paths (routes and lines) dedicated to (regular and flexible) public transport operation. This
description may be considered as a macroscopic view of the topological aspects of the network.
Fixed object model: description of geographical aspects of fixed elements such as stopping locations, or
points of interest. It represents, in particular, a detailed view of the stopping places, and their associated
elements, such as services or equipment. It also includes concepts enabling the representation of the
navigation through the stops or their access.
Tactical planning components model: description of basic concepts related to the description of the
work patterns of public transport vehicles, such as journey patterns and service patterns, which are
useful for planning transport and some related aspects. This part describes the space-related aspects of
the vehicle services, whereas the time-related aspects (vehicle journeys, run times, etc.) are described in
EN 12896-3, Public transport - Reference data model - Part 3: Timing Information and Vehicle Scheduling.
Explicit frames model: specific sets of “explicit” VERSION FRAMES that specify sets of data elements
appropriate for a particular use case or set of related use cases.
The present document is structured according to the model structure.
5.3 Network description model
5.3.1 Model overview
The network description model describes the basic physical network for transport and is itself divided
into several separate sub-models covering different aspects of the network:
— Network infrastructure model:
— Infrastructure network;
— Network restriction;
— Route model;
— Route instruction model;
— Line model;
— Line network model;
— Flexible network model;
— Activation model;
— Vehicle and crew point model.
For ease of understanding, the sub-models are presented one at a time, each describing only a small set
of related concepts.
The sub-models depend on several general framework models (e.g. generic point and link model, notice
model, etc.) described in EN 12896-1, Public transport - Reference data model - Part 1: Common concepts.
5.3.2 Infrastructure network
5.3.2.1 General
The infrastructure network model describes the physical network on which the transport services run.
The closely related network restriction model describes the physical restrictions on its use. This part does
not concern the service aspects, i.e. vehicle work patterns are described separately (e.g. by TIMING
PATTERNs, JOURNEY PATTERNs, SERVICE PATTERNs).
5.3.2.2 Infrastructure network – Conceptual model
5.3.2.2.1 General
Figure 3 presents the INFRASTRUCTURE NETWORK conceptual model, i.e. describes the main
components of the physical path network (rail, roads, etc.).
This modelling of the infrastructure is, however, very basic and simple and is used here to represent
specific operational constraints (restrictions) for public transport operation resulting from the
characteristics of the INFRASTRUCTURE POINTs and LINKs and of VEHICLE TYPEs. The spatial detailed
organization of the infrastructure itself is described by other models (GDF, Inspire, etc.) and the data are
usually provided by GIS datasets.

Figure 1 — Infrastructure network – Conceptual model
5.3.2.2.2 Infrastructure points and links
The PT network is described in Transmodel by POINTs and LINKs. This means that separate descriptions
of a network either as a set of points or a set of links, or both, are possible and may be kept separately (cf.
Generic POINT and LINK – conceptual model in EN 12896-1, Public transport - Reference data model -
Part 1: Common concepts).
The approach of representing the network in terms of generic POINTs and/or LINKs and their
specializations (here, INFRASTRUCTURE POINT, INFRASTRUCTURE LINK) is used extensively in
Transmodel to describe distinct functional layers as separate graphs.
5.3.2.2.3 Infrastructure network and functional aspects of the network
In Transmodel terms, the infrastructure network builds a LAYER (cf. Layer – Conceptual Model in EN
12896-1, Public transport - Reference data model - Part 1: Common concepts). A LAYER is a user-defined
GROUP OF ENTITies, specified for a particular functional purpose, associating data referring to a
particular LOCATING SYSTEM.
Examples of LAYERS (described through concepts introduced later in this document) are: timing pattern
layer (defined through TIMING POINTs and TIMING LINKs), and service pattern layer (defined through
SCHEDULED STOP POINTs and SERVICE LINKs). Transmodel defines a correspondence mechanism
between LAYERS, called PROJECTION (cf. section Generic Projection in EN 12896-1, Public transport -
Reference data model - Part 1: Common concepts). It should be noted that the uniqueness of a LOCATING
SYSTEM within a LAYER is an important parameter, in particular for the coherence of distances.
Each separate LAYER reflects different concerns and is deliberately kept independent of other LAYERs.
Thus, for example the modelling of the objects necessary to describe the work patterns of vehicles
(JOURNEY PATTERNs) is represented separately in the LAYERs describing the operational planning and
not in the infrastructure layer.
The different functional LAYERs may be projected (using the Transmodel projection mechanism) onto
the infrastructure layer to represent how they are related to the physical paths represented by sequences
of INFRASTRUCTURE LINKs.
Figure 2 — Examples of layers – Different layers according to the transport mode

Figure 3 — Example of layers – Different layers according to an operational need
Any POINT necessary to describe the infrastructure network is defined as an INFRASTRUCTURE POINT,
which is a generic entity including several specializations (e.g. ROAD JUNCTION, RAILWAY JUNCTION).
Similarly, the necessary LINKs between the POINTs are defined as INFRASTRUCTURE LINKs (e.g. ROAD
ELEMENT, RAILWAY ELEMENT).
Any INFRASTRUCTURE LINK shall be bordered by a start and an end INFRASTRUCTURE POINT. This
orientation does not necessarily refer to the direction of the traffic flow, but must be interpreted as an
arbitrary orientation (it may be “used” in one way or the other by the objects, like ROUTEs, JOURNEY
PATTERNs, etc. referring to it through the PROJECTION mechanism).
5.3.2.2.4 Road network: road junction and road element
The physical road network represents all the carriage ways available for example for buses, into which
the bus line network can be embedded.
The corresponding road INFRASTRUCTURE POINTs are defined as ROAD JUNCTIONs, while the
corresponding INFRASTRUCTURE LINKs are defined as ROAD ELEMENTs.
5.3.2.2.5 Rail network: rail junction and rail element
The rail network model represents the track network along which VEHICLEs (usually TRAINs) can
physically proceed, without taking into account other operational aspects such as security, regulations or
operational conventions followed by the company staff or other authorities. Railway elements are
modelled in this data model for reference purposes and not for control functions.
The corresponding rail INFRASTRUCTURE POINTs are defined as RAILWAY JUNCTIONs, while the
corresponding INFRASTRUCTURE LINKs are defined as RAILWAY ELEMENTs.
RAILWAY ELEMENTs will always have to be interpreted as non-overlapping parts of the rail network.
This means that one railway section between two switches (“points” in English vernacular) or crossings
cannot be described alternatively, and in parallel, by two or more different subdivisions into chains of
railway elements. Different sequences of railway elements between two switches will principally mean
multiple connections, physically separated from each other.
The location where contiguous RAILWAY ELEMENTs are connected is represented by a RAILWAY
JUNCTION. The two RAILWAY JUNCTIONs bounding a RAILWAY ELEMENT are specified by two
relationships between these entities. The name of each relationship end suggests a direction, which has
to be interpreted as an arbitrary orientation, similar to the orientation of ROAD ELEMENTs described in
the previous section.
5.3.2.2.6 Wire network: wire junction and wire element
The wire network for power supply of trolley buses (or trams) is modelled according to the same
principles as applied for the rail network. WIRE ELEMENTs will be defined as the links between WIRE
JUNCTIONs, which may be at places where three or more WIRE ELEMENTs are joined, at locations where
only two adjacent WIRE ELEMENTs are connected or possibly at intermediate locations.
5.3.2.3 Network infrastructure – Example
In Figure 6, the street network is an example of an infrastructure network, which may be represented (in
a GIS for instance) by ROAD JUNCTIONs and ROAD LINKs.
Other layers are represented by coloured graphs: green (timing pattern layer), blue (route layer), red
(service pattern layer).
Figure 4 — Network infrastructure example (source: NeTEx – Part 1)
5.3.3 Network restriction
5.3.3.1 General
Constraints resulting from the physical characteristics of the network are represented in Transmodel by
a range of restrictions. The network restriction model represents some of the most relevant constraints
(e.g. the OVERTAKING POSSIBILITY). Transmodel explains the approach as follows: the fact that trains
cannot overtake each other or meet each other on the same track is obvious for railway systems, but
similar restrictions apply for trolley buses and even conventional buses, under specific circumstances
(e.g. depending on the number and width of lanes on the street). This type of restriction may be relevant
for the scheduling process, because vehicle journeys shall be scheduled in a way to avoid such conflicting
events.
5.3.3.2 Network restriction – Conceptual model
5.3.3.2.1 General
The network restriction model is not aimed at describing the management of tracks or of train
movements, for which the concepts to consider are far more complex. It fits with a use case often found
in light train operation, which consists of an initial verification of the train movements planned in a
schedule, in order to check whether there are situations in which the track constraints make the schedule
impossible to run. This function is usually operated with feedback to the scheduling process.
The model comprises a set of different types of network restriction elements (VEHICLE TYPE AT POINT,
OVERTAKING POSSIBILITY, IMPOSSIBLE MANOEUVRE and MEETING RESTRICTION) that apply to
specific VEHICLE TYPEs (cf. EN 12896-1, Public transport - Reference data model - Part 1: Common
concepts)
Restrictions are explicit: if no NETWORK DESCRIPTION is described, it can be assumed that no limitations
apply.
Figure 5 — Network restriction – Conceptual model
5.3.3.2.2 Vehicle types at points
A VEHICLE TYPE characterises the common properties of a defined class of public transport vehicles (cf.
EN 12896-1, Public transport - Reference data model - Part 1: Common concepts). Vehicles of a certain
VEHICLE TYPE may not be allowed, or physically not able, to stop for any length of time at particular
INFRASTRUCTURE POINTs in the network. The entity VEHICLE TYPE AT POINT may be used to express
how many vehicles of each type there is space for at the specified POINT. This usually will be a
SCHEDULED STOP POINT. If the number is 0, then vehicles of that VEHICLE TYPE cannot stop at this
INFRASTRUCTURE POINT at all. This restriction sometimes may be relevant for checking the timing of
overtaking journeys during the scheduling process.
5.3.3.2.3 Availability of links
Vehicles of a certain VEHICLE TYPE may not be able, allowed or safe to cross particular ROUTE LINKs (cf.
5.3.4 Lines and routes) in the network. For example, a double-decker bus may not be able to pass under
a low bridge. The reference data model expresses this as a positive relationship: a VEHICLE TYPE is safe
to traverse a particular ROUTE LINK.
There may be LINKs which are not available at all on certain DAY TYPEs (cf. EN 12896-1, Public transport
- Reference data model - Part 1: Common concepts). While these limitations generally depend only on the
choice of the public transport company to offer or not particular services, there may be physical
restrictions that prevent particular LINKs to be used on a specific DAY TYPE. For instance, a street may
be blocked because of a special event (e.g. market day) which occurs regularly on each day of that DAY
TYPE. A relationship between the LINK and the DAY TYPE entity may be used to express this kind of
limited availability on parts of the public transport network.
5.3.3.2.4 Overtaking possibility
In rail or wire systems, overtaking is only possible if an appropriate overtaking track is available. In bus
systems, the situation of two buses regularly planned to overtake each other while operating on the same
ROUTE LINK can be practically neglected. Consequently, the places where it is possible to overtake can
be described by particular POINTs, as far as the planning domain is concerned. Most often SCHEDULED
STOP POINTs will be used for this purpose in operational practice.
The entity OVERTAKING POSSIBILITY is therefore related to, and identified by, the INFRASTRUCTURE
POINT which allows a vehicle stopping at this POINT to be overtaken by another vehicle passing by. The
OVERTAKING POSSIBILITY specifies that this INFRASTRUCTURE POINT provides means (for instance a
bus bay, or an overtaking rail) for one vehicle overtaking the other. This possibility may depend on the
characteristics of the VEHICLE TYPEs in question, so the VEHICLE TYPEs of both the overtaking and the
overtaken vehicle are associated with the OVERTAKING POSSIBILITY, by means of identifying
relationships.
5.3.3.2.5 Meeting restrictions
The entity MEETING RESTRICTION expresses that vehicles of two specified VEHICLE TYPEs are not
allowed to meet on a particular pair of INFRASTRUCTURE LINKs (e.g. opposite tracks). In practice, this
will probably occur mainly in tram systems, where several generations of tram vehicles are operating on
the same rail network, with different vehicle widths leading to conflicting clearance profiles along certain
parts of the track network. In metro or light rail systems, such a situation may occur if the network
comprises single-track sections.
5.3.3.2.6 Impossible manoeuvre
A particular characteristic of railway networks (in contrast to road networks) is the fact that the railway
geometry does not always allow vehicle movement between two adjacent railway elements, for instance
in the case of switches or crossings. Railway elements may not be suitable to be passed through in any
arbitrary sequence and some successions may physically be impossible. This kind of restrictions is
expressed by the entity IMPOSSIBLE MANOEUVRE, specifying from which INFRASTRUCTURE LINK to
which other (adjacent) element a rail vehicle cannot proceed because of physical restrictions. Additional
information can be attached, for example the VEHICLE TYPEs for which an IMPOSSIBLE MANOEUVRE
would apply (for instance, bi-directional rail vehicles may be able to perform a certain manoeuvre
whereas one-directional vehicles are not capable of it).
5.3.3.3 Network restriction – Example
Figure 8 provides an example of a meeting restriction: two vehicles run their journeys on opposite tracks,
but due to the narrowing of the track, they are not able to meet on the two opposite red links.
Figure 6 — Network infrastructure example (source: NeTEx – Part 1)
5.3.4 Lines and routes
5.3.4.1 Routes
5.3.4.1.1 Route – Conceptual model
The ROUTE entity represents a conventional way of describing a path through the network, to be used by
regular PT services. A ROUTE is a linear feature composed of points and links specifically defined for that
purpose. This sequence of points and links shall be built in a way that identifies a path without any
ambiguity.
The ROUTE entity represents an abstract concept; in itself it has no real operational meaning. Its purpose
is to describe a path independently of both the infrastructure pattern (e.g. ROAD ELEMENTs or RAILWAY
ELEMENTs) and the operational pattern (e.g. sequence of SCHEDULED STOP POINTs presented in a
further section). ROUTE is classically used as an interfacing object between operational planning and
infrastructure description. The independence of the ROUTE definition serves to separate the concerns of
the different layers allowing a modular consideration of network topology data.
Figure 7 — Route – Conceptual model
A ROUTE is made up of ROUTE LINKs, which are LINKs defined between two ROUTE POINTs. A ROUTE
LINK is restricted to be identifiable by its end ROUTE POINTs, which means that there cannot normally
be any alternative ROUTE LINK between the same pair of ROUTE POINTs. This restriction corresponds
to most practices, but if necessary can be qualified by the use of an OPERATIONAL CONTEXT (See
TRANSPORT ORGANISATION model), which allows separate links for separate designated purposes.
A ROUTE is thus a LINK SEQUENCE, defined by an ordered sequence of (two or more) POINTs ON ROUTE.
A ROUTE may pass through the same ROUTE POINT more than once, as in the case of a loop. The POINT
ON ROUTE entity is accordingly used to describe the ordered list of ROUTE POINTs defining the path of a
ROUTE, with an attribute ‘order’ as identifier.
It should be noted that a ROUTE – as a single path through a network in one direction – corresponds to
only one of the possible senses of ‘route’ in colloquial English. In particular, the more commonly used
sense of a set of paths including branches and conditional variants given a common name for marketing
to the public, is represented by the concept of a LINE.
5.3.4.1.2 Route topologies
The different geometries for routes that are typically found in transport networks may all be described
using POINT and LINK representations.
— Linear: A simple linear path from an origin stop to a destination stop. It may be exactly symmetric
i.e. be traversed to matching stop pairs in the outbound and inbound direction. Or asymmetric – with
differences in the stop sequences in each direction.
— Circular: A path that returns to the origin stop as the destination. It then may continue round
repeatedly. There may be symmetric or asymmetric services in the clockwise or anticlockwise
direction. The destinations shown for such routes may vary along the way.
— Lollipop: A path that goes round a loop one way at the outbound destination end and then returns
past the same stops on the inbound path.
— Cloverleaf: A path that returns repeatedly to the same stop.
— Branching: Alternate paths that go one or other alternative way at either end of the journey.
— Eye: Alternate paths that go one or other alternative way round an intermediate section of the route.
There shall be a valid ROUTE LINK between each pair of consecutive POINTs ON ROUTE.
The general orientation of a ROUTE (a ROUTE is of course oriented) may be described by an expression
like “outwards”, “backwards” etc., often referring approximately to the city centre. This classification may
lead to the definition of arbitrarily chosen DIRECTIONs, which may be used for passenger information,
but may also be relevant for scheduling or fare management. Two DIRECTIONs may be defined as being
opposite to each other.
5.3.4.1.3 Route – Examples
Figure 10 – Route point and point on route – Example (source: NeTEx – Part 1)Figure 10 shows a ROUTE
described through a sequence of POINTs ON ROUTE. It should clarify in particular, the difference between
the infrastructure network (streets) and the schematic representation of the physical path for vehicles:
the ROUTE.
Figure 8 — Route point and point on route – Example (source: NeTEx – Part 1)
Figure 11 shows an example of ROUTE POINTs used by two ROUTEs, with ROUTE 1 (the green one)
passing the same ROUTE POINT several times. Each time the ROUTE passes through a ROUTE POINT, it
“creates” a new POINT ON ROUTE.

Figure 9 — Route point and point on route – Example (source: NeTEx – Part 1)
5.3.4.2 Route instruction – Conceptual model
Some operators require a step-by-step instruction for following the ROUTE that can be provided to
drivers. This can be represented by an additional attachment to the POINT ON ROUTE, the ROUTE
INSTRUCTION.
ROUTE INSTRUCTION is providing information for a human readable instruction as how to follow a step
on the ROUTE. Data may be derived from the underlying ROUTE LINK and spatial PROJECTION of the
ROUTE LINK and ROUTE POINTs.
A ROUTE INSTRUCTION is mandatorily described by:
— Nature of transition between steps of a path e.g. up, down, level, up and down (TYPE OF
TRANSITION)
— Heading to take when following path, e.g. left, right, forward, reverse (PATH HEADING).

Figure 10 — Route instruction – Conceptual model
5.3.4.3 Lines
5.3.4.3.1 General
Transmodel defines a LINE as a grouping of ROUTEs that is generally known to the public by a similar
name or number. These ROUTEs are usually very similar to each other from the topological point of view,
being variants of a core route with some deviations only on certain parts. Often the vehicle journeys on
these ROUTEs are scheduled jointly with tight synchronisation, in order to provide a regular service on
this specific LINE. They are often grouped together for the presentation of the timetable to the public.
Two ROUTEs using the same infrastructure path (or parallel tracks), but with opposite DIRECTIONs, will
generally belong to the same LINE.
5.3.4.3.2 Line – Conceptual model
Figure 13 presents the LINE conceptual model.
LINEs may be grouped into GROUPs OF LINES for specific purposes, such as fare harmonisation, day type
assignment, or to group some kind of service categories (night buses, etc.). Grouping can also be used to
define several kinds of PT networks and sub-networks: what is usually called 'public transport network’
is in fact only a specific GROUP OF LINES and a LINE may belong to several of them. For example, in Ile
de France, a LINE may belong to the Ile-de-France Mobilités Network, but also to the Noctilien network
(night buses)
...