EN 12896-2:2016

SLOVENSKI STANDARD
01-januar-2017
1DGRPHãþD
SIST EN 12896:2006
-DYQLSUHYR]5HIHUHQþQLSRGDWNRYQLPRGHOGHO2PUHåMHMDYQHJDSUHYR]D
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: EN 12896-2:2016
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.

EN 12896-2
EUROPEAN STANDARD
NORME EUROPÉENNE
September 2016
EUROPÄISCHE NORM
ICS 35.240.60 Supersedes EN 12896:2006
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 European Standard was approved by CEN on 5 May 2016.

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. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists 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, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2016 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 12896-2:2016 E
worldwide for CEN national Members.

Contents Page
European foreword . 4
Introduction . 5
1 Scope . 6
1.1 General scope of the Standard . 6
1.2 Functional domain description . 7
1.3 Particular Scope of this Document . 7
2 Normative references . 8
3 Terms and definitions . 8
4 Symbols and Abbreviations . 8
5 The Network Topology Domain . 8
5.1 Introduction . 8
5.2 Model and document structure . 9
5.3 Network description model . 10
5.3.1 Model overview . 10
5.3.2 Infrastructure Network . 11
5.3.3 Network restriction . 15
5.3.4 Main tactical planning points and links . 18
5.3.5 Activation . 20
5.3.6 Vehicle and crew point . 22
5.3.7 Lines and routes . 23
5.3.8 Line Network . 28
5.3.9 Flexible network . 31
5.4 Fixed object model . 37
5.4.1 Model overview . 37
5.4.2 Site . 38
5.4.3 Stop place . 44
5.4.4 Flexible stop place . 54
5.4.5 Associating equipment with site components . 56
5.4.6 Equipment description overview . 57
5.4.7 Waiting and luggage equipment . 58
5.4.8 Point of interest . 59
5.4.9 Passenger service equipment . 64
5.4.10 Ticketing equipment . 65
5.4.11 Site access equipment. 66
5.4.12 Local service . 69
5.4.13 Parking Equipment . 70
5.4.14 Site equipment – Examples . 72
5.4.15 Path links and navigation paths. 76
5.4.16 Path links – Examples . 78
5.4.17 Navigation paths – Examples . 81
5.4.18 Check constraint . 87
5.4.19 Parking . 89
5.4.20 Vehicle stopping . 92
5.4.21 Accessibility coverage . 92
5.4.22 Accessibility coverage of site elements . 92
5.4.23 Accessibility coverage of paths . 93
5.5 Tactical planning components model . 94
5.5.1 Model overview . 94
5.5.2 Journey pattern . 95
5.5.3 Common section . 99
5.5.4 Timing pattern . 100
5.5.5 Service pattern . 104
5.5.6 Service connection . 112
5.5.7 Routing constraints . 116
5.5.8 Time demand type . 118
5.5.9 Passenger stop assignment . 119
5.5.10 Train stop assignment . 124
5.5.11 Path assignment . 126
5.5.12 Notice assignment . 127
5.5.13 Passenger information display assignment . 128
5.6 Explicit frames . 129
5.6.1 General . 129
5.6.2 Infrastructure frame . 130
5.6.3 Service frame . 130
5.6.4 Site frame . 131
Bibliography . 199

