CEN/TS 16157-2:2011

SLOVENSKI STANDARD
01-november-2011
1DGRPHãþD
SIST ENV 13106:2003
SIST ENV 13777:2003
Inteligentni transportni sistemi - Specifikacije za izmenjavo podatkov DATEX II pri
upravljanju prometa in informiranju - 2. del: Navajanje lokacije
Intelligent transport systems - DATEX II data exchange specifications for traffic
management and information - Part 2: Location referencing
Intelligente Verkehrssysteme - DATEX II Datenaustauschspezifikation für
Verkehrsmanagement und Verkehrsinformation - Teil 2: Ortsreferenzierung
Systèmes de transport intelligents - Spécifications DATEX II d'échange de données pour
la gestion du trafic et l'information routière - Partie 2: Localisation
Ta slovenski standard je istoveten z: CEN/TS 16157-2:2011
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL SPECIFICATION
CEN/TS 16157-2
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
October 2011
ICS 35.240.60 Supersedes ENV 13106:2000, ENV 13777:2000
English Version
Intelligent transport systems - DATEX II data exchange
specifications for traffic management and information - Part 2:
Location referencing
Systèmes de transport intelligents - Spécifications DATEX Intelligente Transportsysteme - DATEX II Datenaustausch
II d'échange de données pour la gestion du trafic et Spezifikationen für Verkehrsmanagement und
l'information routière - Partie 2: Localisation Informationen - Teil 2: Positionsreferenz
This Technical Specification (CEN/TS) was approved by CEN on 10 April 2011 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their
comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS available
promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS)
until the final decision about the possible conversion of the CEN/TS into an EN is reached.

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, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.

EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

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

