User guide

User guide

General DATEX II guideline

Introduction

This part of the document portal gives a general overview to understand what DATEX II is. It represents an introduction and a help to understand more specific descriptions of parts of DATEX II.

What is DATEX II?

DATEX II is a standard for the traffic and travel information sector to share data to deliver a comprehensive information service to the end user.

DATEX II was designed and developed as a traffic and travel data exchange mechanism by a European task force set up to standardise the interface between traffic control and information centres.

DATEX II provides to road operators and road data providers, documentation, UML model and XML tools to exchange road data in a homogenous way.

Background of the DATEX II standard

Delivering European Transport Policy requires co-ordination of traffic management and development of seamless pan European services. With the aim to support sustainable mobility in Europe, the European Commission has been supporting the development of information exchange mainly between the actors of the road traffic management domain for a number of years. In the road sector, the DATEX standard was developed for information exchange between traffic management centres and constitutes the reference for applications that have been developed in the last 15 years.

Much investment has been made in Europe both, in traffic control and information centres over the last decade and also in a quantum shift in the monitoring of the Trans European Network.

Collecting information is only part of the story – to make the most of the investment data needs to be exchanged both with other centres and, in a more recent development, with those developing pan-European services provided directly to road users.

DATEX was designed and developed as a traffic and travel data exchange mechanism by a European task force set up to standardise the interface between traffic control and information centres. It has been the reference for applications that have been developed and implemented in Europe. The existing DATEX network consists of 50 to 60 operational nodes organised in different network and node types throughout Europe. The majority of nodes are used for national exchange of data, but some of them support international exchange.

Alongside the DATEX pre-standards, a Data Exchange Memorandum of Understanding (DATEX MoU) covering international exchange of traffic data was formally established in October 1997. The MoU confirmed in a formal manner that the development of international traffic data exchange would be based on the DATEX technical specifications, and it established an organisational framework that enabled users to influence and participate in the developments. The signatories of the current DATEX MoU decided to work on a revised MoU which is more focused on the availability of traffic and travel data to third parties.

It should be noted that many of the original signatories were participants in the Euro-Regional projects which form the EU deployment programme for ITS, know as the TEMPO Programme, involving more than 80 organisations from 14 Member States and three neighbouring countries.

The development of DATEX II was begun in late 2003 and has been supported and partially funded by the European Commission who see it as playing a fundamental role in the ITS domain within European states. This role now extends from traffic control centre / road authority usage to include all types of service provider usage in the ITS domain. Its data content domain is also now extended from the trunk / motorway / TERN road network to include urban network information. Thus DATEX II is aimed at a very wide user base which is far broader than that of the original DATEX specifications.

The original DATEX specifications suffered from a number of shortcomings which made it unlikely to achieve “plug and play” interoperability between DATEX nodes from different manufacturers. Updating the technology, addressing the interoperability issues and the latest stakeholder requirements were the key drivers in the development of DATEX II. DATEX II was not intended to be a rigid set of specifications, but rather one that allowed a degree of choice and one that was able to evolve to allow stakeholders to exchange additional new types of information in the future. However, interoperability between disparate DATEX II systems was still given a high priority.

A first version (1.0) was then produced at the end of 2006 and was then quickly disseminated among countries. The corresponding implementations raised a number of mistakes and requests for change.

Then, a first proposal for the next version was issued in July 2009. The new stable version was called “2.0”, basis of the technical specifications issued by CEN (CEN/TS 16157:2011). This version and its model evolved until the 2.3 version.

A third version was submitted as a standard in CEN in December 2016. And the European Standard was issued by CEN in 2018. (CEN/EN 16157:2018).

Platform Independent data model

The DATEX II development focussed on the production of a set of reference documents which make a very clear distinction between data (content) and exchange mechanisms. The main part of the work has been focused on the subject of Traffic and Travel Data Models. The technical description provides a very clear distinction between platform independent modelling aspects (PIM) and platform specific modelling aspects (PSM). PIM aspects are described in UML. In each case, a clear distinction between the data modelling (referring to traffic domain) and the data exchange specifications (referring to information and communication technology) were introduced. This approach has been chosen, as it provides several advantages:

  • The separation of these aspects provides better understanding of the standard to the users and makes it easier to apply.
  • The platform independent aspects can be considered as more stable than the platform (and technology) specific aspects.
  • The project has produced explicit models in Unified Modelling Language (UML), which define the contents of DATEX Traffic and Travel publications independent of the exchange mechanism or implementation technology.

Model extensions: A, B, C

Level A specification

DATEX II v3 delivers a data mode also called “Level A data model” which is the result of studies on data which are shared by a lot of users in Europe. Nevertheless, there will be situations where data concepts required by a specific user are missing in the Data Dictionary, for example because they only make sense in a National context. In this case, these users are expected to provide an extension to the model (named “level B”) that provides the missing concepts. Users are allowed to apply a limited set of well-defined UML mechanisms for these level B extensions, which then still maintain technical interoperability with standard DATEX II systems. This means that standard (i.e. level A) compliant systems will still be able to process publications generated from an extended model, of course without being able to process the extension content. Specialised clients can process the full content – including the extension – but of course can also process standard (i.e. level A) publications. The main principle of level B is thus that users find the level A model appropriate for a large part of their publications. This may not be the case if entirely new concepts outside the scope of the level A model are introduced. In this scenario, DATEX II users are still expected to apply the modelling rules and the UML profile described in the standards, which will provide them with a basic level of interoperability. These models are denoted as “level C”. Implementations that provide publications according to level C extensions cannot expect to be interoperable with standard level A systems.

The extended model - “Level B” Extension mechanisms

Although the “A” model is rich, over time there will always be cases where new applications, both at national and international level, will want to add additional concepts and attributes to the existing models. To cater for this future proofing aspect of the modelling it is desirable to have a formal mechanism by which the “A” model can be extended. For these new applications requiring extensions to the “A” model, the concept of Level B compliance has been created. This will allow development of specific models that will enrich the “A” model with additional, application specific information. These models/applications will remain interoperable with “A” model compliant suppliers/consumers: they can exchange objects structured according to these enriched models. Suppliers/consumers that want to make full use of the information defined by these extensions to the “A” model will need additional software or metadata driven software to handle the additional application specific information. A registration process for level B model extensions is available on the DATEX II website (www.datex2.eu), under the authority of the DATEX TMG. Once an extension achieves a major degree of consensus it would become a candidate to be absorbed into a new version of the formal DATEX II level A.

Level C Extensions

Using the DATEX II concepts within different contents – “Level C” Users and Models - after consideration of Level A and Level B compliance rules some users within the ITS domain may still find that there is no way that their specific data models can be accommodated. They are just too different from the Level A model or else cover completely different contents. That’s why the concept of “level C” has been created. Level C implementations are to be considered as not compliant with the DATEX II Level A/B content models. However, they are to be compliant in all other aspects of the DATEX II specifications. Obviously these Level C compliant systems would not be interoperable with Level A compliant systems, but at least they would use common modelling rules and common exchange protocols. This would allow opportunities for the exchange of ideas and modelled concepts which may in the future lead to common model elements facilitated via some sort of model registration process. It will also permit many helpful software tools to be used with Level C compliant contents.

Note

For more in depth information on extensions go to the extension guide.

Data dictionary

The DATEX standard provide definitions which are readable by traffic engineers and IT experts alike. As the definitions for the data content in DATEX II are only stored within the UML model, which are not simply accessible for reading by non-IT professionals, a readable data dictionary is available via a software tool which automatically extracts the definitions from the UML model. An excel file with the dictionary can be found here.

XML schemas

Today there is a growing market and use of XML for information exchange. A fundamental part of this approach are the XML Schemas. Based on a data model and a data dictionary, the XML Schema are designed to fit a certain area of applications. The schemas are the tool to understand the content of the exchanged data. A conversion tool has been developed to convert the UML DATEX II data model into a set of XML schemas. The UML model is first exported from the UML modelling tool into an XMI file which the conversion tool then converts to a set of XML schemas. The XML schemas are used for development of real exchanges, by software developers . XMI (XML Metadata Interchange) is an OMG standard for exchanging metadata information via XML. It can be used for any metadata whose metamodel can be expressed in MOF (Meta-Object Facility). The most common use of XMI is as an interchange format for UML models, although it can also be used for serialization of models of other languages (metamodels). The following figure shows the workflow for an automated conversion process.

../../_images/workflowautomatedconversionproces_userguide.jpg

Exchange mechanisms

Generally speaking, DATEX II offers a push and a pull mode for information exchange. The push mode (as in DATEX) allows the supplier to send information to the client while the pull mode allows the client to request the download of information from the supplier’s systems. In detail, DATEX II provides the exchange mechanisms as described below. At a high description level document for details), without considering the notion of technical platforms, data exchange between a supplier and its client(s) can be accomplished by three main operating modes:

  • Operating Mode 1 - Publisher Push on occurrence
    • data delivery initiated by the publisher every time data is changed
  • Operating Mode 2 - Publisher Push periodic
    • data delivery initiated by the publisher on a cyclic time basis
  • Operating Mode 3 - Client Pull
    • data delivery initiated by the Client, where data is returned as a response.

