This publication is a Technical report by the Joint Research Centre (JRC), the European Commission’s science and knowledge service. It aims to provide evidence-based scientific support to the European policymaking process. The scientific output expressed does not imply a policy position of the European Commission. Neither the European Commission nor any person acting on behalf of the Commission is responsible for the use that might be made of this publication.

Contact information

Name: Francesco Pignatelli

Address: via Enrico Fermi 2749, 21027 Ispra (VA) Italy

Email: francesco.pignatelli@jrc.ec.europa.eu

Tel.: +39 0332 78 6319

JRC Science Hub

https://ec.europa.eu/jrc

JRC Mission

As the Commission’s in-house science service, the Joint Research Centre’s mission is to provide EU policies with independent, evidence-based scientific and technical support throughout the whole policy cycle.

Working in close cooperation with policy Directorates-General, the JRC addresses key societal challenges while stimulating innovation through developing new methods, tools and standards, and sharing its know-how with the Member States, the scientific community and international partners.

Serving society
Stimulating innovation
Supporting legislation

Europe Direct is a service to help you find answers to your questions about the European Union

Free phone number (*): 00 800 6 7 8 9 10 11

(*) Certain mobile telephone operators do not allow access to 00 800 numbers or these calls may be billed.

A great deal of additional information on the European Union is available on the Internet.

It can be accessed through the Europa server http://europa.eu

How to obtain EU publications

Our publications are available from EU Bookshop (http://bookshop.europa.eu),

where you can place an order with the sales agent of your choice.

The Publications Office has a worldwide network of sales agents.

You can obtain their contact details by sending a fax to (352) 29 29-42758.

JRC104569

EUR 28301 EN

PDF | ISBN 978-92-79-64456-6 | ISSN 1831-9424 | doi:10.2791/227108 | LF-NA-28-301-EN-N
EPUB | ISBN 978-92-79-75032-8 | ISSN 1831-9424 | doi:10.2791/643543 | LF-NA-28-301-EN-E

Luxembourg: Publications Office of the European Union, 2016

© European Union, 2016

The reuse of the document is authorised, provided the source is acknowledged and the original meaning or message of the texts are not distorted. The European Commission shall not be held liable for any consequences stemming from the reuse.

How to cite this report: Borzacchiello, M.T., Boguslawski, R., Pignatelli, F., Improving accuracy in road safety data exchange for navigation systems – EULF Transportation Pilot, EUR 28301 EN, doi:10.2791/227108

All images © European Union 2016, unless otherwise specified

Improving accuracy in road safety data exchange for navigation systems : European Union Location Framework Transportation Pilot : Study

Acknowledgements

This technical report synthesises the efforts made by different partners developing the EULF Transportation Pilot, documented through several deliverables.

Partners for the Pilot included key organisations participating in the following initiatives:

European Union Location Framework (EULF) project:

http://ec.europa.eu/isa/actions/02-interoperability-architecture/2-13action_en.htm

EULF is an activity supported by the European Commission DG Informatics (DIGIT) Interoperability Solutions for European Public Administrations (ISA) Programme and coordinated by the European Commission Joint Research Centre (JRC).

The objective of this project is to create a European Union Location Framework (EULF) addressing the EU-wide, cross-sector interoperability framework for the exchange and sharing of location data and services. It has been funded through ISA Programme.

EULF was the coordinating partner for the pilot and has facilitated the pilot and tested the feasibility of reusing INSPIRE Directive (2007/2/EC) within the ITS community.

Transport Network ITS Spatial Data Deployment Platform (TN-ITS):

http://tn-its.eu/

The mission of TN-ITS is to facilitate and foster, throughout Europe, the exchange of ITS-related spatial data between public road authorities, as data providers, and ITS map providers or other parties, as data users.TN-ITS is activity under ERTICO.

Pilot partners from TN-ITS included TomTom, HERE, Norwegian Public Road Administration (NPRA) and the Swedish Transport Administration (TrV).

European Location Framework (ELF) project:

http://www.elfproject.eu/

ELF is a three-year project, co-funded by the European Commission, launched in March 2013. The goal of the project is to deliver a pan-European platform and web services required to provide up-to-date, authoritative, interoperable, cross-border, reference geo-information for use by the European public and private sectors, compliant with the INSPIRE Directive.

The project is executed by a collaborative consortium of 30 partners across Europe, including inter alia national and regional mapping and cadastral agencies, software developers, application providers, research and academia.

As the pilot has focused on Norway and Sweden, key pilot partners include the Norwegian and Swedish mapping agencies (Kartverket and Lantmäteriet). In particular, these partners have significant prior experience in implementing the INSPIRE technical framework.

Apart from the authors of this report, the following people have worked hard for the success of the pilot:

Anna Forsell and Jiří Bukovský (HERE), Tom Jensen and Stephen T'Siobbel (TomTom), Per Isaksson (TrV), Martin Fredriksen (NPRA), Kees Wevers (ERTICO, TN-ITS), Olaf Østensen and Saulius Urbanas (ELF), Lars Wikström and Audun Moa (TRIONA), Anders Grönlund (Lantmäteriet), Roy Mellum (Lantmäteriet), Trond Hovland (ITS Norway).

A special thanks to Graham Vowles that has initiated the process and laid out ideas (and cartoons) for developing this project.

Abstract

In the near future, the travel experience for drivers will radically change from what they were used to a decade ago: advanced safety systems will guide drivers and help reduce road accidents; built-in vehicle sensors will detect road and traffic conditions and adapt the behaviour of the vehicle; automatic control of the engine will enable the reduction of emissions and contribute to the objective of decarbonisation of transport. All this will be possible thanks to the application of Information and Communication Technologies (ICT) to the transport system, also called Intelligent Transport Systems, or ITS. These are playing an increasingly important role in shaping European transport policy for the opportunities lying within new technologies. Many elements come together in the development of these systems, and one of them is the availability of accurate digital maps, which is crucial for the provision of real time traffic and multimodal travel information services.

The ITS Directive in 2010 confirmed the importance of digital maps, required mainly in two priority actions (provision of EU-wide real time traffic and multimodal travel information services). The creation of standards is envisaged for the integration of accurate public road data in digital maps, and the ITS Directive provides that to guarantee a coordinated approach, coherence with the INSPIRE framework should be ensured, especially for what concerns static road data (speed limits, access restrictions…). INSPIRE is Directive 2007/2/EC establishing an Infrastructure for Spatial Information in Europe, to share spatial data and services, supporting environmental policies or policies that have an impact on the environment.

The EULF transportation pilot was an opportunity to support concretely the needs of businesses and citizens and address the policy requirements of the ITS Directive, while leveraging the INSPIRE investment by the European countries. It established an up-to-date flow of road safety data between road authorities and commercial map providers in Norway and Sweden, and provided guidance on linear referencing and exchange standards (the TN-ITS protocol), supporting the aims of the ITS Directive and drawing on INSPIRE. Partners included the JRC-led EULF project, ERTICO (a public/private sector European mobility solutions partnership), Norwegian and Swedish Road Authorities, TomTom and HERE (commercial navigation system providers), and Norwegian and Swedish Mapping Agencies (partners of the European Location Framework (ELF) project led by EuroGeographics).

This document describes: (i) the relevant policy context; (ii) the methodology used to implement the TN-ITS protocol in Norway in Sweden; (iii) the use of the linear referencing approach from INSPIRE to complement TN-ITS location referencing; (iv) the testing of the ELF platform by the commercial map providers; (v) the development of a draft technical specification prepared for formal submission of the TN-ITS standard under CEN TC-278; and (vi) an assessment of the added value of the approach undertaken.

Benefits found were: (i) the use of the TN-ITS revealed tangible benefits for map providers and consumers, reducing speed limit error rates from 25% to 7%; (ii) Road Authorities (SE, NO) passed from quarterly to daily updates to map providers (iii) if extended to other EU countries, commercial map providers would be able to move from disparate national processes to more standardised ones in different EU countries; (iv) a continuous flow of data from road authority to end user; (v) reduced effort in handling incremental updates compared to handle full datasets (vi) change of workflows at organisational level towards greater efficiency and avoiding duplication (vi) realising EU investments and leveraging MS efforts in INSPIRE and ELF.

Main findings include: (i) the need to put in place effective data sharing and collaboration agreements between public and private parties, complementing the tested technical solution (ii) the importance of relying on INSPIRE transport network data when national road databases are not available (iii) the need to agree on a common location referencing method to facilitate road data exchange (iv) the need to improve data collection business processes for the public road authorities to supply up-to-date information to the private sector (and other public sector) data users.

Based on these results, there is a commitment from the partners to put the ‘pilot’ processes into ‘production’, and actions are underway to extend the processes to other MS through the project called European ITS Platform (EU-EIP), under the EU Connecting Europe Facilities (CEF) funding scheme.

1 Introduction

1.1 The policy context

This section aims to give an overview of EU policy in the Intelligent Transport Systems (ITS) domain and its relationships with the INSPIRE Directive, establishing a Spatial Information Infrastructure in Europe for policies related to the environment.

Intelligent Transport Systems apply information and communication technologies to all modes of transport. Computers, electronics, satellites and sensors are playing an increasingly important role in our transport systems. Directive 2010/40/EU “on the framework for the deployment of Intelligent Transport Systems in the field of road transport and for interfaces with other modes of transport” (the ITS Directive) aims to establish interoperable and seamless ITS services while leaving Member States the freedom to decide which systems to invest in.

Under this Directive the European Commission has adopted specifications to address the compatibility, interoperability and continuity of ITS solutions across the EU.

Since 2010, the ITS Directive has promoted the following six priority actions:

1. The provision of EU-wide multimodal information services

2. The provision of EU-wide real time traffic information services

3. Data and procedures for the provision, where possible of road safety related minimum universal traffic information free of charge for users

4. The harmonised provision of an interoperable EU-wide e-Call system;

5. The provision of information services for safe and secure parking places for trucks and commercial services; and

6. The provision of reservation services for safe and secure parking places for trucks and commercial services

In addition to the priority actions listed above, work has been carried out in other priority areas of the ITS Directive, and in particular in the field of cooperative systems, and open in-vehicle platforms.

Intelligent Transport Systems are seen as key elements to address many societal challenges like the decarbonisation of transport and road safety, in line with current Commission priorities. They support and are being developed for all modes of transport and in particular for road transport.¹

As ITS involves digital technologies, the Commission is interested in promoting the role of frameworks and standards and the digitisation of transport for new growth and smarter mobility², as part of the Commission Digital Single Market strategy set in 2015[1]. A chapter is dedicated to standards in the ITS domain, which are of particular relevance to the work described in the remainder of this document.

According to [2], road and traffic data are not shared, and the accessible data are fragmented, lacking interoperability and a comprehensive regulatory framework ensuring quality. A variety of public and private sector stakeholders are involved in the traffic information value chain, and this means that cooperation amongst them needs to be encouraged, with appropriate legal and financial tools.

Among the other standards that have been identified, that are of particular interest for this report, there are those regarding the integration of accurate public road data in digital maps.

A good overview of the steps that led to the adoption of the ITS directive can be found in [3], where the need for reference data and issues of privacy are highlighted.

A major initiative on data harmonisation across Europe (including reference data) is the Directive 2007/2/EC [4] aiming to establish an Infrastructure for Spatial Information in Europe (INSPIRE), to share spatial data and services, supporting environmental policies or policies that have an impact on the environment. INSPIRE is a multipurpose infrastructure, comprising 34 spatial data themes, divided into three Annexes according to the legal documents, addressing both reference data (e.g. cadastral parcels, addresses, transport networks) and thematic data (e.g. energy resources, human health and safety)³.

The INSPIRE Directive was designed to promote sharing and harmonising spatial data in the environmental domain. However, the development and implementation of the Directive has helped raise awareness of the importance of addressing access and interoperability issues generally in the spatial domain. Several of the 34 INSPIRE data themes are regarded as ‘core reference’ themes and are applicable to multiple policy domains. These include, amongst others, the Transport Network theme, which applies to all modes of transport. INSPIRE is not only about semantic and technical interoperability; it has developed experience on legal and organisational aspects as well, by initiating and promoting a network of “location” experts in different thematic areas related to environmental policies, and is starting to be recognised in other sectors beyond the environment, as shown in the case of the ITS Directive.

Indeed, the latter provides that, “in order to guarantee a coordinated approach, the Commission should ensure coherence between the activities of the Committee established by the ITS Directive and (among others) those of the Committee established by the INSPIRE Directive”. INSPIRE can support one of the priority areas set by the ITS Directive, namely the “optimal use of road, traffic and travel data”⁴, which is relevant for several priority actions, among which are the provision of EU-wide multimodal travel information services (priority action a⁵) and the provision of EU-wide real–time traffic information services (RTTI, priority action b).

For priority action b) the delegated act 2015/962 of 18 December 2014 published in the Official Journal in June 2015 [6], makes explicit reference to INSPIRE, stating that “the specifications set out in this Regulation should be compatible with the specifications established by Directive 2007/2/EC and its implementing acts, in particular Regulation 1089/2010 [7]. The extension of the application of these specifications to all static road data types might also promote further harmonisation in this field”.