Contents Page
Introduction . 5
1 Scope . 6
2 Conformance . 6
3 Normative references . 7
4 Terms and definitions . 7
5 Symbols and abbreviations . 10
6 UML Notation . 10
7 The DATEX II location referencing model . 10
7.1 General . 10
7.1.1 The package “GroupOfLocations” . 11
7.1.2 The package “TpegDescriptor” . 14
7.2 Point locations. 14
7.2.1 The package “Point” . 14
7.2.2 The package “AlertCMethod2Point” . 16
7.2.3 The package “AlertCMethod4Point” . 17
7.2.4 The package “TpegPointLocation” . 18
7.2.5 The package “PointIAlongLinearElement” . 20
7.3 Linear locations . 22
7.3.1 The package “Linear” . 22
7.3.2 The package “AlertCMethod2Linear” . 24
7.3.3 The package “AlertCMethod4Linear” . 25
7.3.4 The package “AlertCLinearByCode” . 27
7.3.5 The package “TpegLinearLocation” . 27
7.3.6 The package “LinearWithinLinearElement” . 28
7.4 Area locations. 29
7.4.1 The package “Area” . 29
7.4.2 The package “AlertCArea” . 30
7.4.3 The package “TpegAreaLocation” . 31
8 The Predefined Locations publication . 33
8.1 General . 33
8.2 The package “PredefinedLocationsPublication” . 33
8.2.1 The class model . 33
8.2.2 Semantics . 34
Annex A (normative) Data dictionary . 36
A.1 Overview . 36
A.2 Data Dictionary for “GroupOfLocations” . 38
A.2.1 “AlertCArea” package . 38
A.2.2 “AlertCLinearByCode” package . 39
A.2.3 “AlertCMethod2Linear” package . 39
A.2.4 “AlertCMethod2Point” package. 40
A.2.5 “AlertCMethod4Linear” package . 41
A.2.6 “AlertCMethod4Point” package. 41
A.2.7 “Area” package . 42
A.2.8 “GroupOfLocations” package . 43
A.2.9 “Linear” package . 48
A.2.10 “LinearWithinLinearElement” package . 49
A.2.11 “Point” package . 50
A.2.12 “PointAlongLinearElement” package . 52
A.2.13 “TpegAreaLocation” package . 56
A.2.14 “TpegDescriptor” package . 57
A.2.15 “TpegLinearLocation” package . 58
A.2.16 “TpegPointLocation” package . 60
A.3 Data Dictionary of <> for “GroupOfLocations” . 63
A.3.1 The <> “AlertCLocationCode” . 63
A.3.2 The <> “MetresAsFloat” . 63
A.3.3 The <> “MetresAsNonNegativeInteger” . 63
A.3.4 The <> “Percentage” . 63
A.4 Data Dictionary of <> for “GroupOfLocations” . 63
A.4.1 The <> “AlertCDirectionEnum” . 64
A.4.2 The <> “CarriagewayEnum” . 65
A.4.3 The <> “DirectionEnum” . 66
A.4.4 The <> “HeightGradeEnum” . 67
A.4.5 The <> “LaneEnum” . 68
A.4.6 The <> “LinearElementNatureEnum” . 70
A.4.7 The <> “LinearReferencingDirectionEnum” . 70
A.4.8 The <> “LocationDescriptorEnum” . 71
A.4.9 The <> “ReferentTypeEnum” . 73
A.4.10 The <> “TpegLoc01AreaLocationSubtypeEnum” . 74
A.4.11 The <> “TpegLoc01FramedPointLocationSubtypeEnum” . 74
A.4.12 The <> “TpegLoc01LinearLocationSubtypeEnum” . 74
A.4.13 The <> “TpegLoc01SimplePointLocationSubtypeEnum” . 75
A.4.14 The <> “TpegLoc03AreaDescriptorSubtypeEnum” . 75
A.4.15 The <> “TpegLoc03IlcPointDescriptorSubtypeEnum” . 76
A.4.16 The <> “TpegLoc03JunctionPointDescriptorSubtypeEnum” . 76
A.4.17 The <> “TpegLoc03OtherPointDescriptorSubtypeEnum” . 77
A.4.18 The <> “TpegLoc04HeightTypeEnum” . 79
A.5 Data Dictionary for “PredefinedLocationsPublication” . 80
A.5.1 “PredefinedLocationsPublication” package . 80
A.6 Data Dictionary of <> for “PredefinedLocationsPublication”. 81
A.7 Data Dictionary of <> for “PredefinedLocationsPublication” . 81
Annex B (normative) Referenced XML schemas . 82
B.1 Overview . 82
B.2 The GroupOfLocations subschema . 82
B.3 The PredefinedLocationsPublication subschema . 118
Annex C (informative) Locations referencing methods . 125
C.1 Overall approach . 125
C.1.1 General . 125
C.1.2 Pre-defined locations . 126
C.1.3 GDF features . 126
C.1.4 Linear referencing systems . 126
C.2 Methods for ALERT-C . 126
C.2.1 General . 126
C.2.2 Primary and secondary locations . 126
C.2.3 Pre-defined primary location + extent . 127
C.2.4 Pre-defined primary and secondary locations . 128
C.2.5 Primary and secondary locations using pre-defined location, extent and distances . 128
C.2.6 Primary and secondary locations using Pre-defined locations + distances . 129
C.2.7 Explanation for ALERT-C. 129
C.3 Linear Referencing Methods . 131
C.3.1 Absolute Linear Referencing Methods. 131
C.3.2 Relative Linear Referencing Methods . 132
C.3.3 Interpolative Linear Referencing Methods. 134
Bibliography . 135