Each Operating Mode can be both on- and offline. For the “Client Pull” operating mode, two implementation profiles have been defined for implementing this operating mode over the Internet: by direct use of the HTTP/1.1 protocol or via Web Services over HTTP. For the “Supplier Push” operating modes, one platform has been defined using Web Services over HTTP. The common corresponding document, describing all operating modes and both profiles for Client Pull as well as their interoperability, is [Exchange PSM]. PSM exchange documents have been designed to be independent from the exchanged content (the payload). These documents can be studied without knowing the details of the UML DATEX II data model.

DATEX II Profile

DATEX II allows exchange for several kinds of data via several Exchange Specific Platforms. Not all of those PSM’s have necessarily to be implemented in every DATEX II system and not all data content need be implemented. Thus DATEX II allows the implementation of profiles. “Profiling” aims to define a customised subset of options offered by a standard for a particular need.

The profiling guide section of the portal gives an in depth description of the profiling methodology.

What is a Profile?

A DATEX II system is composed of different publications which can be delivered with different Exchange PSM’s. Each DATEX II system builder chooses to implement the subset of couple publications - Functional Exchange Profile + Exchange Pattern(FEP+EP) implemented by an Exchange PSM based on his needs. This subset is called a « DATEX II profile ».

The need is to have profiles and options that allow DATEX II users to customize their implementations in order to provide more or less functionalities/facilities as necessary and not to be forced into implementing all the features. DATEX II allows every user to define a profile according to his own requirements whilst keeping interoperability on common parts (publications, operating modes) with other users.

What must the stakeholder choose?

Because different needs for different use cases of DATEX II may lead to the definition of different profiles, this step will require close stakeholders’ involvement to elicit their requirements. Moreover, profiling will require assessment of the cost/benefit trade-off, in particular of:

  • standard features/services;
  • implementation platforms; and
  • level of service that must be achieved.

Stakeholders need to provide their own perspective which will influence the main choices to be made concerning:

  • the list of publications to be exchanged,
  • the Exchange Requirement to be fulfilled and Exchange Features to be implemented,
  • and sometimes also specific technology PSM’s, options.

Evolution from V2.0 to V3.0

The main conceptual modifications from DATEX II v2.0 to DATEX II v3.0 are:

  • modularisation,
  • definite split between data and exchange,
  • ability to include external data structures,
  • proper exchange PIM and PSM’s.

The main modifications about content are:

  • addition of
    • missing information elements
    • approved v2.x extensions
    • flexibility when using linear referencing systems;
  • improvement of
    • extensibility
    • information structures
    • consistency of accidents and vehicle obstructions;
  • introduction of
    • a new location referencing system based on ISO/PRF TS 21219-22 “OpenLR™”;
    • a new location referencing g system for linear features based on GML LineString;
    • features to deal with 3D coordinates and accuracy assessment;
  • enabling the mark up of Safety Related traffic information according to Commission Delegated Regulation (EU) No 886/2013;
  • remodelling of
    • the cause of traffic situations, better fitting the operational use;
    • the “PredefinedLocationsPublication”
  • removal of:
    • the TrafficView,

Note

More details can be found in the release notes.

Overview of the exchanged data

Introduction

Before diving into the UML model, this chapter presents the exchanged data. Exchanged data are made with basic elements which are available inside publications.

This presentation is a functional one, and do not present elements in the order of the UML model. Click here for datamodel and details about classes and attributes.

Basic elements

Information exchanged with DATEX II systems is composed of different basic elements:

  • Road and traffic related events (called “Traffic elements”),
  • Operator actions,
  • Impacts,
  • Measured or elaborated data (e.g. travel times, measured traffic speed, elaborated traffic status, weather measurements…),
  • Messages displayed on Variable Message Signs (VMS),
  • Service information (no rest area, delays on trains…).

In addition, there are also Predefined Locations, Parking table, VMS Table and Measurement Site Table information exchanged. They are not part of the basic elements, but are required if the corresponding information in the basic elements is to be understood by a client.

Operator actions

Operator actions are classified in 4 main categories:

  • Network management: road closure, alternate traffic, contraflow …
    • traffic control: rerouting, temporary limits
  • Roadworks: resurfacing, salting, grass cutting …
  • Roadside assistance: vehicle repair, helicopter rescue, food delivery …
  • Sign settings: This refers to a VMS message.

Impacts

It contains, in particular, information on lane availability and on delays (in seconds, in time range or globally).

Measured or elaborated data

These sets of data can be derived from direct inputs from outstations or equipments at specific measurement sites (e.g. loop detection sites or weather stations) which are received on a regular (normally frequent) basis, or can derived on a periodic basis by the Traffic Centre from input data for specified locations:

  • measured traffic values about:
    • flow,
    • speed,
    • headway,
    • concentration
    • individual vehicle measurements,
    • normally published as measured data, but can be derived on a periodic basis and published as elaborated data,
  • traffic status:
    • free flow, heavy, congested, impossible, unknown,
    • normally published as elaborated data, but direct outstation derived values can be published as measured data,
  • travel times:
    • elaborated time, free flow time, normally expected time,
    • normally published as elaborated data, but direct outstation values can be published as measured data,
  • weather values:
    • precipitation, wind, temperature, pollution, road surface condition and visibility,
    • it can be measured, or can be derived on a periodic basis and published as elaborated data,

They can be forecast values.

Service information

It means information about a service which may influence the behaviour of drivers and hence the characteristics of the traffic flow, i.e.:

  • transit information,
    • Information about other transport means,
    • For example, cancellation, or delay, on a tram, train, plane, etc. journey,
  • service disruption (rest area closed, no diesel…),
  • road service disruption (no patrol, emergency call out of order …).

VMS messages

These data sets include different possible messages according to different technologies, including textual messages, pictograms or combinations as well as allowing for full matrix VMS. They are completed by some information about equipment status and position.

Publication of basic elements

The previous basic elements can be exchanged individually or grouped. For these exchanges, the notion of publication is used. There are 5 main publications:

  • Situation publication
    • For traffic elements, operator actions, impacts, or service information,
  • Elaborated data publication,
    • for traffic status, and for travel times,
    • If relevant, for traffic values and weather values,
  • Measured data publication,
    • for traffic values and weather values,
    • and if relevant, for traffic status, and for travel times,
  • Parking Publication,
    • for parking information
  • VMS publication,
    • for VMS messages

Situation publication

A situation publication can contain several different situations.

A situation represents a traffic/travel situation comprising one or more traffic/travel circumstances which are linked by one or more causal relationships and which apply to related locations. Each traffic/travel circumstance is represented by a Situation Record.

A situation record is one element of a situation. It is characterized by values at a given time, defining one version of this element. When these values change, a new version is created. One situation record can be:

  • A road or traffic related event (traffic element),
  • An operator action,
  • A non-road event information,

and can contain:

  • Impact details.

Elaborated data publication

This publication is used to send periodically elaborated data derived by a Traffic Centre relating to specified locations. Locations may be explicitly defined in the publication or, more simply, may be referred to by references to predefined locations which have been exchanged via the “predefined locations” publication.

Measured data publication

This publication is used to send periodically measured data which has been derived from equipment at specific measurement sites, where each site is identified by reference to an entry in a predefined measurement site table. The measurement site table can be exchanged via the “measurement site table” publication and provides for each site the details of its location and parameters associated with the different types of measurements that can be made at the site.

Each set of measurements from a site is ordered (i.e. indexed), where each ordered measurement might be of a different type. The order (or indexing) of these measurements for each site within the Measured Data publication must correspond with the ordered (indexed) definition of the measurement in the Measurement Site Table publication for the particular site.

VMS publication

This publication is used to send periodically messages elaborated by a Traffic Control Centre relating to a set of display equipments among a road network. Static VMS characteristics may be explicitly defined in the publication (for mobile VMS e.g.) or, more simply, may be referred to by references to predefined VMS installations which have already been exchanged via the “VMS table” publication.

Note

This display is just an example in a tree representation of a traffic view and does not imply any specific traffic view requirements. Representations of traffic views can be done in many other ways and is open to implementation design.

Details of UML data model content

Introduction

Objectives

This section is intended to assist readers in understanding the structure and content of the DATEX II UML model.

When reading this section, the Data Dictionary tool and documentation which groups all definitions (classes, attributes, enumeration values …) may also be of help.

Prerequisite

The UML model is available on the DATEX web site in two format:

  • an Enterprise Architect .eap file. The reader must have one Enterprise Architect tool version installed in order to read the model .
  • The UML model may also be directly navigated on the website (html version)

The reader should be familiar with UML modelling.

The UML basic class diagram elements used in the model are presented briefly in this section.

Modelling methodology

For more details of the UML features used in the model please refer to the modelling methodology section.

Logical diagrams structure

All the diagrams are in the same Namespace called “D2Payload”. This namespace gathered logical diagrams in 3 namespaces:

  • Common: contains all the classes, the datatypes and enumerations that are in common with all publications.
  • Extension: is a placeholder for containing the elements composing possible extension.
  • LocationReferencing: contains classes about locations.

and 1 package:

  • PayloadPublication: containing description of publications data to be exchanged.

The logical diagram hierarchy is as the titles in the next parties. This hierarchy is synthetized in the datamodel.