The Commission Staff Working Document (SWD) accompanying the above mentioned delegated regulation [2], when considering benefits states that: “The optimisation of the business exchanges between partners and the reduction in duplications of data lead to an increase in dissemination, better re-use and finally time and cost-saving for everyone”. This is seen as a conclusion of the experience gained through the implementation of the INSPIRE Directive, which has also opened up access to spatial data via interoperable network services, available to the business and other communities.

Also, the SWD points out that “as mostly used by road operators, DATEX II⁶ would be an appropriate European standard for data sharing, acknowledging that for static road data the INSPIRE Directive and its implementing acts should be considered”. For static road data in particular, Member States and other stakeholders are encouraged to use the data categories and network infrastructure that are being developed to meet the requirements of the INSPIRE Directive and its implementing Regulations. It is interesting to note that the “problem tree” reported in an Annex to the SWD highlights the same problems that are addressed by INSPIRE, such as the lack of digital data, of a data sharing culture, the availability of data that are fragmented, non-interoperable and of insufficient quality. The TN-ITS Data standard, introduced later in this document, contributes to tackle these issues.

Following the ITS SWD, in April 2015⁷ the Commission issued a request to three European Standardisation Organisations (ESOs: CEN, CENELEC and ETSI),” to draft new European standards and European standardisation deliverables in support of the implementation of Article 8 of Directive 2010/40/EU for multimodal information, traffic management and urban logistics in the urban ITS domain”.

This request itself includes the INSPIRE Directive in the background documents. Also, the ESOs were requested to take into account existing initiatives and standards, including geo-standards (page 8, sec.1.2.2). The Decision was adopted in February 2016⁸, where it is considered that the [INSPIRE] “digital network graph can be enhanced to be used as a common location referencing system for reliable ITS services. This enhancement should take into account pre-existing standards, in particular Geographic Data File (GDF)”.

The policy context outlined above shows that there is a demand for harmonised exchange of data related to the transport networks, and that INSPIRE is considered of benefit for achieving this aim. In the following subsections a dedicated pilot application combining INSPIRE technical specifications and ITS data exchange specifications will be described in detail.

1.2 Problem statement

ITS applications and in particular real-time traffic information services need maps that are highly up-to-date with consistent and relevant data based on the most accurate information available directly from public road authorities. For example, a public road authority will maintain information about a traffic sign that relates to a specific location on the road network. When information displayed on a sign changes, e. g. the height restriction is lowered, this is important safety information that needs to be shared reliably with ITS map providers so that the respective traffic sign attributes for that road segment are updated accurately.

On the one hand, users of ITS applications need accurate and timely safety-related attribute data, while commercial ITS Map Providers need a reliable and harmonised mechanism mechanism that is consistent in different countries and enables them to process updates on safety-related attribute data from public road authorities accurately and efficiently. On the other hand, Member States’ public authorities, including road authorities, need to promote mechanisms for sharing up-to-date data to improve public safety, reduce the risk of damage to infrastructure, and they want to leverage their investment in INSPIRE-compliant data and services by making them applicable to a broader range of policies and applications.

The market is already providing such services, but there is “a lack of cross-border continuity, few data exchange agreements intra-EU and internationally, or low quality” [8].

Based on the recognition of these problems, an INSPIRE and ITS-related pilot activity (in the following “Transportation Pilot” or “Pilot”) was included as part of the 2014/15 Work Programme of the “Interoperability Solutions for European Public Administrations” (ISA), under the European Union Location Framework Action 2.13 (EULF), led by JRC.

The EULF is a framework of guidance and actions to foster interoperable cross-sector and cross-border sharing and use of location information, based on INSPIRE. EULF is based on five focus areas: Policy and strategy alignment, e-Government integration, Standardisation and interoperability, Return on Investment and Effective Governance and Partnerships. More information can be found on the dedicated website⁹.

1.3 Partners

The EULF project has jointly coordinated the pilot with the TN-ITS consortium, a community of practice interested in the development and promotion of TN-ITS, a standard developed to exchange data updates between public road authorities and other parties. TN-ITS members participating in the pilot have been the commercial map providers TomTom and HERE and the National Road Authorities of Sweden (TrV) and of Norway (Vegvesen, or NPRA). Also collaborating in the pilot is the ELF (European Location Framework) project, which aims to deliver a pan-European platform and web services to provide up-to-date, authoritative, interoperable, cross-border, reference geo-information for use by the European public and private sectors, based on INSPIRE. ELF partners of the pilot are in particular the Swedish Mapping, Cadastral and Land Registration Authority (Lantmäteriet) and the Norwegian Mapping Agency (Kartverket). The specific contribution of each partner and the relationships between them are explained below.

1.4 Objectives and scope

The Pilot has the following objectives:

1. To evaluate the use of the TN-ITS protocol and INSPIRE in supporting more regular exchange of road safety data between road authorities and map providers;

2. To contribute to the provision of more reliable databases used in navigation systems;

3. To establish mechanisms that are capable of being implemented in “production” in Norway and Sweden and rolled out as good practices in other MS.

4. To incorporate the lessons learned in the development of EULF.

Figure 1 gives a schematic view of the Pilot: the public road authorities for Norway and Sweden (bottom-right) publish safety-related road attributes according to the TN-ITS specification based on the INSPIRE data specifications for Transport Networks [9]; the corresponding national mapping and cadastral authorities (bottom - left) provide reference data also based on the INSPIRE technical framework; demonstrator applications are built by commercial ITS map providers HERE and TomTom (up-centre) to consume the feeds from the road authorities using the TN-ITS protocol and evaluate the services provided by the ELF platform.

Public sector stakeholders are possible beneficiaries of this activity, as well as businesses and citizens making use of ITS applications. Knowledge and experience gained during the implementation of the pilot will be captured as reusable methodologies, guidelines and best practices and incorporated into the EULF (in the form of recommendations or guidelines) to support other Member States with location enabling applications both within the transport sector and beyond.

The pilot partners jointly prepared a video to communicate the concept underlying the activities of the project [10]. In the paragraph below more details are given about the actors and the tasks of the Pilot.

Figure 1 - Stakeholders and schematic view of the Transportation Pilot

In parallel, as part of the Pilot, experts from the INSPIRE and ITS domains implemented INSPIRE-based linear referencing in the TN-ITS exchange protocol, as a means of locating features along the road network. INSPIRE supports a common linear referencing method, while the TN-ITS platform originally envisaged an industry-specific location referencing method (either AGORA-C¹⁰ or openLR¹¹, both dynamic location referencing methods). The pilot gave the opportunity to test the INSPIRE method for linear referencing for the TN-ITS service in two countries, which is coherent with the INSPIRE Transport Network data specifications. This provided the possibility to cross-reference data between the TN-ITS and INSPIRE services and use them together to achieve a richer and more reliable data flow, although slightly more complex to implement. More details on this are given in Section 5, on linear referencing. Moreover, the current TN-ITS exchange specification was transformed to the format and template required for a CEN Technical Specification, under Technical Committee TC278 – Working Group 7 on ITS Spatial Data. This Committee is responsible for Intelligent Transport Systems (ITS) standards in Europe, including standardisation of static geographic road network data and standards for data exchange between public road authorities and mapmakers and other users of this data. This gives to the TN-ITS protocol the visibility of a recognised standard in the ITS field.

To summarise, the road authorities implemented a mechanism to exchange frequent updates of their road data with commercial map providers via web services based on the TN-ITS exchange protocol. The commercial map providers tested these data feeds successfully and introduced them into their production processes. These feeds rely on existing data sharing agreements. This is shown in the right side of Figure 1.

As mentioned above, alongside the TN-ITS exchange, the pilot also involved Mapping Agencies in the ELF project giving the commercial map providers access to seamless cross-border INSPIRE-based geodata published as web-services. This led to the creation of new data sharing agreements between ELF and the commercial map providers in the form of an evaluation licence. The private sector map providers tested and evaluated the ELF cloud infrastructure in two platforms (OSKARI and ArcGIS Online), assessing the related tools and available data content (see left side of Figure 1). This work is still undergoing at the time of writing (December 2016).

The document is organised as follows: after this introduction giving an overview of the policy context, the problem statement and the scope and objectives of the work, Section 2 describes (i) the methodology used to implement the TN-ITS Data exchange framework in Norway and Sweden, at the National Road Authorities and at the Commercial Map Providers; (ii) the relevance and testing of the ELF platform in the context of the pilot activities; (iii) the implementation of INSPIRE linear referencing in the TN-ITS framework and the steps followed to propose the TN-ITS protocol as a CEN standard under the 278 Committee on ITS. Section 3 reports on the main outcomes of the assessment of the added value performed during the pilot activities, followed by Section 4 on sustainability aspects for the different partners. Conclusions in Section 5 shed light on issues identified, lessons learned and next steps.

2 Methodology

2.1 Overview of the TN-ITS standard¹²

The grounds for the development of the TN-ITS data exchange framework can be found back in 2008, within the ROSATTE project (2008-2010¹³). This project “aimed at establishing an efficient and quality-ensured supply chain for information on safety-related road attributes, from public authorities to commercial map providers and other road data users, with a focus on changes in the relevant attributes rather than full data sets”. Already in 2010 the idea of aligning these specifications to the INSPIRE specification of the Transport Network theme [9] was analysed by the ROSATTE experts in [11] and then put forward in a study commissioned by EC DG Mobility and Transport [12], where the organisational approach used during the INSPIRE development and implementation and the alignment to INSPIRE specifications was recommended. After the ROSATTE project, follow-up work was carried out in the eSafety Forum Digital Maps Working Group (DMWG), and the EU-funded support action eMaPS. As a result of these activities the "Transport Network ITS Spatial Data Deployment Platform" was created, or "TN-ITS" for short. The term "Transport Network" in the name refers to the INSPIRE specification for theme "Transport Networks" [9], and signifies the close relationship between the specification and the INSPIRE framework. The remit of TN-ITS as a platform is to foster the roll-out of the concept of the ROSATTE data chain, now renamed TN-ITS data chain, across Europe, and to deploy the related specification. In doing this, TN-ITS also directly supports the implementation of Action 1.3 of the ITS Action Plan [12], which is reflected and detailed in the Delegated Regulation with respect to real-time traffic information (RTTI) [6].

The idea behind TN-ITS is that if road authorities maintain (day by day) an up-to-date data store of the road network and related attributes, such as traffic signs (or the traffic regulations of which these are an expression), it should in principle be possible to extract and share overnight any changes that have occurred in such road network attributes. Even a continuous process can be envisaged. Information of a change, together with location information in terms of a location reference, is packed in an update transaction. Many such transactions are grouped into update sets, and these are delivered to the ITS map providers, to help them to keep their ITS maps up to date. For such data exchange infrastructure to be meaningful, it is equally important that a data chain from the ITS map providers to user devices (in-vehicle and other) is in place. Substantial efforts are also ongoing in this latter respect. The vision is that in the future a change made by a road authority one day, can be presented in the user devices the next day (or maybe even sooner).