Foreword
This document (CEN/TS 16157-2:2011) has been prepared by Technical Committee CEN/TC 278 “Road
transport and traffic telematcis”, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights.
This document supersedes ENV 13777:2000, ENV 13106:2000.
As a user of the standard, attention is drawn to the resources of www.datex2.eu. This web site contains related
software tools and software resources that aid the implementation of CEN/TS 16157 DATEX II.
According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following
countries are bound to announce this Technical Specification: 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, Romania, Slovakia, Slovenia, Spain,
Sweden, Switzerland and the United Kingdom.
Introduction
This Technical Specification defines a common set of data exchange specifications to support the vision of a
seamless interoperable exchange of traffic and travel information across boundaries, including national, urban,
interurban, road administrations, infrastructure providers and service providers. Standardisation in this context
is a vital constituent to ensure interoperability, reduction of risk, reduction of the cost base, promotion of open
marketplaces and many social, economic and community benefits to be gained from more informed travellers,
network managers and transport operators.
Delivering European Transport Policy in line with the White Paper issued by the European Commission
requires co-ordination of traffic management and development of seamless pan European services. With the
aim to support sustainable mobility in Europe, the European Commission has been supporting the development
of information exchange mainly between the actors of the road traffic management domain for a number of
years. In the road sector, DATEX II has been long in fruition, with the European Commission being fundamental
to its development through an initial contract and subsequent co-funding through the Euro-Regional projects.
With this standardisation of DATEX II, there is a real basis for common exchange between the actors of the
traffic and travel information sector.
This Technical Specification includes the framework and context for exchanges, the modelling approach, data
content, data structure and relationships, communications specification.
This Technical Specification supports a methodology that is extensible.
This Part, Part 2 of this Technical Specification, deals with DATEX II location referencing. It references existing
location referencing Standards or Technical Specifications.
The European Committee for Standardisation (CEN) draws attention to the fact that it is claimed that
compliance with this document may involve the use of a patent concerning procedures, methods and/or formats
given in this document.
CEN takes no position concerning the evidence, validity and scope of patent rights.
1 Scope
This Technical Specification (CEN/TS 16157-2) specifies and defines component facets supporting the
exchange and shared use of data and information in the field of traffic and travel.
The component facets include the framework and context for exchanges, the modelling approach, data content,
data structure and relationships, communications specification.
This Technical Specification is applicable to:
 traffic and travel information which is of relevance to road networks (non urban and urban);
 public transport information that is of direct relevance to the use of a road network (e.g. road link via train
or ferry service).
This Technical Specification establishes specifications for data exchange between any two instances of the
following actors:
 Traffic Information Centres (TICs);
 Traffic Control Centres (TCCs);
 Service Providers (SPs).
Use of this Technical Specification may be applicable for use by other actors.
This Technical Specification covers, at least, the following types of informational content:
 road traffic event information – planned and unplanned occurrences both on the road network and in the
surrounding environment;
 operator initiated actions;
 road traffic measurement data, status data, and travel time data;
 travel information relevant to road users, including weather and environmental information;
 road traffic management information and instructions relating to use of the road network.
This part of the CEN/TS 16157 specifies the informational structures, relationships, roles, attributes and
associated data types, for the implementation of the location referencing systems used in association with the
different publications defined in the Datex II framework. It also defines a DATEX II publication for exchanging
predefined locations. This is part of the DATEX II platform independent data model.
2 Conformance
The DATEX II platform independent data model of which the location referencing packages as well as
Predefined Locations Publication sub-model are parts, corresponds to the Level A model as defined in
CEN/TS 16157-1.
Conformance with this Part shall require platform independent models from which platform specific models are
generated to comply with the UML modelling rules defined in CEN/TS 16157-1 and with the following
requirements of this sub-model which are expressed in this Part:
 comply with all stipulated minimum and maximum multiplicity requirements for UML elements and
relationships;
 comply with all definitions, types and ordering;
 employ optional elements as specified;
 comply with all expressed constraints.