European foreword
This document (EN 12896-2:2016) has been prepared by Technical Committee CEN/TC 278 “Intelligent
transport systems”, the secretariat of which is held by NEN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by March 2017, and conflicting national standards shall
be withdrawn at the latest by March 2017.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document together with documents EN 12896-1:2016 and EN 12896-3:2016 supersedes
EN 12896:2006.
The series composed of the following documents:
Public transport - Reference data model - Part 1: Common concepts
Public transport - Reference data model - Part 2: Public transport network
Public transport - Reference data model - Part 3: Timing information and vehicle scheduling
Public transport - Reference data model - Part 4: Operations monitoring and control
Public transport - Reference data model - Part 5: Fare management
Public transport - Reference Data model - Part 6: Passenger information
Public transport - Reference data model - Part 7: Driver management
Public transport - Reference data model - Part 8: Management information and statistics
Together these create version 6 of the European Standard EN 12896, known as “Transmodel” and thus
replace Transmodel V5.1.
The split into several documents intends to ease the task of users interested in particular functional
domains. Modularisation of Transmodel, undertaken within the NeTEx project, has contributed
significantly to this new edition of Transmodel.
In addition to the eight Parts of this European Standard an informative Technical Report (Public
Transport – Reference Data Model – Informative Documentation) is also being prepared to provide
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 all the eight parts are
completed.
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,
Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.
Introduction
Part 1 of this standard presents the following items:
— rationale for the Transmodel Standard;
— use of the Transmodel Standard;
— applicability of the Transmodel Standard;
— conformance statement;
— transmodel origins ;
— reference to the previous version and other documents.
The data structures represented in Part 1 are generic patterns that are referenced by different other
parts. This particular document (Part 2) represents a new edition of EN 12896:2006 of the chapter
“description of the network”. Moreover, it incorporates the major part of the IFOPT standard model of
stop places and related concepts as updated and harmonized within the NeTEx project.
1 Scope
1.1 General scope of the Standard
The main objective of the present Standard is to present the public transport reference data model
based on:
— the public transport reference data model published 2006 as EN 12896 and known as Transmodel
V5.1;
— the model for the Identification of Fixed Objects for Public transport, published 2009 as
EN 28701and known as IFOPT;
incorporating the requirements of
— EN 15531-1 to 3 and CEN/TS 15531-4 and CEN/TS 15531-5, Service interface for real-time
information relating to public transport operations (SIRI);
— CEN/TS 16614-1 and CEN/TS 16614-2, Network and Timetable Exchange (NeTEx);
in particular the specific needs for long distance train operation.
Particular attention is drawn to the data model structure and methodology:
— the data model is described in a modular form in order to facilitate understanding and use of the
model;
— the data model is entirely described in UML.
In particular, a reference data model kernel is described, referring to the data domain:
— network description: routes, lines, journey patterns, timing patterns, service patterns, scheduled
stop points and stop places.
— This part corresponds to the network description as in Transmodel V5.1 extended by the relevant
parts of IFOPT.
— Furthermore, the following functional domains are considered:
— timing information and vehicle scheduling (runtimes, vehicle journeys, day type-related
vehicle schedules);
— passenger information (planned and real-time);
— operations monitoring and control: operating day-related data, vehicle follow-up, control
actions;
— fare management (fare structure and access rights definition, sales, validation, control);
— management information and statistics (including data dedicated to service performance
indicators);
— driver management:
— driver scheduling (day-type related driver schedules);
— rostering (ordering of driver duties into sequences according to some chosen methods);
— driving personnel disposition (assignment of logical drivers to physical drivers and
recording of driver performance).
The data modules dedicated to cover most functions of the above domains will be specified. Several
concepts are shared by the different functional domains. This data domain is called “common concepts”.
1.2 Functional domain description
The different functional domains taken into account in the present Standard and of which the data have
been represented as the reference data model are described in “Public transport reference data model -
Part 1: Common concepts”.
They are:
— public transport network and stop description;
— timing information and vehicle scheduling;
— passenger information;
— fare management;
— operations monitoring and control;
— management information;
— personnel management: driver scheduling, rostering, personnel disposition.
The aspects of multi-modal operation and multiple operators’ environment are also taken into account.
1.3 Particular Scope of this Document
The present European Standard entitled “Reference data model for Public transport – Part 2: Public
transport network” incorporates data structures which form the network topology description of
Transmodel V5.1 and the major part of the fixed objects model of IFOPT. It is composed of three data
packages:
— network description;
— fixed objects;
— tactical planning components.
The data structures represented in this part form network topology descriptions. They typically
reference to structures as described in the “Public transport - Reference data model - Part 1: Common
concepts”, such as version frames or generic grouping mechanisms.
This document itself is composed of the following parts:
— Main document (normative) representing the data model for the concepts shared by the different
domains covered by Transmodel;
— Annex A (normative), containing the data dictionary, i.e. the list of all the concepts and attribute
tables present in the main document together with the definitions;
— Annex B (informative), indicating the data model evolutions.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. 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 and definitions
For the purposes of this document, the terms and definitions given in EN 12896-1:2016 apply.
4 Symbols and Abbreviations
DRT Demand responsive transport
FTS Flexible transport service
GIS Geographic information system
IFOPT Identification of fixed objects in public transport
ISO International standards organization
IT Information technology
NeTEx Network and Timetable Exchange
PT Public transport
PTO Public transport operator
SIRI Service Interface for Real-time Information
UML Unified modelling language
URI Uniform resource identifier
URL Universal resource locator
VDV Verband Deutscher Verkehrsunternehmen (D)
WGS World geodetic standard
5 The 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 IFOPT standard and
harmonized with Transmodel within the NeTEx project., 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 three main sub-models.
a) network description model (ND);
b) fixed object model (FO);
c) tactical planning components model (TP).
Network description model: describes 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 network topological aspects of the
network. The model splits into:
— network infrastructure model;
— line network model;
— route model;
— flexible network model;
— activation model;
— vehicle and crew point model.
Fixed object model: describes 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 associated
elements, such as services or equipment, but also concepts enabling the representation of the
navigation through or access to the stops. The model splits into:
— site model;
— stop place model;
— flexible stop place model;
— point of interest model;
— equipment description model;
— path and navigation path model;
— check constraint model;
— parking model;
— vehicle stopping model;
Tactical planning components model: describes basic concepts related to the description of the work
patterns of public transport vehicles, such as journey patterns and service patterns, 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 Part 3 –
Timing Information and Vehicle Scheduling. The model splits into:
— journey pattern model;
— timing pattern model;
— service connection model;
— service pattern model;
— common section model;
— routing constraint model;
— time demand type model;
— stop assignment model;
— train stop assignment model;
— path assignment model;
— notice assignment model;
— passenger information display assignment model.
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 as shown above with some
exceptions due to the necessity to introduce some concepts earlier in the document in order to ease the
understanding.
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 a number of separate sub-models covering different aspects of the network:
— network infrastructure model:
— infrastructure network;
— network restriction;
— main tactical planning points and links model (from the journey pattern model);
— activation model;
— vehicle and crew point model;
— line and route model;
— line network model;
— line network;
— line schematic map;
— flexible network model;
— flexible link, point and zone;
— flexible route;
— flexible line.
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 a number of general framework models (for example, generic point and link
model, notice model, etc.) described in the part “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;
a 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 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 1 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 data sets.
class NT ND Infrastructure Network MODEL
Name: NT ND Infrastructure Network MODEL
end of
Author: Transmodel
to
CC Generic Point & Link
CC Generic Point &
Version: 1.0
MODEL::POINT Link MODEL::LINK
1 *
Created: 05/02/2014 11:24:53
Updated: 12/02/2014 19:10:11
from
start of
1 *
end of to
INFRASTRUCTURE POINT
INFRASTRUCTURE LINK
1 *
«UID»
from
«UID»
Id
Id
start of
1 *
ROAD JUNCTION RAILWAY JUNCTION WIRE JUNCTION ROAD ELEMENT RAILWAY ELEMENT WIRE ELEMENT
«UID» «UID» «UID» «UID» «UID» «UID»
A
Id Id Id Id Id Id
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 from the “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 from
the “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 from part “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 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 — Examples 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 has to 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 carriageways available 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 of 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 names of the relationship ends suggest 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 4, the street network is an example of an infrastructure network, that 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
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 a number 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 (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 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 diesel buses,
under specific circumstances (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.
The network restriction model is not aimed at describing the management of track 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 makes 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 . “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.
class NT ND Network Restriction MODEL
+included in *
+made up
CC Vehicle Type MODEL::VEHICLE TYPE
of 0.1
1 +subject to
1 1 1 +safe to traverse * +subject of 1 1
+used to define
+allowed to be +overtaking
+overtaken
located at at
at
+providing space for *
+against * +for *
+against * +for *
+defined for *
VEHICLE TYPE AT POINT
MEETING RESTRICTION
OVERTAKING POSSIBILITY
IMPOSSIBLE MANOEUVRE
+ Capacity [0.1]
«UID»
+ OvertakingWidth [0.1]
«UID» «UID»
+ Id
«UID»
+ Id + Id
+ Id
+on * *
+with regard
+from * +to *
* to the
+specifying the
+at
+at * * opposite
capacity of
+safely
+start
traversed
+location +overtaking +end +referred
+referred to
of 1
+overtaking by
{exclusion}
1 at of
of 1 to in in
1 1
at 1 * 1
POINT
+end LINK
NT Infrastructure Network
+to
of
NT Infrastructure Network MODEL::INFRASTRUCTURE LINK
MODEL::INFRASTRUCTURE POINT
1 *
1 *
+start
+from
of
Name: NT ND Network Restriction MODEL
Author: Transmodel
Version: 1.0
Created: 05/02/2014 11:24:53
Updated: 01/09/2014 16:38:16
Figure 5 — Network restriction – Conceptual model
5.3.3.2.2 Vehicle types at points
A VEHICLE TYPE characterizes the common properties of a defined class of public transport vehicles
(cf.“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.7, 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.“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 to offer 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 IMPOSSIBLEMANOEUVRE 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 6 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 Main tactical planning points and links
The generic point and link model (cf. “Public transport - Reference data model - Part 1: Common
concepts”) presents the generic objects composing a network (points, links and zones). Specific roles
are assigned to these simple objects according to the functional purpose. Figure 7 presents the network
points and links, dedicated in particular to the tactical planning of operations.
...