Apart from the technology updates of DATEX II version 3 - which is faster and more user-friendly than the previous versions - the introduction of the SRTI profile is another reason why you may consider upgrading your DATEXII data-feed.
Infrastructure-to-vehicle (I2V) communication is increasingly becoming more important in future-proof road infrastructure - especially when it comes down to safety. A step closer to the deployment of Cooperative, Connected and Automated Mobility (CCAM) in the European Union is the transferral of specific messages from Cooperative Traffic Management (CTM) systems to the vehicle so that this information can be relayed to the driver via the dashboard or a mobile app.
Safety-Related Traffic Information (SRTI) is one of those key components to transfer important (safety) information. It adds another attribute to every traffic event: safetyRelatedMessage indicating whether the information in the event is classified as a danger or not. Cooperative Intelligent Transport Systems (C-ITS) can benefit greatly from this. With the new release of DATEX II the recommended reference profile SRTI can be used to successfully relay safety messages.
This post describes the technical challenges of migrating to DATEX II version 3 and concludes with next steps to create an efficient service for location-based requests from individual vehicles or app instances.
How does the upgrade happen? According to the release notes of version 3, the most important technical changes for the scope of this article are:
With the help of the datex online wizard (https://webtool.datex2.eu/wizard/) source xsd schema’s can be created which represent the backbone of a DATEX II exchange feed. To be fully compliant you can check all the elements you can in the wizard:
Target PSM: XML Schema
Generate schema with definitions
There is also an option to save your profile selection to the file selection.sel by checking the checkbox in the last step and use this file in Step 2 as your own selection (like this you don’t have to mark the checkboxes in the Selection Profile). Our selection file
However, placing the unedited source xsd schema’s in the project can lead to several errors. We solved them in the following manner. First of all there are duplicate complexType definitions in the files Situation.xsd, Common.xsd and LocationReferencing.xsd. A simple solution is to delete the definitions in the beginning of the files to avoid errors. Next in the file LocationReferencing.xsd another error reared its head:
Property "NamedAreaExtension" is already defined
Renaming the property in NamedArea by adding
<xs:annotation> <xs:appinfo> <jxb:property name="valueAttribute"/> </xs:appinfo> </xs:annotation>
in the _namedAreaExtension element solved the issue.
You guessed it. There were still errors:
A class/interface with the same name <className> is already in use. Use a class customization to resolve this conflict.
To resolve the issue at hand you can add the argument XautoNameResolution in the JAXB configuration of the Pom.xml file. No more duplicates were to be found and generating the Java Classes went smoothly. Generating xsd schema’s through JAXB can be done by running
mvn clean package in the project directory or simply by a full install:
mvn clean install.
As you may have noticed, this is not sufficient to publish an xml data feed. There is no
@XmlRootElement tag in any of the generated objects (like before). As is described in the DATEXII Academy documentation:
PROGRAMMER NOTE Code Generation by JAXB: Please note that importing the WSDL and xsd schemas generated with JAXB the generated code need a manual update to set XMLRoot for ExchangeInformation and MessageContainer such as
add tag @XmlRootElement to ExchangeInformation and MessageContainer classes after they had been generated by JAXB
A manual update by adding the aforementioned tag to generated classes is not an option in many projects, and therefore the need arose to add another element in Payload.xsd which will act as the Root Element to publish the feed:
<xs:complexType name="Payload"> <xs:complexContent> <xs:extension base="com:PayloadPublication"> <xs:sequence> <xs:element name="situationPublication" type="sit:SituationPublication" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="predefinedLocationsPublication" type="loc:PredefinedLocationsPublication" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>
One final thing to do is to add bindings to the source xsd files:
Bindings for Common.xsd, LocationReferencing.xsd and Situation.xsd in jxb-bindings.xml.
<jxb:bindings schemaLocation="./Common.xsd"> <jxb:schemaBindings> <jxb:nameXmlTransform> <jxb:elementName prefix="XMLDatex2PublicationOut_" /> <jxb:typeName prefix="XMLDatex2PublicationOut_" /> <jxb:anonymousTypeName prefix="XMLDatex2PublicationOut_" /> </jxb:nameXmlTransform> </jxb:schemaBindings> </jxb:bindings> <jxb:bindings schemaLocation="./LocationReferencing.xsd"> <jxb:schemaBindings> <jxb:nameXmlTransform> <jxb:elementName prefix="XMLDatex2PublicationOut_" /> <jxb:typeName prefix="XMLDatex2PublicationOut_" /> <jxb:anonymousTypeName prefix="XMLDatex2PublicationOut_" /> </jxb:nameXmlTransform> </jxb:schemaBindings> </jxb:bindings> <jxb:bindings schemaLocation="./Situation.xsd"> <jxb:schemaBindings> <jxb:nameXmlTransform> <jxb:elementName prefix="XMLDatex2PublicationOut_" /> <jxb:typeName prefix="XMLDatex2PublicationOut_" /> <jxb:anonymousTypeName prefix="XMLDatex2PublicationOut_" /> </jxb:nameXmlTransform> </jxb:schemaBindings> </jxb:bindings>
These bindings add a prefix to each of the generated classes.
If your project already has a publication factory for DATEX II feeds, you may have to make several changes. One of the biggest modifications is the move of the former GroupOfLocations package to the LocationReference package. OpenLR and GML functionality can be implemented in this package (more about this in the next paragraph). Another important attribute that has been added is safetyRelatedMessage in a situationRecord (see SRTI Compliance).
As seen before, SituationPublication and PredefinedLocationsPublication have been combined together in the previously made Root Element object. Other minor changes consist of removing the publication language and situation version from a situation. The model base version has been updated and unfortunately the CountryEnum class has been removed and became an EN ISO 3166-1 two-character country code in the InternationalIdentifier class.
Lastly, exposing the DATEX II publication can be done through a REST interface for example.
Coordinates can be added to a GMLLineString posList in any coordinate reference system. However, if your coordinate data is in a different reference system than WGS84, it is important to add the technical system name in the srsName attribute so that clients know which coordinate system they are dealing with.
Additionally, if the srsDimension attribute is left empty, the coordinates will be assumed to be the x and y coordinates only. The z coordinate can be added for height.
The technical term for WGS84 is EPSG:4326 and for Belgian Lambert 72 EPSG:31370. More information about the coordinate reference systems can be found on https://epsg.io/.
Fortunately to be SRTI compliant it’s not necessary to implement the elements of which we don’t have the content. The profile provides the selection of all information elements that according the EU Delegated Regulation 886 on the provision of Safety Related Traffic information should be published if you as a source collect and register that kind of information. For example if you don’t have any information about the trafficConstriction of events, there is no reason to implement this. The published data-feed will never have that information.
The setting of the attribute safetyRelatedMessage is related to the national policy regarding the SRTI delegated regulation. It is set to true if the event and the location where the event occurs qualify as being relevant according to the delegated regulation. If there is no national policy regarding the qualifying road-network, the delegated regulation limits the geographical scope to the TERN network.
In other words, if the Traffic Event corresponds to an SRTI datex phrase and the event is located on a main road, we will set safetyRelatedMessage to true.
List of SRTI datex phrases can be found in the excel file.
Example of a generated xml (which can also be found on the DATEX website):
Example-Accident with A...ring.xml 4 KB
By now we know the important impact a DATEX II upgrade to version 3 can have on C-ITS, specifically the SRTI profile, contributing to the overall safety of the road network and individual drivers. Traffic events which are legally classified as a danger can be brought to the driver’s attention so that adequate action can be performed.
However, this poses another issue. The full DATEX II data-feed contains all of the traffic events while most of them will not even be applicable to one specific vehicle. The inefficiency of many vehicles constantly trying to retrieve the data-feed can cause unnecessary delays in retrieving the publication, reduce system performance or even worse: service crashes.
In light of this, the next step really is to implement location-bound requests so that only traffic events in the vehicle’s vicinity would be published in the data-feed. Only those events would be relevant for that specific vehicle, reducing bandwidth and increasing performance majorly on all sides.