It should be noted that conformance of a publication service with all the structural requirements stated above
does not necessarily ensure that the informational content of that service will be semantically comprehensible.
3 Normative references
The following referenced documents are indispensable for the application 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.
CEN/TS 16157-1:2011, Intelligent Transport Systems — DATEX II data exchange specifications for traffic
management and information — Part 1: Context and framework
CEN ISO/TS 18234-6:2006, Traffic and Travel Information (TTI) — TTI via Transport Protocol Expert Group
(TPEG) data-streams — Part 6: Location Referencing application (TPEG-Loc) (ISO/TS 18234-6:2006)
CEN ISO/TS 24530-2:2006, Traffic and Travel Information (TTI) — TTI via Transport Protocol Experts Group
(TPEG) Extensible Markup Language (XML) — Part 2: tpeg-locML (ISO/TS 24530-2:2006)
EN ISO 14819-3:2004, Traffic and Travel Information (TTI) — TTI messages via traffic message coding — Part
3: Location referencing for ALERT-C (ISO 14819-3:2004)
prEN ISO 19148, Geographic Information — Linear Referencing (ISO/DIS 19148:2009)
4 Terms and definitions
For the purposes of this document, the terms and definitions given in CEN/TS 16157-1:2011 and the following
apply.
4.1
area
two-dimensional, geographical region on the surface of the Earth
[ISO 17572-1:2008]
4.2
descriptor
characteristic of a geographic object, usually stored in an attribute
EXAMPLE Road names or road numbers.
4.3
destination
specification of the end point of a defined route or itinerary
NOTE This may be either a location on a network or an area location.
4.4
european terrestrial reference system 89
ETRS89
recommended terrestrial reference system for Europe and coincident with ITRS at the epoch 1989.0
NOTE Unlike ITRS, ETRS is centred on the stable part of the European plate and not subject to change due to
continental drift in most of Europe.
4.5
geodetic coordinate
one of the sequences of two (or three) numbers designating the position of a point, expressed in geodetic
latitude, geodetic longitude and (in the three-dimensional case) ellipsoidal height
[ISO 19111:2007]
4.6
ILOC descriptor
one of the three descriptors associated to an ILOC reference
4.7
international terrestrial reference system
ITRS
reference system for the earth derived from precise and accurate space geodesy measurements, not restricted
to GPS Doppler measurements, which is periodically tracked and revised by the International Earth Rotation
Service (I.E.R.S.)
[ISO 17572-1:2008]
4.8
itinerary
group of one or more physically separate locations arranged as an ordered set that defines a route
4.9
latitude
geodetic latitude
angle from the equatorial plane to the perpendicular to the Earth through a given point, northwards treated as
positive
NOTE adapted from ISO 19111:2007
4.10
linear
having a one-dimensional character
[ISO 17572-1:2008]
4.11
linear referencing
specification of a location relative to a linear element as a measurement along that element
[prEN ISO 19148]
4.12
location
identifiable geographic place
[EN ISO 19112:2005]
NOTE It is either on a network (as a point or a linear location) or an area. This may be provided in one or more
referencing systems.
4.13
location code
tabular address of the pre-stored location details in the location table used by the information provider
[EN ISO 14819-3:2004]
4.14
location reference
reference
data set assigned to a location
NOTE A reference shall define unambiguously and exactly one location in the location referencing system. The
reference is the set of data which is passed between different implementations using the same location referencing system
to identify the location.
4.15
location referencing system
LRS
referencing system
complete system by which location references are generated, according to a location referencing method, and
communicated, including standards, definitions, software, hardware, and databases
[ISO 17572-1:2008]
4.16
longitude
geodetic longitude
angle from the prime meridian plane to the meridian plane of a given point, eastward treated as positive
[ISO 19111:2007]
4.17
primary point
point met at the end of a linear road section when it is travelled according to the location direction
NOTE In case of an affected area with an event it generally pinpoints the origin of the event
[EN ISO 14819-3:2004]
4.18
point
zero-dimensional element that specifies a geometric location
[ISO 17572-1:2008]
4.19
predefined location
location using a unique identifier (reference) that is agreed upon in both sender and receiver system to select a
location from a set of locations already exchanged
[ISO 17572-1:2008]
4.20
referent
known location from which relative measurement are made along a linear element
[prEN ISO 19148]
4.21
secondary point
point met first when a linear road section is travelled according to the location direction
5 Symbols and abbreviations
For the purpose of this document, the following abbreviations apply throughout the document unless otherwise
specified.
ALERT-C Alert and problem Location for European Road Traffic, version C
GIS  Geographic Information System
GPS  Global Positioning System
ILOC  Intersection Location
NOTE It is the basis of a dynamic referencing system named “ILOC referencing system”, subsequently adopted by
TPEG as “TPEG-Loc”.
LR  Linear Referencing
LRM  Linear Referencing Method
TPEG  Transport Protocol Expert Group
6 UML Notation
The UML notation used in these Technical Specifications shall be as described in ISO/IEC 19501:2005. A short
summary explaining the notation used in this Technical Specification is provided in Annex A of
CEN/TS 16157-1.
7 The DATEX II location referencing model
7.1 General
Normative Annex A provides the data dictionary i.e. a comprehensive view of the different classes, attributes
and association roles for each package. Each subclause corresponds to a package.
The types of attribute and the enumerations specific to this part are defined in normative Annex A.
The XML subschema corresponding to this part of CEN/TS 16157 is provided in normative Annex B.
Informative Annex C provides some explanations about the location referencing methods that are relevant for
this part of CEN/TS 16157, some of them being drawn from approved standards like those on linear referencing
or on ALERT-C.
7.1.1 The package “GroupOfLocations”
7.1.1.1 The overall model
The package “GroupOfLocations” supplies classes and attributes to the definition of a location locating a traffic
object e.g. a situation record in a situation publication. It is pictured including the relationships between the
classes in Figure 1.
This contributes important information in the different publications defined in Part 1 of CEN/TS 16157, bringing
information on “where” in each case.