It should be noted that ITS map providers use a multitude of data sources to keep their maps up to date and accurate. For them this is not an easy task. ITS maps were originally developed for in-vehicle navigation. Over time they became a component of certain advanced driver assistance systems (ADAS), and at a later stage of cooperative ITS¹⁴. Now a new wave of technology is on the horizon to support automated driving. Much research and development is ongoing in this new domain, and ITS digital maps will again be an important component of the technology. Over time and in synchrony with these technological developments, we see the requirements for ITS digital maps gradually increase, especially to higher levels of freshness and accuracy.

The TN-ITS approach for exchange of updates of road network attributes is just one of the state-of-the-art methods that are available to ITS map providers to keep their maps up to date. Other approaches are use of in-vehicle camera data, and probe data (floating vehicle data¹⁵). Compared to these methods, a major advantage the TN-ITS approach is that the updates concern single data points, which do not need big-data processing. If the road authority processes are well organised, and there is good cooperation between the road authority and the users of its updates, this will over time become a trusted source, which means that updates can generally be incorporated into ITS maps without extensive validation. However, the other two approaches mentioned are not so much in competition with TN-ITS, but complementary to it.

A draft version of a working document for the CEN Technical Specification (TS) "Data exchange on changes in road attributes" was prepared as part of the Transportation pilot. When the specification was developed within the ROSATTE project, INSPIRE was under development as well. During its development, the specification was to a large extent aligned with INSPIRE, as far as the specifications of INSPIRE were known at that time. The original plan was to formalise the TN-ITS specification document by defining it as an extension to the INSPIRE specification for the theme Transport Networks (TN) [9]. In further discussions however it appeared that, although an extension document can be defined, the route to providing such document a formal status was not defined at the time. Because of this, eventually the alternative approach to make the TN-ITS specification a CEN TS was adopted.

In the Transportation Pilot the specification contained in project deliverable D3.1 of the ROSATTE project was used as basis for the implementation of TN-ITS services in Norway, and for extension of the existing service in Sweden. The specification was extended with the possibility to include, in addition to a map-based location reference, also a linear location reference.

2.2 TN-ITS Data exchange framework¹⁶

The TN-ITS specification covers a large number of safety features and the Transportation Pilot has implemented a subset of the possible features according to separate agreements. Also, a few features not currently included in the TN-ITS specification were added, based on the user needs. The set of safety features currently supported by the Transportation Pilot is listed in Section 2.3, Table 1.

The generic data flow is shown in Figure 2, where the data exchange between road authorities and map providers is outlined. The road safety data coming from the authoritative road database is transformed into the TN-ITS data format which enables changes in the data to be downloaded by the map providers, according to a standardised format using standardised web services. These changes are then processed by the map providers, included in their databases, and input to the baseline map used in their navigation systems devices.

From a technical point of view, the overview description of the system architecture can be found in detailed deliverables of the project, available upon request¹⁷.

Figure 2 Generic data flow from Road Authority to Map Provider used in the Transportation Pilot

2.3 TN-ITS implementation in Norway and Sweden¹⁸

This section describes the activities performed and the National Road Database data used to provide a TN-ITS compliant service, in Norway and Sweden.

In both countries a National Road Database¹⁹ (NVDB) exists, containing safety related information as well as other information such as asset management data, traffic data etc.; they have national coverage and are continuously maintained. Different technical solutions are in place in Sweden and Norway, but a similar conceptual model applies.

Based on this starting point, in the context of the Transportation pilot, a software service to publish safety feature updates from the Norwegian and Swedish NVDBs was implemented. Implementation took place in parallel for the Norwegian Public Roads Administration (NPRA) and Swedish Transport Administration (TrV) and a common software platform (Transport Network Engine - TNE²⁰) was used to save time. This platform is compliant with the ROSATTE Specification of data exchange methods from TN-ITS [11] and is currently used at TrV.

For the pilot, TrV in Sweden has implemented an extension of an existing TN-ITS service (established during the ROSATTE project), while NPRA in Norway has set up a new TN-ITS service using its National Road Database (NRDB). The service for NPRA is hosted at TRIONA (see Table 2), a company providing IT services and in particular implementing a TN-ITS service in both test countries.

The list of attributes implemented in the two National Road Authorities is shown in the following Table 1. Updates are currently provided on a daily basis (processing during the night and available in the web service before 07:00 the day after). The geographical coverage is the complete road network in the national road databases (NVDB) of Sweden and Norway.

Table 1 List of provided attributes in the EULF Transportation Pilot

TN-ITS Attribute

SE

NO

INSPIRE

Type

SpeedLimit/MaximumSpeedLimit

X

X

X

Line

RestrictionForVehicles/MaximumHeight

X

X

X

Point

RestrictionForVehicles/MaximumLadenWeight

X

X

X

Line

RestrictionForVehicles/MaximumWeightPerSingleAxle

X

X

X

Line

RestrictionForVehicles/MaximumLength

X

X

Line

RestrictionForVehicles/MaximumWidth

X

X

Line

RoadName/Name

X

X

X

Line

RoadNumber/Number

X

X

X

Line

WarningSign/DangerousCurve

X

Point

WarningSign/MooseCrossing

X

Point

WarningSign/PassingWithoutStoppingProhibited

X

X

Point

NoEntry

X

X

Line

The detailed data flow is reported in Figure 3, which is a detailed view of previous Figure 2 and includes reference to the deliverables of the ROSATTE project containing the specifications of the exchange format²¹. This diagram also includes further detail regarding a possible “feedback loop” from the map providers to the road authority, which will be explained in Section 5.

The deployment used at TrV and at TRIONA for NPRA for hosting the TN-ITS services is illustrated in Figure 4, with the following elements:

NVDB Database server

The server hosting the NVDB database. For Norway, this server is hosted at NPRA, for Sweden, at TrV.

TNE Application server

The server hosting the TNE update service. This could be the same server as the server also hosting the TN-ITS services or a separate server.

TN-ITS (and TNE) Database server

The server hosting the ROSATTE and TNE databases. These two databases could have been split into separate servers and even separate database engines.

TN-ITS Application server

The server hosting the TN-ITS services. This could be the same server as the server also hosting the TNE update service or a separate server. The specification is the same as for the TNE application server.

In the installation at TrV and Triona, no separate TN-ITS application server has been set up.

Web server

The server hosting the TN-ITS web services.

Information on the deployment software as well as on the application runtime configurations for both countries is contained in the detailed deliverables of the transportation pilot, available upon request²².

Figure 3 Detailed data flow from Road Authority to Map Provider used in the Transportation Pilot. Circled in red are the parts related to the implementation at the National Road Authorities

Figure 4 -Deployment view of the implementation of TN-ITS service in Norway and Sweden

The detailed activities performed and the NVDB data used to provide a TN-ITS compliant service are summarised in Table 2. For the Transportation Pilot, the services have been implemented at the following URLs:

Norway:http://rosatte-no.triona.se/ROSATTEDownload/download/querydatasets

Sweden: https://app.trafikverket.se/RosatteDownload/download/querydatasets

Table 2 TN-ITS Implementation steps in Sweden and Norway

Activity

TrV (Sweden)

NPRA (Norway)

Set up a production environment for the TN-ITS service that is visible on the internet.

This task has been performed at TrV and includes:

• Setting up the necessary hardware

• Installing and configuring the software and databases/database connections

• Scheduling the data conversion and export services and publication of the data for the TN-ITS web service

The implemented ROSATTE REST API is fully described in a separate document available upon request.

The regime for setting up a production environment at NPRA is quite extensive. To be able to have a service up-and-running within the timeframe of Phase 1 of the Pilot, it was decided that Triona would provide such an environment. The environment is now available at http://rosatte-no.triona.se/ROSATTEDownload/download/querydatasets

The aim is to move the hosting of the production environment to NPRA as soon as this is practically feasible. This will also mean that the base URL for the services will change.

The implemented ROSATTE REST API is fully described in a separate document available upon request.

Implement and test an OpenLR encoder (for location referencing)

Already implemented at TrV during the ROSATTE project

The framework of the existing ROSATTE implementation in Sweden was used but has been adapted to data from the Norwegian NVDB. The encoder has been tested against http://demo.tomtom.com/OPENLR/ by selecting various representative samples such as:

• Single carriageway roads in different directions

• Multiple carriageway roads in different directions

• Sliproads

• Roundabouts

Additional testing has been done by TomTom and Here downloading and integrating live data.

Specify and map agreed safety feature types

Together with NPRA/TrV a set of safety feature types to be provided by the service was agreed (see Table 1). For each of the types, a schema level mapping was specified (between NVDB and TN-ITS schemas).

Implement agreed safety feature types

Data transformations between NVDB and ROSATTE according to the specifications and agreements above were implemented.

Implement linear referencing

For each of the supplied safety feature instances, a linear reference was provided in addition to OpenLR location references. Since there is a performance cost to linear referencing, it is configurable whether linear referencing is activated or not. This implementation was done once and valid for both TrV and NPRA.

Test the solution

The solution was tested primarily with live data from the NVDB. We also produced sample test datasets for TomTom and Here which includes all degrees of freedom in the updated schemas.

The solution was tested primarily with live data from the NVDB.

Install and run the production environment

The solution was already installed and running at TRV

The tested solution was installed in the production environment set up by Triona.

Initially, in order to produce datasets of a reasonable size, the service was executed manually to achieve reasonable update intervals. When dataset production caught up with updates in the source data (NVDB), the service was scheduled to run automatically every night, producing daily updates. Sometimes, a daily update in the source data (NVDB) may be extremely large, resulting in the need for occasional manual intervention due to performance reasons. We have noted that especially the OpenLR encoder would need performance optimisations when millions of locations are decoded in a single batch.

Documentation

Documentation of the solution. Besides the description in this report, there is documentation²³ on how to install, set up and run the service [13].

Support clients (TomTom/Here)

Within the context of the Transportation Pilot, when needed, support for project partners (TomTom/Here) was provided. This may relate to the use of additional attribute types or dealing with possible errors in the implementation of the various Transportation Pilot extensions to the software.

3 Implementation at commercial map providers

3.1 HERE²⁴

The scope of the implementation at HERE was to integrate the TN-ITS update service for Sweden and Norway into the HERE map production environment, to create near real time processing and delivery to end users, by creating, testing and establishing a process flow of TN-ITS attributes from the acting authorities to HERE to users of navigation systems.

The main activities undertaken are outlined below and represented in the following Figure 5:

1. Gain understanding of data format delivered and location referencing methods used – to be able to decide on process flow and ensure accuracy (quality)

2. Agreement on attributes for updated TN-ITS service in Sweden and Norway. HERE provided input for attributes of high importance in regards to optimal routing experience and making driving safer

3. Establish technical workflow from acting authority to HERE ‘map to end-user’ experience

4. Testing and evaluating the ELF platform

Figure 5: TN-ITS implementation workflow at HERE (high level) © HERE

Overall the TN-ITS service proved to be an important complementary update mechanism to HERE when it comes to getting updated attributes integrated into the database in a fast and effective way. It is clear that having only the changes (incremental updates) provided through the service is very beneficial. Previously complete datasets for the countries were compared with the HERE map to identify changes. There were some challenges along the way that are described below. These challenges were worth spending time on considering the fact that this pilot potentially could be spread to other countries where HERE can use the same process and experience, with the goal of having a seamless effort.

The main effort and time invested was in converting the GML files received from the road authorities and finding the right balance to be confident in matches with the HERE database. The database of the acting authority and map provider’s database will never be a mirror of each other and therefore the matching of the two will always provide some challenges. A learning that has been confirmed during the pilot, is that acting authorities and map providers will probably never have the same specifications and therefore some of those challenges need to be accepted.

In the context of the pilot, success rates are defined as changes that flow from acting authority through the process developed within the pilot and automatically into the HERE database. For speed limits in Sweden, the success rate is 50% (high confidence matches). To be able to provide success rates for the Norwegian TN-ITS service, further testing is needed. Match rates depend on parameter settings, match distance of the LRP and tolerance for the bearing match.

The main reasons for values not matching are:

• Different geometry representation (Figure 6)

• Deviations in specification (Figure 7)

• Geometry not existing in HERE database (Figure 8)

Figure 6: Fallout – Different geometry representation © HERE

Figure 7: Fallout – Deviations in specifications (Bearings not matching) © HERE

Values not matching fall into different fallout categories and are worked separately.

