CEN/TS 17297-2:2019

SLOVENSKI STANDARD
01-november-2019
Inteligentni transportni sistemi - Uskladitev lokacijskih referenc za mestni ITS - 2.
del: Metode pretvarjanja
Intelligent transport systems - Location Referencing Harmonisation for Urban-ITS - Part
2: Transformation methods
Intelligente Verkehrssysteme - Ortsreferenzierungsharmonisieung für Urbane ITS - Teil
2: Übersetzungsmethoden
Élément introductif - Élément central - Partie 2 : Élément complémentaire
Ta slovenski standard je istoveten z: CEN/TS 17297-2:2019
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.

CEN/TS 17297-2
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
September 2019
TECHNISCHE SPEZIFIKATION
ICS 35.240.60
English Version
Intelligent transport systems - Location Referencing
Harmonisation for Urban-ITS - Part 2: Transformation
methods
Élément introductif - Élément central - Partie 2 : Einführendes Element - Haupt-Element - Teil 2:
Élément complémentaire Ergänzendes Element
This Technical Specification (CEN/TS) was approved by CEN on 21 July 2019 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, Republic of North Macedonia, Romania, Serbia, 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: Rue de la Science 23, B-1040 Brussels
© 2019 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 17297-2:2019 E
worldwide for CEN national Members.

Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 5
4 Symbols and abbreviations . 6
5 Basics on transformations between location reference systems . 6
6 Transformation requirements . 17
Annex A (informative) Examples of Transformations . 34
Annex B (informative) Illustration of transformation to linear . 40
Bibliography . 43