Figure 1 — DATEX II location referencing model
7.1.1.2 Semantics
The most generic concept, group of locations, is a set of one or several locations and is depicted by the
abstract class “GroupOfLocations” that is the main entry point of the corresponding package to carry the
corresponding locations.
This group of locations can be either used as a set of locations that can be seen independently one from
another and without any order (class “NonOrderedLocations”) or as an itinerary (or route) (class “Itinerary”). In
case of an itinerary the different sections defining it have to be defined following a specific order or linkage or
a single location (depicted by the class “Location”), which is the atomic locating unit.
Any group of locations (i.e. an itinerary or a group of non ordered locations or single location) can be
predefined i.e. previously defined, identified and exchanged and then be used through its reference
(respectively class “ItineraryByReference”, class “NonOrderedGroupOfLocationsByReference” and class
“LocationByReference”).
A group of non-ordered locations has at least two locations whereas an itinerary belongs at least one location.
A location can be either:
 a road network element (class “NetworkLocation”),
 an area (class “Area”).
A road network location can be either a linear or a point location (respectively classes “Linear” and “Point”).
The possible description of them is realised in the corresponding packages. The area description is realised in
the “Area” package.
In case of an itinerary destination(s) may be added to it through occurrence(s) of the class “Destination”. A
destination can be delineated either as a point on the road network (class “PointDestination” defined from the
class “Point”) or as an area (class “AreaDestination” defined from the class “Area”).
To help the location to be displayed on a map, geodetic coordinates (in term of geodetic longitude and
geodetic latitude) may be added (class “PointCoordinates”). Geodetic coordinates are defined according to the
European Terrestrial Reference System of 1989 (ETRS89) which was coincident with the International
Terrestrial Reference System (ITRS) in 1989. This is the European implementation of ITRS, but unlike ITRS it
is fixed to the stable part of the Eurasian Plate. The coordinates and maps in Europe based on ETRS89 are
not subject to change due to the continental drift. ETRS89 is the EU-recommended frame of reference for
geodetic data in Europe.
External references may be added to locations if there is a need to add a reference to an external/other
referencing system (class “ExternalReferencing”). The given reference code provided shall be accompanied
with the name of the external referencing system in use. For example, this feature may be used to extend the
present model according to CEN/TS 16157-1.
7.1.1.3 Semantics of supplementary positional information
Supplementary positional information may be added to a road network element for describing the transversal
position of the element to be located on the road (class “SupplementaryPositionalDescription”). Therefore, it is
possible to globally define the sequential ramp number the minimum accuracy (in metres) which may qualify
the corresponding location or to textually qualify this location (e.g. “on bridge”).
Besides it may be completed by transverse positional information (class “AffectedCarriagewayAndLanes”)
with the exact carriageway(s), with for each the corresponding lane(s) and the affected length.
7.1.2 The package “TpegDescriptor”
7.1.2.1 The class model
The package “TpegDescriptor” supplies classes and attributes to the definition of a descriptor in TPEG which
delineates the descriptive part of a TPEG location besides geodetic coordinates. It is pictured including the
relationships between the classes in Figure 2.