During the test phase from 22 July to 28 August 2015, approximately 900 kms of road were updated with new speed limits in Sweden. This included both automatically updated values and fallouts. Speed limits for Sweden coming via the TN-ITS service are brought into an operational level, meaning all speed limit updates are integrated into the production environment. This will continue also after the end of this pilot.

An analysis on data during 7 weeks (22 August-9 of October 2016) in Sweden, showed that in this time about 2216 km were provided via the TN-ITS Service. About 557 km (26%) were already correct in HERE’s database, 529 km (24%) were on unwanted geometry (Figure 6) and the remaining 1130 km (50%) were actual updates to HERE’s database.

This means that in the analysed period, an average of 159km were updated per week in Sweden thanks to the TN-ITS Service.

Figure 8: Fallout – Missing geometry in HERE map © HERE

Success rates for other attributes are not added in this report as further testing is needed. All attributes were downloaded and put through the process flow established, with some adjustments depending on whether it is a ‘line’ location (e. g. Speed limits and NoEntry) or point along the line (Height restriction for example).

Issues encountered at HERE can be summarised as follows:

• Technical issues: Decoding of Base64²⁵ string, e.g. translating the location referencing string.

• Specification issues: Matching of data - transferring the Location Referencing point to the HERE geometry. The road authority and HERE specifications are different. There will most probably never be a one to one match, therefore different confidence levels have been applied.

• Quality issues, in terms of:

Freshness – The service relies on the freshness of the changes delivered to NVDB (National Road Authority database). Therefore an important aspect is that the real changes are reported effectively to the NVDB by different responsible authorities (municipalities for example). This should be considered by the Road Authorities.

Accuracy – Placement of signs. How exact is the placement of the signs in the source data? For HERE the accuracy of the placement of the sign in reality is of high importance. This should be also considered by the Road Authorities.

Regarding the testing of the ELF platform, HERE conducted initial testing and evaluation of the ELF service and gained experience on the “Showcase application”. More testing and investigations need to be carried out using the different queries to be able to evaluate the full potential of the service.

It is clear that testing and evaluation needs to be done more in depth as the ELF service improves and develops and HERE will continue to test, evaluate and assist in any way needed.

Benefits, next steps and sustainability aspects following the implementation at HERE will be described in section 3, 5 and 6, together with related general considerations.

3.2 TomTom²⁶

The scope of the implementation at TomTom was to evaluate and integrate seamless data production of the TN-ITS service update from the road authorities in Norway and Sweden into the production process at TomTom and to evaluate the ELF platform services. The specific objectives of the TP implementation at TomTom were:

• Check the location referencing and mapping of information included in the TN-ITS service against TomTom map data.

• Check whether information included in xml files published through the TN-ITS service are correct and useful

• Explain the benefits of current usages of TN-ITS service and future usages

• Evaluate the ELF platform based on INSPIRE standards

The reference data used by TomTom in the implementation tasks are listed below:

• TomTom data: road network shape dumps, imagery layers