European foreword
This document (CEN/TS 17297-2:2019) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, 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 shall not be held responsible for identifying any or all such patent rights.
According to the CEN/CENELEC Internal Regulations, the national standards organisations 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, Republic of
North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United
Kingdom.
Introduction
Whilst some location data are based on a latitude/longitude system or other coordinate systems, others
are based on the gazetteer reference to physical objects, e.g. bus stops, streets or bays in a car park.
Translations between different location referencing systems are, therefore, a key feature for moving data
between systems and between applications. Nearly all ITS applications need some form of location
determination and referencing to put the data or information into a spatial context.
In data terms, for most systems, we need to know values and where the data was collected. For example,
a loop detector is referenced to a particular point defined generally by a description of the road, the
direction, the lane and a stated distance from a known reference point like a junction. Data from a moving
probe vehicle will often be defined by XY coordinates based on an agreed location referencing systems
such as WGS84. Similarly, public transport information is often referenced to identified routes and stops
but historically, without the need to be concerned about where these routes and stops are in
geographically physical space.
Historically, applications in the transport sector have spawned location referencing systems that have
properties that suit the application itself; this silo approach has resulted in a significant number of
incompatible location referencing systems, often within the same organization. A typical road authority
can have 10 or more different location referencing systems for traffic control, pavement management,
detectors, asset management and content dissemination etc.; none of which are compatible or easily
translated from one to another because of different business rules or definitions. An example of this is
‘lanes’; is a long exit lane from a motorway counted as a running lane, and where does it start and end?
In public transport information services, location references – where they exist – can be both inconsistent
with location information on the infrastructure. For example, even where a bus stop is geo-located as a
point in space, this is often unmatched with the road along which the bus will be travelling. Also, there is
a logical divergence on whether the “stop” is the point where passengers are expected to stand or the
point where the vehicle will stand; whilst this distinction will generally be of no significance for end users
of itself, it makes multimodal information – for example, planning a walk-then-bus journey – difficult and
unreliable.
More generally, in the Urban-ITS context, multiple applications are required to cooperate. So, in a
multimodal environment, the disparity between location referencing systems becomes a major issue.
The only solution is to first identify the characteristics of location referencing that can be “application
independent” and then evolve (a) a conversion strategy for the short-term, and (b) a migration strategy
for the long term; with constant pressure on budgets, this represents a major challenge.
This document has been produced by the CEN/TC 278/WG 17 Project Team PT 1703 “Location
Referencing Harmonisation” under the mandate M/546 on urban ITS (U-ITS).
This document, in examples, mentions tools that can support transformation processes. It is noted that
reference to particular tool does not imply that it is the only or best tool for achieving a task, or that it is
currently available.
The audience for this document are those who need to combine data which use different location
referencing methods due to their different applications, modes or vendors.
The informative Clause 5 describes basics on transformations between location reference systems:
— The concept of transformation is presented in 5.2.
— Data quality in the context of transformations is discussed in 5.3.
The normative Clause 6 specifies transformation requirements and presents transformation examples.
Location referencing inside buildings is not considered in this document.
1 Scope
This document specifies requirements, recommendations, and permissions related to translations
between location referencing methods applicable in the urban transport environment.
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 ISO 14819-3:2013, Intelligent transport systems — Traffic and travel information messages via traffic
message coding — Part 3: Location referencing for Radio Data System — Traffic Message Channel (RDS-
TMC) using ALERT-C
ISO 19157:2013, Geographic information — Data quality
INSPIRE Technical Guidelines, INSPIRE, Data Specification on Coordinate Reference Systems — Technical
Guidelines. 2014
3 Terms and definitions
For the purposes of this document, the terms and definitions given in CEN/TR 17297-1 and the following
apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at https://www.iso.org/obp
3.1
accuracy
closeness of agreement between a test result or measurement result and the true value
[SOURCE: ISO 6709:2008, definition 4.1]
3.2
area of use
geographical area in which a specific map projection applies
3.3
location reference
description of an identifiable geographic place
Note to entry: ISO 17572-1 defines a location reference as a “label which is assigned to a location”, while
ISO TS 21219-7. TPEG2-LRC defines location referencing as “means to provide information that allows a
system to identify accurately a location”
3.4
resolution
unit associated with the least significant digit of a coordinate
[SOURCE: ISO 6709:2008, definition 4.10]
3.5
transformation
operations to change the description of a location (a location reference) from one LRS to another LRS
4 Symbols and abbreviations
AVM automatic vehicle monitoring
CRS coordinate reference system
CS coordinate system
EPSG European Petroleum Survey Group
ETRS European terrestrial reference system
EU European Union
GALILEO name of the European satellite navigation and time reference system
GIS geographic information system
GLONASS Global Navigation Satellite System
NOTE 1 Russian: globalnaja nawigazionnaja sputnikowaja sistema
NOTE 2 name of the satellite navigation and time reference system of the
Russian Federation
GLR geographic location referencing
GML geography markup language
GNSS global navigation satellite system
GPS global positioning system
NOTE 3 name of the satellite navigation and time reference system of the
United States of America
INSPIRE infrastructure for spatial information in Europe
NOTE 4 Name of a directive on the EC; aims on creating a European Union
spatial data infrastructure
IOGP International association of oil and gas producers
ITRS international terrestrial reference system
ITS intelligent transport systems
LLRM linear LRM
LRM location referencing method
LRS location referencing system
OEM original equipment manufacturer
OGC open geospatial consortium
TN-ITS transport networks for ITS
U-ITS urban ITS
UTM universe transverse Mercator
5 Basics on transformations between location reference systems
5.1 Location referencing
The concept of location referencing with location referencing methods (LRMs) and location referencing
systems (LRSs) is described in CEN/TR 17297-1.
5.2 The concept of a transformation
5.2.1 General
Several definitions exist for the term transformation, both in international standards and in other
literature. In this document, the term will be used for operations that are performed to change the
description of a location (a location reference) from one LRS to another LRS. The operation can be done
to change from a location reference in one LRS to another LRS, both based on the same LRM, or to change
between two LRSs based on different LRMs. The transformations that are described in this document are
valid for LRMs and will be employed to transform between LRSs.
The individual LRMs described in CEN/TR 17297-1 have different approaches for describing a location,
both in terms of how the location is described within an LRM, and also how the LRM is used to connect a
location reference to the real world, see Figure 1 in CEN/TR 17297-1:2019 and Figure 1 in this document.
As a result of a transformation between LRSs from two different LRMs is likely to change the location
reference significantly, including the representational shape and the positional accuracy of the location
reference.
Figure 1 illustrates the basic concepts of location referencing and transformation between location
references in different location referencing systems. Two real-world locations are described, i.e. L and
α
L . The location references LR and LR with different LRSs and LRMs, describe location L ; and
β A1,α B2,α α
the location references LR and LR describe location L . A transformation can be applied to
A1,β B1,β β
transform location reference LR to LR and vice versa, and to transform LR to LR and
A1,α B2,α A1,β B1,β
vice versa.
Figure 1 — Basic concepts of location referencing and transformation
There exist several commercial, free and open source tools for transformation of location references,
mainly applications and libraries developed within the domain of geographic information (GIS). These
are not referred to in this document, but the principles described will apply when using them.
5.2.2 Concept of preferred location referencing method
In theory, location references in one LRS can be transformed to become location references in any other
LRS, based on any LRM. However, to be able to set up a transformation, common ground for the two LRSs
in question is needed. This common ground can be parameters that describe the relation between
location references in the two LRSs directly, but more likely, it will be a common LRS that both LRSs can
refer to.
All LRMs have in common that they are methods for describing locations in the real world, and in the end,
they depend on location referencing by coordinates. Location referencing by identifiers and ALERT-C
depends on pre-coded locations described with coordinates, and both linear referencing systems and
dynamic LRSs depend on linear networks described with coordinates. Due to this, location references in
any LRS can be transformed to location referencing by coordinates. On the other hand, there is rarely any
described direct connection between different LRSs.
The preferred location referencing method considered in this document is location referencing by
coordinates.
Table 1 describes the possible direct transformations.
Table 1 — Common direct transformations
to Coordinates Identifier Linear ALERT-C AGORA-C™ OpenLR™
from
Coordinates
yes yes yes yes yes yes
(coordinates)
Identifier
yes
(pre-coded)
Linear
yes  yes
(pre-coded)
ALERT-C
yes
(pre-coded)
AGORA-C™
yes
(dynamic)
OpenLR™
yes
(dynamic)
5.2.3 Preferred method for transformations
This document describes transformations between different LRSs by transforming from the source LRS
to a preferred method, and then transforming to the target LRS from the preferred method. As location
referencing by coordinates is a LRM that all LRMs can relate to, this is the preferred location referencing
method. Requirements for the preferred location referencing method are described in 6.1.
6.1 indicates CRSs that are acknowledged as the common basis for reference and transformation in
conjunction with the INSPIRE Directive, and regulations which for application in the European context
are considered in this document to form the acceptable baseline of preferred location referencing
method. These systems will be called “preferred CRSs”.
The preferred method of transformation of source location reference S to a target location reference T
consists of either one or two steps.
If the target CRS is coordinate-based, the transformation consists only of Step 1:
Step 1: The source location reference S is transformed to a location reference in the preferred location
referencing method (i.e. by coordinates), in particular using the CRS as recommended by the Directive
2007/2/EU.
If the target CRS is not coordinate-based, the transformation consists of two steps:
Step 1: As above.
Step 2: Location reference from Step 1 (T ) is transformed to the target location reference T in the
target system (T ).
Figure 2 — Illustration of the Preferred Transformation Method with two steps
5.2.4 Legislation concerning technical aspects
5.2.4.1 The INSPIRE Directive
To solve problems of interoperability, quality, accessibility and sharing of spatial information, measures
have been taken by the European Commission and expressed in the Directive 2007/2/EC of the European
Parliament and of the Council, called INSPIRE (Infrastructure for Spatial Information in the European
Community).
INSPIRE developed two types of documents: INSPIRE Implementing Rules (IR, legally binding),
describing “what Member States must implement” and INSPIRE Technical Guidelines, specifying “how
Member States might implement the legally binding requirements”. Even if the Technical Guidelines are
not technically binding, they propose specific technical implementation for satisfying the legally binding
requirements.
5.2.4.2 Coordinate reference systems
Whilst INSPIRE concerns a whole range of data domains, i.e. the INSPIRE “data themes”, such as
Addresses, Transport Networks Cadastral Parcels, and Coordinate Reference Systems, the latter play a
special role in INSPIRE; they are considered reference data, i.e. data that represent a link to information
belonging to the different data themes. The CRSs allow for a harmonized and interoperable geographic
localization of spatial features in the different data domains.
Among of a range of CRS, INSPIRE identifies a short list of CRSs to be used to guarantee a common basis
for the geographical harmonization between all the other themes defined in the Annexes of the Directive.
The general legally binding document is the COMMISSION REGULATION (EU) No 1089/2010 of 23
November 2010 implementing Directive 2007/2/EC of the European Parliament and of the Council as
regards interoperability of spatial data sets and services, in particular its ANNEX II entitled
“Requirements for spatial data themes listed in Annex I to Directive 2007/2/EC”. The requirements
concerning the CRS are based on the ISO 19100 series of standards, essentially on ISO 19111.
This legally binding document above requires the use of a specific datum and of at least one out of a list
of CRSs (or, by exception, of another CRS, but defined by parameters allowing for conversion operations);
in particular:
a) “(…) the datum shall be the datum of the European Terrestrial Reference System 1989 (ETRS89) in areas
within its geographical scope, or the datum of the International Terrestrial Reference System (ITRS) or
other geodetic coordinate reference systems compliant with ITRS in areas that are outside the
geographical scope of ETRS89. Compliant with the ITRS means that the system definition is based on
the definition of the ITRS and there is a well-documented relationship between both systems, according
to EN ISO 19111 (…)”.
b) “At least one of the following CRSs shall be used for the spatial data sets:
— Three-dimensional CRS:
— three-dimensional Cartesian coordinates based on a datum specified as in a) above and using
the parameters of the Geodetic Reference System 1980 (GRS80) ellipsoid,
— three-dimensional geodetic coordinates (latitude, longitude and ellipsoidal height) based on a
datum based on a datum specified as in a) above and using the parameters of the GRS80
ellipsoid.
— Two-dimensional CRS:
— two-dimensional geodetic coordinates (latitude and longitude) based on a datum specified as
in a) above and using the parameters of the GRS80 ellipsoid,
— plane coordinates using the ETRS89 Lambert Azimuthal Equal Area coordinate reference
system,
— plane coordinates using the ETRS89 Lambert Conformal Conic coordinate reference system,
— plane coordinates using the ETRS89 Transverse Mercator coordinate reference system,”
— “Compound CRS where the horizontal component of the compound coordinate reference system is
one of the coordinate reference systems above. For the vertical component on land, the European
Vertical Reference System (EVRS) shall be used to express gravity-related heights (within its
geographical scope).”
The related INSPIRE Technical Guidelines provide practical guidance for implementation based on all
relevant requirements for the CRS, in particular, as regards “map projections”; it requires, beyond others,
“Lambert Azimuthal Equal Area (ETRS89-LAEA) for pan-European spatial analysis and reporting, where
true area representation is required”, which is of particular interest for this document.
The INSPIRE Technical Guidelines contain also the identifiers for the different types of coordinate
reference systems that “shall” be used according to it.
5.2.4.3 Pan-European Grids
Geographical grid systems are considered as reference data, similarly to the CRS, i.e. data that constitute
the spatial frame for linking and/or pointing to other information that belong to specific thematic fields
of INSPIRE. In the COMMISSION REGULATION (EU) No 1089/2010 of 23 November 2010 implementing
Directive 2007/2/EC of the European Parliament and of the Council as regards interoperability of spatial
data sets and services INSPIRE fully specifies:
— the Equal Area Grid (Grid_ETRS89-LAEA) intended more for statistical reporting purposes,
— the Zoned Geographic Grid (Grid_ETRS89-GRS80zn_res) intended for the provision of gridded spatial
information (i.e. raster, coverage-based data) for reference data themes.
See also Permissions 1 and 2 in 6.1.
As regards the Zoned Geographic Grid, INSPIRE requires:
— it shall be based on the ETRS89-GRS80 geodetic coordinate reference system;
— the origin of the grid shall coincide with the intersection point of the Equator with the Greenwich
Meridian (GRS80 latitude φ = 0; GRS80 longitude λ = 0);
— the grid orientation shall be south-north and west-east according to the net defined by the meridians
and parallels of the GRS80 ellipsoid.
INSPIRE specifies further the subdivision of the grid in zones.
The INSPIRE Technical Guidelines recognize that existing standards enable different modelling of gridded
data. It recommends that “(…) data exchanged using numerical modelling theme-specific grids shall use
standards in which the grid definition is either included with the data, or linked by reference to an
appropriate scientific document describing the grid (.)”. It further states that “the Zoned Geographic Grid
may be used as a geo-referencing framework”.
Transforming existing data to the Zoned Geographic Grid requires interpolating original data with the
subsequent degradation; but it is a proposal for future convergence at European level to achieve
interoperability. The underlying idea is to promote that new raster reference data sets are produced
based on this grid. In this case, data would be originally stored using this common framework from the
beginning. Hence, no more re-projection, interpolation and degradation will be necessary for INSPIRE
data provision.
In conclusion, the use of the Zoned Geographic Grid is not mandatory.
5.3 Data quality in transformations
5.3.1 Basic principles of data quality
The data quality of a transformed target location reference can never be better than the data quality of
the source location reference. In the best cases, the data quality can be maintained through the
transformation, but more likely it will be reduced, as the transformation will change the representative
shape of the location and/or describe it in a different representation of the real world. The data quality
of the target location reference will be a function of:
— the data quality of the source LRS, see 5.3.3;
— the data quality of the source location reference within the source LRS;
— the quality of the transformation (rounding of decimals and more);
— and the data quality of the LRS for the transformed location reference (how precise the LRS describes
the real world)
DataQuality = f (DataQuality , DataQuality , DataQuality , DataQuality ).
target LRSsource source Transformation LRStarget
The model for describing data quality of geographic information is specified in ISO 19157. The core
component of the model is the data quality unit, which consists of a scope and data quality reported with
one or more data quality elements as shown in Figure 3. The scope of the data quality unit specifies the
extent, spatial and/or temporal, and/or common characteristics that identify the data on which data
quality is to be evaluated.
One particular aspect of data quality is positional accuracy with the following three data quality element
types:
a) Absolute external positional accuracy – closeness of reported coordinate values to values accepted
as or being true.
This element typically describes how accurate the positions in location references are in relation to
actual positions in the LRS, e.g. a coordinate tuple in the ETRS89 Cartesian LRS (EPGS:4936) can have
an absolute external positional accuracy of 20 cm, compared to the actual position in this LRS.
b) Relative internal positional accuracy – closeness of the relative positions of features in the scope to
their respective relative positions accepted as or being true.
This element typically describes how accurate positions in location references are in relation to each
other. Positions can be more accurate in relation to each other than their absolute external positional
accuracy; a distance between two positions can be measured accurately, while the positions
themselves can be less accurate.
c) Gridded positional accuracy – closeness of gridded data position values to values accepted as or being
true.
This element describes how accurate positions are in relation to a grid; it is mostly used for raster
image data.
Figure 3 illustrates the model for the data quality unit and the data quality elements for positional
accuracy.
Figure 3 — Data quality unit and positional accuracy elements from ISO 19157:2013
The data quality elements are further described with measures, evaluation methods and results as shown
in Figure 4. ISO 19157:2013 requires “At least one data quality result shall be provided for each data
quality element.”
Figure 4 — Data quality element descriptors from ISO 19157:2013
Standardized data quality measures are defined in Annex D of ISO 19157:2013; these can be referred to
with their identifier. In addition, it is also possible to define other measures using a name and a
description. Two relevant examples of measures from Annex D of ISO 19157:2013, for absolute external
position accuracy, are:
— Mean value of positional uncertainties (Measure number 28 in ISO 19157:2013)
describes as the mean value of the positional uncertainties for a set of positions where the positional
uncertainties are defined as the distance between a measured position and what is considered as the
corresponding true position.
— Circular standard deviation (Measure number 42 in ISO 19157:2013)
describes as radius describing a circle, in which the true point location lies with the probability of
39,4 %.
Respective normative requirements are presented in 6.2.
5.3.2 Resolution
The resolution of location references is not a quality characteristic, but it is related to data quality:
A high resolution (e.g. many decimal places) does not necessarily mean high accuracy, but it makes no
sense to have a low resolution and high accuracy. The real accuracy of a location reference can never be
better than the resolution; therefore, if the resolution of coordinates in a location reference is reduced,
the description of accuracy shall also be updated accordingly.
5.3.3 Data quality and area of use for an LRS
Two other quality related aspects that shall be considered for transformation of location references are:
— the data quality of the LRS; and
— the area of use for the LRS.
The LRS is the framework that the location reference is using to describe a real-world location, and it is
redefining the real world in different ways.
For pre-defined LRMs, the LRS contains identifiers with a position described in another LRS. An LRS for
location referencing by identifiers contains a set of predefined positions, and these positions will
normally have location references in an LRS for location referencing by coordinates, e.g. ETRS89, and
have their own absolute external positional accuracy. The location references for representative points
of addresses in a gazetteer, for example, can have a mean value of positional uncertainties of 3m in the
ETRS89 Cartesian LRS (EPGS:4936). A pre-defined location reference transformed to location
referencing by coordinates can never be more accurate than this value.
Similarly to this, a LRS for linear referencing contains links that have location references in another LRS,
and where each coordinate tuple on a link has an accuracy. The reference line geometry of roads in a
linear referencing system, for example, can have a mean value of positional uncertainties of 1m in the
ETRS89 Cartesian LRS (EPGS:4936). A linear reference transformed to location referencing by
coordinates will never be more accurate than this value, no matter how accurate the location reference
is within the linear reference system.
It is therefore important to describe the absolute external positional accuracy of the LRS for the source
location references in a transformation.
A Coordinate Reference System (CRS) is describing the real world through a datum, which can include an
ellipsoid and other parameters. The data quality of these CRSs compared to real-world positions will then
depend on how good the datum redefines the actual shape of the Earth. Furthermore, in a projected CRS,
a map projection is applied to a base CRS to present an area of the Earth as flat. The data quality of location
references in a projected CRS will depend on the projection and the area of use, and how far the location
is from the main axis of the projection. The Transverse Mercator projection is recommended for location
referencing at scales larger than 1:500 000.
For example, if the CRS EPSG:3045 (2D Transverse Mercator projection in ETRS89, zone 33N) has an area
of use between 12°E and 18°E in Europe. The main axis is at 15°E, where the scale between a real-world
distance and a distance in the projected CRS is 0.999 6. This scale will increase towards 1,0 as the distance
from the main axis increases, and then continue to increase further as the distance also increases. When
using projected CRSs, this distortion shall be considered.
5.3.4 Describing metadata and data quality
The model for describing metadata for a data set with geographic information is defined in ISO 19115-1.
This model includes description of data quality according to ISO 19157, and in addition it describes other
aspects of a data set, such as a spatial reference system. The data specifications and metadata
specifications in INSPIRE describe data quality according to the predecessors of ISO 19157 (ISO 19113,
ISO19114 and ISO19138) and ISO 19115-1 (ISO 19115), but the principles are the same as in ISO 19157
and ISO 19115-1
According to the Directive 2007/2/EC (known as the INSPIRE Directive) which fixes a roadmap for the
stepwise implementation of spatial data sets in the European Union, 'Member States shall ensure that
metadata are created for the spatial data sets and services corresponding in particular to the following
themes':
— Transport networks,
— Coordinate Reference Systems,
— Geographical grid systems,
— Geographical Names,
— Addresses,
— Administrative Units.
The metadata for spatial data and spatial data services have to be kept up to date and the standards EN
ISO 19115, EN ISO 19119, and ISO 15836:2009 (Dublin Core) have been identified as important
standards.
Commission Regulation (EC) No. 1205/2008 implementing Directive 2007/2/EC of the European
Parliament and of the Council as regards metadata was adopted in December 2008 and is the regulatory
document in this context.
The document “INSPIRE Metadata Implementing Rules: Technical Guidelines based on EN ISO 19115 and
EN ISO 19119” refers to the above-mentioned regulation as regards the way to implement it.
The required metadata presented in Table 2 are relevant for the interoperability issues of this document:
Table 2 — Selected metadata requirements according to the INSPIRE directive
Metadata element Definition Obligation
Coordinate reference Description of the coordinate
system reference system(s) used in the data
set
Temporal reference Description of the temporal reference Mandatory, if the spatial data set or
system systems used in the data set. one of its feature types contains
temporal information that does not
refer to the Gregorian Calendar or
the Coordinated Universal Time.
Encoding Description of the computer language
construct(s) specifying the
representation of data objects in a
record, file, message, storage device
or transmission channel.
Character encoding The character encoding used in the Mandatory if an encoding is used that
data set. is not based on UTF-8.
Spatial The method used to spatially
representation type represent geographic information.
Data Quality / Correctness of the explicitly encoded Mandatory if the data set includes
Logical consistency / topological characteristics of the data types from the Generic Network
Topological set as described by the scope Model and does not ensure centreline
consistency topology (connectivity of centrelines)
for the network.
A full set of data quality characteristics is provided in INSPIRE Metadata Implementing Rules: Technical
Guidelines based on ISO 19115 and EN ISO 19119, Annex B].
6 Transformation requirements
6.1 Basic requirements, recommendations, and permissions
The following requirements, permissions and recommendations, in this subclause and in 6.2, apply for
all subsequent transformations.
Permission 1: For regions outside of continental Europe, another grid than one of the Pan-European
Grids may be defined, although it shall follow the same principles as laid down for the Pan-European
Grids (either the Equal Area Grid or the Zoned Geographic Grid), be documented according to the ISO
19100 series of standards, based on the International Terrestrial Reference System (ITRS), or other
geodetic coordinate reference systems compliant with ITRS in areas that are outside the geographical
scope of ETRS89.
Permission 2: Member States are able to choose between these two grids ('Equal Area Grid' or the 'Zoned
Geographic Grid') which may be used for the provision of gridded data.
Requirement 1: Transformations in general shall go via coordinates with the exception provided by
Permission 3.
Permission 3: In the case of transformations between different linear referencing systems, direct
transformation is acceptable if the source and target systems are based on the same linearly referenced
network.
Requirement 2: The target CRS for the transformation to the preferred method location referencing by
coordinates (Step 1) shall be one of the preferred CRSs described in the INSPIRE Technical Guidelines,
based on ETRS89.
Permission 4: In the case of transformation from CRS to CRS, where the transformation consist only of
Step 1, the target CRS of the transformation does not need to be one of the preferred CRSs.
Recommendation 1: Projected CRSs should only be used for data in the scales where they are
recommended, and within their specified area of use.
Requirement 3: To create a coherent temporal reference, data shall be time stamped.
6.2 Data quality requirements
Requirement 4: Descriptions of data quality shall be applied according to the data quality model from
ISO 19157.
Requirement 5: The absolute external positional accuracy of location references shall be described.
Requirement 6: The resolution of location references shall be described.
Requirement 7: The absolute external positional accuracy of location references shall not be described
as better than the resolution of coordinates in a location reference.
Requirement 8: For pre-coded location referencing methods, the absolute external positional accuracy
of the LRS shall be described according to ISO 19157.
Recommendation 2: By default, the Measure 28 (the Mean value of positional uncertainties presented
in ISO 19157 should be used.
6.3 Transformations towards the preferred method
6.3.1 From coordinates
6.3.1.1 Description
This subclause defines the transformation from coordinates in a source CRS to coordinates in one of the
preferred CRSs described in the INSPIRE Technical Guidelines, based on ETRS89. See also
Requirement 2.
Many different CRSs are in common usage, with the choice between CRS being based on historical usage,
purpose of application, geographical relevance, political choice and other factors. It is common for some
practitioners to not appreciate that there is no single common universal CRS in use.
This provides the rationale for Requirement 9.
As well as identifying and documenting the positional accuracy resulting from transformations, there is
also a need to ensure temporal consistency of the information, especially if high accuracy positions are
being subject to transformation.
This provides the rationale for Requirement 3.
An example for this form of transformation is given in A.2.
6.3.1.2 Data quality consideration
The data quality principles in 5.3 provide the rationale for Requirements 4, 5, 7 and
Recommendation 2.
6.3.1.3 Requirements
Requirement 9: To support transformation from location reference by coordinates in one CRS to
coordinates in one of the preferred CRSs described in the INSPIRE Technical Guidelines, the source CRS
shall be described according to the model in ISO 19111.
Requirement 3 and Requirement 8 shall apply.
6.3.2 From an identifier
6.3.2.1 Description
Location reference by an identifier exists in many forms, including:
— index reference into a pre-defined data set, for point locations, linear locations, or area locations;
— named or identified entries in location gazetteers, e.g. street names, building names, points of
interest, internal data set identifiers, bus stop names, addresses, marker post references, bridge
references, etc.
This provides the rationale for Requirement 10.
NOTE The specific location reference identified by the identifier of interest does not necessarily require
coordinates, so long as a reliable method for inferring coordinates is supported within the processes of the source
data set. However, if the coordinates for the location reference of interest require pre-processing derivation the
potential calculation error can be identified within the quality characteristics that are reported for the source data
sets and the transformation process.
An example for this form of transformation is given in A.3.
6.3.2.2 Data quality consideration
Due to the two step nature of the process, mentioned in 5.2.3, the overall quality measure identified for
transformed data will need to take account of several elements. In the first step the quality measures will
need to take account of the quality characteristics of the transformation of a location reference by
identifier to retrieve or derive the coordinates for the location reference in the CRS of the source data set;
they also need to take account of the quality characteristics of the transformation from a source CRS to
the preferred location referencing method, as described in 5.2.2. In the second step the derived or stated
coordinate for the referenced location is transformed into the target CRS – the quality characteristics
should take account of both the quality characteristics of the transformation from the preferred location
referencing method to the target CRS and the quality characteristics of location references within the
target CRS, which is covered in 5.3.
6.3.2.3 Requirements
Requirement 10: To support transformation from location reference by identifier to coordinates the
source data set shall contain cross-references between location identifiers and their stated coordinates
in a CRS.
Requirement 11: The transformation shall be performed in two phases as part of Step 1, i.e. the first
phase of the transformation of a location reference by identifier shall be to retrieve or derive the
coordinates for the location reference in the CRS of the source data set. The second phase of this
transformation shall be to transform the derived coordinates to coordinates within one of the preferred
CRSs.
6.3.3 From linear
6.3.3.1 Description
Many traditional and current highway management systems use linear network models and linear
referencing for traffic management and a
...