Figure 2 — The TpegDescriptor package class model
7.1.2.2 Semantics
A descriptor is a TPEG-originated word representing any textual description and shall be composed of a
descriptor type, a text string and a language code. The latter two elements shall be embedded in a
“MultingualString” structure.
Different descriptors are provided for areas and for points. The corresponding descriptor types are defined in
different enumeration in A.4.
7.2 Point locations
7.2.1 The package “Point”
7.2.1.1 The class model
The package “Point” supplies classes and attributes to the definition of a point location which specialises a
location of a traffic object. It is pictured including the relationships between the classes in Figure 3.
Figure 3 — The Point package class model
7.2.1.2 Semantics
A point network element (class “Point”) represents a single geospatial point on a road. It shall be referenced
using one of the following four methods without being exclusive:
 the ALERT-C location referencing methods (class “AlertCPoint”);
 the TPEG-Loc location referencing method (class “TpegPointLocation”). This method is defined in 7.2.4
below;
 the linear referencing method (class “PointAlongLinearElement”). This method is defined in 7.2.5;
 A geographic point defined with a geodetic coordinate pair. It may include a bearing (class
“PointByCoordinates”).
There are two methods based on ALERT-C. If AlertCPoint is chosen the method shall be one of:
 a point simply defined by a reference in a ALERT-C location table (class “AlertCMethod2Point”);
 a point defined by a reference in a ALERT-C location table with a distance between the ALERT-C point