• Road network shape dumps from Trafikveket/Vegvesen NVDB database and web service (https://nvdb2012.trafikverket.se/SeTransportnatverket)

• TN-ITS services for the test;

Vegvesen Norway: http://rosatte-no.triona.se/ROSATTEDownload/download/querydatasets

Trafikverket Sweden: https://app.trafikverket.se/RosatteDownload-pt/download/querydatasets

• ELF data webservices:

http://demo.locationframework.eu/

https://security.locationframework.eu/wss/service/%3cname%3e/httpauth

In both services, TN-ITS xml files were provided for Sweden and for Norway with all new attributes except speed restriction, which was already captured in the previously working service for Sweden. The only exception consisted of the new service MaximumHeight attribute for Sweden, which was not included in the “line” Vehicle restriction feature (as it was in the data for Norway), but was presented separately as a “point” feature (see Table 1).

For the production of real time maps, TomTom experts base their updates on several sources to ensure the quality and verify the accuracy of road information.

To deliver high quality and fresh data to users of their map products TomTom needs to maintain a closed information loop of community input together with professional mapping. The result is a transactional map delivered as a real time product thanks to the incremental updates to the devices (see Figure 9 and Figure 10).

Figure 9 Intelligent mapmaking at TomTom © TomTom

Among the different sources used by TomTom, the TN-ITS service is seen as an authoritative source and is given weight in the validation of TomTom maps for the reason that the exchanged data are expected to be fresh and valid, coming directly from the “owner” of the physical regulations, with responsibility for signposting and white paint.

For these reasons, TomTom invested in the past years in being able to decode and read the data from the TN-ITS service. The TN-ITS service up to now proved to be the most efficient and consistent source for road authorities’ to provide road attributes linked to a geographical location.

Figure 10 Closed information loop at TomTom © TomTom

However, one limitation with using the TN-ITS updates in a commercial map-production environment is to validate the correctness and content with regard to location referencing and mapping of information.

TomTom has designed a step by step process to ensure quality and best match, and check whether information included in the TN-ITS service is correct and useful (together with a feedback loop for relevant errors).

Figure 11 Production steps to implement TN-ITS map updates at TomTom © TomTom

As we can see in Figure 11 the steps to integrate TN-ITS map updates in the TomTom production process are:

1. Download xml files from the national TN-ITS services

2. Decode OpenLR strings to TomTom map

3. Check if there is an acceptable match, e.g. locations which have a full geographical match to TomTom maps; these locations will go to an “Automatic attribution process” (step 5).

4. Check if there is no match or a poor match, e.g. location not matching or doubtfully matching to TomTom maps; these locations go to a “Manual attribution process” (step 6).

5. Automatic attribution process: if locations have an acceptable match, transactions are generated with updates to be applied to the TomTom map. In this process there are numerous quality rules checking compliancy with TomTom map requirements.

6. Manual attribution process: if the location does not match road geometry in TomTom maps, it goes to manual processing. In this step the ELF web service has been tested as an additional source of verification.

7. If the updates are rejected, the location or attributes are not applied to the TomTom database. Rejected locations of relevance for the TN-ITS supplier are fed back using email (for now).

8. The updated information is integrated in the commercial map and published as incremental updates for the customer’s devices.

TomTom generally experienced a good and stable performance of both the TN-ITS services provided by Norwegian Public Roads Administration and Swedish Transport Administration, and contributed through the OpenLR method of location referencing²⁷. Originally, OpenLR was designed by TomTom for more dynamic information, but it has now also been proven to be useful in handling static map data.

Benefits, next steps and sustainability aspects following the implementation at TomTom are described in section 3 and 5 together with related general considerations.

4 ELF testing and evaluation²⁸

4.1 Introduction to ELF

The purpose of ELF²⁹ is to deliver the European Location Framework required to provide up-to-date, authoritative, interoperable, cross-border, reference geo-information for use by European public and private sectors, and to create a sustainable European Location Framework for re-use of authoritative public sector reference geo-information at multiple levels of detail.

The framework is designed to include:

• Legal and administrative infrastructure

• Technical infrastructure; i.e. services for delivering data

• Data for the services

Through geo-tools implementing ELF specifications, the ELF platform will provide access to reference geo-information and services based on European national mapping and cadastral authorities (NMCAs) and other public sector geo-information. Value-added services can be developed utilising ELF cloud services.

The aim of the ELF project is further to establish a technical infrastructure that will provide up-to-date, interoperable, cross-border reference data from all over Europe for analysing and understanding information connected to places and features.

The background and framework for the ELF is the INSPIRE Directive with its technical, administrative and legal requirements. The ELF data will be delivered by ELF services through the ELF platform and provided to the users as ELF products.

The following Figure 13 shows the current scope of ELF. The main content of the Platform covers:

• Topographic Base Map

• Administrative Base Map

• Cadastral Index Map (for INSPIRE themes Cadastral Parcels, Buildings, Addresses, Administrative Units)

• Geolocator (For INSPIRE themes Geographical Names, Addresses, Administrative Units)

• Download Services (for INSPIRE themes Addresses, Administrative Units, Buildings, Cadastral Parcels, Elevation, Geographical Names, Hydrography, Land Cover, Protected Sites, Transport Network)

Figure 12 ELF Platform flow © ELF

Figure 13 ELF data coverage © ELF

Regarding licensing and data policy, the agreements with data providers will cover the terms and remuneration for use of their services in the ELF products. Access to data and services from data providers through the platform has to be secured by an agreement, even if the provider has open data.

The data provider can be the data owner as well, but it is assumed that when a data provider sets up services for third party data for delivery through the ELF platform, the data provider is representing the data owner. For the services based on existing EuroGeographics products, EuroGeographics is the data provider.

4.2 ELF testing

The commercial map providers involved in the transportation pilot were interested in testing the use of the ELF platform as an additional data source for thematic features such as buildings and addresses coming from authoritative data providers. However, the ELF platform might also prove useful in EU countries where a NVDB is not available from the National Road Authorities but can be obtained by INSPIRE compliant services through the ELF platform.

For the testing of ELF services carried out within the activities of the EULF Transportation Pilot, an evaluation licence was granted to TomTom and HERE, as partners of the project and first testers of the ELF platform³⁰, for access to the platform and use of data in particular from the Addresses and Transport Networks themes. The Transport Network theme was accessible through the ELF platform only for one municipality in Norway (as of November 2015, see Figure 14). The data coverage should be completed over the whole of Norway but has been delayed due to some technical difficulties in recalculating the total network topology as some data is lacking in the base information (NVDB). This will be overcome, but unfortunately the task will take more time than expected. More information on this activity will be included in a later version of this report.

Figure 14 ELF data coverage in Norway for the Transport Network theme

5 Location referencing³¹

5.1 Methods for location referencing

Location referencing is a technology to enable the unambiguous identification of a location, used to store and/or exchange information related to that location. More specifically, location referencing uses a code for the identification of a location, for exchange of location related information between a sending entity and a receiving entity via a communication medium. A typical location is a section of road in the road network, and typical information concerning a location is traffic information. Digital approaches to location referencing within the ITS sector may be used to exchange traffic information as well as other types of information, such as updates of information concerning road attributes, as is the remit of the TN-ITS framework. Today, location referencing is used for exchange of such information in situations where both the sending and the receiving entity deploy a digital map database, preferably of a comparable high level of detail, and of a comparable data specification.

Various methods for location referencing are described in (at least) the following standards/specifications:

• ISO 17572 - Intelligent Transport System (ITS)— Location Referencing for Geographic Databases

Part 1: General Requirements and Conceptual Model [14]

Part 2: Pre-coded Location References (Pre-coded Profile) [15]

Part 3: Dynamic Location References (Dynamic Profile); includes AGORA-C [16]

• ISO 19148 – Geographic Information - Linear referencing [17]

Also included in GML 3.3

• OpenLR™ Whitepaper [18]

• INSPIRE Generic Network Model (D2.10.1) [19]

Essentially three types of location referencing can be distinguished, namely linear referencing, Traffic Message Channel location referencing, and map-based location referencing.

The oldest is linear referencing. This is location referencing based on a system of predefined mileposts or hectometre locations along a well-defined road. A location is defined by a distance along the road from such milepost. According to ISO standard 19148 [17], linear referencing is a specification of a location relative to a linear element as a measurement along (and optionally a lateral offset from) that element. Note that linear referencing involves pre-coding, and is promoted by INSPIRE [9].

Another method for location referencing, using pre-coding of locations, was developed in the framework of RDS-TMC (Radio Data System - Traffic Message Channel) in the period 1988-1998. TMC location referencing is described in part 3 of the TMC standard [20]. TMC location codes are stored in a location table, together with additional information about the location. Due to bandwidth constraints of the RDS channel, the size of the TMC location code was chosen to be 16 bits, which limits the number of locations that can be stored in a TMC location table. Typically, location tables are created for a country or for a state in a country. Due to the limited number of codes that can be stored in a location table, only a limited part of the road network can be addressed. Further disadvantages of TMC location coding are the need to create, maintain and exchange location tables, and the limited resolution of point locations.

The third type in this family is map-based location referencing. In the mid 1990s it was realised that, in view of the above-mentioned limitations of TMC location referencing, it would be useful to investigate if an alternative would be possible, making use of information elements present in a map database to create an ad hoc location code on the sending side, and discarding the code after decoding on the receiving side. Preferably, the map databases on both sides of the chain are of a comparable high level of detail, and of a comparable data specification (for instance based on the Geographic Data Files (GDF) standard [21]). Other terms used for such an ad hoc approach for location referencing are on-the-fly location referencing and dynamic location referencing. The difference with TMC is that instead of using information from a location table for coding the location, information from the digital map database is used for this.

The AGORA-C method for map-based location referencing was published in April 2005 [22], as a substantial improvement of the AGORA method developed earlier. In tests the AGORA-C method demonstrated a hit rate above 98% and average code size below 40 bytes [23]. The specification was submitted to ISO and became part of ISO standard 17572 part 3 [14], "Dynamic location referencing", published several years later. The standard was substantially extended with elements that were not present in the core part of the original AGORA-C specification. IPR on the standard meant that AGORA-C, despite its excellent performance, did not see a wide-scale deployment in the industry.

Probably as a reaction, an alternative method was developed, named OpenLR, made public in 2009, which tried to circumvent the IPR related to ISO standard 17572 part 3. Although new IPR was vested in the method, it was stated by the owner, TomTom, that the method can be used under licence without any charge. However, like AGORA-C, wide-spread adoption of OpenLR seems to be hampered by the related IPR, in some ways due to the fact that the method is owned and controlled by just one company. OpenLR builds on AGORA-C concepts, but was designed in such a way that it attempts to avoid infringement of the AGORA-C-related patents. Reported success rates between map databases of different origin are lower than the success rates reported for AGORA-C.

The TN-ITS specification was developed during the ROSATTE project [11]. At that time, AGORA-C was selected as the primary method for location referencing, and only a container for holding a base64-encoded AGORA-C string was defined. However, in view of the publication of OpenLR, some testing was done during the ROSATTE project using OpenLR as the map-based location referencing method, simply by including instead of an AGORA-C location string an OpenLR location string.

The TN-ITS implementation that remained in operation in Sweden after the ROSATTE project used OpenLR as the map-based location referencing method. This implementation was limited to a few road attributes, and was only used between the Swedish Transport Administration and TomTom.

5.2 Linear referencing

In the INSPIRE Transport Networks Data Specification [9], linear referencing is used to locate so-called Transport Property features as events along the linear elements of the transport network. To be able to exchange data between parties using linear referencing, it is required that the parties recognise the same linear elements, using some scheme for identification, such as shared permanent identifiers in databases, or that mappings between different systems are known, described and unambiguous. In addition, the parties need to agree on how to measure along the linear elements using a linear coordinate (or measure). When these conditions exist and are implemented by the parties, linear referencing offers safe, accurate and flexible ways to exchange location information.

The figure below illustrates an exchange scenario where two parties have agreed on a representation of the network where the exchanged location needs to carry the information about the identity of the linear element and the measurements along the linear element where the event is located. The example below also illustrates a case where the event has a direction (there may be different speed limits in different directions). In this case, also the positive direction of the linear element needs to be agreed. It may also be noted that the datasets do not need to be exactly the same. There may be differences as long as the identity singles out the representation of the same thing in the real world, and the measurements and directions give an accurate enough result, given the requirements at hand.

Figure 15 Example of data exchange using linear referencing

5.3 Map-based location referencing

OpenLR and AGORA-C fall in the category of "dynamic" or "map-based" location referencing methods. These methods are particularly useful when the parties involved in an exchange of locations do not share a common representation (instances and identities) of the basic network (i.e. the conditions for linear referencing as described above are not fulfilled). As explained above, the principle behind map-based (or dynamic) location referencing is that the sender encodes certain information in a predefined and standardised way based on its own map instance. The receiver decodes that information and uses various algorithms to find the matching location in its map instance. This offers the advantage that the maps may differ (within certain limits). To accommodate such differences between the maps, there is some redundancy in the information for most instances, which may help to solve difficult cases. The drawback is that the exchange may fail and it may also sometimes result in false positives (i.e. decoding without errors but with the wrong result).

The figure below illustrates a similar case to the above. Instead of sharing identities, the sender needs to encode the location according to some scheme and the receiver needs to decode that information and resolve the correct location on the map. As illustrated in the figure, the representations of the networks may differ (within certain boundaries of course) and no identities are shared, but the process still in most cases will produce a correct result.

Figure 16 Example of data exchange using map-based location referencing

5.4 Static vs dynamic segmentation approaches

At this point, it is useful to look at the difference between static segmentation and dynamic segmentation³², something which is relevant in understanding the differences between the various types of location referencing. In principle, the difference is as follows:

• Using static segmentation, one creates a network where each element (spatial object) is homogeneous concerning all occurring attributes. This means that whenever an attribute changes, the network elements need to be split at that point. In principle it would be possible to represent a network as a collection of linear features with a number of attributes for each feature. Static segmentation is an approach that is more easily implemented and the data is easier to use as is, but it becomes very cumbersome when new attributes are needed, especially if the new attribute does not have the same segmentation as the existing attributes. Moreover, implementing a scheme for exchanging incremental updates at an attribute level becomes difficult;

• Using dynamic segmentation, one creates a network only taking into account the topological aspects of the network. This means that linear elements are split only where there are junctions (topological connections) in the network. Attributes are handled separately as overlays of events occurring along (parts of) the linear elements in the network, not influencing the basic network topology. Dynamic segmentation is very flexible when it comes to fulfilling new needs, e.g. new attributes since any new attribute can just be overlaid without impacting the current segmentation of the network. It is possible to generate a statically segmented dataset from a network and a selected set of overlaid event attributes. However, dynamic segmentation is an approach which is more complicated to implement and use, and a generated statically segmented dataset will not have stable persistent ids for the segments, since the segmentation may change over time.

In a predecessor to INSPIRE, EuroRoadS³³, both approaches were allowed. In INSPIRE however, only the dynamic segmentation approach is allowed.

Linear referencing is often used to implement a dynamic segmentation approach in relation to transport networks. When transport network data is related to the network as events (i.e. things that occur along a piece of the network) instead of segmenting the network wherever an attribute change value, this adds flexibility and makes it possible to add new types of data without affecting the basic network segmentation. With reasonably uncomplicated tools (also commercial off-the-shelf tools), a statically segmented view of a selection of the data may be created. This approach is used by both the Swedish Transport Administration and the Norwegian Public Road Administration in their national road databases, which are based on the principles of dynamic segmentation. This means that the basic road network is segmented based only on the occurrence of junctions. The junctions represent a topological choice on the chosen level of representation (road or carriageway). The features and attributes in Table 1 are connected as events along the linear elements (road segments) in the topological network using linear referencing mechanisms. That means that the segmentations for network, speed limits, road names, Functional Road Class and other attributes are independent and may therefore differ from each other. In order to achieve a dataset which is suitable for OpenLR-/AGORA-C encoding in a straightforward manner, a dataset is created and maintained where all segments are homogeneous with regards to all considered events (attributes) which are relevant for encoding the locations. The figure below explains the principles for that process.

Figure 17 - Principles for the homogenisation process on a road link with dynamic segmentation

The process results in a number of segments which are homogeneous with regard to all events (attributes). In everyday use, two methods may be used to get homogeneous attributes from the events:

• Homogenisation: A new segment is created wherever there is a break in the event (e.g. new speed limit value)

• Generalisation: When a value varies along a road segment, a representative value is selected for the whole road segment based on some principle such as mean value, lowest value, highest value…

An infinite number of features/attributes (events) may be added to the process and the method according to the above may be selected independently for each event (attribute).

The resulting dataset contains a road network with elements which are topologically connected by nodes in every junction, road end and also where segments have been created due to attribute value changes (these segments are connected by pseudo-nodes). Each element contains the geometry and has all the necessary attributes which are relevant in order to encode OpenLR or AGORA-C location references. This dataset is maintained and updated prior to every generation of TN-ITS updates in order to have an up-to-date basis for location reference encoding.

5.5 Implementing linear referencing for TN-ITS

Besides the overall goals of the pilot, one goal for the Norwegian and Swedish implementations of a TN-ITS service was to achieve the possibility of cross-referencing data provided by the TN-ITS service with data provided through an INSPIRE-compliant service. To achieve this in a transparent and service-independent way, INSPIRE-compliant linear referencing mechanisms were added to the TN-ITS specification and implementations. This addition to the TN-ITS specifications gives the following benefits for users of TN-ITS data:

• When the decoding of OpenLR locations fails, perhaps because data is missing in the receiving map database, the linear reference provided may be used to access the INSPIRE service to look up data of interest such as:

Geometry for the road segment

Attribution of interest such as road name/number, Form of Way, Functional Road Class

• The linear reference together with an INSPIRE service can be used for error checking to detect and locate false positives which may occur in an OpenLR scenario

For the linear referencing mechanisms to work as intended, it is vital that the identification of the linear elements corresponds between TN-ITS and INSPIRE and refer to exactly the same thing. For the Transportation pilot, we used the RefLink class/dataset from the NVDB which is mapped to RoadLinkSequence according to INSPIRE DS TN [9] in a 1:1 manner. The work done to implement linear referencing is explained in more detail in the Transportation pilot deliverable on Linear Referencing, available upon request³⁴. An outline of the work done in the pilot in relation to linear referencing is given below.

5.5.1 Changes to the ROSATTE specifications

The original TN-ITS specification from the Rosatte project [11] already included an abstract class Indirect Location Reference, as a placeholder for linear (or indirect) referencing. In the Transportation Pilot it was decided that adding a linear reference to a TN-ITS update message might enable the user of the TN-ITS updates (the ITS map providers) very direct and easy access in the road-authority map database to the location to which the update message relates. This may be very helpful in cases for which the decoding of the map-based location reference fails. A very quick inspection in the originating map database may assist the data user in obtaining a quick "manual" interpretation of the map-based location code, and in identifying the correct location.

In order to be able to use linear referencing in ROSATTE/TN-ITS, the deliverable D3.1 – Specification of Data Exchange Methods [11] needs to be updated.

Furthermore, the xsd-schemas need updating. The results of our proposals may be downloaded from the URL http://rosatte-no.triona.se/schemas which contains all schema files. The file that particularly changed for linear referencing may be downloaded from http://rosatte-no.triona.se/schemas/LocationReferencing.xsd.

Proposals for additions to the specification, including new UML, and description of the changes of the specifications is available upon request in detailed reports³⁴.

5.5.2 Changes to the ROSATTE implementation

The Swedish and Norwegian implementations used linear referencing as a basis for locating features and attributes as events along the network. In the implementation for OpenLR or AGORA-C, these locations need to be encoded into the representative OpenLR or AGORA-C location reference. This is a quite demanding task compared to encoding a linear reference.

In order to implement linear referencing according to the specification from INSPIRE we needed to consider the structure where a linear reference is defined by the parameters reported in Table 3.

Table 3 Parameters needed for the linear referencing definition

Parameter

Description

Solution

element

A reference (an identification) to the linear element

We use the identity of the RefLink in NVDB and that the exact same identity is used in the INSPIRE services.

At the moment, this is encoded according to the following xml fragment for NPRA:

<net:element xlink:href="NO.SVV.NVDB:LinkSequence:384562"/>

And the following for TrV:

<net:element xlink:href="SE.TRV.NVDB:LinkSequence:123:456"/>

The exact encoding of the identification needs to be agreed.

applicableDirection

An indication of the direction of the event in relation to the positive direction of the linear element

- bothDirections

- inDirection

- inOppositeDirection

NVDB at both TrV and NPRA use direction as a parameter which needs to be translated into the correct code.

Example:

<net:applicableDirection>inDirection</net:applicableDirection>

Note that a direction may be applicable to both linear and point events.

fromPosition

For linear events - the start position of the linear element, expressed as the distance from the start of the linear network element along its curve geometry.

NVDB at both TrV and NPRA use a relative measure (percentage) along the linear elements. Furthermore, the relationship between these values and the corresponding geometry may not be linear which complicates the calculation slightly. In the TNE³⁵ solution, the option to use extra linear measure values for the vertices of a linear geometry was used to enable environments such as ArcGIS to calculate the correct subsets of linear geometry for linear events based in the measure values.

Based on this fact, a 2D length (not considering altitude) along the geometry of the linear element in meters was calculated.

Example:

<net:fromPosition uom="meter">9514.406</net:fromPosition>

Costs of Linear referencing: the performance cost for linear referencing in this case has to do with the fact that the geometry of the referenced link has to be looked up for each linear reference in order to be able to calculate the actual lengths in metres (required by INSPIRE). Metres is not the native form for storage of the linear references in Sweden/Norway. If INSPIRE would allow for interpolative measures as well, this would not be an issue.

toPosition

For linear events - The end position of the linear element, expressed as the distance from the start of the linear network element along its curve geometry.

See above.

Example:

<net:toPosition uom="meter">9514.406</net:toPosition>

atPosition

For point events - Position of the point, expressed as the distance from the start of the linear network element along its curve geometry.

See above.

Example:

<net:atPosition uom="meter">9514.406</net:atPosition>

offset

An offset from the centreline geometry of the generalised link, where applicable; a positive offset is to the right in the direction of the link, a negative offset is to the left.

This is not considered for TN-ITS since NVDB does not record offsets.

The functionality for linear referencing uses some computer power and decreases performance slightly. Therefore, an extra configuration parameter (in app.config) was added where generation of linear references may be activated/deactivated:

<add key="INCLUDE_LINEAR_REFERENCE" value="true" />

The default is true, which means that the service will generate linear references.

The NVDB solutions in Sweden and Norway are both event-based. This means that the basic road network is segmented based only on the occurrence of junctions. The junctions represent a topological choice on the chosen level of topological representation (e.g. road or carriageway). The other data (e.g. safety features, technical, administrative) are connected as events along the linear elements (road segments) in the topological network using linear referencing mechanisms. That means that the segmentations for the network, speed limits, road names, functional road class and all other elements are independent and may differ from each other.

6 Assessment of added value³⁶

In order to assess the impacts of the Transportation Pilots’ activities some ex-ante interviews with representatives from the pilot partners were organised, to understand the ex-ante state of play regarding data exchange between public road authorities and commercial map providers in the countries involved in Phase 1 (Norway and Sweden), and furthermore to understand the potential benefits from the implementation of the Pilot.

Ex-ante interviews with the partners took place in November and December 2014. Questions considered included:

• the people and processes who will be impacted by the activities of the pilot;

• the significance of the processes involved relative to their overall workload;

• the nature of the current process and issues faced;

• the potential benefits of the Transportation Pilot and how they may be quantified; and

• the steps needed to ensure the benefits are realised.

As well as examining benefits for the particular stakeholders, more general benefits for citizens and businesses were also considered.

In the interviews, one of the commercial map providers confirmed that the main benefits could be linked with time savings, but probably the most critical aspect is the timeliness and quality of data, which is something that their customers take for granted. There is an issue on how to express the timeliness of data, and to understand the impact of more up-to-date data on the market. Apart from this, which represents a benefit from the specific exchange process tested, the pilot itself was seen as an opportunity to engage more countries in testing this process, and to promote a standardised approach to data sharing agreements with the public sector, across Europe.

The Swedish Road Authority had already implemented the TN-ITS exchange protocol during the ROSATTE project, and was able to identify benefits already. In particular, the TN-ITS exchange process had already enabled them to move from twice yearly to daily updates. This made no difference to their costs but enabled a much improved quality of service. Thanks to the pilot, TrV expanded the number of attributes and added linear referencing. The pilot explored the harmonisation of the road safety data exchange process across the Norwegian-Swedish border. Again, the quality and timeliness of the safety-related data is one of the main benefits expected by the pilot’s activities.

For National Mapping and Cadastral Agencies, the benefits linked to the pilot seem to be mainly in terms of marketing opportunities for the ELF platform and of the possibility to test the linear referencing method, both INSPIRE-compliant. Furthermore, the pilot was seen as opening up opportunities for connecting with thematic communities such as the road data community.

Although all the pilot testing (mainly related to ELF) had not been completed at the time of writing this report, an initial ex-post analysis was carried out with TomTom and HERE through a second set of interviews in July 2015 and additional analysis during the rest of the year. This analysis focused on the benefits of the implementation of the TN-ITS service in Sweden and Norway. The evaluation of the ELF services will be finalised in a later stage of the pilot project, once more evidence will be obtained.

The main outcome for the commercial map providers was the possibility of having access to up-to-date data. A benchmark activity that is performed on a regular basis by one of the map providers, comparing the performance of different competing navigation systems through driving on the roads, showed significant improvement comparing data on the whole Swedish network from 2013, before the implementation of the TN-ITS specifications, and from 2015, after such an implementation, with error rates on the accuracy of the speed limits signs going from 25% to 7% (i.e. with a reduction of 72%). More frequent data feeds, enabling more timely and accurate data, was also mentioned as a positive outcome of the TN-ITS implementation, especially for Norway, where the updates have moved from quarterly to daily. In Sweden before the pilot the TN-ITS service was already implemented and the updates were already communicated daily. They benefited from the extension of the pool of attributes and from the collaboration with Norway, enabling sharing of the data across the borders.

Another positive feature of the TN-ITS standard is that it delivers only changes to the data, while previously the commercial map providers had to search and compare huge datasets to detect the changes in the quarterly deliveries. Moreover, the TN-ITS source is lean as technology, and straightforward for implementing direct updates. It enables major timeline reductions from the official decision of a change of road data by the approved authority to its availability at the commercial map provider and eventually to end-users.

Better relationships with public road authorities is another benefit to be mentioned. The close cooperation to implement the TN-ITS service in both Sweden and Norway strengthened the relationship between public and private actors, and the close communication enabled the service to improve further.

As TN-ITS had been operational in Sweden since August 2013, it represents a proven technology: for example, since the start up to July 2016 TomTom has received updates for more than 36,000 km of road.

Thanks to the Transportation Pilot, there will be the opportunity of increasing the coverage of safety features to all roads. Since static information such as speed limits changes often, the effort to ensure correct information on all roads with traditional mapmaking is un-realistically high. The TN-ITS service also provides a way to ensure the representation and publication of road safety attributes on local road-networks, while today mostly speed-limit data on regional road networks is published and shared.

The investment done by commercial map providers to ensure a stable and fast data-chain all the way to end users could help motivate road operators to implement the TN-ITS standard throughout all Europe. However, according to the commercial map providers, to have more road operators implementing the service, coordination by the TN-ITS organisation and EU funding is essential. Although the ELF platform has been only initially tested by the commercial map providers, expected benefits can be outlined:

• the possibility to access information for several countries with same specification through one platform would provide easier access to official data and improve efficiency

• the possibility to access reference data and their latest updates on a map (e.g. addresses) might also improve efficiency

• the ELF platform can be used as additional data source to serve as cross reference in unclear situations, by requesting address information or similar.

In the following Table 4, the benefits of the Transportation pilot with reference with each EULF focus area³⁷ is summarised.

Moreover, as an acknowledgement of the good results of the approach tested in the Transportation pilot, ERTICO has successfully proposed an extension of the transportation pilot concept to five other countries (Belgium – Flanders, Finland, France, Ireland, UK) using funding from the Connecting Europe Facility – Transport strand. This work will run from January 2016 to December 2017. More information on this subject can be found in the section about sustainability below.

Table 4 Expected benefits of the Transportation pilot according to EULF focus areas

EULF Focus Areas

Expected Benefit

Policy and Strategy Alignment

Technical and organisational alignment of INSPIRE and ITS Directive

Support to EC Digital Single Market strategy³⁸, through improving the free flow of data between public and private sector

e-Government Integration

Improvement of Government to Business (G2B) road safety data exchange in support of road navigation services to citizens and businesses

Countries less advanced on their National Road Database can leverage the investment made with INSPIRE

Road authorities upgrade from quarterly to daily updates to map providers

Standardisation and Interoperability

Coordinated data exchange mechanism based on relevant standards

Commercial map providers which are international organisations are able to move from fragmented national processes to more standardised processes in different European countries.

Return on Investment

Tangible benefits to map providers and users in terms of reduced error rates (25% to 7% for speed limits), resulting in time savings for end users, while the cost has not changed

Reduced effort in handling incremental updates compared to handling full datasets

Minimal implementation costs for road authorities with mature road database

Realising EU investments in INSPIRE and ELF

Pilot approach is core to the business strategy of one of the map providers.

Sufficient evidence has emerged to warrant incorporating the pilot in operational processes.

Any additional ROI from ELF is still to be assessed.

Effective Governance and Partnerships

More effective public private partnerships

Improved collaboration between geospatial and thematic communities: pilot as a test bed where a thematic community which is interested in solving a common problem comes together and tries to address the problem by taking into account the location aspects and the solutions that INSPIRE and the geospatial technologies offer

Effective precursor to implementations in other MS, e.g. through the CEF Transport pilots³⁹

7 Sustainability⁴⁰

Although this is a pilot project, and the main focus is on daily data exchange with nominated partners, there will need to be appropriate policies and processes in place to support sustainable operation. For this reason, the National Road Authorities were interviewed in terms of their sustainability plans.

The following questions were asked:

• Is there is a specific plan for ensuring the continued daily provision of data to the commercial map providers after the completion of the pilot project;

• What are the current licensing conditions (Is the data open? Is the data open only for this particular exercise of the pilot? When the process becomes operational, will the data come at a cost?)

• Does the road authority plan to add other types of data in the exchange process, on top of the existing road safety attributes?

• Does the road authority plan to extend the use of the same exchange process with commercial map providers other than TomTom and HERE, thus giving the same opportunities to other players on the market?

• Does the road authority plan to make any change to their data management process from data collection to data provision (i.e. to ensure the exchanged data is as timely as possible, and as close as possible to the real world). For example if the data are generated at a local level, what is the plan for ensuring that local administration communicate the changes in the attributes in a timely manner?

• What is the retention policy for the data (i.e. how long will the exchanged data be made available?). If not in place, does the road authority have any plan for such a retention policy?

The intentions of the national road authorities of Norway and Sweden are summarised in Table 5. Both plan to continue the daily provision of data to the map providers, and their licensing conditions are open. Both stated that they would welcome the possibility to work with other commercial players in the future and to open up the update feed. About the possibility to exchange more data on top of the road safety attributes, this is a possibility for both countries. Moreover, for both the digitisation and the automatic update of the maps is also an opportunity to change the data management process, from collection to the provision, in order to ensure that the exchanged data is as timely as possible, and as close as possible to the real world. Priority will be given to the aspects pointed out by user demands.

In particular for Norway, the implementation of the service relies on the TRIONA infrastructure. The Norwegian Road Administration is working towards using NPRA infrastructure by end of 2016.

Regarding the plan at the commercial map providers, in both partners TomTom and HERE, there is the intention to continue to include the data feed from the road authorities in their production environment, as long as the road authorities provide these data updates. In particular for Sweden this integration is already in place, as the service has been implemented since 2013, as explained in the sections above. For Norway, there needs to be further testing before the integration can take place, in particular because for the pilot implementation the hosting server sits at TRIONA. NPRA plans are to migrate these services in their own servers by end of 2016 as already specified.

The TN-ITS exchange framework could also benefit from a more structured feedback loop: the commercial map providers feed back to the road authorities information about possible misalignment and errors that they find in the data. This is already done is a less formalised way by TomTom (see section 2.4.2). A more structured approach would improve the quality of the National Road Databases and indirectly the quality of the data updates they send to the commercial map providers through the TN-ITS protocol. However, such a structured mechanism is not yet in place, mainly due to the proprietary nature of the data held by the commercial map providers: the data that they would feed back would be the result of a combination of the data originally received by the road authorities, checked using data collected using other sources (e.g. probe vehicle, cameras, sensors) at their own expense and covered by commercial rights.

Table 5 Sustainability plans at the road authorities (Yes, No, Maybe)

Sustainability Aspects

Sweden

Norway

Plan for continued daily data exchange

Y

Y

Road authority licensing conditions: open

More data in the exchange process in the future41

Road authority supply to other commercial players in the future

Y

Y

Y

Y

M

Y

Change of data management process (from collection to provision)

Y

Y

Retention of historical data by road authorities

Y

M

Integration of data in the production environment of map providers

Y

In progress

8 Issues identified

The transportation pilot project described in this document, has been a truly collaborative effort between different partners that have been involved in a variety of activities, ranging from more technical ones to the dissemination of the project results.

There are various issues that have emerged during this 18-month project.

Some technical issues were already reported in the previous sections, and they concern mainly problems in map matching at the commercial map providers’ side. These problems are difficult to overcome, in that the public road authority database and the commercial map provider database will never be a one-to-one match (see section 3.1 and 2.4.2). Quality issues were also identified, in terms of freshness and accuracy of data. The daily update from the road authorities not always contained the real update “of the day”. The local authorities feeding the national database might still send their updates monthly or quarterly, and this does not ensure that the database always corresponds to the real situation on the transport network.

Linear referencing issues, described in section 5, are mainly related to the fact that, as explained in Table 3, the NVDB at both TrV and NPRA uses a relative measure (percentage) along the linear elements. Furthermore, the relationship between these values and the corresponding geometry may not be linear, which complicates the calculation slightly. The performance cost for linear referencing in this case has to do with the fact that the geometry of the referenced link has to be looked up for each linear reference in order to be able to calculate the actual lengths in metres (required by INSPIRE). Metres is not the native form for storage of the linear references in Sweden/Norway. If INSPIRE would allow for interpolative measures as well, this would not be an issue. Both TrV and NPRA are very keen on allowing also interpolative linear references (0-1) within the INSPIRE specifications and not only absolute (meters – which is the case today). If INSPIRE decided on a more comprehensive implementation of ISO 19148 [17] than the simplified version that exists today, this problem would be solved.

Another issue related to linear referencing resides in the fact that the INSPIRE TN Technical specifications allow only for a dynamic segmentation approach. This could be limiting, especially if National Road Databases adopting a different location referencing approach would have to implement TN-ITS. For this reason, three options have been identified, to be considered by INSPIRE team:

1. Keep the schemas as is, i.e. use a dynamic segmentation approach

2. Allow for both dynamic and static segmentation approaches, e.g. as was done in EuroRoadS

3. Allow only for a static segmentation approach. This alternative is not considered further since that would mean a complete change compared to the existing approach

From a data producer perspective, the current INSPIRE TN approach (option 1) will mean more work for those who use a static segmentation approach in their datasets. The method they will have to use is as follows:

• Generate a network from the set of segments in the transport network;

• Generate a transport property for each required attribute using a linear reference where the event starts and ends at the start and end of the network element. Since each transport property is a spatial object in terms of INSPIRE, some scheme for identity generation is needed for these objects.

This means that it is possible to implement option 1 even though it is not straightforward. From a data producer perspective, option 2 would mean that the existing data could be exported as is. From a data consumer perspective, an option with several possible ways to represent the same situation (option 2) means increased complexity. In addition, option 1 offers the advantage that attribute data (transport properties) may be exchanged separately which is the case in TN-ITS.

A further clarification needed on the technical side is the difference between the TN-ITS standard and the DATEX II standard. DATEX is a standard developed for information exchange between traffic management centres, traffic information centres and service providers. The second generation DATEX II specification opens to all actors in the traffic and travel information sector⁴².

DATEX II is used quite consistently for ITS applications, including for Cooperative systems (C-ITS). The main difference with TN-ITS is that DATEX II is used for traffic data and some of the dynamic road status data according to RTTI delegated regulation [6], while TN-ITS is used for static road data and some of the temporary road status data, defined in the same regulation. Moreover, DATEX II is deliberately location referencing agnostic and uses Open LR as a location referencing method, so it can be used with precise and less-precise approaches, while TN-ITS requires a constant and high degree of precision, hence linear referencing is more appropriate. It is worth noting that while DATEX II is a standard within CEN/TC 278⁴³ (ITS Standardisation) WG8 (Road Traffic Data), TN-ITS has been proposed as a formal standard to CEN/TC 278 (ITS) WG7 (ITS Spatial Data).

On a legal level, the policy applied to the data from public authorities should be clarified, both for data deriving from Road Authorities and Mapping Agencies (the latter is relevant if the ELF platform is used as additional data source). In the pilot countries, an open data policy is applied and governmental data can be used for commercial purposes without any restriction. Other European countries that apply a different data policy might restrict the use of government data to non-commercial purposes, or hinder redistribution of the data under other forms. This aspect might depend on a variety of legal and organisational factors, such as the national administrative and legal systems, but also on cultural and legacy systems. Therefore, if the pilot is to be extended to other countries, this aspect should be considered at the outset, in order to remove all the barriers to data accessibility. If data are not open, clear licensing conditions for use and reuse of data should be stated.

Among the organisational issues the long time needed to engage partners, and to setup collaboration agreements that meet the expectations of all the pilot partners are among the most important ones. At the pilot level this was solved by voluntary and informal agreements, as all the partners were recognising the added value of such an activity. However, on a large scale application this should be addressed with different instruments, before implementation starts. This has already happened in the case of the TN-ITS implementation in additional countries through the CEF funds, with clear rules of engagement and sharing mechanisms.

9 Conclusions and next steps

9.1 Lessons learned and some recommendations

The work of the EULF Transportation Pilot supports the European Commission proposal to fill the gaps in the provision of EU-wide real time traffic information services. The Pilot has shown that there is the need for all the actors in the ITS sector to overcome inadequacies in road data quality, timeliness and interoperability, and to exchange this data seamlessly across European borders.

The Transportation Pilot has been an opportunity for testing the TN-ITS specifications (previously ROSATTE), that was not done in the ROSATTE project, and where only the need for such testing was identified.

A learning that has been confirmed during the pilot, is that acting road authorities and map providers will probably never have the same specifications and therefore some of those challenges needs to be accepted.

The work in the Transportation Pilot is based on INSPIRE data specifications, in particular the TN-ITS standard and the ELF services.

There are specific recommendations coming out from the activities on the TN-ITS implementation and on the linear referencing application. For the linear referencing, possible recommendations were discussed in Section 8.

On TN-ITS implementation, it is recommended that in future the TN-ITS codelists are handled in the same way as INSPIRE codelists (i.e. as separate lists managed, available and accessible through the web).

In terms of recommendations to National Road Authorities, the implementations at the commercial map providers has highlighted the importance of having real changes reported effectively and accurately to the NVDB by different responsible authorities.

Moreover, the investment done by commercial map providers to ensure a stable and fast data-chain all the way to end users could, as a consequence, strongly motivate road authorities across Europe to implement the TN-ITS standard. However, according to the commercial map providers, to have more road authorities implementing the service, a coordination by the TN-ITS organisation and EU funding is essential.

Finally, it is worth noting that the TN-ITS standard could qualify as an extension to the INSPIRE Transport Network data specifications [9]. It could be therefore be appropriate to investigate the formal steps needed to integrate this work within the wider INSPIRE framework, for the benefit of data providers and users.

9.2 Next steps

A follow up of the Transportation Pilot in other 5 countries has been funded through the Connecting Europe Facilities Programme⁴⁴, and this will allow for more dissemination of the concept, testing and implementation as well as delivery of benefits across other European countries. In particular, the EU-ITS Platform has the aim of piloting the TN-ITS data exchange on selected corridors in Flanders, United Kingdom, Ireland, Finland and France. Although the starting point of these countries is different in terms of road database organisation and INSPIRE implementation, they are working together with the commercial map providers towards the same goal of implementing the TN-ITS standards and sharing road safety data in up-to-date feeds.

Other activities directly following from the Transportation Pilot include:

• exchange of incremental updates for other road attributes on top of those implemented in the Transportation Pilot, and for additional attributes as required by the Annexes of the delegated acts;

• take-up of the ITS Directive provisions in terms of digital maps in Member States that have less mature national road databases: they can use the databases set up to comply with the INSPIRE Directive;

• clarification of the licensing conditions applied to the data needed for TN-ITS data exchange, including the ones provided by ELF platform;

• Continued testing of the ELF platform;

• test the possibility to change the linear referencing requirements in the INSPIRE Technical Specifications, including interpolative measure and map-based location referencing as an option.

Moreover, the efforts of the Transportation Pilot can be leveraged and used to investigate how INSPIRE, TN-ITS and the effective use of location information can support:

• development of national single access points for traffic and travel information (as required by the ITS Directive) based on the experience of national data portals and geoportals;

• opportunities related to the use of open mapping platforms, in coordination with the authoritative data from National Road Authorities and Mapping Agencies, thus promoting transparency and openness, and supporting potential growth opportunities;

• improvement of data flows between a wider range of actors involved in road traffic management, considering both dynamic and static data and involving processes such as roadworks, accident management, traffic congestion etc.;

• work on priority Action a) on the provision of EU-wide multimodal travel information services (apart from priority Action b) discussed in this document), taking into account the INSPIRE data specifications for the Transport Networks and Addresses themes;