PayloadPublication

The payloadPublication package contains 4 namespaces. Situation is standardized as version 3.0 and described below. The other namespaces have a different status and can be found here.

Situation and SituationPublication

A situation publication can group several situations.

Situation definition: An identifiable instance of a traffic/travel situation comprising one or more traffic/travel circumstances which are linked by one or more causal relationships. Each traffic/travel circumstance is represented by a Situation Record.

Warning

Each situation has a unique versioned identifier. This versioned identifier comprises a part established when the situation is first created in a DATEX II system database and kept within that system for all its life. The second part (“version”) is established at every new version of the situation.

Such mechanism allows having several versions of the same situation in the same publication The situation severity on traffic can be indicated: “overallSeverity”.

If this situation relates to another situation, its reference can be indicated: “relatedSituation” (this reference is the “versioned identifier” of the corresponding situation object).

With this publication, attributes can be given in the InformationHeader which provide clients with information management details (area of interest, confidentiality, urgency, information status) relating to this situation.

Note

Special case: when the Supplier sends SituationPublication to Clients in Operating Mode 1 “Publisher Push on occurrence”, the situation management has to follow different rules.

Situation record

A situation may be composed of one or more situation records.

Situation record definition: An identifiable instance of a single record/element within a situation.

This class is abstract.

Each situation record has a unique versioned identifier. This first part of this identifier is established when the situation record is first created in the DATEX II system database. It is completed by a version part. The first part is kept within that system for all its life. The subsequent versions of this situation record must differ by their version part of the identifier. If the situation record is forwarded down a supply chain, each DATEX II system within that chain will assign its own unique identifier to the record when it first creates a corresponding record in its database, but the (compound) identifier created by the original supplier in the chain may optionally be forwarded in the record’s situationRecordCreationReference attribute.

In DATEX Version 3.0, the SituationRecord class and adds the attribute “safetyRelatedMessage” of type Boolean. This attribute indicates, whether the corresponding SituationRecord specifies a safety-related message according to the Commission Delegated Regulation (EU) No 886/2013 with regard to data and procedures for the provision, where possible, of road safety-related minimum universal traffic information free of charge to user. A subset of DATEX II elements, which should be used to meet the requirements of the delegated regulation, can be found in the document “Safety related message sets –Selection of DATEX II Codes, TPEG2-TEC-Causes and TMC-Events for EC high level Categories” from the ITS Directive Working Group.

It is located with one group of locations.

It can have one cause.

It can have one impact on the traffic (when the record type is “TrafficElement” or “OperatorAction”), qualified with:

  • Indications on delays (code, value range, value)
  • Other details (capacity remaining, effect on lanes, restriction type)..

Source information can be given (country, identifier, name, type, if reliable or not)

A situation record has a validity composed of:

  • An validity status which defines if the record has an “active” or “suspended” status, or this status is defined according to periods of time,
  • One mandatory global first start time “overallStartTime”,
  • One optional global real end time “overallEndTime”,
  • One or several validity periods, each having a start date and an end date, for which the situation record is active/valid, detailed with hours/days/weeks/months,
  • One or several exception periods, each having a start date and an end date, for which the situation record is not active/valid, detailed with hours/days/weeks/months,
  • The optional “overrunning” means the activity/action is still in progress, overrunning its planned duration as indicated in a previous version of the record.

Remarks for forecasts:

  • When a record is created, with a start time in the future, it means it is a « forecast » and therefore for traffic elements, probabilityOfOccurrence should never have the value « certain ».
  • When this start time arrives, the Supplier should update or end this information if it has not really occurred. If a supplier does not provide updated information at this time a client can not assume that the traffic element is now active, only that it was predicted to be active now.

There are 3 main categories of situation records:

  • Traffic element: An event which is not planned by the traffic operator, which is affecting, or has the potential to affect traffic flow (note this does includes events planned by external organisations e.g. exhibitions, sports events etc.).
  • Operator action: Actions that a traffic operator can decide to implement to prevent or help correct dangerous or poor driving conditions, including maintenance of the road infrastructure.
  • Non-road event information: Information about an event which is not on the road, but which may influence the behaviour of drivers and hence the characteristics of the traffic flow.

These 3 categories are detailed in the following paragraphs.

TrafficElement

This class is abstract.

There are 6 kinds of traffic elements:

  • Abnormal traffic,
  • Activity
  • Accident,
  • Conditions
  • Equipment or system fault,
  • Obstruction,

Obstruction

Any stationary or moving obstacle of a physical nature (e.g. obstacles or vehicles from an earlier accident, shed loads on carriageway, rock fall, abnormal or dangerous loads, or animals etc.) which could disrupt or endanger traffic.

This class is abstract.

For each obstruction type, the number of obstructions can be given.

For each obstruction type, details can be given of:

  • Mobility type: mobile/stationary,

There are 5 kinds of obstructions:

  • Animal presence (alive or not, presence type)
  • Environmental obstruction (depth, type),
  • Infrastructure damage obstruction (type),
  • General obstruction (type),
  • Vehicle obstruction (type + individual vehicles characteristics)
  • Abnormal traffic: A traffic condition which is not normal.

Details can be given: type, number of vehicles waiting, queue length, relative traffic flow, traffic flow characteristics, traffic trend type.

Accident

Accidents are events in which one or more vehicles lose control and do not recover. They include collisions between vehicle(s) or other road user(s), between vehicle(s) and any obstacle(s), or they result from a vehicle running off the road.

Details can be given:

  • cause type,
  • accident type,
  • overview of people involved (number, injury status, involvement role, type),
  • overview of vehicles involved per type (number, status, type, usage),
  • details of involved vehicles (type + individual vehicle characteristics)

Equipment or system fault

Equipment or system which is faulty, malfunctioning or not in a fully operational state that may be of interest or concern to road operators and road users. The type of equipment or system and the type of fault must be given.

The type of equipment or system and the type of fault must be given.

Activities

Deliberate human actions external to the traffic stream or roadway which could disrupt traffic. Details must be given in term of: types of authority operations / disturbance / public event, and possibly in term of mobility(mobile/stationary).

Conditions

Any conditions which have the potential to degrade normal driving conditions. A general indicator can be given with 8 possible values “drivingConditionType”:

  • impossible,
  • very hazardous,
  • hazardous,
  • passable with care,
  • winter conditions (driving conditions are consistent with those expected in winter),
  • normal,
  • other,
  • unknown.

There are 3 conditions categories:

  • road surface conditions that are related to the weather which may affect the driving conditions, such as ice, snow or water,
  • road surface conditions that are not related to the weather but which may affect driving conditions, such as mud, oil or loose chippings…,
  • environment conditions which may be affecting the driving conditions without being directly linked to the road (precipitation, visibility, pollution, temperature, wind)
Operator action

For each operator action type, details can be given of:

  • Origin: internal / external,
  • Status: requested, approved, being implemented, implemented, rejected, termination requested, being terminated,
  • Considered action plan

There are 4 kinds of operator actions:

  • Roadworks,
  • Sign setting,
  • Network management,
  • Roadside assistance.

Roadworks

Highway maintenance, installation and construction activities that may potentially affect traffic operations.

This class is abstract.