and the actual point (class “AlertCMethod4Point”).
Each of them shall have an associated direction of traffic flow. These methods are respectively defined in
7.2.2 and in 7.2.3.
7.2.2 The package “AlertCMethod2Point”
7.2.2.1 The class model
The package “AlertCMethod2Point” supplies classes and attributes to the definition of a point location using
the method 2 as explained in EN ISO 14819-3:2004, Annex C. It is pictured including the relationships
between the classes in Figure 4.
Figure 4 — The AlertCMethod2Point package class model
7.2.2.2 Semantics
An ALERT-C point using method 2 (class “AlertCMethod2Point”) represents a single point on the road network
defined by reference to a point in a pre-defined ALERT-C location table (class
“AlertCMethod2PrimaryPointLocation”). This point is called primary point. It also has an associated direction of
traffic flow representing the direction of traffic flow along the road to which the information relates (class
“AlertCDirection”).
The ALERT-C point location is given an ALERT-C direction using a set of predefined values with a code. A
name may also be added to complete the direction definition. In case of a ring road the sense in which
navigation should be made is not ambiguous and therefore the sense need not be given.
7.2.3 The package “AlertCMethod4Point”
7.2.3.1 The class model
The package “AlertCMethod2Point” supplies classes and attributes to the definition of a point location using
the method 4 as explained in EN ISO 14819-3:2004, Annex C. It is pictured including the relationships
between the classes in Figure 5.
Figure 5 — The AlertCMethod4Point package class model
7.2.3.2 Semantics
An ALERT-C point using method 4 (class “AlertCMethod4Point”) represents a single point on the road network
defined by reference to a point in a pre-defined ALERT-C location table (class
“AlertCMethod2PrimaryPointLocation”). It shall be augmented with the non-negative distance in metres
between the ALERT-C point and the actual referenced point (class “OffsetDistance”). This point is called
primary point. It also has an associated direction of traffic flow representing the direction of traffic flow along
the road to which the information relates (class “AlertCDirection”).
The ALERT-C point location is given an ALERT-C direction using a set of predefined values with a code. A
name may also be added to complete the direction definition. In case of a ring road the sense in which
navigation should be made is not ambiguous and therefore the sense need not be given.
7.2.4 The package “TpegPointLocation”
7.2.4.1 The class model
The package “TpegPointLocation” supplies classes and attributes to the definition of a point location using the
methods described in CEN ISO/TS 18234-6:2006 and CEN ISO/TS 24530-2:2006. It is pictured including the
relationships between the classes in Figure 6.
Figure 6 — The TpegPointLocation package class model
7.2.4.2 Semantics
A TPEG point represents a single point on the road network defined by a TPEG-Loc structure and shall have
a direction of traffic flow. It shall be realised as:
 A simple point (class “TpegSimplePoint”) i.e. a point on the road network not bounded by any other points
on the road network, or
 A framed point (class “TpegFramedPoint”) i.e. represents a point on the road network framed (or
bracketed) between two other points on the same roadIt can be used when the location is not at a
junction and is a point without a predefined name. The two points at either side are used to frame the
location with known points.
Points of one type or of the other have the common characteristics of all of TPEG points (class “TpegPoint”).
They can be either located at a road junction (class “TpegJunction”) or located outside any road junction
(class “TpegNonJunctionPoint”). They also include a geodetic coordinate pair as already defined in 7.1.1.2.
When a TPEG point is at a junction it shall be defined with one to three ILOC descriptors (class
“TpegILCPointDescriptor”). It may also be described with a junction descriptor (class
“TpegJunctionPointDescriptor”) and/or with other point descriptors (class “TpegOtherPointDescriptor”).
Regarding ILOC descriptor the different values of this descriptor shall be mutually exclusive.
When a TPEG point is not at a junction it shall be defined with at least one point descriptor (the class
“TpegOtherPointDescriptor”). One of these descriptors shall identify the road or street on which the TPEG
point is located. The corresponding descriptor type shall have either the value ‘linkName’ or the value
‘localLinkName’ (see in 7.1.2.2 and in A.4.17).
A TPEG framed point shall be defined by three TPEG points. In addition to the framed point that is not on a
junction, it shall define other two points that frame the framed point.
The different descriptors are described in 7.1.2.2.
7.2.5 The package “PointIAlongLinearElement”
7.2.5.1 The class model
The package “PointAlongLinearElement” supplies classes and attributes to the definition of a point location
using different linear referencing methods as described in prEN ISO 19148. It is pictured including the
relationships between the classes in Figure 7.

Figure 7 — The PointAlongLinearElement package class model
7.2.5.2 Semantics
A point defined by a linear reference represent a single point on a linear element, part of the road network. In
addition to the linear location definition itself (class “PointAlongLinearElement”), which contains
complementary elements like geographic direction, if the point is at-grade or below/above ground level, it shall
be realised with two elements:
 the underlying linear element (class “LinearElement”);
 the distance expression between a given point on this linear element and the point itself (abstract class
“DistanceAlongLinearElement”).
The distance expression shall be one of the following:
 an absolute distance expression i.e. a curvilinear measurement (in metres) starting from the origin point
of the underlying linear element (class “DistanceFromLinearElementStart”)
...