• clarification of the role of traffic data within the provisions of the Directive on the reuse of PSI, which is relevant when Public Administrations need to distribute traffic and travel data, in view of the Regulation on access to public and private transport data foreseen for adoption in late 2015.

• Investigation into the requirements for static road data and improvements needed to work alongside other location based capabilities associated with automated driving.

The items above are fully in line with the Commission strategies on Digital Single Market, Better Regulation and Public Sector Modernisation, and synergies can be sought with the follow up of the ISA Programme in the 2017-2021 timeframe.

References

[1] European Commission, ‘A Digital Single Market Strategy for Europe - COM(2015) 192 final’, Digital Single Market. [Online]. Available: https://ec.europa.eu/digital-single-market/en/news/digital-single-market-strategy-europe-com2015-192-final. [Accessed: 06-Dec-2016].

[2] European Commission, ‘Commission Staff Working Document SWD (2014)356, The provision of EU-wide real-time traffic information services’, 18-Dec-2014. [Online]. Available: http://ec.europa.eu/transport/themes/its/news/doc/2014-12-18-rtti/swd(2014)356.pdf. [Accessed: 09-Jun-2016].

[3] N. Vandezande and K. Janssen, ‘The ITS Directive: More than a timeframe with privacy concerns and a means for access to public data for digital road maps?’, Comput. Law Secur. Rev., vol. 28, no. 4, pp. 416–428, Aug. 2012.