Details can be given of:

  • duration,
  • scale: major / medium / minor
  • under traffic or not,
  • urgent or not,
  • mobility type: mobile / stationary,
  • construction work type: blasting / construction / demolition, road improvement, road widening,
  • road maintenance type (e.g. grass cutting, resurfacing, repair, road marking, salting…,
  • subject type of works (e.g. bridge, crash barrier, gantry, road tunnel,…,
  • information on associated maintenance vehicles

Network management

Changes to the configuration or usability of the road network whether by legal order or by operational decisions. It includes road and lane closures, weight and dimensional restrictions, speed limits, vehicle restrictions, contra-flows and rerouting operations.

There are 6 types of network management:

  • Rerouting management (type, itinerary description, sign posted or not,…),
  • Speed management (type, speed value),
  • Road, carriageway or lane management (type, specified lane or carriageway, minimum number of persons in a vehicle required for HOV/car pool lane),
  • Winter driving management (type),
  • General instructions to road users (type),
  • General network management (type of management and type of person that is manually directing traffic in case of manually directed traffic).

Information on whether the network management instruction or the control resulting from a network management action is advisory or mandatory shall be given.

Other details can be given:

  • In which traffic direction the traffic management is applicable,
  • For which vehicles the traffic management is applicable,
  • If the traffic management instruction has been automatically initiated or not,
  • The places (defined in generic terms) where the network management applies (e.g. at toll plaza, in galleries, at high altitude, on slip roads, on the crest of hills),
  • Vehicles characteristics for which the network management applies,

Roadside assistance

Details of roadside assistance required.

The roadside assistance type can be given: food delivery, helicopter rescue, vehicle repair …

Service information

There are 3 kinds of Service information:

  • transit information,
    • Information about other transport means,
    • For example, cancellation, or delay, on a tram, train, plane, etc. journey,
  • service disruption (rest area closed, no diesel…),
  • road service disruption (no patrol, emergency call out of order …).

PayloadPublication (non-standardized parts)

Warning

This publication in the version 3 PIM contentmodel is structured according to the version 2 content, mapped to the version 3 methodology, enabling the use of version 3 tooling. However: this publication is NOT an interoperable representation of the version 2 standard. The standard is in the process of revision according to CEN procedures and an update of this Publication is foreseen end of 2018. When these namespaces in this section are used the resulting data exchange is not compliant to any version of the DATEX II standard.

The following namespaces in payloadPublication contain the publications that are structured according to the version 2 informationmodel according to the version 3 methodology.

Each of them contains its specific classes, datatypes and enumerations. Moreover, they gathered their own publications:

  • Parking:
    • ParkingTablePublication
    • ParkingStatusPublication
    • ParkingVehiclesPublication
  • RoadTrafficData
    • ElaboratedDataPublication
    • MeasuredDataPublication
    • MeasurementSiteTablePublication
  • VMS
    • VMSpublication
    • VmsTablePublication

Each publication must have:

  • its creation time “PublicationTime”,
  • the language to be used by default,
  • a description of the information which is to be found in the publications originating from the particular feed (URL), “FeedDescription”,
  • a feed type, which is a classification of the information which is to be found in the publications originating from the particular feed.
  • a publication creator which is an international identifier: a two-letter country enumeration (and “other”) plus a national identifier in that country. This creator may be different of the publication supplier.

The following paragraphs detail each publication. The location referencing, which is used by every publication, is detailed in a dedicated paragraph.

Parking

Warning

This publication in the version 3 PIM contentmodel is structured according to the version 2 content, mapped to the version 3 methodology, enabling the use of version 3 tooling. However: this publication is NOT an interoperable representation of the version 2 standard. The standard is in the process of revision according to CEN procedures and an update of this Publication is foreseen end of 2018.

ParkingStatusPublication

Objectives and utilisation mechanisms

This publication is used to give information on dynamic data of parking sites or groups of parking sites (e.g. free spaces, trends, vehicle count on the parking site …). The publication refers to static information about a parking site or groups of parking sites prior published with the ParkingTablePublication (by using the concept of versioned references).

ParkingTablePublication and ParkingStatusPublication are in accordance with the Commission Delegated Regulation (EU) No 885/2013 about the provision of information services for safe and secure parking places for trucks and commercial vehicles.

Content

The following topics can be covered by this publication:

  • Occupancy information for a parking site, a group of parking sites or a group of parking spaces (all declared in the static model and referenced in this publication):
    • Number of spaces (as an override in case of dynamic changes)
    • Number of vacant spaces (as a number, as a ‘higher than’ or ‘lower than’ information as well as in an enumerated form)
    • Number of occupied spaces (as a number, in enumerated form as well as in trend form)
    • Number of parking vehicles
  • Information on individual parking spaces (occupied or free, temporary closed)
  • Overriding thresholds: It is possible to override the static threshold information, i.e. the defined fill grades of a parking site for which the dynamic status information should change between different states (incl. overcrowding states)
  • Status information: A state information on the fill grade of a parking site incl. overcrowding information (in limited form also for a group of parking sites)
  • Validity of parking space- and group of parking space-declarations: Spaces might be temporary closed or defined for mixed usage (i.e. declaration not valid all the time).
  • Information about the availability of additional equipment or additional service facilities (overriding the amount, current availability, opening and vacancy information).
  • Fill- and exit rates (sensor data, which can be based on a static MeasurementSiteTable information)
  • Vehicle count within interval, i.e. incoming or outgoing vehicles or change of occupancy within time

By defining the validity of the dynamic information, it is possible to publish real time data, historical data or forecasts. It is also possible to publish series over time.

ParkingTablePublication

Objectives and utilisation mechanisms

This publication is used to publish static information of parking sites or groups of parking sites. This comprises urban or interurban parking sites as well as special facility and (secure) truck parking information. It covers on street parking as well as off street parking (car parks, parking places, motorway parking areas …). Within a parking site, information can be specified down to groups of parking spaces or even for individual parking spaces. There are four minor Level B extensions entailed in this publication:

  • Area is extended to specify a polygonal area
  • Point is extended to specify junctions
  • Period is extended to specify special days and holidays
  • VehicleCharacteristics is extended to specify additional vehicle types, loads and emission information

The static information forms the base for dynamic occupancy information, for which you should use the ParkingStatusPublication.

ParkingTablePublication and ParkingStatusPublication are in accordance with the Commission Delegated Regulation (EU) No 885/2013 about the provision of information services for safe and secure parking places for trucks and commercial vehicles.

Content

Because of the size of this publication, it is not described on attribute level here. The description is focussed on included subjects instead:

  • For parking sites, groups of parking spaces or individual parking spaces the following assignments can be specified as convenient, as allowed or as not allowed:
    • Specified type(s) of users
    • Specified type(s) of vehicles (incl. hazardous materials)
    • Time (for mixed usage of parking spaces, for example day usage for cars, night usage for lorries).
  • Basic information (number of spaces, reservation information, short or long term parking, …), each also possible for individual groups of parking spaces (i.e. for example it is possible to specify the possibility of reservation just for a part of the parking site or to specify the number of parking spaces for lorries).
  • Special Permits for users or vehicles (e.g. disabled permit, government permit)
  • Permitted or prohibited actions on the parking site (e.g. smoking, camping)
  • Contact information (address, telephone number etc.) for the parking site as well as for several other stakeholders or services (e.g. owner, reservation service, …)
  • Entrances and exits with characteristics and geo-reference
  • Opening times, expressed by the detailed validity model
  • Additional equipment and additional service facilities (long list of items, like for example toilets, internet, restaurants, police station) optional each with opening times, tariffs, location, validity or restriction to users or vehicles
  • Electric charging stations (incl. technical parameters and connector types)
  • Information on the LABEL-categorisation and on security measures
  • Tariff information in a complex structure, for different charge bands, depending on user or vehicle type and for different seasons (incl. different types and modes of payment, payment cards and reservation fees)
  • Thresholds, i.e. defined fill grades of a parking site for which the dynamic status information should change between different states (incl. overcrowding states)
  • Parking Routes incl. geo-reference, direction and colour information
  • A colour mapping to occupancy states
  • Parking scenario (truck parking, rest area, car sharing, mechanical drop off, …)
  • Geo-reference information (all methods which are available in DATEX) for all elements

The following two pictures show information on assignments, dimensions and Geo-referencing, which can be specified with the Parking Table Publication:

../../_images/assignmentsanddimensionsinparkingtablepublication_userguide.jpg

../../_images/georeferenceinparkingtablepublication_userguide.jpg

ParkingVehiclesPublication

Objectives and utilisation mechanisms

The ParkingVehiclesPublication allows specifying information on specific parking vehicles. The publication refers to static information about a parking site or groups of parking sites prior published with the ParkingTablePublication (by using the concept of versioned references).

Content

For a parking vehicle, the following information can be specified:

  • Reference to the parking space used
  • The parking period
  • The parking permit
  • Information about the vehicle, like licence plate information or vehicle characteristics
  • Information on the individual charge, including the paid amount or the method of payment

The process of parking must not yet be finished; it is possible to omit the end of the parking period.

RoadTrafficData

Warning

This publication in the version 3 PIM contentmodel is structured according to the version 2 content, mapped to the version 3 methodology, enabling the use of version 3 tooling. However: this publication is NOT an interoperable representation of the version 2 standard. The standard is in the process of revision according to CEN procedures and an update of this Publication is foreseen end of 2018.

ElaboratedDataPublication

Objectives and utilisation mechanisms

This publication is used to give information that is in some way elaborated or derived. Typically, this is data which has been elaborated by a traffic centre from input data held in its database.

Content

This publication contains one or more elaborated data sets.

With this publication, attributes can be given in the InformationHeader class which provide clients with information management details (area of interest, confidentiality, information status, urgency) relating to this publication.

A set of default values for “forecast”, “period” and “time” can be provided to clients which are applicable throughout the publication if no others are provided at the detailed level. This helps in minimising the size of publications where large numbers of values are sent which share common parameters.

Also to assist in minimising the volume of required values to be sent for traffic status covering wide expanses of a road network, ReferenceSettings can be provided to a client. ReferenceSettings comprise a reference to a predefined set of non-ordered locations (see Predefined Locations publication) and a default value that can be assumed by a client for the traffic status at all these locations if none is received. Thus a supplier only needs to send for those locations the actual values of traffic status which deviate from this default value.

Source information can be given (country, identifier, name, type, reliable) for each elaborated data.

A validity can also be given (as for situation records) composed of:

  • An validity status which defines if the record has an “active” status or this status is defined according to periods of time (one can consider the third possible value “suspended” is not applicable for this kind of data element).
  • One mandatory global first start time “overallStartTime”
  • One optional global real end time “overallEndTime”
  • Several periods, each having a start date and an end date, for which the elaborated data is active/valid, detailed with hours/days/weeks/months
  • Exception periods, each having a start date and an end date, for which the elaborated data is not active/valid, detailed with hours/days/weeks/months.

The optional “overrunning” is not applicable for this kind of data element.

It can be indicated if the elaborated data is a forecast.

In case of fault when elaborating this data, it is possible to specify the type of fault (intermittent data values, no data available, spurious unreliable data values, unknown fault or other).

Each elaborated data item comprises a Basic Data value.

MeasuredDataPublication

Objectives and utilisation mechanisms

This publication is used to give measured data which has been derived from equipment at specific measurement sites, where each site is identified by reference to an entry in a predefined measurement site table.

Content

This publication contains measurements from one or more sites.

With this publication, attributes can be given in the InformationHeader which provide clients with information management details (area of interest, confidentiality, information status, urgency) relating to this publication.

The measured data publication must contain a reference to the measurement site table used.

Each set of site measurement values must always contain a reference to the measurement site and a measurementTimeDefault which is the default time for each measured value if no other time is specified for an individual measurement.

Each set of site measurements has an ordered (indexed) list of measured values, where the order (index) corresponds with the measurement definition order (index) in the Measured Site table. So there is no need for any further identification for each measured value. The values that are measured are referenced by the index in the ordered list of values for that site.

A measured value can identify the type of measurement equipment used.

A measured value can also have a Location characteristics override. This is used to override the predefined lanes attribute and to indicate a reversal of flow compared with that was defined in the Measurement Site table.

In case of fault when measuring this data, it is possible to specify the type of fault (intermittent data values, no data available, spurious unreliable data values, unknown fault or other).

Each measured value comprises a Basic data value.

However the following points are of note for its use in the Measured Data publication:

  • The point at which the measurement equipment is located (i.e. the site) is defined in the appropriate entry in the Measurement Site table. However, if the measurement relates to a section of road or a location (e.g. ANPR which determines measurements over a stretch of road) this can also be provided in the “pertinentLocation” which is an aggregation associated with the BasicData.
  • TrafficStatus and TravelTimeData are normally provided as Elaborated data, but may be provided as Measured data if appropriate (e.g. because values are provided by an outstation).
Basic Data

Basic data value is a general abstract class which has the following attributes:

  • Time precision, precision to which time of calculation or measurement is given
  • Period (in seconds)
  • Time, the time when basic data value was measured or elaborated.

Each Basic Data value can have a pertinent location. (see “location” paragraph). Generally, this location is identified by reference; see the paragraph concerning predefined locations.

Basic Data values are of one of the following types:

  • Travel Time data
  • Traffic Status
  • Traffic data
  • Weather data

The following paragraphs describe each of these basic data types:

Travel Time data

It has the following specific attributes:

  • Travel time trend type: decreasing, increasing, stable
  • Travel time type: best, estimated, instantaneous, reconstituted
  • Vehicle type for this travel time.

It may be also associated with:

  • Travel time (in seconds)
  • Free flow travel time
  • Normally expected travel time, as well as
  • Free flow speed

Traffic Status

It has the following specific attribute:

  • Traffic trend type: traffic building up, traffic easing, traffic stable, unknown.

and can be associated with

  • Traffic status value: Impossible, congested, heavy, free flow, unknown if it differs from the reference value given for the publication

Traffic data

This value is usually sent as Measured Data, but may also be sent as Elaborated Data.

Traffic values can be classified on the basis of Vehicle characteristics.

There are 5 kinds of traffic values:

  • Traffic headway
  • Traffic flow
  • Traffic speed
  • Traffic concentration
  • Individual vehicle measurements (not applicable for elaborated data).

Weather data

This value is (usually sent as Measured Data, but may also be sent as Elaborated Data).

There are 7 types of weather values:

  • Precipitation information,
  • Wind information,
  • Temperature information,
  • Pollution information,
  • Road surface condition information,
  • Visibility information,
  • Humidity information.

However, the following point is of note for its use in the Elaborated Data publication:

  • Traffic values and weather values are normally provided as Measured data, but may be provided as Elaborated data if appropriate (e.g. because values are provided by calculation).
MeasurementSiteTablePublication

Objectives and utilisation mechanisms

The Measurement Site Table publication is used to provide information relating to predefined measurement sites and the measurements that can be made at those sites. The sites and the details of their measurement characteristics are seen as static or quasi static (i.e. they seldom change).

The measurement site details and their measurement characteristics are referenced by Measured Data publications which enable these publications to be efficient when large volumes of measured data values need to be conveyed.

Content

This publication contains one or more measurement site tables.

With this publication, attributes can be given in the InformationHeader which provide clients with information management details (area of interest, confidentiality, information status, urgency) relating to this publication.

The Measurement Site table has a unique versioned identifier.

The Measurement Site table has a list of Measurement site records, each corresponding to a single measurement site. Every Measurement site record has a unique versioned identifier and the following attributes:

  • Computation method,
  • Measurement equipment reference,
  • Measurement equipment type used,
  • Measurement site name,
  • Measurement site number of lanes,
  • Measurement site identification,
  • Measurement side,
  • Measurement site record version and time.

The Measurement site record always has a single location.

Every site record must also have an ordered list of Measurement specific characteristics. This ordered (indexed) list of characteristics relates to the types of measurements that can be made at that measurement site. The ordering is significant because this order (indexing) is used in the Measured Data publications to distinguish between the different measurements received from the referenced site.

Measurement specific characteristics contains information about:

  • Accuracy
  • Period
  • Smoothing factor
  • Specific lane
  • Specific measurement value type.
  • Specific vehicle characteristics

These values are seen as static for the particular measurement at the site and do not have to be repeated for each measured value in the Measured data publication, unless they need to be overridden in particular cases (see Measured data publication section).

VMS

Warning

This publication in the version 3 PIM contentmodel is structured according to the version 2 content, mapped to the version 3 methodology, enabling the use of version 3 tooling. However: this publication is NOT an interoperable representation of the version 2 standard. The standard is in the process of revision according to CEN procedures and an update of this Publication is foreseen end of 2018.

VmsPublication

Objectives and utilisation mechanisms

This publication is used to give information on the current status and settings of one or more variable message signs (VMS) units, each unit controlling one or more individual variable message signs.

Content

This publication contains one or more VMS units.

With this publication, attributes can be given in the InformationHeader class which provide clients with information management details (area of interest, confidentiality, information status, urgency) relating to this publication.

Each VMS unit must always contain a reference to a versioned VMS Unit table and a reference to a versioned VMS unit record in this VMS Unit table which defines the characteristics of the VMS unit.

A VMS unit may control one or more variable message signs on a single gantry or on different gantries.

The VMS class provides the current status and settings of the VMS and the currently displayed information. Where a VMS is displaying a sequence or alternating set of messages these are ordered according to the messageIndex qualifier. Each VMS associated with a VMS unit is referenced by its vmsIndex. The vmsIndex also provides a reference to the specific VmsCharacteristics (defined in the VmsUnitTablePublication) that are relevant for the VMS which is controlled by the referenced VMS unit.

To assist in minimising the volume of required values to be sent for VMS messages covering wide expanses of a road network, characteristics of VMS and VMS units can be provided to a client using the VmsTablePublication.

In case of fault of VMS site or of VMS, it is possible to specify the type of fault (communication failure, power failure, out of service, incorrect message or pictogram display, unable to clear down, unknown fault or other).

A VMS is composed of:

  • A general item if the VMS is working and about message sequencing interval in seconds, if applicable.
  • The Text Display Area Settings (text lanterns, text luminance level, and luminance override).
  • An ordered set of Pictogram Display Area Settings, one for each display area (picto lantern, picto luminance, …). Each pictogram display area on a VMS is referenced by its “pictogramDisplayAreaIndex” and details of its position relative to the text or its absolute position may be provided in VmsPictogramDisplayCharacteristics.
  • An ordered set of VmsMessages. The messageIndex provides the ordering of a sequence of displayable messages. The VMS is displaying each message in turn according to its messageindex “order”. The sequence of messages displayed is continuously cycling.

In case a VMS is not defined previously in a VmsTablePublication, its static characteristics must be provided about:

  • Its location in term of position (vmsLocation – practically defined with a point) and in term of managed logical location i.e. the road section (defined as a location reference) where the VMS is applicable.
  • Its physical characteristics with VMS text display characteristics and VMS pictogram display characteristics. As a VMS may have several pictogram areas, every one is referenced by its pictogramDisplayAreaIndex. Every area may be completed by VMS supplementary panel characteristics.

These latter classes are defined more in details in the subsequent VMS table publication. Each elaborated data item comprises a Basic Data value.

Every VMS message comprises several elements. The adopted modelling takes into account different types of messages, with or without displayed text of several lines (in sequence), with or without pictogram display, each pictogram can have a VMS supplementary panel. The general information includes:

  • VMS message information type (situation warning, travel time, traffic management, date and time, temperature, campaign message, instruction, future information).
  • Time, the time when message was lst set
  • Coded reason for setting (situation, campaign, operator created, traffic management, travel time or default) and the associated management or diversion plan.
  • The authority, organisation or system which requested the setting of the message and the one which set it.
  • References towards the related situations and situation records for which the message is related.
  • Distance of the VMS from the location of the related situation record/element

A VMS message includes:

  • One or several text pages. Where multiple pages of text are defined each is referenced by its “pageNumber” and is displayed sequentially according to the “pageNumber” order in the same display area.
  • Each VMS text page comprises one or several lines of text. Where multiple lines of text are defined each is referenced by its “lineIndex” qualifier and is ordered accordingly. The VMS text line is also defined by the text itself, its colour, the used language, if it is flashing or not.
  • One or several VMS pictogram display areas. Each pictogram display area on a VMS is referenced by its “pictogramDisplayAreaIndex” and details of its position relative to the text or its absolute position may be provided in VmsPictogramDisplayCharacteristics.
  • Each VMS pictogram display area may display one pictogram or a sequence of pictograms. The order of sequencing of the pictograms is defined by the “pictogramSequenceIndex” values.
  • Each VMS pictogram can be defined by one or several pictogram description, a code, the value of distance,, length, weight or width to be displayed on the pictogram, if the pictogram is in inverse colour or if there is presence or red triangle or not, if it is compliant with the Vienna convention on road signs and signals, …
  • A pictogram can be supplemented by one VMS supplementary panel which consists in one VMS text line (see above for description)
VmsTablePublication

Objectives and utilisation mechanisms

The VMS Table publication is a publication containing one or more VMS Unit Tables each comprising a set of records which hold details of VMS units. The VMS sites and the details of their characteristics are seen as static or quasi static (i.e. they seldom change).

The VMS tables and their VMS unit characteristics are referenced by VMS publications which enable these publications to be efficient when large volumes of displayed messages need to be conveyed.

Content

This publication contains one or more VMS unit tables.

With this publication, attributes can be given in the InformationHeader which provide clients with information management details (area of interest, confidentiality, information status, urgency) relating to this publication.

The VMS unit table has a unique versioned identifier.

The VMS unit table has a list of VMS unit records, each corresponding to a single VMS unit (entity managing one or several physical VMSs).

Every VMS unit record has a unique versioned identifier and the following attributes:

  • Number of VMS,
  • VMS unit identifier,
  • VMS unit electronic address,
  • VMS unit IP address,

Every VMS unit record must also have an ordered list of VMS records containing the physical characteristics and the location of each VMS. This ordered (indexed) list of these characteristics relates to different display areas on the VMS. The ordering is significant because this order (indexing) is used in the VMS publications to distinguish between the different display areas.

The VMS record can have until two location references. The first one gives the physical VMS location in term of position (vmsLocation – practically defined with a point) location references and the second one gives its managed logical location i.e. the road section (defined as a location reference – practically defined with one or several linears) where the VMS is applicable.

The VMS record also contains global information about:

  • VMS type (colour graphic, monochrome graphic, continuous sign, matrix sign, other)
  • Number of pictogram display areas
  • VMS description
  • VMS display height and width, its height above roadway
  • VMS physical mounting (gantry, central reservation, roadside and roadside cantilever, overhead bridge, tunnel entrance, trailer and vehicle)
  • VMS owner
  • VMS type code.
  • If its display areas are dynamically configurable.

It can also contain information for the VMS text display characteristics:

  • Maximum font height, width and spacing
  • Maximum numbers of characters, rows and sequential pages
  • Maximum text luminance level
  • Minimum font height, width and spacing
  • Text display height and width
  • Text lanterns presence
  • Text page sequencing capability
  • Number of text pixels across and down
  • Text position absolute (on left, on right, at top, at bottom) and coordinates (X & Y) in metres
  • Legend code list identifier

As well as for each VMS pictogram display characteristics through its “pictogramDisplayAreaIndex”, details of its position relative to the text or its absolute position may be provided like:

  • Maximum number of sequential pictograms
  • Pictogram display height and width
  • Pictogram number of colours
  • Maximum pictogram luminance level
  • Pictogram lanterns presence
  • Pictogram sequencing capability
  • Number of pictogram pixels across and down
  • Pictogram position absolute (on left, on right, at top, at bottom), relative to text (above, below, to the left, to the right) and coordinates (X & Y) in metres
  • Pictogram code list identifier

These values are seen as static for the particular VMS and do not have to be repeated for each displayed message in the VMS publication, unless they need to be overridden in particular cases (see VMS publication section).

Common

Common informational structures, relationships, roles, attributes and associated data types are published in submodel called Common. This contains only the elements which are used by more than one publication. It excludes those elements that relate to location information which are specified in the location publication.

More information on the submodel can be found here. In a later phase this document will be converted to web content as a part of this portal.

Extensions

To get more information on model extensions and extension rules go to the Extension guide section.

Important features about locations in Datex II

  • Information can be located with one location reference containing different locations which must be physically different.
  • A location reference can be an itinerary (i.e. an ordered set of locations), a group of non-ordered locations or a single location.
  • Each individual location can be defined with several location referencing systems (ALERT-C, linear referencing, TPEG-Loc, …): for interoperability, the Supplier and its Clients MUST use at least one common location referencing system which is a result of an interchange agreement (refer paragraph to Interchange agreement) .
  • The location references and each location can be expressed by references defined in the Predefined Locations Publication.
  • A location can correspond to a road network element (point or linear) or to an area,
  • An itinerary can relate to one or several destinations, each being a point or an area, It is also true for a road network location.
  • When the location is on the network, supplementary positional description information can be given (e.g. characteristics at the carriageway and/or at the lane level, …).

Note

More information is provided about the different location referencing systems in the section Use of ALERT-C location referencing system

Location Reference by types

In the UML model, two different walkthroughs lead to information about location.

In the diagrams, the classes are presented by types:

  • Point
  • Linear
  • Area

In the packages, the classes are gathered by packages:

  • AlertC
  • Gml
  • LinearReferencing
  • OpenLR
  • PointCoordinates
  • SupplementaryPositionalDescription
  • TpegLoc
  • NamedArea
Point location

Several location referencing systems can be used. At least one must be present:

  • Point by coordinates (ETRS89): latitude, longitude plus optional bearing
    • Warning: Coordinates are defined according to the European Terrestrial Reference System 1989 (ETRS89) which was coincident with ITRS in 1989. This is the European implementation of ITRS, but unlike ITRS and WGS84 it is centred on Europe. ETRS89 is the EU-recommended frame of reference for geodata in Europe.
  • Point along linear element:
    • linear referencing system based on referents, distances to referents all of them being along a linear element (road element). Details (road name, direction, height, …) may also be added.
  • TPEG Point Location: a TPEG point location has direction (e.g. northbound, eastbound, clockwise …) and is either specified as:
    • a simple point on the road network either at a junction or not, or
    • a framed point on the road network between two other points (i.e. framing points) on the road network.

Warning

Each point (simple point, framed point or framing point) is defined by its latitude and longitude (ETRS89) which may be at a junction or between junctions. Each is further elaborated by one or more textual descriptors of prescribed type (i.e. names like junction names, point names, railways station name…).

  • ALERT-C Point : country code, table number and version, plus:
    • Mandatory code and ALERT-C direction and optional name (Method 2); or
    • Same elements plus offset distance (Method 4)
  • OpenLR Point
Linear Referencing

Several linear location referencing systems can be used. At least one must be present:

  • Single Road linear element
    • Linear within linear element location: besides details common with the point along linear element, it includes:
      • A linearly referenced point identifying the “from” point and another linearly referenced point identifying the “to” point, where the “to” point is downstream from the “from” point according to the direction provided by the underlying linear road element
    • ALERT-C linear : country code, table number and version, plus:
      • Mandatory linear location code and ALERT-C direction and optional name (method linear by code) or
      • Mandatory primary code, secondary code and ALERT-C direction and optional names (Method 2), plus offset distances (Method 4)
    • TPEG Linear Location
      • A TPEG point location identifying the “from” point and another TPEG point location identifying the “to” point, where the “to” point is downstream from the from” point according to the direction of traffic flow.
      • A direction (e.g. northbound, eastbound, clockwise …)
    • OpenLR Linear
    • GmlLineString

Any Linear Location must have an instance of at least one of these classes. If using multiple instances, producers must take care to ensure they represent the same location.

Moreover, supplementary descriptions can be added to the linear location: length, position on the carriageway, position descriptor (at rest area, in tunnel…), etc.

Area location

Several location referencing systems can be used. At least one must be present:

  • ALERT-C area: country code, table number and version, plus:
    • Mandatory area location code and optional name
  • TPEG Area Location, a TPEG area has a type of either “largeArea” or “other” and optional height information and height type (e.g. above sea level…). It is further specified either as:
    • A “named only” area (i.e. by a name and a descriptor type, e.g. county name, town name…) or
    • A geometric area comprising a centre point (defined by ETRS89 latitude and longitude), a radius and an optional “named area”.
  • namedArea
  • GmlMultiPoygon
  • OpenLR Area

At least one of these aggregated classes must be present. If using multiple instances, producers must take care to ensure they represent the same location.

Location Reference by packages

In the UML model, two different walkthroughs lead to information about location.

In the diagrams, the classes are presented by types:

  • Point
  • Linear
  • Area

In the packages, the classes are gathered by packages:

  • AlertC
  • Gml
  • LinearReferencing
  • OpenLR
  • PointCoordinates
  • SupplementaryPositionalDescription
  • TpegLoc
  • NamedArea
ALERT-C location referencing system

This section describes the ALERT-C referencing system and gives details of the contents of ALERT-C tables. Since this version of the DATEX II specification does not include the exchange of ALERT-C Location tables this is provided as general support information.

Note

Reminder: An ALERT-C localisation is a tabular address defining a locating element belonging to this table.

Only the reference is transmitted between the Supplier and the Client. It is up to the client to look it up in the table for the descriptive elements corresponding to the referenced location using the ALERT-C code. To have a unique ALERT-C coding at the European level, the reference must comprise three elements (triplet):

  • Country Code,
  • Table number,
  • Location number

Two distinct locations at the European level cannot have the same triplet.

Warning

Caution: currently certain codes for country table references were not allotted; they are thus invalid.

It is the European standard EN ISO 14819-3 that defines the rules of constitution of the ALERT-C location tables.

The following table gives indications on the contents of the various common attributes used by the classes related to the ALERT-C location.

Code Definition Possible values
alertCLocationCountryCode Country code defined by RDS (IEC 62106). It uses only 15 values (1 hexadecimal digit: 1 to 9 and A to F). It doesn’t identify a specific country because values are shared by several countries.
F (France)1 (Germany)
1 (Germany)
E (Spain)
5 (Italy) etc…
etc…
alertCLocationTableNumber Number allowed for a country CountryCode + TableNumber fully identifies the table
17 to 32 (France)
17 to 24 (Spain)
1 to 16 (Italy)
5 (Italy) etc…
etc…
alertCLocationTableVersion Version number of the ALERT-C location table in a country.  
alertCDirectionCoded It is the concerned direction. Positive direction corresponds to the direction used when following positive linkage in the table
both
negative
positive
unknown
alertCDirectionNamed String for the direction name  
alertCDirectionSense Indicates for circular routes (i.e. valid only for ring roads) the sense in which navigation should be made from the primary location to the secondary location, to avoid ambiguity. The value TRUE indicates the positive RDS direction, i.e. direction of coding of road.
true (ALERT-C positive direction)
false (ALERT-C negative direction)
alertCLocationName Location name (redundant because already in the table)  
offsetDistance The non-negative offset distance from the ALERT-C referenced point to the actual point.  
specificLocation Unique code within the ALERT-C location table which identifies the specific point, linear or area location. Number between 1 and 63487

Examples can be found here.

Alert-C Point location

A point will be used to locate certain phenomena where dimension length is negligible such as for example accidents, incidents (broken down vehicles), obstacles, …. DATEX II proposes two methods of localization for the points, called method 2 and method 4 (the previous DATEX method 1 and method 3 have been abandoned):

  • In method 2, the point is defined by the tabular address of the ALERT-C point;
  • In method 4, the point is defined by the tabular address of the ALERT-C point, supplemented by the distance between this ALERT-C point and the point to be located.

In an ALERT-C location table an ALERT-C point includes a type and a point name as well as the name of intersecting roads at the point. Moreover, a reference towards the road (or the segment of road which carries it) is systematically added to the point and makes it possible to attach the name/number of road to this point. Consequently, all points are attached to a road (and only one).

Alert-C Linear location

Linear will be used to locate certain phenomena or operator actions where dimension length is relevant, such as for abnormal traffic flow (queues, …), the bad condition of roads (e.g. road surface), …

DATEX II proposes three methods of localization for linear:

  • In method 2, the linear one is defined by two points (primary location and secondary location), each point being defined only by the tabular address of the corresponding ALERT-C point;
  • In method 4, the linear one is defined by two points (primary location and secondary location), each point being defined by the tabular address of the corresponding ALERT-C point, supplemented by the distance between this ALERT-C point and the end of the linear location.
  • In method “linear by code”, the linear is defined only by the tabular address of the corresponding linear ALERT-C location (road, street or segment).

The primary location is the nearest defined downstream point (for methods 2 or 4). In an ALERT-C location table an ALERT-C linear location includes a type, the names of the origin and end of linear section as well as the associated road number/name.

Alert-C Area location

In an ALERT-C location table an area location includes a name and its type can be found starting from the contents of the location table.

It can be used to locate certain surface phenomena like weather phenomena. It can also be used to provide an indication of the destination (when it corresponds to a city for example).

Gml

The package “Gml” includes four class with their attributes for the definition of a linear location which specializes a location of a traffic object. This method complies with EN ISO 19136.

GmlLinear

The class “GmlLineString” instantiates a GML line string and has three attributes:

  • “posList” which contains the ordered list of the two- or three-dimensional point coordinates,
  • “srsName” which specifies the Coordinate Reference System (CRS) used to interpret the coordinates
  • “srsDimension” which provides the number of coordinates for each point belonging to the LineString. This value is either 2 or 3. If it is not provided, the default value is “2”.

Generally, the sequence in the coordinates is “latitude” then “longitude”.

The order of the points forming the line string provides the direction of the geographic feature.

GMLArea

The class “GmlMultiPolygon” instantiates a case of GML_MultiSurface where all the surfaces belonging to the set are polygons (class “GmlPolygon”). When this area is defined by several polygons (and not only one), each of them may be associated with a name (attribute “gmlAreaName”) to distinguish them.

Each polygon is defined by an exterior linear ring and zero to several interior linear rings that define interior patches. A linear ring (class “GmlLinearRing” equivalent to GM_LinearRing) is a specific, not self-intersecting closed curve derived from a line string, i.e. where the last tuple is identical to the first one. Such linear ring is composed of at least four positions. This linear ring is not self-intersecting to avoid creating fragmented (non-compact) areas since several exteriors can be attached to an instance of the “GmlMultiPolygon” class.

Linear referencing system of locations

This section describes the linear referencing system used by DATEX II. It accommodates all the actual linear referencing systems adopted by road operators in Europe. It can be used for systems based on a distance measured from the linear element origin: kilometre point or its US equivalent mile point or true mileage as well as for the UK system named “chainage”, hectometre-points, or link offset. It also accommodates systems where there exist intermediate points from which the distance is measured: systems based on kilometre-post, milepost, reference post as well as cross-streets or control sections. It is fully compliant with a draft CEN ISO standard on the same topic (EN ISO 19148) being adopted, with the two following restrictions:

  • Distances are only expressed in metres according to the DATEX II principle on units, unlike the draft standard where it is permissible to express them with different units.
  • The lateral/vertical offset features are not implemented

Reminder: This system is based on predefined elements that need to exchanged and agreed by the Supplier and the Client before being used in a DATEX II exchange. Only the reference is transmitted between the Supplier and the Client. It is up to the client to look up the descriptive elements corresponding to the referenced location using the provided elements.

Such a linear referencing system includes three elements:

  • general information on the location itself:
    • administrative area including the location,
    • geographic direction: e.g.: northbound, westbound, clockwise, …
    • relative traffic flow direction of the considered location regarding the underlying
    • referenced linear element direction: aligned, opposite, both, unknown
    • height grade of linear section: above grade, at-grade, below grade
  • Expression of distance of the referenced point: this expression of distance can be absolute (expressed from the origin of the road element), relative to an upstream intermediate point named “from referent”, or interpolative (expressed by a percentage along the linear element and calculated from the linear element origin).

In case of relative method, the “from referent” may also be associated with a “toward referent” (downstream), both bracketing the considered point.

In case the considered point is bracketed by two referents, the direction defined as going from the “from referent” to the “toward referent” overrides the general direction of the linear element (see below). The location direction is thus compared to this direction.

A referent is typified: boundary, intersection, reference marker, landmark, road node.

Finally, each referent may be associated with ETRS89 geographic coordinates (latitude, longitude).

  • The linear element underlying the location. It includes several attributes:
    • road number,
    • road name, one of the two attributes shall be provided,
    • linear element nature (optional): road, road section, slip-road, other
    • reference model which identifies the road network reference model which segments the road network according to specific business rules. It may be e.g. a graph describing the considered road network.
    • reference model version: version of the referenced road network model

This underlying linear element is defined either with an identifier string (e.g. looking up in a map database) or as an ordered sequence of points with one at each extremity. These points are defined as referent. In this latter case, the sequence order provides the reference linear element direction.

Point along a linear element

A point will be used to locate certain phenomena where dimension length is negligible such as for example accidents, incidents (broken down vehicles), obstacles, …. In case of a point referencing, the general information is provided by the class “PointAlongLinearElement”.

Linear within a linear element

Linear will be used to locate certain phenomena or operator actions where dimension length is relevant, such as for abnormal traffic flow (queues, …), the bad condition of roads (e.g. road surface), …

This linear is defined by its two extremities: “from” point and “to” point. Unlike some other referencing based on points like ALERT-C, the order between “from” point and “to” point is only defined downstream by considering the underlying linear element direction. If the impacted traffic direction is aligned, the attribute “directionRelativeOnLinearSection” is used. The general information is provided by the class “LinearWithinLinearElement”.

No area referencing

This referencing system cannot be used for referencing areas.

OpenLR

OpenLR point location references are defined in more detail in the OpenLR whitepaper version 1.5.

OpenLR Line Location Reference

An OpenLR line reference is defined as a sequence of OpenLR base Location Reference points forming a route/itinerary on a road network.

Be aware that OpenLR lines can comprise more than one linear in terms of the DATEX II definitions of a linear. It would harm the basic concepts of on-the-fly location referencing as supported by OpenLR when an implementation is made by splitting the openLR lines up according to the DATEX II definition of a linear.

Therefore, it is recommended to include only one OpenLR linear from the beginning to the end of a trajectory.

OpenLR Area Location reference which

OpenLR Area Location reference is a set of ordered X,Y coordinates (ETRS89) together forming a geometric area, which has to be one of the following types:

  • circle location reference: defined by a centre point in coordinates, with a radius of the circle
  • rectangle location reference: defined by the coordinates of the lower left (south-west) and upper right (north east) corners of the rectangle
  • grid location reference: defined by a rectangles and the number of columns and rows that form the grid within this rectangle
  • polygon location reference: defined by the coordinates of at least 3 corners of the polygon.
  • closed line location reference: an area framed by road segments. This area is defined by openLR lines
PointCoordinates
SupplementaryPositionalDescription
TpegLoc
NamedArea

Todo

The above content is missing, but will be added as soon as possible.

PredefinedLocationsPublication

Objectives and utilisation mechanisms

This publication is used to predefine (sets of) locations which can then be referred to in any of the other publications by means of a single versioned reference attribute. This allows great simplification of those publications where repeating static or quasi-static locations are used.

A set of locations defined as a container may contain one location or can be characterised as an Itinerary (ordered set of locations) or as a group of non-ordered locations. Predefined itineraries as well as a group of non-ordered locations contain several predefined locations. Each predefined location may be of any type, i.e. point, linear or area. Obviously an itinerary cannot include area-typed locations. Each set of predefined locations and each individual predefined location have its own unique versioned identifier and can be referenced in other publications.

The main utilisation is when publications are sent periodically and always concern the same locations, which are mostly itineraries or elementary linear locations (for instance, elaborated data and traffic views publications).

The utilisation mechanism is as follows:

  • Step 1: the DATEX II client gets a predefined location publication with the locations identifiers and definitions,
  • Step 2: when the DATEX II Supplier delivers publications to this client, it only uses the predefined location identifiers and the client is able to look up the identifier and obtain the real location details.

The advantage of this mechanism is to reduce the publication size.

When a predefined location set is modified, the DATEX II Supplier has to inform the concerned DATEX II Clients.

Content

With this publication, attributes can be given in the InformationHeader which provide clients with information management details (area of interest, confidentiality, information status, urgency) relating to this publication.

The predefined location container (abstract) shall be derived into a predefined itinerary, a predefined group of non-ordered locations or simply a predefined location. All three have a unique versioned identifier and may have a name.

Itinerary and group of non-ordered locations are made up of predefined locations; each location has its own unique versioned identifier and may have its own name.

The definition of each predefined location uses the same location definition as the other publications. When predefining these locations, usage of other references is not allowed when it infers circular references.

Exchange specifications

Exchange references

For DATEX II, one of the objectives was to clearly split the content data modelling and the data exchange specification.

Two documents deal with data exchange:

  • A high level document, called here [Exchange PIM], which is independent from technological platforms and presents, definitions, subsystems, use cases, metadata, and operating modes.
  • A detailed specification, called here [Exchange PSM]., which is specific for one platform which has been chosen to be for DATEX II, “Web Services over http”.

These documents which contain the details on the exchange process may not be of direct interest for stakeholders who only want to know the main exchange features and the main options they have to decide. This chapter provides a brief overview of what DATEX II exchanges comprise.

Exchange Overview

Logical view

An exchange system between a Supplier and its Client(s) is composed of 2 main subsystems:

  • A Publisher subsystem, which makes data available and creates the payload publications,
  • A Delivery subsystem, which adds exchange specific information and performs the physical delivery.

The DATEX II exchange specification only describes the delivery subsystem.

A subscription specifies the payload type to be exchanged. It can be defined by the Supplier or by the Client, online or offline. DATEX II allows users to have the liberty to develop subscriptions with the refinements they need.

There are 3 possible operating modes for data delivery:

  1. Publisher Push on occurrence: Data delivery is initiated by the Publisher every time data is changed
  2. Publisher Push periodic: Data delivery is initiated by the Publisher on a cycle time basis
  3. Client Pull: Data delivery is initiated by the Client and data is returned as a response

Remarks:

  • operating mode “Publisher Push on occurrence”:
    • in this mode, for situation publications (events, operator actions, …), situation and situation records lifecycles have to be managed (update, cancel, and end). This is described in section: “Special case: Publisher Push on occurrence”,

The main advantage of this mode is the response time (which can be measured in seconds).

  • operating modes “Publisher Push on occurrence and Publisher Push periodic”:
    • after a link failure between the Supplier and his Client(s), recovery mechanisms have to be built, see also exchange PSM.

Depending on operating mode and publication type, different update methods are possible:

  • singleElementUpdate
    • If an atomic part of the data has been changed, this atomic part, and only this atomic part, will be exchanged (e.g. only a single situation record update in a multi element situation)
  • allElementUpdate
    • If an atomic part of the data has been changed, all data associated with the atomic part will be exchanged (e.g. all situation records in a multi element situation)
  • snapshot - A snapshot contains all information available, at a given time, for a subscription

Remarks:

With “Client Pull” operating mode:

  • Only “snapshot” update method is used,
  • For situations publication, there is no need to manage situation and situation records lifecycles because the exchanged situations are only the active ones at the time of the snapshot (i.e. in the last received exchange),
  • After a link failure, no recovery mechanism is needed (the first Pull automatically gets the latest versions).

OPTIONS: depending on his needs, a stakeholder has to decide, at this logical level:

  • The refinement of subscriptions, from the “exchange everything” to sophisticated filtering,
  • The operating modes he wants to implement (as Supplier and/or as Client), the Pull operating mode being the more simple to develop,
  • The update methods he wants to implement, if he uses Publisher Push operating modes

Technical view

At this technical level, we distinguish 2 kinds of systems:

  • Pull systems,
    • Supplier: it can use either:
      • Web services over http, with DATEX II WSDL description,
      • Only a http server.
    • Client: it can use either:
      • Web services over http, with DATEX II WSDL description,
      • Basic http requests, either GET or POST.
  • Push systems
    • Supplier: it uses Web services over http, with DATEX II WSDL description,
    • Client: it uses Web services over http, with DATEX II WSDL description.

OPTIONS: depending on his needs, the stakeholder has to decide, at this technical level, for the operating modes he has chosen:

  • for Pull supplier systems, the usage of Web Services technologies and tools or basic http technology,
  • for Pull client systems, the usage of Web Services technologies and tools or basic http technology.

Remark: specialists do not agree on the solutions which have the lowest cost for a Pull system:

  • Web Services technology or basic http technology, the choices depend essentially on general policy for software development.

Interchange agreement

Definition

The interchange agreement is a document that describes bilateral agreements between a Supplier and a Client, needed for the exchange of DATEX II information. The interchange agreement should deal with all the information that is needed for the data exchange to take place. The description assumes that the information exchange follows the basic principles of DATEX II. Specifically, it is assumed that two parties are involved: a Supplier providing content and a Client receiving content.

General

Time period throughout which the overall agreement is valid

The agreement shall state the time period for which the agreement is valid. It should define the date of commencement and may indicate the date of its ending. Rules for terminating the agreement before the expiry time of the agreement The agreement should specify the conditions under which the contract can be terminated prior to an expiry date.

Company/authority names, contact addresses, telephone, fax and E-mail details

The two parties shall provide the company and the authorities´ names, address and the operational contact with all related communication data such as telephone, fax numbers and email addresses.

Access

IP Address of the Client

The agreement may mention the IP address of the client which is to be used if the supplier is to implement IP address discrimination.

IP Address of the Supplier

The agreement shall mention the IP addresses on which the supplier’s services will be available. Each supplier service may have different applicable conditions associated with it.

Supplier user name

The agreement should stipulate the user name that will be adopted by the supplier.

Client user name

The agreement should stipulate the user name that will be adopted by the client.

Password for Supplier to connect to Client

If the parties decide to use a password, this should be specified. If other means of access control are used these should be specified.

Password for Client to connect to Supplier

If the parties decide to use a password, this should be specified. If other means of access control are used they should be specified.

Data exchange

Choice of network for exchange of data and configuration

All technical information needed for the exchange of data and configuration between the parties should be described (Example: VPN details, router parameters, …).

Options

The choices made by the supplier and the client have to be compatible:

  • DATEX II model version and any extension,
  • Operating mode,
  • Update method

Location referencing systems

The choices made by the supplier and the client have to be compatible.

When using ALERT-C tables, they have to be exchanged first between the Supplier and the Client and kept compatible when they are updated. When using linear referencing with referents, these latter also have to be exchanged between supplier and clients.

Rights and obligations

Quality of the data

Description of the quality of the data provided by Supplier.

Fail soft mode

Description of actions by Supplier in connection with the Supplier Server being down:

  • actions when Supplier Server is down for planned maintenance,
  • actions when Supplier Server is down following a system failure,
  • actions when Supplier server starts up.

Description of actions by Client in connection with the Client system being down:

  • actions when Client system is down for planned maintenance,
  • actions when Client system is down following a system failure,
  • actions when Client system starts up.

Statement on liability in case of transmission of incorrect information.

Payment

Description of payment mechanism for the service, if any.

Data dissemination

Rules for the further dissemination by the Client of information received using DATEXII.

User support

Recommended profiles

Downloads

Contentmodel

Exchange 2020

DATEX II Archive

Other links