[4] European Commission, ‘Directive 2007/2/EC of the European Parliament and of the Council of 14 March 2007 establishing an Infrastructure for Spatial Information in the European Community (INSPIRE)’, 2007. [Online]. Available: http://eurlex.europa.eu/JOHtml.do?uri=OJ:L:2007:108:SOM:EN:HTML. [Accessed: 10-Mar-2010].

[5] G. Giannopoulos, E. Mitsakis, and J. M. Salanova, ‘Overview of Intelligent Transport Systems (ITS) Developments in and Across Transport Modes’, Publications Office of the European Union, EUR - Scientific and Technical Research Reports, 2012.

[6] Eruopean Commission, ‘COMMISSION DELEGATED REGULATION (EU) 2015/ 962 - of 18 December 2014 - supplementing Directive 2010/ 40/ EU of the European Parliament and of the Council with regard to the provision of EU-wide real-time traffic information services’. .

[7] European Commission, ‘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’. .

[8] European Commission, ‘SWD/2014/0320 final - COMMISSION STAFF WORKING DOCUMENT Progress Report and review of the ITS action plan Accompanying the document Report from the Commission to the European Parliament and to the Council Implementation of Directive 2010/40/EU of the European Parliament and of the Council of 7 July 2010 on the framework for the deployment of Intelligent Transport Systems in the field of road transport and for interfaces with other modes of transport’, 2014. [Online]. Available: http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52014SC0320. [Accessed: 26-Jan-2016].

[9] INSPIRE Data Specifications team, ‘INSPIRE Data Specification on Transport Network - Technical Guidelines’, 2014.

[10]‘The EULF Transportation Pilot’, YouTube, 2015. [Online]. Available: http://www.youtube.com/watch?v=jnny5ATwTYE. [Accessed: 23-Jul-2015].

[11]‘ROSATTE D3.1 Specification of data exchange methods’, D 3.1, Aug. 2009.

[12]T. van de Ven and J. Long, ‘ITS Action Plan D7 - Final Report Action 1.3 Availability of Public Data for Digital Maps’, D7, Dec. 2011.

[13]TRIONA, ‘Drifthandbok för ROSATTE - TNE.Export’, 2012.

[14]‘ISO 17572-1:2015 - Intelligent transport systems (ITS) -- Location referencing for geographic databases -- Part 1: General requirements and conceptual model’, ISO. [Online]. Available: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=63400. [Accessed: 10-Jun-2016].

[15]‘ISO 17572-2:2015 - Intelligent transport systems (ITS) -- Location referencing for geographic databases -- Part 2: Pre-coded location references (pre-coded profile)’, ISO. [Online]. Available: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=63401. [Accessed: 10-Jun-2016].

[16]‘ISO 17572-3:2015 - Intelligent transport systems (ITS) -- Location referencing for geographic databases -- Part 3: Dynamic location references (dynamic profile)’, ISO. [Online]. Available: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=63402. [Accessed: 10-Jun-2016].

[17]‘ISO 19148:2012 - Geographic information -- Linear referencing’, ISO. [Online]. Available: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=32566. [Accessed: 10-Jun-2016].

[18]TomTom International, ‘OpenLR White Paper’, Version 1.5 rev 2, 2007.

[19]INSPIRE Data Specifications team, ‘INSPIRE Generic Conceptual Model - D2.10.1’. 04-May-2013.

[20]‘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. [Online]. Available: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=59232. [Accessed: 10-Jun-2016].

[21]‘ISO 14825:2011 - Intelligent transport systems -- Geographic Data Files (GDF) -- GDF5.0’, ISO. [Online]. Available: http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=54610. [Accessed: 10-Jun-2016].

[22]T. Hendriks, K. Wevers, M. Heßling, and H. W. Pfeiffer, ‘Specification of the AGORA-C on-the-fly location referencing method’, version 1.0, Jun. 2005.

[23]K. Wevers and T. Hendriks, ‘AGORA-C Map-Based Location Referencing’, Transp. Res. Rec. J. Transp. Res. Board, vol. 1972, pp. 115–122, Jan. 2006.

[24]M. T. Borzacchiello, R. Boguslawski, and F. Pignatelli, ‘INSPIRE as a driver for up-to-date ITS digital maps in Europe – benefit assessment’, 2015.

List of abbreviations and definitions

AGORA-C
The ISO Standard 17572-3 Intelligent Transport System (ITS)—Location Referencing for Geographic Databases—Part 3: Dynamic Location References, also known as “AGORA-C” is designed to improve the real-time accuracy of GPS and to allow the development of enhanced navigation services. AGORA-C specifies a method for dynamic encoding and decoding of location references—that is, the unique identification of geographic objects such as road junctions, exit ramps, and postal addresses—into any map, without requiring predefined location codes or lookup tables. AGORA-C is patented and licensed according to the description here.

OpenLR
OpenLR™ is a method for location referencing which accommodates requirements of communication of location between systems which have dissimilar maps. OpenLR™ is communication channel independent. It takes bandwidth requirements into account in the sense that OpenLR™ requires minimal bandwidth. OpenLR™ is a royalty-free technology and open Industry Standard. More information may be found here.

ROSATTE
ROSATTE was an EU-funded project, which ran between January 2008 – June 2010. The project produced a number of reports and specifications which were adopted by TN-ITS. More information at http://tn-its.eu/rosatte-project

TN-ITS
TN-ITS is concerned with the exchange of information on changes in static road attributes. Static meaning that the attributes are of a more or less permanent nature, even though they may sometimes change. More information at http://tn-its.eu/. The specification for TN-ITS is the specification developed within the ROSATTE project. Therefore, names of xml elements or software components still contain “ROSATTE”.

Direct location referencing
Direct location referencing uses a description of a location by geo-references (i.e. a description in reference to a geodetic reference system, e.g. latitude and longitude coordinates in WGS84). In the TN-ITS specification (Wikström et al., 2009), geo-references are often used synonymous to direct location references. AGORA-C and OpenLR use direct location references as part of the location description.

Indirect location referencing
Indirect location referencing describes a location by its logical reference to other objects (e.g. road segments, or nodes) in a digital database, which themselves hold direct geo-references for describing their location.

Linear referencing
Linear referencing is a kind of indirect location referencing. According to ISO 19148 linear referencing is described as a “specification of a location relative to a linear element as a measurement along (and optionally offset from) that element”

TrV
Swedish Transport Administration

NPRA
Norwegian Public Roads Administration

Commercial map providers
Private companies providing maps and navigation services (e.g. TomTom, Nokia/HERE)

The table below describes the TN-ITS components:

Component
Description

NVDB
This is the national road database that contains the necessary data structured according to NVDB specifications.

TNE UpdatingService
A service that incrementally updates the TNE database which is structured and optimised for GIS usage.

Other db
This is a potential complementary data source. This is not used in the solution for the Swedish NVDB.

TNE LoaderQueueService
A service that updates the TNE database from other data sources. This is not used in the solution for the Swedish NVDB.

TNE
A road database optimized for use within a GIS environment (e.g. ArcGIS). The same structure may be used for both basic NVDB data and for the TN-ITS data even though the various datasets may be stored in separate database instances. The database structure also contains facilities for update logging to be able to produce incremental update files for TN-ITS.

Segmentation service
A service that produces a network suitable as basis for location reference encoding based on principles of homogenization and generalization.

ROSATTE Conversion
A software service that incrementally translates NVDB data into a structure which complies with the TN-ITS specification.

ROSATTE Conversion plugin
Each specific safety feature is produced by a separate plugin module responsible for the specific data conversion.

LR encoder
The location referencing encoder (AGORA-C or OpenLR) is implemented as a separate plugin module. Available encoders are AGORA-C and OpenLR

ROSATTE export
A software service that outputs datasets according to the TN-ITS xml schemas (GML) which are ready to be provided via the download service.

WsDownload
A RESTful web service which responds to requests according to the TN-ITS specification.

WsFeedback
A RESTful web service which requests feedback information from the feedback service at the map provider. This is not used in the solution for the Swedish NVDB. Feedback (from consumer to producer) is a part of the TN-ITS exchange specification, primarily as means to improve data quality. However, it is still being discussed in the community what would be the most useful ways of doing this.

Feedback visualisation ArcMap
An ArcMap plugin used to match feedback information with provided datasets and visualize the result. This is not used in the solution for the Swedish NVDB.

List of figures

Figure 1 - Stakeholders and schematic view of the Transportation Pilot

Figure 2 Generic data flow from Road Authority to Map Provider used in the Transportation Pilot

Figure 3 Detailed data flow from Road Authority to Map Provider used in the Transportation Pilot. Circled in red are the parts related to the implementation at the National Road Authorities

Figure 4 - Deployment view of the implementation of TN-ITS service in Norway and Sweden

Figure 5: TN-ITS implementation workflow at HERE (high level) © HERE

Figure 6: Fallout – Different geometry representation © HERE

Figure 7: Fallout – Deviations in specifications (Bearings not matching) © HERE

Figure 8: Fallout – Missing geometry in HERE map © HERE

Figure 9 Intelligent mapmaking at TomTom © TomTom

Figure 10 Closed information loop at TomTom © TomTom

Figure 11 Production steps to implement TN-ITS map updates at TomTom © TomTom

Figure 12 ELF Platform flow © ELF

Figure 13 ELF data coverage © ELF

Figure 14 ELF data coverage in Norway for the Transport Network theme

Figure 15 Example of data exchange using linear referencing

Figure 16 Example of data exchange using map-based location referencing

Figure 17 - Principles for the homogenisation process on a road link with dynamic segmentation

List of tables

Table 1 List of provided attributes in the EULF Transportation Pilot

Table 2 TN-ITS Implementation steps in Sweden and Norway

Table 3 Parameters needed for the linear referencing definition

Table 4 Expected benefits of the Transportation pilot according to EULF focus areas

Table 5 Sustainability plans at the road authorities (Yes, No, Maybe)

Notes

¹ For an overview of the EU ITS Actions please see: http://ec.europa.eu/transport/themes/its/maritime_inland_navigation_en.htm

² http://ec.europa.eu/transport/themes/its/news/2016-01-21-c-its_en.htm

³ http://inspire.ec.europa.eu/index.cfm/pageid/2/list/7

⁴ For an overview of the other application areas, please refer to the JRC report [5].

⁵ Delegated regulation expected by end 2016.

⁶ DATEX is a standard developed for information exchange between traffic management centres, traffic information centres and service providers. The second generation DATEX II specification opens up the standard to all actors in the traffic and travel information sector. See www.datex2.eu

⁷ http://ec.europa.eu/DocsRoom/documents/9773/attachments/1/translations/en/renditions/native

⁸ http://ec.europa.eu/growth/tools-databases/mandates/index.cfm?fuseaction=search.detail&id=568#

⁹ http://ec.europa.eu/isa/actions/02-interoperability-architecture/2-13action_en.htm; https://joinup.ec.europa.eu/community/eulf/description

¹⁰ http://www.vialicensing.com/licensing/agora-overview.aspx; or http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=45962

¹¹ http://www.openlr.org

¹² The original extended version of this section was written by Kees Wevers, ERTICO.

¹³ http://tn-its.eu/rosatte-project

¹⁴ Cooperative ITS (or C-ITS) is the term used to describe technology which allows vehicles to become connected to each other, and to the infrastructure and other parts of the transport network, see http://ec.europa.eu/transport/themes/its/c-its_en.htm

¹⁵ A method to determine the traffic speed based on the signals sent by mobile phones present in the vehicle that is driven

¹⁶ The original extended version of this section has been written by Lars Wikström and Audun Moa, TRIONA (Norway)

¹⁷ Contacting eulf-info@jrc.ec.europa.eu

¹⁸ The original extended version of this section has been written by Lars Wikstrom and Audun Moa, from TRIONA (Norway)

¹⁹ NVDB: National road database (Nationell vägdatabas). For Sweden: www.nvdb.se/en; for Norway: www.vegvesen.no/en/Professional/Roads+and+transport/National+Road+Data+Bank+NRDB

²⁰ www.triona.se/produkter_tjanster/produkter/transport_network_engine/

²¹ see http://tn-its.eu/rosatte-project

²² Contact eulf-info@jrc.ec.europa.eu

²³ This documentation may be provided upon request to eulf-info@jrc.ec.europa.eu

²⁴ The original extended version of this section has been written by Anna Forsell, HERE.

²⁵ Base64 is a group of similar binary-to-text encoding schemes that represent binary data in an ASCII string format by translating it into a radix-64 representation (Wikipedia)

²⁶ The original extended version of this section was written by Tom Jensen, TomTom.

²⁷ OpenLR method is developed by TomTom.

²⁸ The original extended version of this section was written by Olaf Ostensen and Saulius Urbanas, ELF project.

²⁹ Extensive documentation on ELF can be found at http://elfproject.eu/; http://locationframework.eu/

³⁰ See http://www.eurogeographics.org/news/eulf-transportation-pilot-first-test-elf-delivery-platform

³¹ The original extended version of subsection 2.6.1 has been written by Kees Wevers (ERTICO), while the originals of the remaining subsections have been provided by Lars Wikström (TRIONA)

³² Also discussed in the INSPIRE community of practice at https://themes.jrc.ec.europa.eu

³³ http://www.euroroads.org/php/start.php

³⁴ Contacting eulf-info@jrc.ec.europea.eu

³⁵ TNE: Transport Network Engine, a Triona solution

³⁶ The original version of this section has been published in [24]

³⁷ More information on EULF focus areas can be found on https://joinup.ec.europa.eu/community/eulf/description

³⁸ http://ec.europa.eu/priorities/digital-single-market/

³⁹ http://ec.europa.eu/transport/themes/infrastructure/ten-t-guidelines/project-funding/cef_en.htm

⁴⁰ This section in based on inputs provided by Per Isaksson, TrV and Martin Friedriksen, NPRA.

⁴¹ The partners have agreed on wish list of attribute that will be integrated step by step in the production environment using the TN-ITS standard

⁴² See www.datex2.eu

⁴³ See http://www.itsstandards.eu/index.php/work-areas

⁴⁴ More information available at https://eip.its-platform.eu/activities/sa-47-provision-updates-its-spatial-road-data