Disclaimer

This document is the copyrighted property of ASAM e.V. Any use is limited to the scope described in the license terms.

Introduction

1. Overview

This concept paper serves as a source for future developments of the OpenDRIVE standard. It is the result of a collaboration of various companies in the simulation and navigation data domains in 2019 and 2020. The features discussed in the concept paper were first introduced during a series of ASAM OpenDRIVE workshops. The features were collected in ASAM OpenDRIVE – List of Features and Requirements. Because the features and their underlying concepts were still rough outlines, the OpenDRIVE standard transfer group decided to initiate a concept project with the goal of clarifying scope and limitations of the suggested features. This decision was taken during the meeting of the OpenDRIVE group in Höhenkirchen on January 15th and 16th 2019.

The concept project was split in two phases:

Phase 1: Concept exploration and comparison with the existing OpenDRIVE standard
Phase 2: Work on technical implementation

During the concept exploration, the suggested features were compared to the existing standard. Experts and newcomers to the OpenDRIVE standard shared knowledge and experience and filled gaps in the technical application of the features. The results of this phase were used in phase 2. Feasibility and technical implementation were discussed in more detail in this phase of the concept project. The outcome of this concept project is intended to form the basis of a new standard project that further develops the OpenDRIVE standard.

In the kick-off workshop for the OpenDRIVE concept project, working groups were formed to work on the most important features. The following feature categories were identified:

Junctions
Environment representation
Road geometry
International traffic sign model
Area concept

2. Motivation

OpenDRIVE is very strong when it comes to modeling roads and road networks. Because real-world and road networks can be very complex, modeling these in an exchange format can also become quite complex. The current version of OpenDRIVE (version 1.6) lacks features for modeling complex junctions, for example, tilted junctions. Because OpenDRIVE’s road geometry definition does not use discrete points, complex junction implementations by different tool vendors leave room for interpretation.

The automotive industry also faces the challenge of simulating road networks from all over the world. This means that all kinds of regional traffic signs and traffic rules need to be considered. The current version of OpenDRIVE allows describing a wide variety of signals, but a known gap in the standard is the definition of dynamic traffic signals that can often be found on highways.

The modeling approach of OpenDRIVE is centered around the reference line of a road, which makes using existing GIS data for OpenDRIVE difficult. For this reason, one working group in the project concentrated on an area concept for OpenDRIVE to simplify use of such data sources.

3. Scope

Five work packages had been defined in the concept project. For each work package, a working group was established. These were the working groups:

3.1. Working group 1, Junctions

The goal of this work package was to simplify the modeling of junctions and also solve some modeling issues. It also extended the possibilities of modeling junctions, for example, by introducing a junction grid.

3.2. Working group 2, Environmental representation

This work package had the following goals:

Create an interface between OpenDRIVE and other standards that are capable of representing environment, for example, City GML
Determine how many levels of detail (LoD) need to be created for a future OpenDRIVE standard
Determine for which objects the levels of detail are needed
Separate logical information from geometry information

3.3. Working group 3, Road geometry

This work package focused on improving the geometry descriptions in OpenDRIVE, identifying poorly defined geometry descriptions, and introducing new ways of describing road geometry. One way of improving OpenDRIVE and making it leaner is to identify redundant information and evaluate if it can be removed. This work package also evaluated if new rules needed to be introduced to avoid problems with modeling OpenDRIVE.

3.4. Working group 4, International traffic sign model

The working group worked on the following aspects:

Scope of the traffic signs model
International signs model
Logical data and physical data for the international traffic signs model
The catalog database that is referenced from the OpenDRIVE file
Semantics for the traffic signs model

3.5. Working group 5, Area concept

The area concept is a new approach to avoid issues that are caused by using the reference line as the basis for modeling. It is a new modeling methodology, which builds on all the experience and learnings that different members have accumulated during years of using OpenDRIVE. This document describes the current proposal for the OpenDRIVE area concept.

Concept Paper WP01

1. Improved description of the elevation profile of roads in junctions

Table 1. Status of the concept
Target Version:	Effect Backward compatibility:	Complexity for Implementation:	Acceptance Status:
1.7	N	mid (concept→Standard)	accepted

1.1. Short summary and motivation of the proposal

The concept proposes an improved method for describing the elevation (z-value) of roads in junctions. The proposal includes the following subconcepts:

Junction borders to define the outline of junctions. The borders specify a clearly defined and closed junction area.
A junction road with its own reference line that runs through the junction area. The junction road will be used for placing individual objects independent of the connecting roads.
A junction grid, that is similar to the grid of OpenCRG and may be defined left and right of the junction road. The grid defines all elevations points within the junction area.
A transition area between the junction grid and each road leading in and out of the junction. The grid shall create a smooth transition for the simulated traffic participants. It is intended that the transition takes place within the junction area. The details of transition areas need to be specified by the standardization project. (It is intended to use the same calculations as in the corresponding concept in WP03).

There are the following advantages:

Modelling of elevation profiles is easier compared to OpenCRG.
It is no longer necessary to define the elevation profile of connecting roads inside junctions.
Overlaps or gaps between connecting roads in junctions, resulting from diverging height information, vanish.
Positioning of objects via junction roads is more flexible.
Transition areas provide a smooth transition from the junction elevation profile to the incoming roads.
Grid and the lane heights can be used to visualize the junction area.
Junctions will contain more information than just the connections between roads.

There are the following disadvantages:

The creation of junctions gets more complex because grids need to be defined.
The JunctionBorderOutline has to be defined.
The JunctionGrid has to be defined.

1.2. Use cases

In previous versions of OpenDRIVE, it is difficult to create a consistent elevation profile for junctions, as soon as a slope needs to be modeled. The concept would greatly simplify this process.
Using a grid for the junction area will simplify the calculation of z-values for any point in the junction area.
Using a junction grid will ensure that the junction has elevation information for the entire junction area (all gaps are closed).

The following stakeholders will benefit:

Users of OpenDRIVE who create junctions in slopes.

1.3. Details of the proposal

1.3.1. How is it done in OpenDRIVE 1.6

In OpenDRIVE 1.6, height information for junctions can only be specified in each individual connecting road or by means of OpenCRG using the surface element that is attached to the junction. It has to be ensured that the OpenCRG covers the desired parts of the junction. It is not possible with OpenDRIVE 1.6 to specifically exclude the sidewalks from the OpenCRG data.

The junction area is only implicitly defined by the connecting roads. Each connecting road has its own elevation and superelevation. Overlapping connecting roads can cause jumps and a rough surface of the resulting junction. It is also possible that connecting roads do not cover the complete junction, which can lead to gaps in the junction area.

This concept is separated into three subconcepts:

Junction road
Junction grid
Junction border

1.3.2. General description: Junction road

Every junction area shall have a junction road with its own reference line. junctionRoad is a new element and has the same attributes as the road element. The junction road is used to attach the junction grid and other relevant objects to the junction area.

The junction road is also defined in the reference line coordinate system (s-t-coordinates).

The following rules apply to junction roads, as shown in Figure 1:

A junction road shall have its own reference line.
A junction road shall have a starting point, heading and length.
A junction road shall contain one geometry element of type line.
A junction road shall have no lanes and no elevation or superelevation.
s-t-coordinates shall be used to place objects.
The reference line of a junction road shall share at least one point with the junction area, as shown in Figure 4. This will prevent junction roads from being placed far from the junction area.
A junction road covers at least the full junction area.

The junction road may be used for

Adding additional OpenCRG files.
Adding a junction grid.
Placing objects that have no impact on traffic rules on the junction, independent of the connecting roads, as shown in Figure 2. Also see the XML example

Figure 1. junctionRoad reference line

Figure 2. Placing an object along the junction road

1.3.3. General description: Junction grid

A junction grid, similar to the grid used in OpenCRG, may be attached to the junction road. A junction grid avoids possible gaps within a junction. The simplest junction grid will contain four points with the same z-value, providing a plane with constant height. If needed, more points may be added to achieve a higher level of detail.

Junction grids are optional. If a junction grid exists, there shall be only one junction grid per junction.

The following rules apply to junction grids:

A junction grid shall be defined left and right of the junctionRoad with vectors perpendicular to the reference line. The vectors contain the grid points.
A junction grid shall cover at least the whole junction area.
A junction grid shall overrule all height information of the connecting roads inside the junction area.

Because the junction grid is only valid inside the junction area, the vectors containing the height information may be adjusted in size to contain only the necessary values.

For a smooth transition onto the junction grid, elevation and slope of roads attached to the junction needs to be considered in the values of the junction grid.

Figure 3 and Figure 4 illustrate junction grids and vectors.

Figure 3. Junction grid example including some vectors

Figure 4. Junction grid example where the reference line is placed at the very border

A junction grid uses the junctionGrid element and shall have the following attributes:

Table 2. Attributes of the element **grid**
attributes	name	type	unit	value	Description
	`sStart`		m		Start position of the grid on the junction road reference line
	`gridSpacing`		m		Distance between grid values

1.3.4. General description: Junction borders

In OpenDRIVE 1.6, not only the gaps and height difference cause problems when calculating the z-values. The visualization of the junction may show unwanted results as well.

For a consistent visualization, the borders of the junction must be known. Furthermore, the exact location of sidewalks and curbs must be known, so the lane height can be taken into account.

There are two different approaches to define the junction border:

borderedRoad:
OpenDRIVE only defines the bordered roads and lets the application determine the outer lane borders for the junction.
borderedLane:
OpenDRIVE defines the border according to the lanes of the connecting roads. If necessary, points are added to the border outline in order to connect the borderOutline across difficult sections. Figure 5 illustrates this approach.

Figure 5. Second approach with borderedLane.

Both approaches are suitable for modelling the junction border outline.

The borderedRoad approach is very easy and straight-forward for the user to understand. It makes it easier to evaluate the z-value within the junction. The application that generates the visualization must evaluate the junction area from the bordered roads and the lane types (special types: median, curb, sidewalk).
The borderedLane approach is a lot more difficult and complex to understand for the user. It requires that the roads are identified, as well as the lanes and their borders, including, if necessary, additional points to connect the outline elements. On the other hand, it provides a very accurate way of modelling the junction border outline, see Figure 5. For the application, this modeling approach is unambiguous, apart from the known issues with the implementation of parametric polynomials.

use borderedRoad for the junction border outline:

Because not all connecting roads are part of the border, the bordered roads need to be listed. See the following example:

<junctionBorders>
		borderRoad="8"
		borderRoad="17"
		borderRoad="52"
		borderRoad="32"
		borderRoad="41"
</junctionBorders>

borderRoad="52" is not a connecting lane, but the road needs junctionId in the road attributes.

use borderedLane for the junction border outline:

In this approach the borders are directly defined in OpenDRIVE. The order of definition is very important. The border is defined through the lane borders. In order to connect the borderOutline across difficult sections, for example traffic islands, additional points may be added to the outline. The connection between laneBorder ends and between points is always a straight line, as shown in Figure 5.

Figure 6. Border definition

In the following example, the first part of the border is obtained by following lane -2 of road 8, from the beginning to the end. The inner side of the lane -2 is considered relative to the reference line and defines the area towards the inside of the junction. The dotted lines are straight lines between two defined <areaBorder> elements.

<junctionAreaOutline borderDirection = "left">
	<areaBorder borderType="lane" borderRoad="8" borderLane="-2" startS="begin" endS="end" borderPosition="inner"/>
	<areaBorder borderType="lane" borderRoad="17" borderLane="-1" startS="begin" endS="end" borderPosition="outer" />
	<areaBorder borderType="roadPosition" borderroad="17" s="end" borderLane="1" borderPosition="outer"/>
	<areaBorder borderType="roadPosition" borderroad="60" s="begin" borderLane="1" borderPosition="inner"/>
	<!-- the lane of borderRoad= "52" is just a border and not a connecting lane -->
	<areaBorder borderType="lane" borderRoad="52" borderLane="1" startS="end" endS="begin" borderPosition="inner" />
	<areaBorder borderType="lane" borderRoad="32" borderLane="-2" startS="begin" endS="42.0" borderPosition="outer" />
	<areaBorder borderType="lane" borderRoad="32" borderLane="-1" startS="42.0" endS="end" borderPosition="outer" />
	<areaBorder borderType="lane" borderRoad="41" borderLane="-2" startS="begin" endS="end" borderPosition="inner" />
</junctionAreaOutline>

When a traffic participant enters the junction area, it uses the z-value from the junctionGrid, taking transition area into account, until it has left the junction. Should the traffic participant be on one of the borderRoads or even beyond them the grid still applies.

If a lane height is used, it is always added to the grid height, within the boundaries of the elevated lanes. In which direction (h, z) the lane height is added needs to be defined by the standardization project.

The roads attached to the junction also define the junction border. Here the transition area and the grid are used for calculating the z-values and the visualization.

If multiple sources of elevation information are defined in a file, the following priority should apply:

OpenCRG
Junction grid
Connecting road height profiles

Modeling guideline regarding lane heights (task for the following project):

The lane heights will be added on top of the junction grid in the junction area. It needs to be accurately defined how to handle the elevation of the road (when to add z-values and when to subtract z-values): Is the lane height perpendicular to the grid or the inertial coordinate system?
Add rules about when to interpret the lane height according to the lane type.

1.3.5. Rules

Every junction should have junctionBorders that define the junction area.
The reference line of the junctionRoad shall share at least one point with the junction area.
The junctionRoad shall cover at least the maximum extent of the junction area. This is required for objects and grid to cover the full junction area.
A junction shall have only one junction grid.
If a junction grid is defined, a junction border is required.
The junctionGrid shall cover the whole junction area, enclosed by the junctionBorders.
The junction grid shall be defined to the left and right of the junction road with perpendicular vectors
The junction grid shall be valid from the point where a traffic participant enters the junction area until it leaves the junction area on an outgoing road.
The junction grid outside the junction area is overwritten by a road passing the junction grid. This does not apply to connecting roads, because they are inside the junction area.
If a junction grid is present it shall override any elevation values derived from connecting roads.
For junction entries and exits, a smooth transition should be assured.

1.3.6. XML examples

XML example of the concept

<junction name="" id="1">
	<connection id="0" incomingRoad="1" connectingRoad="8" contactPoint="start">
		<laneLink from="1" to="-1"/>
		<laneLink from="2" to="-2"/>
	</connection>
	<connection id="1" incomingRoad="1" connectingRoad="17" contactPoint="start">
		<laneLink from="1" to="-1"/>
	</connection>
	<connection id="2" incomingRoad="1" connectingRoad="20" contactPoint="start">
		<laneLink from="1" to="-1"/>
	</connection>
	<connection id="3" incomingRoad="2" connectingRoad="23" contactPoint="start">
		<laneLink from="-1" to="-1"/>
	</connection>
	<connection id="4" incomingRoad="2" connectingRoad="26" contactPoint="start">
		<laneLink from="-1" to="-1"/>
	</connection>
	<connection id="5" incomingRoad="2" connectingRoad="29" contactPoint="start">
		<laneLink from="-1" to="-1"/>
	</connection>
	<connection id="6" incomingRoad="4" connectingRoad="32" contactPoint="start">
		<laneLink from="-2" to="-1"/>
		<laneLink from="-3" to="-2"/>
	</connection>
	<connection id="7" incomingRoad="4" connectingRoad="35" contactPoint="start">
		<laneLink from="-2" to="-1"/>
	</connection>
	<connection id="8" incomingRoad="4" connectingRoad="38" contactPoint="start">
		<laneLink from="-1" to="-1"/>
	</connection>
	<connection id="9" incomingRoad="4" connectingRoad="50" contactPoint="start">
		<laneLink from="-1" to="-1"/>
	</connection>
	<connection id="11" incomingRoad="5" connectingRoad="41" contactPoint="start">
		<laneLink from="-1" to="-1"/>
		<laneLink from="-2" to="-2"/>
	</connection>
	<connection id="12" incomingRoad="5" connectingRoad="44" contactPoint="start">
		<laneLink from="-1" to="-1"/>
	</connection>
	<connection id="13" incomingRoad="5" connectingRoad="47" contactPoint="start">
		<laneLink from="-1" to="-1"/>
	</connection>
	<junctionBorder >
		 borderRoad="8"
         borderRoad="17"
         borderRoad="52"
         borderRoad="32"
         borderRoad="41"
	</junctionBorder>
<junctionRoad name="" length="7.8602200000000011e+01" id="53" >
        <planView>
            <geometry s="0.0000000000000000e+00" x="-1.5770723137386160e+01" y="-2.2540441410945846e+01" hdg="8.4265887962140396e-01" length="7.8602200000000011e+01">
                <line/>
            </geometry>
        </planView>
		<!-- The shown values are just an example without a relation to the image -->
        <junctionGrid sStart=1.35191514000e+00" gridSpacing="1.000000000e+01">
			<gridVector left = "5.0 5.0 5.1" center= "5.0" right = ""/>
			<gridVector left = "5.0 5.0 5.1" center= "5.0" right = ""/>
			<gridVector left = "5.0 5.0 5.1" center= "5.0" right = ""/>
			<gridVector left = "5.0 5.0 5.1" center= "5.0" right = ""/>
			<gridVector left = "5.0 5.0 5.1" center= "5.0" right = ""/>
			<gridVector left = "5.0 5.0 5.1" center= "5.0" right = "5.1 5.2 5.2"/>
			...
			</junctionGrid>
        <objects>
            <object type="obstacle" name="AB_FahrbbTeiler10m-blank.flt" id="0" s="3.5994894962499764e+01" t="2.7350042032262745e+00" zOffset="-7.0000000000000007e-02" validLength="0.0000000000000000e+00" orientation="none" length="1.0050000000000001e+01" width="1.3999999999999999e+00" height="2.0000000000000001e-01" hdg="3.1415926535897931e+00" pitch="0.0000000000000000e+00" roll="0.0000000000000000e+00">
            </object>
            <object type="patch" name="Rd_Damage_Patch_30_CRG.flt" id="1" s="4.1310368737499687e+01" t="-1.3278559699814148e+00" zOffset="1.2000000000000000e-02" validLength="0.0000000000000000e+00" orientation="none" length="4.7599999999999998e-01" width="4.0400000000000003e-01" height="0.0000000000000000e+00" hdg="0.0000000000000000e+00" pitch="0.0000000000000000e+00" roll="0.0000000000000000e+00">
            </object>
        </objects>
        <surface>
            <CRG file="Rd_Damage_Patch_30.crg" sStart="4.1069649500000025e+01" sEnd="4.1545649500000025e+01" orientation="same" mode="attached" purpose="elevation" sOffset="4.1069649500000025e+01" tOffset="-1.3278531856958835e+00" zOffset="0.0000000000000000e+00" hOffset="0.0000000000000000e+00" zScale="1.0000000000000000e+00"/>
        </surface>
    </junctionRoad>



</junction>

Image and XML example for the adaption of virtual junctions

Figure 7. Junction outline for a virtual junction

<junction name="myJunction" type="virtual" id="555"  mainRoad = „1“ sStart = „60“ sEnd = „70“ >
   <connection id="0" incomingRoad="1" connectingRoad="2" contactPoint="start">
      <laneLink from="-2" to="-1"/>
   </connection>
   <connection id="1" incomingRoad="-1" connectingRoad="4" contactPoint="start">
    <laneLink from="-1" to="-1"/>
   </connection>
   <connection id="2" incomingRoad="-1" connectingRoad="5" contactPoint="start">
      <laneLink from="-1" to="-1"/>
   </connection>
   <junctionAreaOutline borderDirection="left">
		<areaBorder borderType="lane" borderRoad="2" borderLane="-1" startS="begin" endS="end" borderPosition="outer"/>
   		<areaBorder borderType="lane" borderRoad="5" borderLane="-1" startS="begin" endS="end" borderPosition="outer"/>
   		<areaBorder borderType="roadPosition" borderroad="4" s="end" t="-3.0"/>
   		<areaBorder borderType="lane" borderRoad="1" borderLane="-1" startS="70" endS="60" borderPosition="inner"/>
   </junctionAreaOutline>
</junction>

2. Direct Links

Table 3. Status of the concept
Target Version:	Effects Backward Compatibility:	Complexity for Implementation:	Acceptance Status:
1.7	N	low(concept→Standard)	accepted

2.1. Short summary and motivation of the proposal

This concept proposes adding a new junction type to OpenDRIVE in order to simplify the modeling of motorway exits and entries. Motorway roads shall be linked directly without connecting roads. This will reduce the number of roads required to describe motorway exits and entries by up to 40 to 50 %.

There are the following advantages:

Easier modeling of motorway exits by removing the connectingRoad element.
Leaner XML code.
Improved processing by simulation applications.

There are the following disadvantages:

The concept would be limited to a specific junction class. It can only be used for non-overlapping entry or exit lanes, see the concept on junction classes.
The concept could be used for junctions that are not in scope. To prevent misuse, a clear recommendation for how to model specific junction types is required. This should be carried out in liaison with the concept on junction classes.

2.2. Use cases

Simplify the modeling of junctions that serve as motorway exits and entries.

The following stakeholders will benefit:

Users of OpenDRIVE who model junctions.
Tool vendor who process OpenDRIVE files containing non-overlapping junctions

2.3. Details of the proposal

2.3.1. How is it solved in OpenDRIVE 1.6?

Motorway exits and entries are treated in the same way as junctions in urban areas or junctions of other junction types. They need a connecting road to link roads that lead into the junction with roads that lead out of the junction, as shown in Figure 8.

Figure 8. Motorway exit entries in OpenDRIVE 1.6

2.3.2. General description

In OpenDRIVE 1.6, motorway exits and junctions in urban areas are modeled in the same way, although junctions in urban areas mostly have many more possible turns. Connecting roads are required for urban junctions to model the turning possibilities. Because turning is not allowed on motorway junctions, connecting roads in motorway exits are obsolete.

The concept proposes a new junction type that uses direct links between roads that lead into the junction and roads that lead out of the junction, as shown in Figure 9. Junctions that are modeled in this way conform to junction class 1 that is part of the concept on junction classes.

The new junction type for junction elements shall be type=direct.

The element connectingRoad is obsolete for the junction type direct and replaced by the element followingRoad (see XML example. In this way, roads that lead into a junction can be directly linked to roads that lead out of a junction, without connecting roads.

The introduction of followingRoad would also solve a semantic problem with connecting roads. In OpenDRIVE 1.6, connecting roads are often placed in areas where it still seems possible to change the road although a vehicle has chosen one road in the traffic simulation. See also Figure 8, where the change from the road with id=102 to the road with id=101 is not possible. With direct links, it would be possible to link incoming roads with the following roads at the theoretical gore point, which would eliminate that issue.

Figure 9. Motorway exit with the possibility to change lanes

2.3.3. Rules

The reference lines for successor roads shall have the same heading as the incoming road. In this way, gaps in the road surface can be avoided. See linking of roads in OpenDRIVE 1.6.
The junction should be placed at the point where the traffic rule for lane changing on motorway exits or entries changes.
The proposed junction type shall only be used for non-overlapping entry and exit lanes.

2.3.4. XML example

Proposed new structure

<road name="" length="50" id="1" junction="-1">
    <link>
        <predecessor elementType="junction" elementId="000" />
        <successor elementType="junction" elementId="111"/>
    </link>
</road>
<road name="" length="50" id="2" junction="-1">
    <link>
        <predecessor elementType="junction" elementId="111" />
        <successor elementType="junction" elementId="222"/>
    </link>
</road>
<road name="" length="50" id="3" junction="-1">
    <link>
        <predecessor elementType="junction" elementId="111" />
        <successor elementType="junction" elementId="333"/>
    </link>
</road>
<junction name="" type="direct" id="111">
    <connection id="0" incomingRoad="1" followingRoad="2" contactPoint="start">
        <laneLink from="-4" to="-1"/>
    </connection>
    <connection id="1" incomingRoad="1" followingRoad="3" contactPoint="start">
        <laneLink from="-1" to="-1"/>
        <laneLink from="-2" to="-2"/>
        <laneLink from="-3" to="-3"/>
    </connection>
</junction>

2.4. Out of scope and limitations

It shall not be possible to combine incoming roads and following roads. For the example in Figure 9 that means it shall not be possible to merge the road with id=1 and road with id=2. Merging would further reduce the number of roads in a junction from two to one. A road of such a length, 50 km or more, could cause issues due to floating point errors. To prevent this, the maximum length is from one motorway junction to the next.

3. Specify the length of virtual junctions

Table 4. Status of the concept
Target Version:	Effect Backward compatibility:	Complexity for Implementation:	Acceptance Status:
1.7	N	low (concept→Standard)	accepted

3.1. Short summary of the proposal and motivation

Simulated vehicles driving into virtual junctions cannot recognize connecting roads inside the virtual junction. Therefore, incoming traffic on those connecting roads are unexpected for the simulated vehicles. For this reason, the concept proposes adding the length of the area created by the virtual junction to the virtual junction element.

There are the following advantages:

It will be easier for simulated vehicles to access virtual junctions.
Vehicles in simulation will find it easier to determine the possible interaction with traffic on connecting roads inside a virtual junction.

3.2. Use cases for the concept

Recognition of connecting roads inside a virtual junction by vehicles.
Easier modelling of parking/driveway/… exit/entries.

Possible further use case:

Use of virtual junctions for slip roads and overlapping motorway exits.

3.3. Details of the proposal

3.3.1. How is it solved in OpenDRIVE 1.6?

In OpenDRIVE 1.6, there is no possibility for simulated vehicles on the main road to recognize where connecting roads or the overlap of roads in virtual junctions begin. Virtual junctions have the attribute type=virtual. See Figure 10 and XML example

Figure 10. Virtual junction example from OpenDRIVE 1.6

3.3.2. General description

As the concept proposes to add the length of the areas of virtual junctions to the virtual junction element, this idea is shown in Virtual junction in OpenDRIVE 1.6.

Simulated vehicles driving into areas with virtual junctions cannot recognize the connecting roads created by the virtual junction element. The concept proposes storing information on the position of virtual junctions by means of three attributes in junction elements of type=virtual:

mainRoad: the main road from which the connecting roads of the virtual junction branch off.
sStart: start position of the virtual junction in the reference line coordinate system.
sEnd: end position of the virtual junction in the reference line coordinate system.
orientation: defines the relevance of the virtual junction according to the driving direction
The values should be: +, -, none (=both)

Their application is shown in this XML example.

The additional attributes enable simulated vehicles to detect where the area of the virtual junction begins. This is shown in Figure 11.

3.3.3. Rules

The attributes mainRoad, sStart, sEnd, orientation shall only be valid for junctions of type virtual.

3.3.4. XML examples

Virtual junctions in OpenDRIVE 1.6

<junction name="myJunction" type="virtual" id="111" >
    <connection id="0" incomingRoad="1" connectingRoad="2" contactPoint="start">
        <laneLink from="-1" to="-1"/>
    </connection>
    <connection id="1" incomingRoad="99" connectingRoad="3" contactPoint="start">
        <laneLink from="-1" to="-1"/>
    </connection>
</junction>

Proposed new structure

<junction name="myJunction" type="virtual" id="111" mainRoad = "1" sStart = "50" sEnd = "70" orientation = "+">
    <connection id="0" incomingRoad="1" connectingRoad="2" contactPoint="start">
        <laneLink from="-1" to="-1"/>
    </connection>
    <connection id="1" incomingRoad="99" connectingRoad="3" contactPoint="start">
        <laneLink from="-1" to="-1"/>
    </connection>
</junction>

3.3.5. Images

Virtual junction in OpenDRIVE 1.6

virtJunctionLength

Figure 11. Virtual junction area

Figure 12. 2nd example of a virtual junction area

4. Junction Classes

Table 5. Status of the concept
Target Version:	Effect Backward Compatibility:	Complexity for Implementation:	Acceptance Status:
1.7	N	high (concept→Standard)	accepted

4.1. Summary of the proposal and motivation

The concept proposes standardized modeling guidelines for different junction classifications. Six junction classes shall be used as templates for typical traffic situations. This means, similar junctions can be consistent including the correct usage of the junction type attribute. The introduction of a junction class attribute is not goal of this concept.

The guidelines should be valid for all three junction types: regular, virtual, direct.

There are the following advantages:

Better portability between creators and consumers of OpenDRIVE files
Clearer usage of junction type attribute
Increase usability of OpenDRIVE

There are the following disadvantages:

The concept does not propose changes to the standard but only to the documentation. It is only a guideline

4.2. Use cases

The concept deals with the issue that the creation of junctions in OpenDRIVE is complex and hard to understand for some users. There are different approaches to define one and the same junction in the standard. Standardized junction classes would simplify the creation of junctions by providing guidance for creation.

This list of junction classes should cover the most common junctions found in reality. It should be possible to create any junction based on one of the listed classes. There might also be examples for junctions that do not fit in a class though.

4.3. Detailes of the proposal

4.3.1. How is it solved in in OpenDRIVE 1.6?

In OpenDRIVE 1.6 every junction has to be built from scratch. There are two junction types (with type as an attribute): virtual and default. Virtual junctions are not designed for real world traffic situations. Their only use case are driveways that lead to parking lots or residential estates.

4.3.2. General description

The working group proposes the following junction classes:

JC1 – Non overlapping motorway entry and exit

This junction class in shown the embedded map. It is planned to be natively supported by the new junction type direct proposed in the concept on direct links.

The guideline for this class focuses especially on the following points:

How to use junctions of type direct in this use case.
The configuration of lanes for exit and entry roads.

Example of non-overlapping highway entry

JC2 - Common junctions

The junction class common, is shown in the embedded maps. This class should be the default junction type for urban scenarios. Multiple exit and entry roads are allowed. There shall be no overlapping of lanes except for connecting roads.

The guideline for this class focuses especially on the following points:

How to model junctions with roads that do not end with an 90° angle at a junction.
How to model junctions with roads that end with an 90° angle at a junction.
How to model T-junctions, X-junctions, and junctions with five or more incoming roads.
Definition of, for example, stopping lines.
Road marks on connecting roads, including how and when to hide road marks on connecting roads.

Examples for common junctions:

JC3 - Forks and overlapping exit or entries

The junction class fork is shown in the embedded maps. This type is used for junctions whose exit or entry roads enter from an existing lane. The use case for this junction type are mainly German motorway exits. Overlapping roads shall be allowed.

The guideline for this class focuses especially on the following points:

How to use (virtual) junctions in this use case.

The configuration of lanes for exit and entry roads.

Examples forks

JC4 - Slip roads

The junction class sliproads is shown in the embedded map. This type should be the default for right-turning traffic. It contains junctions of classes 1 and 3. It allows overlapping and non-overlapping roads.

The guideline for this class focuses especially on the following points:

This is a combination of junction classes JC1 and JC3, so maybe no separate class is required.
How to use junction groups for large junctions including slip roads.

Example of slip roads

JC5 - Roundabouts

In OpenDRIVE, a roundabout, as shown in the embedded maps, is a collection of several T-junctions.

The guideline for this class focuses especially on the following points:

How to model single-lane and double-lane roundabouts.
How to use junction groups for roundabouts.

Single lane roundabout

Two lane roundabout

JC6 - Motorway interchange

Two interchanging motorways result in very complex intersections, for example clover leaf, trompetes, stack interchange, … These complex interchanges are an assembly of many small junctions.

The guideline for this class focuses especially on the following points:

How to use junction groups for motorway interchange.
Why is a junction group useful and what use case can it support.
How to best use the different junction types in these interchanges.

4.4. Out of scope and limitations

This is only an input to create a guideline for the creation of junction classes.

5. Concept postponed for later editing

5.1. Elongated reference line in junctions

Table 6. Status of the concept
Target Version:	Effect Backward compatibility:	Complexity for Implementation:	Acceptance Status:
2.0	Y	low/mid/high (concept→Standard)	no further time investigating this concept

5.1.1. Short summary and motivation of the proposal

Elongate the reference line in certain junctions to “main road” reference line and use connecting lane links to remove holes or redundant geometry information.

Figure 13. Lane Information

Figure 14. Junction reference line overview

5.1.2. Notes / Comments / Links

This concept will be looked at again in the follow-up project.

6. Rejected concepts:

6.1. Elevation values for lanes in junctions

Table 7. Status of the concept
Target Version:	Effect Backward compatibility:	Complexity for Implementation:	Acceptance Status:
n.a	n.a	n.a	not accepted

6.1.1. Which problem is the concept intended to solve?

elevation differences in junctions
gaps in junctions

6.1.2. What is the idea of the concept?

The idea is to use the elevation of the incoming roads until the end of the junction.

6.1.3. How is it done in OpenDRIVE 1.6?

Within a junction it is possible to define the z-position of the lanes by the following methods:

via OpenCRG as in OpenDRIVE 1.5 but with a defined transition
via lane elevation as in OpenDRIVE 1.x
if the junction is flat, the incoming elevation can be taken for the entire area

6.1.4. Why has the concept been rejected?

The issue of elevation differences would only be moved outside of the junction. This concept will only solve the gaps within the junction. The concept on the junction grid can solve both issues.

6.2. Global reference point

Table 8. Status of the concept
Target Version:	Effects Backward Compatibility:	Complexity for Implementation:	Acceptance Status:
n.a	n.a	n.a	not accepted

6.2.1. What is the idea of the concept?

Define a global reference point in the OpenDRIVE file to place, for example, objects.

6.2.2. Why has the concept been rejected?

The concept on junction road will solve the issue in a more convient way. Furthermore, to link all objects to a global reference point would make the association with objects in a junction difficult.

Concept paper WP02: Environmental representation

1. Simplifying the data model of OpenDRIVE by implementing modeling paradigms

Table 9. Status of the concept
Target Version:	Effect Backward Compatibility:	Complexity for Implementation:	Acceptance Status:
2.0	Y	mid (concept→Standard)	accepted

1.1. Short summary and motivation of the proposal

The concept proposes to reduce the complexity of the OpenDRIVE data model with focus on object modeling. A more generalized abstractObject class will be introduced in the UML model to eliminate redundancies in the representation of objects. This class will group semantic information of other object classes.

The approach can also be applied to other classes, such as signals and roads.

There are the following advantages:

Reduce the complexity of the OpenDRIVE objects data model.
The OpenDRIVE standard becomes easier to understand.

There are the following disadvantages:

There is no backward compatibility.

1.2. Use cases

Simplify the process of getting started with OpenDRIVE.
Easier modeling of objects.

The following stakeholders will benefit:

Users of OpenDRIVE creating objects.

1.3. Details of the proposal

1.3.1. General description

There are three standard modeling paradigms that will improve the OpenDRIVE data model. This concept illustrates the improvements by applying these paradigms to the object class.

Introducing a more generalized `abstractObject` class

In OpenDRIVE 1.6, objects are modeled in four classes (see UML model):

Object
Tunnel
Bridge
ObjectReference

All these classes have similar basic information, like name and ID. The new abstractObject class (see UML model) groups the attributes name, ID , validLength, and orientation in one class and provides the information to its subordinate classes. As a result, these attributes only need to be defined once in the UML model. This avoids redundancies as in OpenDRIVE 1.6, where attributes have to be defined separately for each class. See also the XML example.

Extending the relationship between classes by the methods of aggregation and composition

In OpenDRIVE 1.6, all relationships between classes are modeled as simple class relations. In some cases, it would be more precise to use aggregation or composition instead.

Aggregation is a special type of association that describes a part-of relation between the aggregate (whole) and the part. The part can exist independently of the whole.
Composition is a form of aggregation with strong ownership and coincident lifetimes of the whole and its parts. The parts cannot exist independently of the whole. Parts with non-fixed multiplicity may be created after the whole itself, but once created they live and die with it. Parts may also be removed before the death of the whole. Composition may be recursive. For OpenDRIVE, composition should be avoided.

The following overview shows the available relations in the UML model:

Table 10. Available relations in the UML model
Name	Type of relationship	Example
Relation	Class A has a class B	Every relationship in the object class (see below)
Aggregation	Class B is part of class A (part-of relation)	`LaneSection` is part of `Lanes` (see UML model of OpenDRIVE 1.6)
Composition	Class B is part of class A and can only exist as long as class A exists	No example in current UML model

Implementing naming conventions and name spaces

In complex data models it is helpful to organize classes in package structures. These packages are encapsulated by namespaces. Each package has its own namespace prefix. The package classes can be identified by a unique class name and a prefix.

In OpenDRIVE 1.6, there are no namespaces. An implicit package structure is given by the class name, which is very cumbersome. For example: t_road_objects_tunnel

The working group proposes simplifying the class names and introduceing a namespace for each OpenDRIVE package.

An OpenDRIVE class would look like this:

Class name: Object::Tunnel
Instance element: <obj:tunnel>

This will make it possible to use identical class names in multiple packages. To make class names easier to understand, they should be short.

An XML example is shown below.

The new UML structure is a suggestion and needs to be discussed further.

1.3.2. UML model

Figure 15. UML model of the OpenDRIVE 1.6 object class.

Figure 16. UML model of the proposed OpenDRIVE 2.0 object class

1.3.3. XML examples

Example 1. Introducing a more generalized `abstractObject` class

Current OpenDRIVE 1.6

<objects>
  <object type="streetlamp" name="" id="" s="" t="" zOffset="" validLength="" orientation="" height="" hdg="" />
  <object type="tree" name="" id="" s="" t="" zOffset="" validLength="" orientation="" height="" hdg="" />
  <object type="roadMark" name="" id="" s="" t="" zOffset="" orientation="" length="" width="" height="" hdg=""/>
</objects>

New proposal with semantic subclasses

<abstractObject>
  <genericObject id="" name="" type="pole" subtype="streetlamp" orientation=""/>
  <genericObject id="" name="" type="vegetation" subtype="tree" orientation=""/>
  <auxiliaryMarking id="" name="" type="roadmark" subtype="text" orientation=""/>
</abstractObject>

Example 2. Naming conventions and name spaces

Current OpenDRIVE 1.6

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<OpenDRIVE>
  <header revMajor="" revMinor="" name="" date="" north="" east="" south="" west="" vendor="">
    <geoReference></geoReference>
  </header>
  <road name="" length="" id="" junction="">
    <link>
      <successor elementType="" elementId="" />
    </link>
    <type s="" type="" />
    <planView>
      <geometry s="" x="" y="" hdg="" length="">
        <paramPoly3 aU="" bU="" cU="" dU="" aV="" bV="" cV="" dV="" pRange="" />
      </geometry>
    </planView>
    <elevationProfile>
      <elevation s="" a="" b="" c="" d="" />
    </elevationProfile>
    <lateralProfile>
      <superelevation s="" a="" b="" c="" d="" />
    </lateralProfile>
    <lanes>
      <laneSection s="" singleSide="">
        <left>
          <lane id="" type="" level="">
            <link>
              <successor id="" />
            </link>
            <width sOffset="" a="" b="" c="" d="" />
          </lane>
        </left>
        <center>
          <lane id="" type="" level="">
            <roadMark sOffset="" type="" weight="" color="" width="" material="" />
          </lane>
        </center>
        <right>
          <lane id="" type="" level="">
            <link>
              <successor id="" />
            </link>
            <width sOffset="" a="" b="" c="" d="" />
          </lane>
        </right>
      </laneSection>
    </lanes>
    <object>
      <object type="" name="" id="" s="" t="" zOffset="" validLength="" orientation="" height="" hdg="" />
    </objects>
    <signals>
      <signal s="" t="" id="" name="" dynamic="" orientation="" zOffset="" country="" type="" subtype="-1" value="-1" hOffset="" />
    </signals>
  </road>
</OpenDRIVE>

New proposal with namespaces

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<OpenDRIVE xmlns="http://www.asam.net/opendrive/1.6/schema/core"
xmlns:geom="http://www.asam.net/opendrive/1.6/schema/geometry"
xmlns:junc="http://www.asam.net/opendrive/1.6/schema/junction"
xmlns:lane="http://www.asam.net/opendrive/1.6/schema/lane"
xmlns:obj="http://www.asam.net/opendrive/1.6/schema/object"
xmlns:rail="http://www.asam.net/opendrive/1.6/schema/railroad"
xmlns:road="http://www.asam.net/opendrive/1.6/schema/road"
xmlns:sig="http://www.asam.net/opendrive/1.6/schema/signal"
>
  <core:header revMajor="" revMinor="" name="" date="" north="" east="" south="" west="" vendor="">
    <core:geoReference></geoReference>
  </core:header>
  <road:road name="" length="" id="" junction="">
    <road:link>
      <road:successor elementType="" elementId="" />
    </road:link>
    <road:type s="" type="" />
    <road:planView>
      <geom:paramPoly3 aU="" bU="" cU="" dU="" aV="" bV="" cV="" dV="" length="" pRange="" >
        <geom:linearReference s=""/>
        <geom:inertialReference x="" y=""/>
        <geom:inertialTransform hdg=""/>
      </geom:paramPoly3>
    </road:planView>
    <road:elevationProfile>
      <geom:polynom a="" b="" c="" d="" >
        <geom:linearReference s=""/>
      </geom:polynom>
    </road:elevationProfile>
    <road:lateralProfile>
      <geom:polynom a="" b="" c="" d="" >
        <geom:linearReference s=""/>
      </geom:polynom>
    </road:lateralProfile>
    <lane:lanes>
      <lane:laneSection s="" singleSide="">
        <lane:left>
          <lane:lane id="" type="" level="">
            <lane:link>
              <lane:successor id="" />
            </lane:link>
            <lane:width sOffset="" a="" b="" c="" d="" />
          </lane:lane>
        </lane:left>
        <lane:center>
          <lane:lane id="" type="" level="">
            <lane:roadMark sOffset="" type="" weight="" color="" width="" material="" />
          </lane:lane>
        </lane:center>
        <lane:right>
          <lane:lane id="" type="" level="">
            <lane:link>
              <lane:successor id="" />
            </lane:link>
            <lane:width sOffset="" a="" b="" c="" d="" />
          </lane:lane>
        </lane:right>
      </lane:laneSection>
    </lane:lanes>
    <obj:object>
      <obj:object type="" name="" id="" s="" t="" h="" zOffset="" validLength="" orientation="" height="" hdg="" />
    </obj:objects>
    <sig:signals>
      <sig:signal s="" t="" h="" id="" name="" dynamic="" orientation="" zOffset="" country="" type="" subtype="-1" value="-1" hOffset="" />
    </sig:signals>
  </road:road>
</OpenDRIVE>

2. Geometry modeling in OpenDRIVE

Table 11. Status of the concept
Target Version:	Effects Backward Compatibility:	Complexity for Implementation:	Acceptance Status:
2.0	Y	high (concept→Standard)	accepted

2.1. Short summary and motivation

The concept proposes simplifying the modeling of object geometry in OpenDRIVE. In the current version, geometry records are scattered over the entire OpenDRIVE file. The records are not separated from attributes that describe semantic or logical information. The concept suggests to summarizing geometry records in a new geometry class that contains all available geometry types of OpenDRIVE.

There are the following advantages:

OpenDRIVE will be easier to understand and more readable, see example.
UML model and XML schema of OpenDRIVE become simpler, because there are fewer redundancies. This will make it easier to create OpenDRIVE files and make them more compact, see example.
Geometry types can be reused for different situations.
Multiple geometry representations for the same object on different levels of detail will be possible.
Interoperability improves and OpenDRIVE becomes open to new data sources, because standardized geometry types are used.
Semantic, logical, and geometric attributes are separated and can be moved to new classes (where useful). These classes can then be used in the whole OpenDRIVE standard. For example, STH-position could be introduced as one class describing a linear reference along the reference line, which can be used for various OpenDRIVE elements, see example.
The modeling of road elements will be improved, see example.

There are the following disadvantages:

There is no backward compatibility.

This concept focuses on the geometry model of objects but tries to define a general geometry package containing all geometry types describing the shape of any OpenDRIVE element.

2.2. Use cases

Parametric road geometry description, as in the current version of OpenDRIVE.
Parametric object geometry description where preferable, for example simple or low level description.
Boundary representation, using simple features for planar or voluminous objects.
All geometry representations with all levels of detail are possible at the same time.
Even more detailed geometries can be linked as an external reference (using the concept on external references).
Different use cases might need information in different levels of detail regarding road geometry and especially regarding environment representation. For some use cases a simple outline representation is enough, whereas sensor simulation need detailed object description including 3D object shape and surface materials. Multiple geometry representation can help to increase the field of application of OpenDRIVE.

2.3. Details of the proposal

The proposal contains the following sections:

Requirements
How is it done in OpenDRIVE 1.6
Common modeling approaches for (multiple) geometry representation
General description
Referencing external geometry definitions
Rules
Examples

2.3.1. Requirements:

Using common geometry types requires the separation of information on semantics, topology, and geometry.

Semantic: Properties describing the interpretation of the object.
Topology: Properties describing the relation to other objects.
Geometry: Properties describing the position and shape of the object.

Material and appearance are not in the scope of this work package.

2.3.2. How is it done in OpenDRIVE 1.6?

In OpenDRIVE 1.6, information on geometry is scattered over the entire OpenDRIVE file. The basic modeling approach is a parametric geometry description. This is useful to describe the road shape but is cumbersome and by design limited regarding the description of object shapes. Furthermore, some attributes defining geometry types are defined multiple times, for example polynomials.

2.3.3. Common modeling approaches for (multiple) geometry representation

Depending on the application and the required level of detail, different approaches can be used to model objects.

Boundary Representation (BREP)

With BREP, objects are described by their limiting surfaces. This method is used to describe complex real-world structures derived from measurement data.

BREP has the following advantages:

The boundary of objects can be modeled by measurement data derived from real-world scenarios.
Complex objects of arbitrary shapes can be modeled.

BREP has the following disadvantages:

It is too sophisticated for simple primitive shapes, such as box, cylinder, and sphere.

Constructive Solid Geometry (CSG)

CSG allows creating a complex surface or object by using Boolean operators to combine simpler objects and generate more complex objects by combining a few primitive ones. It is used for simpler shapes.

CSG has the following advantages:

Geometry description using primitive shapes, such as box, cylinder, sphere.
More complex shapes can be created with CSG by using set operations, for example, union, intersection, and difference.
CSG is especially useful for simple shapes.

CSG has the following disadvantages:

CSG breaks the backward compatibility to OpenDRIVE 1.6

External reference

External reference to complex shapes with appearance (see also the concept on external references).

NOTE:

A style guide is required that defines which levels of detail should be included directly in OpenDRIVE and which details can be external references.
A standard support of common geometry representations in OpenDRIVE would make object modeling easier and more understandable.
External references could help improve interoperability and open new data sources.

2.3.4. General description

The new geometry class contains the following sections, as shown in the following UML models.

The general geometry packages define all available geometry types for OpenDRIVE.

One basic AbstractGeometry class with three different child classes, see UML model for the class Geometry.
- Standard OpenDRIVE geometries for modeling road shape (_AbstractODRGeometry), see UML model for the class ODRGeometry.
- Object modeling using CSG primitives (_CSGPrimitive), see UML model for the class CSGGeometry.
- Object modeling using BREP geometry (_BREPGeometry ), see UML model for the class BREPGeometry.
All geometry types derived from the _AbstractGeometry may have a bounding box that can be used for spatial indexing, see UML model for the class Geometry.
All geometry types derived from the _AbstractGeometry may have a transformation matrix specifying sth-offsets and rotation for STGeometries or xyz-offsets, rotation, and scale for other geometry types, see UML model for the class Geometry.

Figure 17. Structure of the new geometry class

The method used for describing the road shape is not changed. The current geometry types Line, Arc, Spiral, poly3, and paramPoly3 are only moved to the new geometry package. Therefore, all subclasses of the abstract class “_AbstractGeometry” (see UML model for the class Geometry) are further specialized to distinct geometry types. Additionally existing concepts of linear reference and repeated objects are added as standard geometry types (see UML model for the class ODRGeometry).

Discussion on repeated objects

Repeated objects are objects that occur repeatedly along a given base, for example the reference line. For such cases, the type _AbstractRepeatGeometry is introduced that defines the basic properties of a repeated object:
- Linear reference
- Start position
- End position
- Base geometry, for example, the reference line or possibly a specific curve defined for this object.
Primarily, repeated objects are used for repeating object types. This is especially useful for synthetic data, if the same object type is repeated after a certain distance. For example, delineators can be easily described by defining the distance and by a unique description of the geometry. This use case would be supported by the new geometry type STHRepeat. It defines a distance to repeat an object and inherits attributes to describe an object using parameters. If an unchanged shape of the object shall be modeled, for example delineator, a _BREPGeometry, _SolidGeometry or external reference can be used.
On the other hand, the geometry for repeated objects can be used to describe curves parallel to the reference line. This is particularly useful for continuous objects, such as guardrails. These could also be described by the geometry type polyline. For particularly elongated objects that stretch over several kilometers, however, the insertion of such a long geometry is very complex. For this use case, the parametric description of repeated objects is very space-saving. If, in such use cases, the geometry is inserted only in small pieces, the continuous curve of the object is lost. For these use cases, the ContinuousRepeat type is introduced.

The repeated objects are still under discussion. All described use cases should be covered by the implementation project for OpenDRIVE 2.0

Figure 18. Standard OpenDRIVE geometries for modeling road shapes

Figure 19. Parametric modeling of objects using CSG primitives

Figure 20. More detailed object modeling with BREP geometries according to the Simple Feature model

Referencing external geometry definitions

In OpenDRIVE 1.6, an object like a tree can have only one very primitive geometry representation using a cylinder or cube (see Figure 21). That means that a tree would be modeled as one or more cylinders, which is a very rough approximation of its shape in the real world. For some applications this might be sufficient while others need more details. However, there is no reason why a geometry representation should be restricted to cylinders and spheres.

Extending the geometry class with CSG primitives makes modeling easier to understand, because common geometry types are used. Furthermore, extending the geometry module by the Simple Feature Model simplifies the detailed representation of objects and enables the storage of more complex geometries within OpenDRIVE. For more information on the Simple Feature Model, see ISO 19125-1:2004 or the OGC website.

The concept therefore proposes to introduce implicit geometries (implicitGeometry) as a standardized way of referencing complex external geometries with or without appearances or reusing generic geometry representations (see UML model for the class Geometry).

With multiple geometry representation, one object can have different geometry representations in different levels of detail at the same time, for example 2D outline, extruded outline, and 3D objects in different resolutions.

Figure 21. Comparison of different tree representations: a) OpenDRIVE point b) CSG cylinder c) BREP geometry d) CityGML with appearance e) 3D Billboard

2.3.5. Rules

Because the concept is still a preliminary draft, no rules have been defined yet. When implementing the concept or parts of the concept, specific rules for the use of each new element must be defined.

2.3.6. Examples

It is very cumbersome to describe planar or voluminous objects using st-positions. Instead, common geometry types shall be introduced, as described above. The following examples provide an overview of how objects could be modeled using the proposed concept of separating semantic, topology and geometry properties.

General example of describing objects in OpenDRIVE

The concept uses XML namespaces as proposed in the concept "Simplifying the data model of OpenDRIVE by implementing modeling paradigms".

Current OpenDRIVE 1.6

<object type="" name="" id="" s="" t="" zOffset="" validLength="" orientation=" " length="" width="" height="" hdg="" pitch="" roll="">
  <outline>
    <cornerRoad s="" t="" dz="" height="" />
    <cornerRoad s="" t="" dz="" height="" />
    <cornerRoad s="" t="" dz="" height="" />
    <cornerRoad s="" t="" dz="" height="" />
    <cornerRoad s="" t="" dz="" height="" />
  </outline>
</object>

New proposal

The following example is not complete but is provided to illustrate the possibilities of the new approach. It still needs to be discussed how coordinates of simple features are stored in XML instance documents. One possibility would be GML. The Transformation class specifying translation, rotation and scale of geometries is discussed in more detail in the concept on the referencing of external objects..

<obj:genericObject id="" name="" type="" subtype="">
  <lane:LaneValidity/>
  <obj:Material/>
  <obj:linearReference>
    <geom:sthPosition s="" t="" h=""/>
  </obj:linearReference>
  <obj:explicit2DGeometry> <!-- optional -->
    <geom:Point>x y (z)</geom:Point>
    <geom:Polygon>x1 y1 (z1) x2 x2 (z2) x3 y3 (z3) ... xn yn (zn)</geom:Polygon>
  </obj:explicit2DGeometry>
  <obj:explicit3DGeometry> <!-- optional -->
    <geom:MultiPolygon>
      <!-- polygon elements -->
    </geom:MultiPolygon>
  </obj:explicit3DGeometry>
  <obj:parametric3DGeometry> <!-- optional -->
    <geom:Cube length="" width="" height=""/>
  </obj:parametric3DGeometry>
  <obj:implicit2DGeometry> <!-- optional -->
    <geom:implicitGeometry transformation="" libraryObject="" mimeType=""/>
  </obj:implicit2DGeometry>
  <obj:implicit3DGeometry> <!-- optional -->
    <geom:implicitGeometry transformation="" libraryObject="" mimeType=""/>
  </obj:implicit3DGeometry>
</obj:object>

Example of reduced redundancies and the complexity of the OpenDRIVE model using the `lane` chapter

Even with the current approach, some attributes or attribute types are defined multiple times within the OpenDRIVE standard. For example, there are multiple classes for left, right, and center lanes describing the same type Lane. The same applies to polynomials that are defined, as proposed by concept A, as class Geometry:Polynomial, Lanes:LaneOffset, Lanes:Border and Lanes:Width. To eliminate redundancies, a type polynomial could be used for all these occurrences. An important part of OpenDRIVE is the linear referencing using an s-position. If a type Geometry:ST-Position is introduced, this type could be reused all over the OpenDRIVE format as a linearReference relation.

The following UML models of the lane class summarizes the proposed concept. The comparison between the UML model of OpenDRIVE 1.6 with the new proposal illustrates the reduced complexity.

Figure 22. UML model of lanes in OpenDRIVE 1.6

Figure 23. UML model of a lane class in the proposed OpenDRIVE 2.0

2.3.7. Specific examples of OpenDRIVE objects

The following examples show how the new concept is applied to different kinds of objects or signals. Objects affecting traffic are modeled as signals while objects that do not affect the traffic are modeled as object.

It is part of the concept to rename the class Objects:Marking to Objects:AuxilliaryMarking. This would emphasize, where which markings should be modeled.

Example 1: Tree

Tree

Semantic

Topology

Geometry

type, subtype

road reference

Point (st / xyz)
Polygon
MultiPolygon

New proposal

<road:road id="100">
  <obj:objects>
    <obj:genericObject id="1" name="" type="vegetation" subtype="tree" orientation="">
      <obj:linearReference>
        <geom:sthPosition s="" t=""/>
      </obj:linearReference>
      <obj:explicit2DGeometry> <!-- optional -->
        <geom:Point>
          <!-- point definition in XYZ -->
        </geom:Point>
      </obj:explicit2DGeometry>
      <obj:explicit3DGeometry> <!-- optional -->
        <geom:MultiPolygon>
             <!-- polygon elements defining polygonal shape (BREP) in XYZ -->
        </geom:MultiPolygon>
      </obj:explicit3DGeometry>
      <obj:parametric3DGeometry> <!-- optional -->
        <geom:Cylinder height="" radius=""/>
        <geom:Sphere radius=""/>
      </obj:parametric3DGeometry>
      <!-- further geometry representation or reference possible -->
    </obj:genericObject>
  </obj:objects>
</road:road>

OpenDRIVE version 1.6

<road id="100">
  <objects>
    <object type="tree" name="tree" id="" s="" t="" zOffset="" validLength="" orientation="" radius="" height="" hdg="" />
  </objects>
</road>

Example 2: House

House

Semantic

Topology

Geometry

type, subtype

road reference

Point (st / xyz)
Polygon
MultiPolygon

New proposal

<road:road id="100">
  <obj:objects>
    <obj:genericObject id="1" name="building" type="building" subtype="building">
      <obj:linearReference>
        <geom:sthPosition s="" t=""/>
      </obj:linearReference>
      <obj:explicit2DGeometry> <!-- optional -->
        <geom:Polygon>
           <!-- point list defining polygonal outline (building footprint) in XYZ -->
        </geom:Polygon>
      </obj:explicit2DGeometry>
      <obj:explicit3DGeometry> <!-- optional -->
        <geom:MultiPolygon>
             <!-- polygon elements defining polygonal shape (BREP) in XYZ -->
        </geom:MultiPolygon>
      </obj:explicit3DGeometry>
      <obj:parametric3DGeometry> <!-- optional -->
        <geom:Cube length="" width="" height=""/>
      </obj:parametric3DGeometry>
      <!-- further geometry representation or reference possible -->
    </obj:genericObject>
  </obj:objects>
</road:road>

OpenDRIVE version 1.6

<road id="100">
  <objects>
    <object type="building" name="building" id="" s="" t="" zOffset="" orientation="none" height="" hdg="">
        <outline>
          <cornerRoad s="" t="" dz="" height="" />
          <cornerRoad s="" t="" dz="" height="" />
          <cornerRoad s="" t="" dz="" height="" />
          <cornerRoad s="" t="" dz="" height="" />
          <cornerRoad s="" t="" dz="" height="" />
        </outline>
      </object>
  </objects>
</road>

Example 3: Guardrail

Guardrail

Semantic

Topology

Geometry

type, subtype

road reference

LineString
MultiPolygon

New proposal

<road:road id="100">
  <obj:objects>
    <obj:genericObject id="1" name="guardRailLeft" type="barrier" subtype="guardRail">
      <obj:linearReference>
        <geom:sthPosition s="" t=""/>
      </obj:linearReference>
      <obj:repeat>
        <obj:continuosRepeat length="">
          <obj:start length="" width="" height="">
            <geom:sthPosition s="" t=""/>
          </obj:start>
          <obj:end length="" width="" height="">
            <geom:sthPosition s="" t=""/>
          </obj:end>
        </obj:continuosRepeat>
      </obj:repeat>
      <obj:explicit2DGeometry> <!-- optional -->
        <geom:LineString>
           <!-- point list defining line in XYZ -->
        </geom:LineString>
        <geom:Polygon>
           <!-- point list defining polygonal outline in XYZ -->
        </geom:Polygon>
      </obj:explicit2DGeometry>
      <obj:explicit3DGeometry> <!-- optional -->
        <geom:MultiPolygon>
             <!-- polygon elements defining polygonal shape (BREP) in XYZ -->
        </geom:MultiPolygon>
      </obj:explicit3DGeometry>
      <!-- further geometry representation or reference possible -->
    </obj:genericObject>
  </obj:objects>
</road:road>

OpenDRIVE version 1.6

<road id="100">
  <objects>
    <object type="barrier" name="guardRailLeft" id="" s="" t="" zOffset="" orientation="none" height="" hdg="">
      <repeat s="" length="" distance="" tStart="" tEnd="" widthStart="" widthEnd="" heightStart="" heightEnd="" zOffsetStart="" zOffsetEnd="" />
    </object>
  </objects>
</road>

Example 4: Roadmark

Roadmark

Semantic

Topology

Geometry

type, subtype

road reference

Polygon

New proposal

<road:road id="100">
  <obj:objects>
    <obj:auxiliaryMarking id="1" name="arrow" side="" weight="" color="" >
      <obj:linearReference>
        <geom:sthPosition s="" t=""/>
      </obj:linearReference>
      <obj:explicit2DGeometry> <!-- optional -->
        <geom:Polygon>
           <!-- point list defining polygonal outline in XYZ -->
        </geom:Polygon>
      </obj:explicit2DGeometry>
      <obj:parametric3DGeometry> <!-- optional -->
        <geom:ExtrudedPrimitive height="">
          <geom:Polygon>
            <!-- point list defining polygonal outline in XYZ -->
          </geom:Polygon>
        </geom:ExtrudedPrimitive>
      </obj:parametric3DGeometry>
      <!-- further geometry representation or reference possible -->
    </obj:auxiliaryMarking>
  </obj:objects>
</road:road>

OpenDRIVE version 1.6

<road id="100">
  <objects>
    <object type="roadMark" name="arrowStraight" id="" s="" t="" zOffset="" orientation="none" length="" width="" height="" hdg="">
      <outline>
        <cornerLocal u="" v="" z="" height="" />
        <cornerLocal u="" v="" z="" height="" />
        <cornerLocal u="" v="" z="" height="" />
        <cornerLocal u="" v="" z="" height="" />
        <cornerLocal u="" v="" z="" height="" />
      </outline>
    </object>
  </objects>
</road>

Example 5: Crosswalk

Crosswalk

Semantic

Topology

Geometry

type, subtype, country, countryRevision

road reference, LaneValidity

Point (st / xyz)
Polygon
MultiPolygon

New proposal

<road:road id="100">
  <sig:signals>
    <sig:signal id="1" name="Crosswalk" dynamic="no" orientation="" country="Germany" type="..." subtype="-1">
      <obj:linearReference>
        <geom:sthPosition s="" t=""/>
      </obj:linearReference>
      <obj:explicit2DGeometry> <!-- optional -->
        <geom:Polygon>
           <!-- point list defining polygonal outline in XYZ -->
        </geom:Polygon>
      </obj:explicit2DGeometry>
      <!-- further geometry representation or reference possible -->
    </sig:signal>
  </sig:signals>
</road:road>

OpenDRIVE version 1.6

<road id="100">
  <signals>
    <signal s="" t="" id="" name="Crosswalk" dynamic="no" orientation="" zOffset="" country="Germany" type="" subtype="-1" value="-1" hOffset="" />
  </signals>
</road>

AND as <object> as applied in the other examples.

Example 6: Reflector post

Reflector post

Semantic

Topology

Geometry

type, subtype

road reference

Point
MultiPolygon

New proposal

<road:road id="100">
  <obj:objects>
    <obj:genericObject id="1" name="" type="post" subtype="delineator" orientation="">
      <obj:linearReference>
        <geom:sthPosition s="" t=""/>
      </obj:linearReference>
      <obj:repeat>
        <obj:sthRepeat length="" distance="">
          <obj:start length="" width="" height="">
            <geom:sthPosition s="" t=""/>
          </obj:start>
          <obj:end length="" width="" height="">
            <geom:sthPosition s="" t=""/>
          </obj:end>
        </obj:sthRepeat>
      </obj:repeat>
      <obj:explicit3DGeometry> <!-- optional -->
        <geom:MultiPolygon>
             <!-- polygon elements defining polygonal shape (BREP) in XYZ -->
        </geom:MultiPolygon>
      </obj:explicit3DGeometry>
      <obj:parametric3DGeometry> <!-- optional -->
        <geom:Cylinder height="" radius=""/>
      </obj:parametric3DGeometry>
      <!-- further geometry representation or reference possible -->
    </obj:genericObject>
  </obj:objects>
</road:road>

OpenDRIVE version 1.6

<road id="100">
  <objects>
    <object type="post" name="reflector" id="" s="" t="" zOffset="" orientation="none" height="" hdg="">
      <repeat s="" length="" distance="" tStart="" tEnd="" widthStart="" widthEnd="" heightStart="" heightEnd="" zOffsetStart="" zOffsetEnd="" />
    </object>
  </objects>
</road>

AND as signal.

<road id="100">
  <signals>
    <signal s="" t="" id="" name="reflector" dynamic="no" orientation="" zOffset="" country="Germany" type="..." subtype="-1" value="" hOffset="" />
  </signals>
</road>

Example 7: Stop sign

Stop sign

Semantic

Topology

Geometry

type, subtype, country, countryRevision

road reference, LaneValidity

Point (st / xyz)
MultiPolygon

New proposal

<road:road id="100">
  <sig:signals>
    <sig:signal id="1" name="StopSign" dynamic="no" orientation="" country="Germany" type="206" subtype="-1">
      <obj:linearReference>
        <geom:sthPosition s="" t=""/>
      </obj:linearReference>
        <geom:MultiPolygon>
             <!-- polygon elements defining polygonal shape (BREP) in XYZ -->
        </geom:MultiPolygon>
      <obj:parametric3DGeometry> <!-- optional -->
        <geom:Cylinder height="" radius=""/>
      </obj:parametric3DGeometry>
      <!-- further geometry representation or reference possible -->
    </sig:signal>
  </sig:signals>
</road:road>

OpenDRIVE version 1.6

<road id="100">
  <signals>
    <signal s="" t="" id="" name="StopSign" dynamic="no" orientation="" zOffset="" country="Germany" type="..." subtype="-1" value="" hOffset="" />
  </signals>
</road>

AND as <object> as applied in the other examples.

Example 8: Traffic light

Traffic light

Semantic

Topology

Geometry

type, subtype, country, countryRevision

road reference, LaneValidity

Point (st / xyz)
MultiPolygon

New proposal

<road:road id="100">
  <sig:signals>
    <sig:signal id="1" name="TrafficLight" dynamic="yes" orientation="" country="Germany" type="..." subtype="-1">
      <obj:parametric3DGeometry> <!-- optional -->
        <geom:Cube length="" width="" height=""/>
      </obj:parametric3DGeometry>
      <!-- further geometry representation or reference possible -->
    </sig:signal>
  </sig:signals>
</road:road>

OpenDRIVE version 1.6

<road id="100">
  <signals>
    <signal s="" t="" id="" name="TrafficLight" dynamic="yes" orientation="" zOffset="" country="Germany" type="1000015" subtype="-1" value="-1" hOffset="" />
  </signals>
</road>

AND as <object> as applied in the other examples.

Example of modeling road elements at a junction using the new proposal

Some road markings indicate traffic rules that need to be modeled in OpenDRIVE. This is often reflected in the fact that they have been included in the respective national catalogs of road signs. In Germany, for example, a stop line has the sign code ‘Z 294’. In OpenDRIVE 1.6, stop lines can only be described by modeling the line as a signal, which is a point feature, and the outline of the stop line as an object. Separating semantic information from geometry information allows modeling a stop line as a single signal feature that has the corresponding outline attached to it. Road markings that do not indicate important traffic rules can still be modeled as objects.

Figure 24 shows an American junction with pedestrian crossings and illustrates how road marks can be modeled with this approach. American traffic rules also use road markings that partially limit pedestrian passages as stop lines. These parts would be modelled as signals. The other parts are roadmark objects. The crossing areas can be modeled as ‘passage’ object.

Figure 24. American junction with pedestrian crossing and specific road marks

It still needs to be discussed whether crosswalks, stop lines, and arrows should be modeled as signals or as objects. The main differentiation shall be made between elements relevant to traffic and those not relevant. For OpenDRIVE 1.x objects to be modeled as signals, a geometry representation of signals is required. Furthermore, a type list for signals is necessary, comparable to crosswalk code or objectType enumerations.

2.4. Out of scope and limitations

Material and appearance are not in the scope of this work package.

A high level description of objects with textures or material information shall not be part of OpenDRIVE, but can be linked using the concept on external references.

3. External object referencing

Table 12. Status of the concept
Target Version:	Effects Backward Compatibility:	Complexity for Implementation:	Acceptance Status:
1.x	N	high (concept→Standard)	accepted

3.1. Short summary and motivation of the proposal

OpenDRIVE is a format for the description of roads. It does not and shall not include complex high-resolution geometry of objects. For use cases that require a detailed description of objects, references to external sources shall be used. The current version of OpenDRIVE does not specify how external objects are referenced. Neither does it specify how these objects are transformed from one coordinate system to another, which is a key issue of this concept.

A possible use case for referencing an external object is a multi-storey car park, where the road description is done with OpenDRIVE, while the geometry description of the building is inserted by an external reference.

There are the following advantages:

It will be easier to place objects of any shape in OpenDRIVE without making changes to the standard itself.
The visual representation of scenarios created by OpenDRIVE is improved.

3.2. Use Cases

This concept helps referencing and placing single 3D objects within OpenDRIVE, for example 3D models of traffic signs, trees, single buildings (see example).
The concept especially addresses use cases with synthetic datasets.
The concept can also be used with real-world datasets.

3.3. Detailes of the proposal

3.3.1. How is it done in OpenDRIVE 1.6?

OpenDRIVE 1.6 does not feature a standardized way of referencing external objects within OpenDRIVE.

3.3.2. General description

The decomposition of matrixes may be difficult to handle, as described in the schematic diagram.

Referencing external objects

For referencing external objects, the following elements shall be introduced:

ID: unique identifier of the referenced object in the external database
Link: reference to an external source (URL)

Transformation of coordinates of referenced objects from one coordinate system to another

To transform the coordinates of external objects from one coordinate system to another, the following elements shall be introduced:

Translation: translation of X, Y, Z, see Figure 26.
Rotation
- Quaternion (ABCD), for more information, see definition on Wolfram MathWorld)
- Euler angles in radians (heading, pitch, roll) (for more information, see definition on Wolfram MathWorld)
- Axis angle (XYZW)
Scale (XYZ)

The reference frame may have the following properties:

Local
Global

There are the following axis systems:

Y-up or Z-up
Left-handed or right-handed

Using the concept on the simplification of the OpenDRIVE data model, an external object can provide one of multiple geometry representations of an OpenDRIVE object.

Some of the points listed above are alternatives. The implementation project should choose one of the options where appropriate or explicitly allow more than one option.

Ways of transformation:

Translation, rotation, scale should be kept separately within the OpenDRIVE format.
- Translation is a 3D-vector (XYZ).
- Rotation is either a quaternion (ABCD) or Euler angle (heading, pitch, roll) or axis angle (XYZW).
- Scale is expressed as unit for each axis (XYZ).
An additional 4x4 SRT matrix (row-major? column-major?) can be added.

Extracting the different components of the matrix (translation, rotation, scale) is not always possible, because there can be multiple solutions. This may decrease precision. Especially decomposition of rotation and scale from a 4x4 matrix would need fixing the order of transformations.

Figure 25. Why matrix decomposition can be difficult to handle

Figure 26. Transformation order

The way how of forming a transformation matrix from translation, rotation and scale should be defined and vice verca. See sample code in Calculations.

3.3.3. Rules

Objects shall be defined corresponding to the reference line of the closest road object.

3.3.4. Calculations

Example of translation and rotation matrix composition

CreateMatrix(Vector3 translation, Quaternion rotation)
{
    var b = rotation.B + rotation.B;
    var c = rotation.C + rotation.C;
    var d = rotation.D + rotation.D;

    var ab = rotation.A * b;
    var ac = rotation.A * c;
    var ad = rotation.A * d;
    var bb = rotation.B * b;
    var bc = rotation.B * c;
    var bd = rotation.B * d;
    var cc = rotation.C * c;
    var cd = rotation.C * d;
    var dd = rotation.D * d;

    result.M11 = 1f - cc - dd;
    result.M12 = bc - ad;
    result.M13 = bd + ac;
    result.M14 = translation.X;
    result.M21 = bc + ad;
    result.M22 = 1f - bb - dd;
    result.M23 = cd - ab;
    result.M24 = translation.Y;
    result.M31 = bd - ac;
    result.M32 = cd + ab;
    result.M33 = 1f - bb - cc;
    result.M34 = translation.Z;
    result.M41 = result.M42 = result.M43 = 0f;
    result.M44 = 1f;
}

3.3.5. UML model

Figure 27. UML diagram of the proposed transformation classes in OpenDRIVE

3.3.6. Examples

Transformation of an object from one coordinate system to another.

Transformation uvz (local) ←→ xyz (inertial)

Assumption: The object to be referenced is modeled in a Figure 28. For example, a detailed building model with a local origin at the lower left corner of the building

Figure 28. External Object Reference Frame

The follow-up project will define the handling of offsets and insertion points.

Requirement: Positioning of the object in OpenDRIVE, according to the inertial coordinate system.

Solution: Transformation between the local coordinate system and the inertial coordinate system.

Figure 29. Transformation between a local object coordinate system and a inertial coordinate system

Transformation uvz (local) ←→ sth

Assumption: The object to be referenced is modeled in a local coordinate system, for example a traffic sign.

Requirement: Positioning of the object in OpenDRIVE according to the reference line coordinate system.

Solution: Transformation between the local coordinate system and the reference line coordinate system.

No translation is needed when the object is modeled at the origin of the local coordinate system and positioned in OpenDRIVE with the reference line coordinate system.

Figure 30. Transformation between a local object coordinate system and the reference line coordinate system

These methods are important for repeated objects, for examples signs, poles, …

A flag should be added that defineds the OpenDRIVE coordinate system that the transformation refers to. Each external reference should contain an information on the referenced coordinate system.

Example of a single house

<road:road id="100">
  <obj:objects>
    <obj:genericObject id="1" name="building" type="building" subtype="building">
      <obj:linearReference>
        <geom:sthPosition s="" t=""/>
      </obj:linearReference>
      <obj:explicit2DGeometry> <!-- optional -->
        <geom:Point/>
        <geom:Polygon/>
      </obj:explicit2DGeometry>
      <obj:explicit3DGeometry> <!-- optional -->
        <geom:MultiPolygon/>
      </obj:explicit3DGeometry>
      <obj:parametric3DGeometry> <!-- optional -->
        <geom:Cube/>
      </obj:parametric3DGeometry>
      <obj:implicit2DGeometry> <!-- optional -->
        <geom:implicitGeometry libraryObject="" mimeType="">
          <geom:transformation>
            <geom:translation x="" y="" z=""/>
            <geom:rotation>
              <geom:eulerAngles hdg="" pitch="" roll=""/>
              <geom:quaternion x="" y="" z="" w=""/> <!-- alternative -->
            </geom:rotation>
            <geom:scale x="" y="" z=""/>
          </geom:transformation>
      </obj:implicit2DGeometry>
      <obj:implicit3DGeometry> <!-- optional -->
        <geom:implicitGeometry libraryObject="lowfidelity_house.flt" mimeType=""/>
      </obj:implicit3DGeometry>
      <obj:implicit3DGeometry> <!-- optional -->
        <geom:implicitGeometry libraryObject="midfidelity_house.flt" mimeType=""/>
      </obj:implicit3DGeometry>
      <obj:implicit3DGeometry> <!-- optional -->
        <geom:implicitGeometry libraryObject="highfidelity_house.flt" mimeType=""/>
      </obj:implicit3DGeometry>
    </obj:genericObject>
  </obj:objects>
</road:road>

Each geometry can have its own transformation.

Example of a repeated object

<road:road id="100">
  <obj:objects>
    <obj:genericObject id="1" name="" type="post" subtype="streetLamp" orientation="">
      <obj:linearReference>
        <geom:sthPosition s="" t=""/>
      </obj:linearReference>
      <obj:repeat>
        <obj:sthRepeat length="" distance="">
          <obj:start length="" width="" height="">
            <geom:sthPosition s="" t=""/>
          </obj:start>
          <obj:end length="" width="" height="">
            <geom:sthPosition s="" t=""/>
          </obj:end>
        </obj:sthRepeat>
      </obj:repeat>
      <obj:explicit2DGeometry> <!-- optional -->
        <geom:Point/>
        <geom:Polygon/>
      </obj:explicit2DGeometry>
      <obj:explicit3DGeometry> <!-- optional -->
        <geom:MultiPolygon/>
      </obj:explicit3DGeometry>
      <obj:parametric3DGeometry> <!-- optional -->
        <geom:Cube/>
      </obj:parametric3DGeometry>
      <obj:implicit2DGeometry> <!-- optional -->
        <geom:implicitGeometry transformation="" libraryObject="" mimeType=""/>
      </obj:implicit2DGeometry>
      <obj:implicit3DGeometry> <!-- optional -->
        <geom:implicitGeometry transformation="" libraryObject="lowfidelity_house.flt" mimeType=""/>
      </obj:implicit3DGeometry>
      <obj:implicit3DGeometry> <!-- optional -->
        <geom:implicitGeometry transformation="" libraryObject="midfidelity_house.flt" mimeType=""/>
      </obj:implicit3DGeometry>
      <obj:implicit3DGeometry> <!-- optional -->
        <geom:implicitGeometry transformation="" libraryObject="highfidelity_house.flt" mimeType=""/>
      </obj:implicit3DGeometry>
    </obj:genericObject>
  </obj:objects>
</road:road>

The transformation applies to all objects defined by a repeated object.

Example of OpenDRIVE 1.6

<object type="" name="" id="" s="" t="" zOffset="" validLength="" orientation=" " length="" width="" height="" hdg="" pitch="" roll="">
</object>

3.4. Notes / Comments / Links

Open points

Topologic interface between ODR and external data defining entrance?
Different attachment modes (compare ODR ←→ OpenCRG)

4. Interface to other (GIS) standards

Table 13. Status of the concept
Target Version:	Effects Backward Compatibility:	Complexity for Implementation:	Acceptance Status:
1.7	N	low (concept→Standard)	accepted

4.1. Short summary and motivation of the proposal

OpenDRIVE does not include a detailed environment model. It focuses on the detailed description of the logical road network, not the road environment.

However, some use cases require a detailed description of both the road and the environment. In order to cover those use cases, the concept proposes to link OpenDRIVE to standards with an environment model like CityGML (see Figure 31 and Figure 32). The goal is to implement simpler references to spatial reference systems in OpenDRIVE.

There are the following advantages:

Improved alignment with other standards, for example, CityGML.
Datasets in the same geodetic datum may be linked directly, without transformation.

There are the following disadvantages:

The group agrees that there is nothing to note here as the proposed concept is fully optional.

4.2. Use cases

This concept would simplify the simulation of real-world data and sceneries in OpenDRIVE. This is achieved by adding information on buildings, terrain, city furniture, and vegetation to the simulation domain. In the GIS domain, there are standards for storage and exchange of environmental information, for example CityGML.

The following stakeholder will benefit:

Creators of simulation environments based on real-world data.

4.3. Details of the proposal

4.3.1. How is it solved in OpenDRIVE 1.6?

OpenDRIVE 1.6 contains an element for georeferences (<geoReference>). It works only with proj4 strings.

4.3.2. General description

The concept proposes deprecating proj4 strings and using EPSG codes to refer to spatial reference systems instead. proj4 describes all parameters that define a particular spatial reference system including ellipsoid, datum, projection units, and projection definition. EPSG codes consists of 4 or 5 digits only and represent a key in a known database. In this way, EPSG codes can be used to refer to a large variety of spatial reference systems.

To achieve backwards compatibility, the concept proposes allowing both proj4 and EPSG for the next version of OpenDRIVE and deprecate proj4 afterwards.

4.3.3. Examples

In OpenDRIVE 1.6, the extent is specified in the header element and the coordinate system in the element geoReference.

The following example shows how to specify the coordinate system and extent of an OpenDRIVE file with EPSG codes in one element.

<geom:BoundingBox srsName="urn:ogc:def:crs,crs:EPSG:6.12:32632,crs:EPSG:6.12:5783">
  <geom:Point>691642.42 5334989.726 518.547</geom:Point>
  <geom:Point>691979.173 5335172.823 559.547</geom:Point>
</geom:BoundingBox>

4.3.4. Images

Figure 31. Linking OpenDRIVE and environment models

Figure 32. Linking OpenDRIVE and environment models using georeferences

The coordinate system and the perspective are not correct, the image serves only the purpose of illustrating the concept.

5. Object list

Table 14. Status of the concept
Target Version:	Effects Backward Compatibility:	Complexity for Implementation:	Acceptance Status:
1.x	N	high (concept→Standard)	accepted

5.1. Short summary and motivation of the proposal

The object definition in OpenDRIVE 1.6 is not sufficient, because object types in the current version of the standard are ambiguous. This concept proposes using a standardized object catalog. It also suggests an extension mechanism to define object entries that are compliant with the standard.

There are the following advantages:

OpenDRIVE object packages are restructured to achieve a clear and unambiguous object definition.
The object list is checkable and extendable.

There are the following disadvantages:

The fact that users can define extensions in namespaces of their choice offers maximum flexibility but restricts direct software support. Software support might even be not possible at all.

5.2. Use cases

Specifying objects that match the standardized object labels.
Increasing relevance of object data in OpenDRIVE for simulation and visualization.

5.3. Details of the proposal

This concept does not aim to provide a complete object list. It aims to provide a basic concept that can be extended later. The following standards could be considered as references when creating a new object list in OpenDRIVE:

5.3.1. How is it done in OpenDRIVE 1.6?

Currently, objects are defined by type and subtype. A subtype, such as a street lamp, depends on its type, in this case a pole. This dependency requires a condition check to prevent wrong definitions, for example, type=vegetation or subtype=streetlamp.

It is possible to include condition checks within XSD (xs:alternative or xs:assert). However, not all tools support these checks and they cannot be derived automatically from UML. This was required for OpenDRIVE 1.6, because the OpenDRIVE XSD is generated from UML.

5.3.2. General description

There should be a common list of OpenDRIVE objects within the standard and the list should be used to check OpenDRIVE files. Currently, this is done using an enumeration. It should be possible to extend the default list by additional object types. This extended list should also be checkable.

New classes and enumerations

The concept proposes the following new classes and enumerations:

Types: introduce new semantic classes that represent groups of objects.
Subtypes: define enumeration lists for a detailed categorization. For each semantic class, one list should be defined.

Conclusion:

The use of subtype should be deprecated and be replaced by type, as is currently the case for the classes Bridge or Tunnel.
The enumerated attribute type takes the enumerations BridgeType, TunnelType, AuxilliaryMarkingsType, PoleType, etc.

The UML model illustrates this.

These object classes are suggestions. Further classes with corresponding enumerated types can be added within the hierarchy.

Extension mechanism

Because custom applications may require new object types, this concept cannot provide a complete list. This concept suggests the following extension mechanism:

Namespaces with corresponding XSD sources can be specified in an XML instance document, see the concept on modeling paradigms.
Additional object types may be defined in separate XSD documents. They may be added to an OpenDRIVE file with a new namespace. The XML example of an OpenDRIVE file with an extension illustrates this.
The OpenDRIVE file may be extended with object types, similar to the approaches in the following standards:

Discussion of the extension mechanism

The extension approach offers the following advantages:

A clearly defined syntax for the extension.
A possibility to check with XSD.

A disadvantage is that tools may not support the extension out of the box.

The work package currently has no suggestion for an alternative.

Suggested objects

The concept proposes the following objects, which are categorized by geometry types.

This categorization does not prohibit multiple geometry representation, vegetation, for example, can have a point, line or area geometry.

Object class: new class grouping current (OpenDRIVE 1.6) object types
Type enumeration: class (group) specific enumerations (derived and extended from current enumeration ObjectType)
Attributes: class specific additional attributes. The additional attribute value, for example, describes the text in RoadMark

Table 15. Object list
	Object class	type enumeration	attributes
Points
	Pole	pole
		permanentDelineator
		streetLamp
		trafficSign
		trafficLight
		emergencyCallBox
	Vegetation	tree
		bush
	RoadSurfaceObject	manhole
	Obstacle	advertColumn
Repeat
	Barrier	guardRail
		jerseyBarrier
		soundBarrier
		tunnelWall
		fence
		railing
Lines
	Portal	portal
		bridge
		tunnel
	Gantry	gantry
	SecurityGate	securityGate
	Vegetation	treeStrip
		hedge
Areas
	RoadMark	arrowLeft
		arrowRight
		arrowLeftLeft
		arrowRightRight
		arrowLeftRight
		arrowStraight
		arrowStraightLeft
		arrowStraightRight
		arrowMergeLeft
		arrowMergeRight
		text	value = `bus`, `taxi`, etc.
		number	value = `20`, `30`, etc.
		symbol
		roadmark
		zebraStripe
		stopLine
	CrossWalk	crossWalk
		virtual
		zebra
	Building	building
		busStop
		tollBooth
		callBox
	Barrier	wall
		raisedMedian
		trafficIsland
	ParkingSpace		value = `all`, `car`, `women`, `handicapped`, `bus`, `truck`, `electric`, `residents`
	NoParkingSpace
	RoadSurfaceObject	patch
	Obstacle	hydrant
		bench
		controllerBox
		postBox
		stone
		art
		pillar
		foundation
		crashbox
		box
		telephoneBox
		column
		speedBump
		unknown
	Vegetation	forest
	Waterbody	river
		sea
Range
	Bridge	concrete
		steel
		brick
		wood
	Tunnel	standard
		underpass

5.3.3. Rules

Objects that are relevant for traffic shall be modeled as OpenDRIVE signals.
Objects that are not relevant for traffic shall be modeled as OpenDRIVE objects.

5.3.4. UML model

Figure 33. UML model of a proposed OpenDRIVE 2.0 object module

5.3.5. XML examples

XML example of an object schema file

<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" xmlns="example/object" targetNamespace="example/object">
    <xs:element name="Example" type="exampleType"/>
	<xs:simpleType name="e_objectType">
		<xs:restriction base="xs:string">
			<xs:enumeration value="pole"/>
			<xs:enumeration value="tree"/>
			<xs:enumeration value="vegetation"/>
			<xs:enumeration value="barrier"/>
			<xs:enumeration value="building"/>
			<xs:enumeration value="parkingSpace"/>
			<xs:enumeration value="patch"/>
			<xs:enumeration value="railing"/>
			<xs:enumeration value="trafficIsland"/>
			<xs:enumeration value="crosswalk"/>
			<xs:enumeration value="streetLamp"/>
			<xs:enumeration value="gantry"/>
			<xs:enumeration value="soundBarrier"/>
		</xs:restriction>
	</xs:simpleType>
	<xs:complexType name="exampleType">
      <xs:sequence>
        <xs:element name="objects" type="objectsType"/>
      </xs:sequence>
    </xs:complexType>
	<xs:complexType name="objectsType">
      <xs:sequence>
		<xs:element maxOccurs="unbounded" ref="objectSubGroup"/>
      </xs:sequence>
    </xs:complexType>
	<xs:element name="objectSubGroup" abstract="true"/>
    <xs:element name="object" type="objectType" substitutionGroup="objectSubGroup"/>
	<xs:complexType name="abstractObjectType">
      	<xs:attribute name="name" type="xs:string" use="required" />
    </xs:complexType>
	<xs:complexType name="objectType">
	  <xs:complexContent>
        <xs:extension base="abstractObjectType">
          <xs:attribute name="type" type="e_objectType" use="required" />
		  <xs:attribute name="id" type="xs:string" use="required" />
		  <xs:attribute name="s" type="xs:string" use="required" />
		  <xs:attribute name="t" type="xs:string" use="required" />
		  <xs:attribute name="zOffset" type="xs:string" use="required" />
		  <xs:attribute name="validLength" type="xs:string" use="required" />
		  <xs:attribute name="orientation" type="xs:string" use="required" />
		  <xs:attribute name="height" type="xs:string" use="required" />
		  <xs:attribute name="hdg" type="xs:string" use="required" />
        </xs:extension>
	  </xs:complexContent>
	</xs:complexType>
</xs:schema>

XML example of an extension schema file

<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:obj="example/object" elementFormDefault="qualified"
	attributeFormDefault="unqualified" xmlns="example/extension" targetNamespace="example/extension">
	<xs:import namespace="example/object" schemaLocation="object.xsd"/>
	<xs:element name="extObject" type="extObjectType" substitutionGroup="obj:objectSubGroup"/>
	<xs:simpleType name="extensionType">
      <xs:restriction base="xs:string">
		<xs:enumeration value="busStop"/>
		<xs:enumeration value="emergencyCallBox"/>
	  </xs:restriction>
	</xs:simpleType>
	<xs:complexType name="extObjectType">
	  <xs:complexContent>
        <xs:extension base="obj:abstractObjectType">
          <xs:attribute name="type" type="extensionType" use="required" />
        </xs:extension>
	  </xs:complexContent>
	</xs:complexType>
</xs:schema>

XML example of an OpenDRIVE file with an extension

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<Example xmlns="example/object"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xmlns:ext="example/extension"
 xsi:schemaLocation="example/object object.xsd example/extension extension.xsd">
  <objects>
    <object type="pole" name="" id="" s="" t="" zOffset="" validLength="" orientation="" height="" hdg="" />
    <!-- the following object entry would lead to a type error -->
	<!-- <object type="busStop" name="" id="" s="" t="" zOffset="" validLength="" orientation="" height="" hdg="" /> -->
    <ext:extObject type="busStop" name=""/>
  </objects>
</Example>

Concept Paper WP03 Geometry

1. Relative road geometries within single roads

Table 16. Status of the concept
Target Version:	Effects Backward Compatibility:	Complexity for Implementation: (concept→Standard)	Acceptance Status:
2.0	Y	low	accepted

1.1. Short summary and motivation of the proposal

When roads are created in OpenDRIVE, the geometry information in the header is calculated separately for each part of the road. This causes redundancies, for example in the case of transition between road geometries. The concept proposes storing the geometry information of a road in the header only.

There are the following advantages:

Files can be exchanged more easily.
There will be no gaps or leaps in the reference line.
Parameter variation for single roads will become easier.

There are the following disadvantages:

Old OpenDRIVE files, mostly those with unknown clothoid and paramPoly3 implementations, will no longer produce the same road.
There may still be gaps at the end of a road which might be bigger than in the current OpenDRIVE version.
Inaccuracies will sum up over longer distances and potentially lead to gaps when loops are closed.

1.2. Use cases for the concept

Faster exchange of large OpenDRIVE files.
More convenient parameter variation, for example variation of corner radii.

1.3. Details of the proposal

1.3.1. How is it done in OpenDRIVE 1.6?

In OpenDRIVE 1.6, every part of a road element, for example line or arc, has mandatory geometry information stored in separate geometry elements (see also the example below):

s: s-coordinate of start position
x: start position (x inertial)
y: start position (y inertial)
hdg: start orientation (inertial heading)
length: length of the element’s reference line

1.3.2. General description

The proposal is to remove redundant information by attaching road geometries relative to one another. This means that the start of geometry n is the end of geometry n-1. The geometry information shall be stored directly in the road element. The record shall have a start point and an angle. The geometries of the following road parts shall reference that geometry information and not store their own geometry information, as illustrated in the XML example.

There will be no need for saving the s-coordinate or the length of the first part of the road. The length is either given, for example in the line element, or can be calculated. The s-coordinates of the elements xStart, yStart, hdgStart are implicitly given by adding up the length of all previous elements.

If two roads with own road elements follow one another, the geometry information still needs to be calculated for each road.

End position and orientation for clothoids and paramPoly3 elements shall be kept to ensure that the real end position matches the intended end position. In this way, the application can find a solution for non-standard clothoids and paramPoly3 elements.

The overall end position and orientation of a road shall be added to the road header for accuracy checking purposes. The information is not intended to be used for an automatic correction of a potentially faulty OpenDRIVE file.

The end position and orientation of each road geometry may be kept as optional information. It is strongly recommended to use this information only for accuracy checking purposes, not for correction of errors.

Necessary additions for standardization project

If the concept is accepted, the following standard development project should add the following:

Reference implementation for clothoids, etc.
Reference implementation for paramPoly3: how to calculate the s-coordinate and curve length from the parameters
Consider a checker tool to identify remaining and find new gaps

1.3.3. Rules

The starting point of a following geometry element shall be the calculated end point of the previous geometry element.

1.3.4. XML examples

The following example from OpenDRIVE 1.6 shows a line element, followed by a 90° arc, followed by a line element.

Figure 34. Relative road geometry

<road rule="RHT" length="228.5398163" id="1" junction="-1" x="10.0" y="20.0">
        <planView>
            <geometry s="0.0" x="10.0" y="20.0" hdg="0.0" length="100.0">
                <line/>
            </geometry>
            <geometry s="100.0" x="110.0" y="20.0" hdg="0.0" length="78.5398163">
                <arc curvature="0.02" />
            </geometry>
            <geometry s="178.5398163" x="160.0" y="70.0" hdg="1.57079633" length="50.0">
                <line/>
            </geometry>
        </planView>
</road>

Proposed new XML structure

<road rule="RHT" length="228.5398163" id="1" junction="-1" xStart="10.0" yStart="20.0" hdgStart="0.0" xEnd="160.0" yEnd="120.0" hdgEnd="1.57079633">
        <planView>
            <geometry length="100.0">
                <line/>
            </geometry>
            <geometry length="78.5398163">
                <arc curvature="0.02"/>
            </geometry>
            <geometry length="50.0">
                <line/>
            </geometry>
        </planView>
</road>

The following new attributes shall be added to the road element, as illustrated in Figure 34.

Name	Type	Unit	Value	Description
xStart	double	m	]-∞;∞[	x-coordinate of the beginning of the road element
yStart	double	m	]-∞;∞[	y-coordinate of the beginning of the road element
hdgStart	double	rad	]-π; π]	heading angle of the beginning of the road element
xEnd	double	m	]-∞;∞[	x-coordinate of the end of the road element
yEnd	double	m	]-∞;∞[	y-coordinate of the end of the road element
hdgEnd	double	rad	]-π; π]	heading angle of the end of the road element

Name

Type

Unit

Value

Description

xStart

double

]-∞;∞[

x-coordinate of the beginning of the road element

yStart

double

]-∞;∞[

y-coordinate of the beginning of the road element

hdgStart

double

rad

]-π; π]

heading angle of the beginning of the road element

xEnd

double

]-∞;∞[

x-coordinate of the end of the road element

yEnd

double

]-∞;∞[

y-coordinate of the end of the road element

hdgEnd

double

rad

]-π; π]

heading angle of the end of the road element

1.4. Out of scope and limitations

The concept shall only be valid inside one road element.

2. Parametric cubic splines

Table 17. Status of the concept
Target Version:	Effects Backward Compatibility:	Complexity for Implementation: (concept→Standard)	Acceptance Status:
1.7	N	mid	accepted

2.1. Short summary and motivation of the proposal

The concept proposes adding a parametric cubic spline element to OpenDRIVE. The element is designed to simplify the integration of measurement data into OpenDRIVE. It aims to simplify the creation of roads that originate in the real world.

There are the following advantages:

Simplifies the editing of coordinates.
Eliminate bends or gaps in roads.
Prevents the misuse of the line element. This often happens to avoid the calculation of polynomial coefficients.

There are the following disadvantages:

OpenDRIVE gets more complex due to the additional geometry option.

2.2. Use cases

This concept deals with the complex implementation of real-world measurement data into OpenDRIVE. Transforming measurement data directly into the OpenDRIVE syntax would make it easier to create road networks. Those road networks would then also represent real-world scenarios.

The following stakeholders will benefit:

Map creators: It will be easier to create road networks in OpenDRIVE.
Test engineers in the automotive industry: Test tracks would become more realistic.
Unexperienced users of OpenDRIVE: Parametric cubic splines are easier to handle than parametric cubic curves or cubic polynomials that were used in previous versions. Using parametric cubic splines might discourage users from adopting workarounds for curves using line elements.

2.3. Details of the proposal

2.3.1. How is it solved in in OpenDRIVE 1.6?

In OpenDRIVE 1.5 and 1.6, road geometry is described by a mix of complex elements using parametric cubic curves (paramPoly3) and simpler elements like line, arc, and spiral. The simpler elements are not suitable for creating complex road networks. Parametric cubic curves are complex and hard to understand and not suitable for integrating measurement data into OpenDRIVE. This is because they use the local u/v coordinate system that requires eight points per coordinate. These points have to be transformed from measurement data into the OpenDRIVE syntax.

Attributes of the paramPoly3 element:

x, y, heading, s and length
Eight coefficients and range of a cubic curve for a local uv coordinate system

All three shown examples use the same points. The same reference line is defined using:

Only line elements

Figure 35. Line Elements

<planView>
    <geometry s="0.0" x="0.0" y="0.0" hdg="3.4877100358390700e-01" length="5.8523499553598128e+01">
                <line/>
            </geometry>
    <geometry s="5.85e+01" x="5.50e+01" y="2.0e+01" hdg="-4.52e-01" length="3.89e+01">
                <line/>
            </geometry>
    <geometry s="9.74e+01" x="9.0e+01" y="3.0" hdg="-5.22e-01" length="4.61e+01">
                <line/>
            </geometry>
    <geometry s="1.44e+02" x="1.30e+02" y="-2.0e+01" hdg="6.04e+00" length="4.12e+01">
                <line/>
            </geometry>
        </planView>

Only paramPoly3

Figure 36. Parametric Polynoms

<planView>
    <geometry s="0.0" x="0.0" y="0.0" hdg="3.49e-01" length="5.92e+01">
        <paramPoly3 pRange="arcLength"
                    aU="0.0"
                    bU="1.0"
                    cU="-2.31e-04"
                    dU="5.85e-07"
                    aV="0.0"
                    bV="0.0"
                    cV="6.99e-03"
                    dV="-1.18e-04"/>
            </geometry>
    <geometry s="5.92e+01" x="5.50e+01" y="2.0e+01" hdg="-5.17e-02" length="3.93e+01">
        <paramPoly3 pRange="arcLength"
                    aU="0.0"
                    bU="1.0"
                    cU="-3.34e-03"
                    dU="2.81e-05"
                    aV="0.0"
                    bV="0.0"
                    cV="-1.92e-02"
                    dV="2.39e-04"/>
            </geometry>
    <geometry s="9.85e+01" x="9.0e+01" y="3.0" hdg="-4.87e-01" length="4.62e+01">
        <paramPoly3 pRange="arcLength"
                    aU="0.0"
                    bU="1.0"
                    cU="-1.46e-04"
                    dU="2.32e-06"
                    aV="0.0"
                    bV="0.0"
                    cV="-4.51e-03"
                    dV="8.14e-05"/>
            </geometry>
    <geometry s="1.44e+02" x="1.30e+02" y="-2.0e+01" hdg="-3.83e-01" length="4.12e+01">
        <paramPoly3 pRange="arcLength"
                    aU="0.0"
                    bU="1.0"
                    cU="-3.87e-04"
                    dU="3.04e-06"
                    aV="0.0"
                    bV="0.0"
                    cV="6.70e-03"
                    dV="-8.13e-05"/>
    </geometry>
</planView>

For detailed information on how to use the line, arc, spiral, and paramPoly3 elements, see the OpenDRIVE 1.6 specification chapter 7.7.1.

2.3.2. General description

Parametric cubic splines

Parametric cubic splines will be a new feature in OpenDRIVE in addition to parametric cubic curves. Cubic polynomials (poly3) have already been deprecated in OpenDRIVE 1.6 and shall not be used anymore. A parametric cubic spline shall be represented in an inertial coordinate system only and not use a reference line coordinate system or local coordinate system.

Attributes

Parametric cubic splines shall only have attributes for the curve lengths between two points and the start and end heading. The cubic spline is defined by the length between two measurements points, without room for interpretation by the user or the application. All attributes can be derived directly from the measurement data.

Parameters for a parametric cubic spline:

Start and end heading
List of 𝑛 xy-points
List of 𝑛−1 curve lengths 𝑙

2.3.3. Calculations

$c_{i-1}(s=l_{i-1})=c_{i}(s=0)$
$c_{i-1}(s=l_{i-1})=c'_{i}(s=0)$
$c_{i-1}(s=l_{i-1})=c''_{i}(s=0)$
- c: coordinate
- c‘: first derivative at a coordinate
- c‘‘: second derivative at a coordinate
- l: length of the curve/spline [m]
- s: s-coordinate of the road [m]

The curve length must be given because there is no closed solution to calculate the curve length of a parametric cubic spline.

To calculate the s-coordinate in a standardized way, a reference implementation is necessary.

Creation of parametric cubic splines out of measurement data

There are two possible ways:

1. Absolute definition

s0 x0 y0

s1 x1 y1

s2 x2 y2

with s<X> as distance on the spline relative to the beginning of the spline (⇒ s0=0);

2. Relative definition

ds0 x0 y0

ds1 x1 y1

ds2 x2 y2

with ds<X> as distance to the previous point, also with ds0=0;

2.3.4. XML examples

<geometry x="0.0" y="0.0"  hdgStart="1.3962640" hdgEnd="0.0" length="187.140">
    <paramCubicSpline mode="absolute">
        <point ds="0.0"      x="0.0"     y="0.0"/>
        <point ds="60.186"   x="55.0"    y="20.0"/>
        <point ds="99.406"   x="90.0"    y="3.0"/>
        <point ds="145.619"  x="130.0"   y="-20.0"/>
        <point ds="187.140"  x="170.0"   y="-30.0"/>
    </paramCubicSpline>
</geometry>

<geometry s="0.0" x="0.0" y="0.0" hdgStart="1.3962640" hdgEnd="0.0" length="187.140">
    <paramCubicSpline mode="relative">
        <point ds="0.0"      x="0.0"     y="0.0"/>
        <point ds="60.186"   x="55.0"    y="20.0"/>
        <point ds="39.220"   x="90.0"    y="3.0"/>
        <point ds="46.213"   x="130.0"   y="-20.0"/>
        <point ds="41.521"  x="170.0"   y="-30.0"/>
    </paramCubicSpline>
</geometry>

Figure 37. Parametric cubic splines

3. Transition area for OpenCRG

Table 18. Status of the concept
Target Version:	Effects Backward Compatibility:	Complexity for Implementation: (concept→Standard)	Acceptance Status:
1.x	N	high	accepted

3.1. Short summary and motivation of the proposal

In OpenDRIVE 1.6, there is no option to ensure a smooth transition to an OpenCRG patch regardless of the OpenCRG data quality. OpenCRG data is directly added to the local OpenDRIVE elevation data (@mode = attached) or replaces any local elevation values from OpenDRIVE, such as elevation or superelevation (@mode = attached0 or @mode = genuine). To ensure a smooth simulation, OpenCRG data must be consistent with OpenDRIVE data.

This concept proposes the following solution: add optional transition areas for OpenCRG in both longitudinal and lateral direction. This will ensure existing OpenCRG data can be reused more easily in various OpenDRIVE road files while vehicle dynamics models run more robustly.

There are the following advantages:

The possibility of a smooth transition on OpenCRG patches in x- and y-direction, regardless of the data.
OpenCRG patches can be reused more easily.

3.2. Use cases

Using OpenCRG patches on multiple OpenDRIVE roads with elevation data that are shaped differently.
Using OpenCRG patches as a complete junction grid (see Improved description of the elevation profile of roads in junctions).

The following stakeholders will benefit:

Creators of OpenCRG data
Users with detailed vehicle dynamics simulation models

3.3. Details of the proposal

This concept proposes the possibility to smoothly ramp on and off an OpenCRG patch by using a sinusoidal function in longitudinal and lateral directions of the OpenCRG patch. At the start of a transition area, the original OpenDRIVE elevation values shall be in effect with a weight of 1 and the OpenCRG data shall have a weight of 0. And the end of a transition area, the OpenCRG data shall have a weight of 1 and the original OpenDRIVE elevation values shall have a weight of 0. The transition area may be inside or outside the CRG area. This is defined by a negative (outside) or positive (inside) length of the transition area. If the transition area is outside the CRG area, only the z-values at the border of the CRG area are considered for the sinusoidal interpolation.

Additional, optional attributes for CRG

The principle of the transition area is shown in the table, Figure 38 and in Figure 39.

Table 19. Additional and optional attributes
Name	Type	Unit	Value	Description
`u_TransStart`	double	m	]-infinity; +infinity[	Length of the transition area at the beginning of an OpenCRG patch in u-direction
`u_TransEnd`	double	m	]-infinity; +infinity[	Length of the transition area at the end of an OpenCRG patch in u-direction
`v_TransLeft`	double	m	]-infinity; +infinity[	Length of the transition area on the left side of an OpenCRG patch relative to the u-direction
`v_TransRight`	double	m	]-infinity; +infinity[	Length of the transition area on the right side of an OpenCRG patch relative to the u-direction

Figure 38. OpenCRG transition area outside the CRG

Figure 39. OpenCRG transition area inside the CRG

3.3.2. How is it done in OpenDRIVE 1.6?

OpenDRIVE 1.6 does not contain a conceptfor supporting a smooth transition onto an OpenCRG patch.

Currently, OpenCRG offers border-smoothing options to provide an ascend or descend of z-values that is linearly scaled along a defined range at the beginning and at the end of the road. When a car moves in lateral direction on an OpenCRG patch, it is possible that the z-values change significantly, which may result in unstable and unrealistic vehicle behavior. Because there are currently no plans to fill this gap in OpenCRG, a solution must be considered in OpenDRIVE.

OpenCRG patches are included into an OpenDRIVE file as an object. They are embedded into OpenDRIVE files using a local coordinate system.

3.3.3. Calculations

To enable a smooth transition from the OpenDRIVE file, the working group proposes a sinusoidal interpolation between elevation values from OpenDRIVE and OpenCRG:

z(u,v) = scale_u * scale_v * z_CRG(u,v)

with (Transition area inside the CRG patch - positive values)

scale_u = 0 at the outer edges of the transition areas (to the OpenDRIVE surface) in u-direction
scale_u = 1 at the inner edges of the transition areas (to the CRG surface) in u-direction

scale_v = 0 at the outer edges of the transition areas (to the OpenDRIVE surface) in v-direction
scale_v = 1 at the inner edges of the transition areas (to the CRG surface) in v-direction

and a sinusoidal interpolation between 0 and 1 within the transition areas.

with

Name Type Unit Value Description

Name	Type	Unit	Value	Description
`scale_u`	double	-	[0; 1]	Scale factor for longitudinal smoothing in a transition area
`scale_v`	double	-	[0; 1]	Scale factor for lateral smoothing in a transition area
`u`	double	m	[0;u_End]	The u-value that is used to query OpenCRG for a z-value
`v`	double	m	[0;v_End]	The v-value that is used to query OpenCRG for a z-value

scale_u

double

[0; 1]

Scale factor for longitudinal smoothing in a transition area

scale_v

double

[0; 1]

Scale factor for lateral smoothing in a transition area

u

double

[0;u_End]

The u-value that is used to query OpenCRG for a z-value

v

double

[0;v_End]

The v-value that is used to query OpenCRG for a z-value

3.3.4. Rules

OpenCRG patches shall not be placed at the same location. They may touch each other (both transition areas and CRG patches, then transition area must be 0 or positive).

The above rule has to be confirmed or adapted by the standard development project. Currently, the rules regarding several CRG files are not clearly defined.

The transition area shall not be placed on negative s-coordinates. If the CRG beginns at s=0, the transition area needs to be inside the CRG patch (positive).
The transition area shall not exceed the maximum s-definition.
The transition area should not extend the maximum width of the road.
Overlapping transition zones of neighboring OpenCRG are not allowed.

The rules are illustrated in Figure 40 and Figure 41.

Figure 40. Rules for OpenCRG transition area

Figure 41. Rules for OpenCRG transition area

3.3.5. XML examples

<surface>
<CRG file="fancyData.crg" sStart="0.0" sEnd="100.0" orientation=”same” mode="attached" tOffset=”0.0” u_TransStart="-1.0" u_TransEnd="2.0" v_Left="-0.7" v_Right="1.0">
</CRG>
</surface>

4. Improved shape definition by using two cubic functions

Table 20. Status of the concept
Target Version:	Effects Backward Compatibility:	Complexity for Implementation: (concept→Standard)	Acceptance Status:
1.7	N	mid	accepted

4.1. Short summary and motivation of the proposal

This proposal aims at simplifying the definition of lateral road profiles. The road profile is applied to the left and right of the reference line, using only one cubic function for each direction. In OpenDRIVE 1.6, a complicated combination of superelevation and lateral shapes, with potentially multiple shapes at a single s-coordinate, is necessary to calculate the lateral profile.

There are the following advantages:

Easier and faster calculation of road elevation.

There are the following disadvantages:

There is no backward compatibility because this is a new feature of OpenDRIVE.
The methods of the concept are not detailed enough for the realistic description of sophisticated roads, for example, complex motorways.

4.2. Use cases

It will cost less effort to describe the road elevation.

4.3. Details of the proposal

4.3.1. How is it done in OpenDRIVE 1.6?

At a given s-coordinate there are two ways to create a lateral profile:

Superelevation: Describes the cross slope of the road. It is defined as the roll angle of the road cross section around the reference line.
Lateral shape: Shapes describe the elevation of a road cross section at a given point on the reference line in a more detailed way. This means, there may be several shape definitions at one s-coordinate that have different t-values, thereby describing the curvy shape of the road.

For complicated use cases, superelevation may be combined with shape.

OpenDRIVE 1.5 additionally offers the element crossfall, but this feature has been deprecated in OpenDRIVE 1.6.

4.3.2. General description

The following shall be valid for one s-position:

Six coefficients, each is a function of s
Two lateral offsets

There is no z-offset at t=0 because a=0 is already given by the elevation profile, if tLaneoffset=0 for both.

The two cubic functions are illustrated in Figure 42.

4.3.3. Implications

level attribute is still allowed at the outer lanes of a road (one or more, all outer lanes must contain the level attribute if one inner lane contains the level attribute), in order to model pedestrian sidewalks without the need of a road shape element.

4.3.4. Rules

Rules that apply to the concept:

The use of the two cubic functions shall not be combined with another roadShape.
The use of the two cubic functions shall not be combined with superelevation.
The use of two cubic functions may be combined with elevation.

4.3.5. Calculations

Interpolation in s-direction between multiple shapes:

z: cubic (default)
t_offsets: cubic (default)
1 cubic function(s) to the left (t in positive direction):

\[h(s,t)=d_{1}(t-t_{laneoffset1})^3 + c_{1}(t-t_{laneoffset1})^2 +b_{1}(t-t_{laneoffset1}) + a_{1}; t > t_{laneoffset1}\]

1 cubic function(s) to the right (t in negative direction):

\[h(s,t)=d_{2}(t-t_{laneoffset2})^3 + c_{2}(t-t_{laneoffset2})^2 +b_{2}(t-t_{laneoffset2}) + a_{2}; t < t_{laneoffset2}\]

where

h(s,t)

The elevation at a given position

d1, c1, b1, a1

The coefficients of the cubic function on the left side of the reference line

d2, c2, b2, a2

The coefficients of the cubic function on the right side of the reference line

tLaneoffset1, tLlaneoffset2

The offset in lateral direction to shift the start of the cubic function around the reference line. Between both lane offsets, the additional elevation from the lateral profile must be interpolated linearly.

4.3.6. XML example

Proposed new structure:

<lateralProfile>
    <shape
        d_1="0.0005"
        c_1="0.005"
        b_1="0.05"
        a_1="1.0"
        t_laneoffset1="1.0"
        d_2="-0.0001"
        c_2= "0.0"
        b_2="0.05"
        a_2="1.0"
        t_laneoffset2="-1.0"
    />
</lateralProfile>

Figure 42. Shape description with two cubic functions.

Realistic example for a motorway:

<lateralProfile>
    <shape
        d_1="0.0"
        c_1="0.0"
        b_1="-0.1"
        a_1="0.5"
        t_laneoffset1="1.0"
        d_2="0.0"
        c_2= "0.0"
        b_2="-0.1"
        a_2="-0.5"
        t_laneoffset2="-1.0"
    />
</lateralProfile>

Figure 43. Shape description with two cubic functions for a motorway.

4.4. Out of scope and limitations

The projection of the road will not change when using this approach. This causes the lanes to widen when this concept is applied. This approach shall not be used in parallel to superelevation.

5. Concept postponed for later editing

5.1. Prohibit combination of shape and superelevation

Table 21. Status of the concept
Target Version:	Effects Backward Compatibility:	Complexity for Implementation: (concept→Standard)	Acceptance Status:
1.7	N	mid	postponed

5.1.1. Short summary and motivation of the proposal

In OpenDRIVE 1.6 there is the possibility of using shape and superelevation at the same time at the same x-y-/s-t-position. This can lead to multiple z-values when trying to calculate the z-values at a given x and y, because the s-t-coordinate system is rotated when using superelevation, and shape is defined perpendicularly to this axis system. The current OpenDRIVE Manager does not seem to provide reasonable results in these cases (it already provides wrong data when using only superelevation).

Simulations should be able to get an unambiguous z-value for a given x-y-position. Therefore, it needs to be discussed if shape and superelevation may be used at the same time or if this should be forbidden. If it stays allowed, it needs to be clearly defined how applications retrieve the correct z-values.

Because the investigations have only started towards the end of the concept project, this issue is postponed to the Standard Development Project.

6. Rejected concepts

6.1. One fixed reference point

Table 22. Status of the concept
Target Version:	Effects Backward Compatibility:	Complexity for Implementation:	Acceptance Status:
1.x or 2.0	Y/N	low/mid/high (concept→Standard)	not accepted

6.1.1. Which problem is the concept intended to solve?

This concept is supposed to be an addition to concept on (relative road geometries within single roads) with the purpose of removing redundant information from OpenDRIVE.

It proposes to remove information on successor and predecessor lanes in the process of lane linkage.

6.1.2. What is the idea of the concept?

The idea of the concept is to define exactly one fixed reference point for the entire road network, as shown in Figure 44. Road linkage and lane linkage shall be defined in relation to that point only, by specifying information about the start point, end point, and the header. In this way, gaps or bends between roads will be avoided.

The advantage of the proposed concept is that there are no gaps or bends between roads.

Figure 44. One fixed reference point

6.1.3. How is it done in ODR 1.6?

The predecessor and successor elements may be used for the linkage of lanes AND for the linkage of roads. They are both inside the link element.

Example of lanes:

<lane id="-2" type="driving">
    <link>
        <predecessor id="5"/>
        <successor id="2"/>
    </link>
</lane>

Example of roads:

<road length="2.6" id="69" junction="2">
        <link>
            <predecessor elementType="road" elementId="89" contactPoint="start" />
            <successor elementType="road" elementId="71" contactPoint="end" />
        </link>
</road>

6.1.4. Why has the concept been rejected?

When lanes or roads are linked over longer distances, inaccuracies might accumulate. They might lead to gaps in linked roads when loops are closed.
Different applications might create different IDs for lanes and roads. This inconsistency might complicate the interchangeability of OpenDRIVE data.

6.2. Enable automatic corrections in OpenDRIVE

Table 23. Status of the concept
Target Version:	Effects Backward Compatibility:	Complexity for Implementation:	Acceptance Status:
1.x or 2.0	Y/N	low/mid/high (concept→Standard)	not accepted

6.2.1. Which problem is the concept intended to solve?

Straight elements, that is line, arc, and spiral, that are linked may have deviating header information. OpenDRIVE allows to link straight elements but this may cause problems when users try to model curvy roads using only line elements.

6.2.2. What is the idea of the concept?

This concept proposes implementing a procedure for aligning headings and other geometry parameters when linking two geometry elements.

The suggested procedure is the following: When linking straight elements, the start points and end points of the elements have priority over the header information and the length of the elements. The header information and the length may be ignored. The end position and header information of a road must be included.

6.2.3. How is it done in OpenDRIVE 1.6?

There is no feature for automatic corrections in OpenDRIVE 1.6.

6.2.4. Why has the concept been rejected?

It is not a robust procedure to adjust linked lines, arcs, and spirals with corrected lines, arcs, and spirals. If the information in the header are to be corrected, the delivered points would be corrected using parametric cubic curves (paramPoly3). But even this option does not work sufficiently.

The working group has therefore decided to decline the concept of automatic corrections. Instead, the concept for a new road geometry option of parametric cubic splines will be pursued. This concept will make it easier to build roads out of point lists, making the currently incorrectly used method of linking line elements with different headings obsolete.

6.3. B-spline

Table 24. Status of the concept
Target Version:	Effects Backward Compatibility:	Complexity for Implementation:	Acceptance Status:
1.x or 2.0	Y/N	low/mid/high (concept→Standard)	not accepted

6.3.1. Which problem intends the concept to solve?

Some companies provide navigation map data in B-spline format. This concept evaluates the usefulness and feasibility of using B-spline functions within OpenDRIVE.

6.3.2. What is the idea of the concept?

In OpenDRIVE 1.6, map data must be converted by using parametric cubic curve elements. Setting parameters for parametric cubic curves can be very difficult, especially for less experienced OpenDRIVE users.

6.3.3. How is it done in ODR 1.6?

In OpenDRIVE 1.6, map data must be converted by using parametric cubic curve elements.

6.3.4. Why has the concept been rejected?

Because measuring points cannot be used directly but need to be enhanced with more data, B-spline functions would cause a high load on the performance of simulation applications processing OpenDRIVE files. Importing existing maps would be facilitated, but the runtime load on the OpenDRIVE simulation would be too high. The work package group therefore decided to proceed with the concept on parametric cubic splines, which leads to a higher effort during map data import but causes very little impact on performance during a simulation.

Furthermore, the focus of OpenDRIVE should remain on simulation data, not real-world map data.

6.4. Constant projection in x-y-plane after application of superelevation

Table 25. Status of the concept
Target Version:	Effects Backward Compatibility:	Complexity for Implementation:	Acceptance Status:
1.x or 2.0	N	low/mid/high (concept→Standard)	not accepted

6.4.1. Which problem intends the concept to solve?

In OpenDRIVE, geometry is defined on the x-y-plane. For example, a straight line is defined with its length in the x-y-plane, which does not consider changes in elevation. The projection of its geometry is constant. The width of roads and lanes deviates from this rule. For roads and lanes, the projection in the x-y-plane changes after superelevation has been applied.

6.4.2. What is the idea of the concept?

The idea is to harmonize the geometry definition of all elements in the x-y-plane to create a constant projection. As a result, the application of superelevation does not change the actual lane or road width.

This principle has been introduced in version 1.6 of OpenDRIVE and should be applied consistently.

6.4.3. Rules

The width that is stated for a road or lane is identical to the projection of that road or lane in the x-y-plane.
When applying superelevation, the elevation of a road or lane is increased but the projection in the x-y-plane remains the same.

6.4.4. How is it done in OpenDRIVE 1.6?

The projection in the x-y-plane changes after superelevation is applied, that is, the projected road width narrows along its length.

6.4.5. Why has the concept been rejected?

This issue is considered a tooling issue. Tool suppliers need to automatically display a different road width when a road or lane width is entered in combination with superelevation.

6.5. Lane shapes

Table 26. Status of the concept
Target Version:	Effects Backward Compatibility:	Complexity for Implementation:	Acceptance Status:
1.x or 2.0	N	low/mid/high (concept→Standard)	not accepted

6.5.1. What is the idea of the concept?

The idea is to use one or more cubic functions per lane n relative to lane n-1. This would increase the possibilities for creating shape definitions for individual lanes. The concept shall not be used in combination with the concept on improved shape definition by using two cubic functions.

Figure 45. Image derived from drawing from Member Meeting in Frankfurt Jan 2020

6.5.2. Why has the concept been rejected?

The concept was not accepted as it would be very expensive for simulators to calculate and would not provide significant advantages.

Concept paper WP04: International traffic signs model

1. International traffic signs model

Table 27. Status of the concept
Target Version:	Effects Backward Compatibility:	Complexity for Implementation:	Acceptance Status:
2.0	Y	mid (concept→Standard)	accepted

1.1. Short summary of the proposal and motivation

The international signs model aims to introduce a system that provides parameters and images for the signs. It will also make it possible to define traffic signs in major jurisdictions such as North America, Europe, and Japan. The signs and traffic lights in this concept are used according to the test stages mentioned in the use cases.

1.2. Use cases

OpenDRIVE 1.6 allows the modeling of international signs as legacy information. When modeling an international sign, the year in which the corresponding legislation has come into effect is stated in the OpenDRIVE file. Figure 46 shows users in multiple countries modeling a sign or signal in one OpenDRIVE file.

Figure 46. Use case of the international signs model

We suggest three levels of use cases for this concept:

Level 1: Semantics of international signs are not included
Level 2: Semantics of international signs are included
Level 3: OpenDRIVE is embedded in the Electronic Control Unit (ECU). See Semantics of signals for more information.

The following three figures illustrate the different levels:

Figure 47. Level 1, semantics of the international signs are not included

Figure 48. Level 2, semantics of the international signs are included

$img4$

Figure 49. Level 3, OpenDRIVE is embedded in the ECU

Use case number

Simulation platform

System architecture

Testing stage

Use case level

Sensing

Recognizing

Judgement actuation

HIL

Real sensor

Logic in ECU

Functional test

Level 1

HIL

Real sensor

Logic in ECU

Recognition test

Level 1

MIL/SIL

Logic in ECU

Logic

Functional test

Level 1

MIL/SIL

Logic in ECU

Logic

Functional test

Level 2 with driver model (ego car/ multi-agent)

xIL

Real sensor

Logic in ECU

Certification

Level 1 and 2

The use case numbers are also referenced by the statement of the Japanese OEM members regarding the use case for international road signs of this work package (2nd edition).

The above use cases are also referenced in Semantics of signals.

1.3. Details of the proposal

Although traffic signs and signals vary from country to country, many have common implications. The ISO 14823 standard classifies signs and signals of each country by type and promotes their standardization. The classification of signs that is defined in the Graphic Data Dictionary in ISO 14823 is applied to the international signs model.

1.3.1. General description

ISO 14823 does not cover all traffic signs and signals that are described in this chapter. It does not include all countries and does not consider individual regulations of each country, which are updated regularly. This concept suggests creating an area for all traffic signs and signals that are not defined by ISO 14823. This area is then extended to also include the classification that is defined in ISO 14823.

The international signs model uses the following key values to identify signs:

Country (for example, JPN)
Revision of signal set by year (for example, 2003)
Type: the 1st category code of the signal
SubType: the 2nd category code of the signal

The international signs model includes the following road signage, as shown in Figure 50:

Variable road signs
Traffic lights
Road information signs. It is suggested that all variations of a road information sign are mapped to one modeled sign.
Markings on a road surface
Road signs

Figure 50. Examples of road signage according to the international signs model

In Japan, traffic signs are classified as follows:

|-- legal sign-------
|			|--Information sign
|			|--Warning sign
|			|--Regulatory sign
|			|--Indication sign
|--Auxiliary sign　
|--Non-legal sign

Sign on road surface
|--Regulatory sign
|--Indication sign

Lane marking

Non-legal marking

1.4. Separation of logical and physical data

When describing traffic signs and signals in OpenDRIVE, data needs to be divided into logical and physical data, thus increasing maintainability and reusability:

Logical data define positions, postures, classifications, and simple rectangular information in traffic signs and signals.
Physical data define pictograms and three-dimensional information, that is, detailed shapes of signs and signals. Material definitions can also be added to physical data. Physical data serve as the ground truth for simulation and visualization. They should be used when assigning shape and appearance to signs. Physical data require a reference to a dedicated model for each sensor, for example, a camera or LiDAR sensor in a simulation of the sensing system.

The sign’s position and orientation is specified by logical data. The shape of a sign is defined with physical data.

1.5. Catalog database

As an optional feature, OpenDRIVE files can reference catalog databases. A catalog database is a set of signal information. The international sign model identifies the information by specifying a catalog file, country code, year of revision, type, and subtype. OpenDRIVE files can be used without referencing a catalog database.

This international traffic signs model uses country identification codes and classification codes that are defined in ISO 14823 to model signs. The country identification code follows the specifications in ISO 3166-1. Specifically, the country identification code is alpha-2 in ISO 3166-1. The classification code includes a use classification code and a pictogram classification code. The classification codes that are used are broadly designated for traffic signs, public facilities, roads, and road surrounding environments. For signs that are not defined by ISO 14823, an extension area is provided in the classification code. The application decides on the extension area (see also Figure 52). A code that is unique to each country or tool can be defined in that area. In addition, the year or revision can also be defined to indicate that the traffic signs or signals are defined by laws and regulations at any time.

The table shows the attributes of a signal:

Table 28. Attributes of the signal element, extended by the international signs model
Name	Type	Value	Description
`catalogName`			Catalog database file name, for example, \catalog_data.xml. See Catalog database.
`STHPosition`			Track position. See WP Environmental Representation
`id`	string		Unique ID of the signal within the database
`name`	string		Name of the signal. May be chosen freely.
`dynamic`	t_yesNo	yes; no	Indicates whether the signal is dynamic or static. Example: traffic light
`country`	e_countryCode		Country code of the signal, see ISO 3166-1, alpha-2 codes
`countryRevision`	string		Revision of the country code
`type`	string	-1; none	When using the catalog database, indicate the `type` of the catalog database.
`subtype`	string	-1 / none	When using the catalog database, indicate the `subtype` of the catalog database.
`value`	double	Value of the signal, if value is given, unit is mandatory	Value of the signal, if value is given, unit is mandatory
`unit`	e_unit		Unit of @value
`text`	string		Additional text that is associated with the signal, for example, on city limit "Stadt\Bad Aibling"
`3dObject`			External 3D object reference. See WP Environmental Representation
`validity`			Lane validity record. See OpenDRIVE 1.6
`dependency`			Signal dependency record. See OpenDRIVE 1.6
`reference`			Reference record. See OpenDRIVE 1.6
`material`			Material record. See OpenDRIVE 1.6
`geometry`			Geometrical attributes record. See WP Environmental Representation

1.5.1. Rules

The appearance of a signal shall only be described by the identifier in the signs model, for example, type.
The attributes catalogName and 3dobject shall not be used to describe the appearance of a signal.
The appearance of an external 3D object signal shall be referenced by the attribute 3dobject.
Catalogs shall be referenced by catalogName and the corresponding identifier.
Both the catalog name and the identifier are recognized on their own.
Only one catalog database can be referenced in the OpenDRIVE file.

1.6. Referencing a catalog database

First, a catalog database that should be referenced by the OpenDRIVE file, is selected. Additional information and appearance are set for simulation purposes, for example, the sign and its graphic that are used for camera sensor simulation.

Figure 51 illustrates this process:

Figure 51. Use case of the catalog database

Figure 52 shows the possible architecture:

Figure 52. Catalog database architecture

The table shows the schema of a catalog database:

Table 29. Attributes and catalog database
Element	Level	Mult	Attribute	Description	Remarks
`catalogDatabase`	0	1	-	-	-
`catalog`	1	0+	-	-	-
`header`	2	1	`country`	Country code for the signal
`header`	2	1	`countryRevision`	Year of revision of the country code
`data`	2	0+	`type`	Type identifier
			`subtype`	Subtype identifier
			`nameText`	Name
			`dynamic`	Dynamic or static
			`value`	Value
			`valueLimitMax`	Dynamic upper limits
			`valueLimitMin`	Dynamic lower limits
			`unit`	Unit of the attribute value
			`semantics`	Data semantics	To be determined
			`degradationLevel`	Degradation level	To be determined
			`occlusion`	Occlusion rate	To be determined
`file`	3	0+	`type`	Pictogram or model (3DCGData)
			`path`	File path of pictogram or model (3DCGData) data that is relative to the catalog database
			`xOffset`	x-offset that corrects the OpenDRIVE signal/object local origin	Only for model (3DCGData)
			`offset`	Offset for correcting the OpenDRIVE signal/object local origin. Use the conversion concept from the work package on environment representation	Only for model (3DCGData)

1.6.1. Rules

The element catalogDatabase may define multiple catalogs.
Multiple indicators may be defined for a catalog.
Multiple models may be defined for one sign. The application specifies which model to display.
The model types assume a 2D (pictogram) model and a 3D (3DCG) model.
The 2D (pictogram) model assumes common image formats, for example, BMP, PNG, and JPEG etc.
The 3D (3DCG) model assumes a format that is determined by the work package on environment representation.

Figure 53. Relation of the catalog database to the attributes that it references

1.6.2. Examples

To reference the international signs model in the catalog database from the OpenDRIVE file, we suggest the following procedure:

Specify the catalog database file name in the catalogName attribute of the OpenDRIVE file.
From the specified catalog database, retrieve the corresponding database using country and countryRevision as keys.
Retrieve the sign model from the relevant database, using the keys type and subtype.

Figure 54 shows an example of the procedure with XML snippets:

Figure 54. XML example of referencing the sign model

The following XML example shows the description of a signal in OpenDRIVE:

<signals catalogName=".\CatalogDatabase.xml">
	<signal		s="5.0e+01"
			    t="5.0e+00"
		    	id="5000000"
			    name="stop"
			    dynamic="no"
			    orientation="+"
			    zOffset="1.8e+00"
			    country="JPN"
			    countryRevision="1990"
			    type="101"
			    subtype="1"
                value="-1"
                unit=""
                height="0.80e+00"
                width="0.80e+00"
                text="">
    </signal>
</signals>

The following XML example shows a catalog database file:

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<catalogDatabase>
    <catalog>
        <header country="JPN" countryRevision="1990"/>
        <data
            type="101"
            subtype="1"
	        nameText="stop"
            dynamic="no"
	        value=""
	        valueLimitMax=""
	        valueLimitMin=""
	        unit=""
			semantics="">
            <file	type="model"
		            path=".\models\sign_stop.flt"
		            xOffset="0.0"
		            yOffset="-0.1"
		            zOffset="2.2"
		            hOffset="0.0"
		            pOffset="0.0"
		            rOffset="0.0"/>
            <file	type="pictgram"
                	path=".\pictgrams\sign_Stop.png"/>
        </data>
    </catalog>
</catalogDatabase>

1.7. Semantics for the international signs model

Target Version:

Effect Backward compatibility:

Complexity for Implementation:

Acceptance Status:

2.0

high (concept→Standard)

accepted

1.7.1. Short summary of the proposal and motivation

Simulation for autonomous driving (AD) vehicles needs to include not only self-driving cars but also the surrounding traffic flow. To realize this, it is important to understand that traffic rules are displayed in different styles.

General description

Defining semantic data structures from AD test cases is not realistic, because it includes many different traffic situations and uncertainties. In order to deal with this task, this concept proposes a common semantics structure: a meta-language and a hierarchical data structure. The part of the hierachical data structure that is part of any local rule can be used as an original description part.

This concept does not target the case of defining meaning for multiple signs in OpenDRIVE. In this version, the concept intends that meaning is defined for each sign individually.

The semantics concept is based on the following ideas:

An analysis and logical description that is based on common information and knowledge.
Common/variable analysis of sign image and semantics.
Separation of common semantics from each country/region by the result of common/variable analysis.

The semantics concept extends the verification range of AD simulation.

There are the following advantages:

Multiple signs can be interpreted: Software vendors can build the interpretation logic based on each sign’s semantics.
It provides labeling information: In the case of machine learning, the semantic information of each traffic sign can be used as metadata for teachers.
Multi-agent simulation: It can be used for driving rules when expressing the behavior of other vehicles with a model.

There are the following disadvantages:

The semantics concept increases the map size.

Implementing semantics data

Provide a rule and information for the sign images of various countries and regions.
Relate features of the sign image and semantics information. And it could assign the sign image for each area by using common semantics, see Figure 55.
Relates to the catalog database
Relates to these further ASAM projects: OpenX Ontology, OpenSCENARIO2.0

Figure 55 illustrates a use case for the semantics concept:

Figure 55. Use case for the semantics concept

Ensuring edit maintainability

The semantics concepts enables editing region-specific semantics as variable elements, see Figure 56.

Figure 56. Editability and maintainability

Using semantics in AD simulation

Figure 57 and Figure 58 illustrate how traffic sign data can be structured. The examples are a Japanese and a German traffic sign:

Figure 57. Japanese traffic sign

Figure 58. German traffic sign

References

For creating the logical structure of a traffic sign, use the ontology model of traffic signs, see Figure 59 and source[3]
To learn more about Japanese traffic signs, refer to the Traffic Department textbook.

Figure 59. Traffic sign ontology model

Feature model structure

Extract features of a traffic sign and perform a common/variable analysis.
Correct necessary information to express the data structure of traffic sign.

Correct step1 : Extract rough features from road sign information
First, Figure.3 Japanese traffic sign and Figure.4 German traffic sign were used as reference information for traffic signs. Next, set two features from the aim of the concept. Finally, read out rough information.
Feature[1] Appearance of traffic signs Example of extracted features：Round traffic signs, Blue traffic sign, etc.
Feature[2] Meaning of traffic signs Example of extracted features：Traffic sign that means regulation, Traffic sign that means instruction, etc.
Correct step2 : Create the skeleton of the structural model from the extracted features
Figure.5 Traffic sign ontology model was used as reference information for the structural model. Create a simple structural model from the extracted features. With such a model, it is possible to get an overall feeling when structuring the features.
Correct step3 : Refine the features to be extracted
While balancing the amount of information and the granularity of information at the time of structuring, the information to be extracted from the traffic sign information for each feature is detailed.

Extract features of a traffic sign.

Figure 60 illustrates one feature, the sign image:

Figure 60. The feature of traffic sign

Figure 61 illustrates another feature, the semantics feature of alert and guidance:

Figure 61. The feature of semantics

Modeling the feature model

To express data structures about information in Japan and Germany, we use a feature model. This modeling method uses a tree diagram that illustrates and describes commonality and variability of a target, see 1990; Kang 1998 and Figure 62. The uper layer of the feature model needs to be represented by an abstract concept system. Typical viewpoints for capturing features are functional value, characteristics, and service.

Services: Benefits provided, solutions to problems, …
Functional value: Service related to function
Characteristics: quality attributes, cost, appearence, constraints, …

Figure 62. Overview of feature model

(Sign) https://code.asam.net/simulation/opendrive/-/blob/wp04_rework/concept_paper/WP04_IntlTrafficSign/Feature_model_example/sign.pdf
(Semantics) https://code.asam.net/simulation/opendrive/-/blob/wp04_rework/concept_paper/WP04_IntlTrafficSign/Feature_model_example/semantics.pdf

Figure 63 and Figure 64 show examples of feature model diagrams:

Figure 63. Feature model of a sign image

Figure 64. Feature model of semantics

Description method of the feature model

The feature model is described in detail in these files:

Interpreting a feature model

The upper level of the feature model diagram shows abstract features that are extracted from traffic signs:

Figure 65 illustrates the upper level of the sign image feature model:

Figure 65. Interpreting the upper level of the sign image feature model

Figure 66 illustrates the upper level of the sign image feature model.

Figure 66. Interpreting the upper level of the semantics feature model

The lower level of the feature model diagram shows specific features that are extracted from traffic signs

Figure 67 illustrates the lower level of the sign image feature model:

Figure 67. Interpreting the lower level of the sign image feature model

Figure 68 illustrates the lower level of the semantics feature model:

Figure 68. Interpreting the lower level of the semantics feature model

In some cases, parts of Japanese or Germany traffic signs cannot be expressed with the feature model. To express these traffic signs with the feature model, provide more detailed reference knowledge.

The “more detailed reference knowledge” mentioned here refers to the Traffic Department textbook introduced in the References chapter.The Traffic Department textbook is a textbook that explains Japanese road signs in great detail.
When trying to consider the lower layer of the feature model (the end of the features of the road sign), detailed features of the road sign may be required. At this time, the detailed characteristics may not be captured only by the information obtained from the list of road signs of the Ministry of Land, Infrastructure, Transport and Tourism. In such cases, using more detailed knowledge of road signs (eg, Traffic Department textbook) makes it easier to think about the lower layers of features.

Common and variable analysis of traffic signs with the feature model

The feature model can show the logic of common parts and of individual parts.
That means, it can separate common and local features of each country and of each region.

Case 1: Traffic sign "Maximum speed is 50 km/h" analysis example, see Figure 69

Figure 69. Common and variable analysis of the 'Maximum speed is 50km/h' sign

Case 2: Traffic sign "Right side with bend" analysis example, see Figure 70

Figure 70. Common and variable analysis of the 'Right bent' sign

Common and variable analysis of semantics with the feature model

Case 1: Traffic sign "No vehicle entry" analysis example, see Figure 71

Figure 71. Common and variable analysis of the 'No vehicle entry' semantics

Case 2: Traffic sign "Arrow and blue back ground color" analysis example, see Figure 72

Figure 72. Common and variable analysis of the 'Arrow and blue back ground color’ sign

Common and variable separation and structuring of the traffic sign feature

In order to define the semantics of various countries and regions with a common structure, it is necessary to ensure the maintainability of data structures.
If common and variable parts are configured properly, the data structure can be separated into a fixed global part for countries and regions and a variable local part.
This enables reducing the size of the data structure that is required by a country or region and, consequently,reducing the overall impact of editing a data structure.

Tendency of commonality and variability of the feature model

Figure 73 illustrates the tendency of commonality and variability of a sign image feature model:

Figure 73. Tendency of commonality and variability of the sign image feature model

Figure 74 illustrates the tendency of commonality and variability of a semantics feature model:

Figure 74. Tendency of commonality and variability of the semantics feature model

Figure 75 shows an expression example of the variable part of the semantics feature model:

Figure 75. Example of expressing the variable part of the semantics feature model

Base concept for structuring association

The mapping ontology model of traffic signs is intended to link all ontologies, see Figure 76 and source[4].
It is also used to express “Represent /represented by” relations. These relations are defined as expression constraints.
There are the following advantages:

There is a clear distinction between the image concept and the semantic concept, that is, the expression constraints include both types of content.
It is easier to generate with non-ontology sources, for example text files, etc.
Expression constraints can be passed on

[Concept_E_Fig221] illustrates an example of a mapping onotology:

Figure 76. The concept of mapping ontology for traffic signs

Structure association

A relational analysis confirms the relation of sign images and semantics.

Figure 77 and Figure 78 illustrate an example of a relational analysis of Japanese and German traffic signs

Figure 77. Example of a relational analysis of a Japanese traffic sign

Figure 78. Example of a relational analysis of a German traffic sign

Get the contents of a regulatory or instructional traffic sign and its target from the pictogram. If the target is related to traffic, it will get a traffic-related action. If the target is not traffic-related, it will get information of the target.

Figure 79 illustrates this retrieval process:

Figure 79. Example of the target retrieval of a pictogram

The resulting data structure is related to some features. Features are then mapped to structures that have a relationship.

Figure 80 and Figure 81 illustrate an example of mapping a Japanese and a German traffic sign to a regulatory and auxiliary target.

Figure 80. Linking sign and semantics of a Japanese traffic sign

Figure 81. Linking sign and semantics of a German traffic sign

Interpreting the mapping

Figure 82 and Figure 83 illustrate an example of how the mapping of a Japanese and a German traffic sign:

Figure 82. Interpreting the mapping of a Japanese traffic sign

Figure 83. Interpreting the mapping of a German traffic sign

Example image of the data structure

By linking sign and semantics of a traffic sign, it is possible to create a pictogram and a semantics table, see Figure 84.

Country and region information that is mapped to features can be exchanged easily, without changing the data structure, see Figure 85.

Figure 84. Use case image of linking sign image and semantics

Figure 85. Use case of exchanging mapping information

Feature association

Figure 86 and Figure 87 show examples for associating features:

Figure 86. Example of feature association

Figure 87. Task of associating of feature

Sources

[1] Japanese traffic sign
http://www.mlit.go.jp/road/sign/sign/douro/ichiran.pdf
Homepage : Ministry of Land, Infrastructure, Transport and Tourism (Japan’s national land development/maintenance, administrative agency responsible for operations such as transportation)

[2] German traffic sign
Homepage : Wikipedia
https://ja.wikipedia.org/wiki/%E3%83%A8%E3%83%BC%E3%83%AD%E3%83%83%E3%83%91%E3%81%AE%E9%81%93%E8%B7%AF%E6%A8%99%E8%AD%98

[3] Traffic sign ontology model
Formalization of the semantics of iconic languages: An ontology-based method and four semantic-powered Applications
P.7 Algorithm1 ，P.8 Fig.4 Icon ontology for traffic signs (in blue on the left) and the associated domain ontology (in red on the right).

[4] Traffic sign mapping ontology model
Formalization of the semantics of iconic languages: An ontology-based method and four semantic-powered Applications
P.4 Fig.2 General structure of the icon ontology (in blue on the left), the mapping ontology (in green in the middle) and the domain ontology (in red on the right).

Concept paper WP05: Area model

Table 30. Status of the concept
Target Version:	Effects Backward Compatibility:	Complexity for Implementation:	Acceptance Status:
2.0	Y	high (concept→Standard)	accepted

1. Introduction to the area model

1.1. Foreword

The OpenDRIVE concept project was launched in the context of the transfer of the OpenDRIVE 1.6 standard to ASAM. The purpose of the concept project is to address the features that will be included in the further development of OpenDRIVE. In this transition phase, several requirements and topics were defined and grouped in five work packages.

While the other four work packages try to solve issues by improving and enhancing the current OpenDRIVE 1.6, the area concept is a completely new approach that avoids all these issues via a new modelling methodology.

1.2. Introduction

1.2.1. Status, problems, and limits of the current OpenDRIVE

Simulations are essential for the development, testing and approval of driver assistance and automation systems. To enable interoperability of simulation databases different road description formats, such as OpenDRIVE, RoadXML and Road5, were developed. Among these formats, OpenDRIVE was able to reach worldwide adoption without being restricted to a specific application or company. Various stakeholders, especially OEMs, Tier-1 suppliers, universities and research institutes, are using OpenDRIVE.

OpenDRIVE was developed for the creation of simulation databases, based on the requirements of the participating companies. Therefore these databases contain artificial data and are built manually. OpenDRIVE uses axis-based road description with a reference line as the most important element. For the definition of road geometry, continuous mathematical functions are used. This approach enables efficient and space-saving descriptions of the course of a road. In following versions, OpenDRIVE was improved by metadata on geo-reference as well as in terms of data quality.

Nevertheless, disadvantages and issues arose, including the following:

Simulation settings and road settings became more and more complex.
More real-world data were introduced.
The databases were linked with various other databases for sensor simulation.

Furthermore, due to the complexity of OpenDRIVE, there are only a few applications that can read, visualize and write OpenDRIVE data. Nevertheless, the number of OpenDRIVE-capable tools is growing, but most of them still focus on artificial, and therefore limited, road environment settings.

Upcoming applications in the automotive domain aim at enabling realistic representations of real-world data on a larger scale. Regarding this, the following issues with the current OpenDRIVE emerge:

Modelling is based on reference lines with relative lane definitions. These are usually virtual constructs, based on clear rules. However, roads in complex urban scenarios are often not built according to these road construction guidelines.
Due to the modeling approach, auxiliary constructions are often necessary, which leads to even more complexity, ambiguities or gaps. It is therefore very difficult to update or patch parts of a complex road model.
The hierarchical XML specification can lead to multiple definitions of the same elements, such as road marks. The strict hierarchy leads to costly and time-consuming update procedures of subordinate elements in one OpenDRIVE file.
Real-world data cannot be transformed into OpenDRIVE syntax directly. This is due to OpenDRIVE being a virtual construct. This means, its modeling procedures are not common among other domains, such as road operators or public authorities.
Scalability and data exchange are very limited, due to a large XML structure that do not have abbreviations, such as namespaces. It is therefore necessary to facilitate huge databases of urban or long motorway settings.

A detailed lineup of differences between the proposed Area Concept and OpenDRIVE 1.x is provided in Section 1.3.1.

1.2.2. Motivation of the area concept

The area concept can solve the issues mentioned above by avoiding them from the beginning. To do this, the way of modeling a road network is changed in order to bridge the gap between current simulation use cases and the upcoming challenges of introducing more real-world settings into the simulation as well as data with a higher level of detail. The key motivations are:

Model roads as they are, without creating gaps.
Simplify the modeling of complex urban situations.
Make the usage of existing real-world data easier by integrating data of public authorities faster.
Use shared geometries to ensure the integrity of topological data and avoid unintended gaps.
Do not use artificial modeling constructs or helping constructions, such as reference lines, junction containers or hard-coded lane structures, in order to model real-world data.
Avoid using relative coordinate referencing at any time, that is referencing along imaginary reference lines. Instead use absolute coordinates wherever possible.
Simplify the linkage to other databases in order to easily provide supplementary information.
Store separate content in layers for flexible access and extension. Layers may be arbitrarily user-defined.
Improve the maintainability of a database by making it easier to update individual parts or elements.
Avoid large XML files and enable spatial indexes and queries by using geographic information system (GIS) technology to quickly access and process large databases.
Improve scalability, since the current OpenDRIVE is not scalable at all.

1.2.3. The area concept approach

The area concept facilitates stand-alone polygons for the description of the usable area, for example for transport modes or traffic participant types. All polygons belonging to one traffic mode are grouped into a layer. This results in having different independent layers for different traffic modes, which simplifies the modeling of complex urban scenarios. The elements can be combined in a variety of ways:

Polygons (areas) within the same layer are linked to each other implicitly using shared geometries which superimpose topology constraints. These topology constraints ensure data integrity and are easy to handle on a database level. The necessary tool support is already available in the GIS domain and partly standardized.
Explicit linking of elements within one layer or between layers can be achieved on a flat attribute level. Such an approach offers great flexibility and easy extensibility.
Additional "logical linking layers", for example using reference lines, lane center lines or movement paths, can be included into the layer tree at any time.

1.2.4. Example

Figure 88 shows a junction, which is a good example for a complex urban use case.

Figure 88. Complex urban junction: John F. Kennedy square in Brunswick (source: Google LLC, aerial image rotated -90°).

Figure 89 shows the model of a complex urban junction using the current version of OpenDRIVE. A lot of roads are necessary to construct the whole junction, each with its own reference line. Furthermore, the paths for bicycles or pedestrians are modelled solely for visual purposes. With the current design of OpenDRIVE, it is not possible to create overlapping or crossing lanes that are adequately linked to each other. Therefore, the model does not include any logical linkage. The linkage of the road-related lanes is quite complex, because link information is widely distributed in the strongly hierarchical object tree. This in turn results in large XML files.

Figure 89. Complex urban junction modeled with current OpenDRIVE (source: DLR).

Figure 90 shows the model of a complex urban junction using the area concept. Different layers for different transport modes or traffic participant types are used:

Blue: motorized
Yellow: pedestrian
Orange: bicycle
Green: trolley

All layers can be linked through GIS spatial relationship functions at any time in real-time.

Figure 90. Complex urban junction modelled with the area concept (source of aerial image: Google LLC).

1.3. New standard proposal

The current OpenDRIVE works well for automated test case generation with a limited scope. The Area Concept enables the extensive use of real-world representations, which is very restricted in OpenDRIVE. Test case creation of smaller settings is also possible with appropriate tool support due to the different modeling approach.

Therefore, the Area Concept can replace the current OpenDRIVE. Once the complexity of test cases increases and test cases incorporate more real-world data, the Area Concept will play out its advantages. Due to the completely different nature of road element modeling, at the current design state the Area Concept will most certainly not be directly compatible with the current OpenDRIVE implementation. This results in a new standard definition. Discussions in the WP05 working group lead to the common understanding that "there won’t be any compatibility to OpenDRIVE 1.x" and that "the tooling has to be re-invented". Still, a common interpretation of datasets is intended to enable the transfer of OpenDRIVE 1.x datasets to the Area Concept model without loss of information. This is achieved, for example, by re-using function reference implementations from OpenDRIVE 1.x and supplying a base converter to translate OpenDRIVE 1.x datasets into the Area Concept data model.

1.3.1. Implications and limitations

Table 31 summarizes some global pros and cons of the Area Concept.

Table 31. Summarized comparison between the Area Concept and OpenDRIVE 1.x.
Capability	Area Concept	OpenDRIVE 1.x
Modeling methodology	Geometric modeling through absolute positioning	Geometric modeling through relative positioning along reference lines
Modeling methodology	Geometric modeling through discrete coordinates	Geometric modeling through continuous functions → ambiguous interpretation on software side
Modeling integrity	Topological integrity implicitly provided due to usage of shared geometries	Responsibility for topological integrity lies in data providers and the interpretation of software tools → ambiguities
Modeling approach	Straight-forward modeling of "what there is"	Modeling is prone to ambiguities and uncertainties due to "imaginary helping constructs" (reference lines)
Modeling structure	Simple, flat layer structure	Deep, complex hierarchical data model with dependencies between different levels
Real-world modeling	Simple modeling of real-world data due to geometric modeling with absolute positioning	Super-complex modeling of real-world data due to geometric modeling with relative positioning
Synthetic modeling	Less simple modeling of synthetic data (adequate tool support required; converter from OpenDRIVE 1.x data could be supplied)	Simple modeling of synthetic data (just build small XML in editor)
Data modification	Easy data modification due to flat layer structure and absolute positioning with implicit topological integrity	Difficult data modification (adequate tool support required) due to complex hierarchical data model and relative positioning
Lane-level routing	Lane links are implicitly determinable during runtime from topological data model	Explicit modeling of lane links (makes data modification difficult)
Schema extension	Simple extendibility through custom layers; spatial and attribute-based linking easily possible on database level with standardized geodata	Difficult extendibility due to data model restrictions and complex hierarchical data model
Handling large data sets	Simple scalability due to simple, flat layer structure and absolute positioning (tool support available)	No scalability due to complex hierarchical data model and relative positioning (XML bloat)
Real-time processing	Spatially indexed data enables real-time processing; applicability in simulation domain still to be evaluated	Well-proven real-time capability in software-in-the-loop (SIL) and hardware-in-the-loop (HIL) simulations

These huge differences in terms of modeling imply the following :

In the domain of driving simulation, new software and tools for interpreting such data are needed.
In the GIS domain, software for modeling and modifying of such data is already present and well-established .
In the domain of automated driving, usage of such data will be much easier because sensor-related functions in cars predominantly work with extracted, simplified, discrete geometry data provided by flat data models instead of complex, continuous geometries and deep hierarchical, complex data models.

The latter argument further raises a question: Will the proposed Area Concept model be just an improved simulation format, or already a new standard for autonomous driving? Keeping this in mind, it is strongly recommended to synchronize intensely with other high-definition map providers in future as "we do not want to re-invent the wheel".

Taking into account these implications and focusing on the modeling approach of the Area Concept, a general trend emerges: The responsibility for a robust processing toolchain and "flawless simulation" is shifted from the data (provider) to the application because ambiguities on data level are extensively reduced.

A more detailed discussion of impacts on stakeholders etc. can be found in stakeholder requirements.

1.4. Description of the Area Concept

1.4.1. Main objectives

The Area Concept introduces a layered modelling of all required road network features making use of technologies and experience from the GIS domain. Adopted from GIS, most of these features are geometrically modelled through discrete coordinates (points) connected into polylines and polygons. Such geometrical polygons are further referred to as "areas". This hints at the fact that the proposed Area Concept focusses on the depiction of real-world road features which mostly correspond to areal features, such as road surface areas, sidewalks, bicycle ways, parking lanes, etc. All such features are projected onto a ground layer from which elevation information is derivable at runtime.

1.4.2. Coordinate system and spatial reference

All layers in the Area Concept which contain geometry information are geo-referenced. The geo-reference is unambiguously defined through a spatial coordinate reference system. In analogy to section 2.2 of the Road2Simulation Guidelines v1.2.1 all geometric measuring points contain two- (x, y) or three-dimensional (x, y, z) position information. For example, the coordinates can be indicated using a projected coordinate reference systems:

x in meters, as easting in the related projection,
y in meters, as northing in the related projection,
z in meters, as elevation above the underlying reference ellipsoid, or as elevation in a deviating elevation reference system.

The selection of the spatial coordinate reference system based on projected coordinates is guided by official data; for Central Germany, it is opted for ETRS89 / UTM Zone 32N (EPSG:25832). If the elevation is not indicated using the reference ellipsoid, the elevation reference system used shall be indicated too, for example, an elevation above sea level in DHHN2016 (EPSG:7837).

If the coordinates are indicated using a geographic reference system, the position information is composed as follows:

x in degrees as longitude,
y in degrees as latitude,
z in meters as elevation above the underlying reference ellipsoid.

The selection of the geographic coordinate reference system is guided by official data; for the European region, common choices are ETRS89 (EPSG:4258) or WGS84 (EPSG:4326).

It is generally recommended to reference the data in a projected coordinate reference system. Rotations are only indicated as geographically absolute values, i.e. a left-hand system is used (clockwise positive). This means, the angles are N = 0°, O = 90°, S = 180°, W = 270°.

1.4.3. Basic geometry definitions

In analogy to section 2.3 of the Road2Simulation Guidelines v1.2.1 spatial data is modelled on database level. Common spatial database implementations are PostGIS (PostgreSQL), Oracle Spatial and SpatiaLite (file-based SQLite). The database implementation imposes certain constraints on the data, such as foreign key relations and topologic data consistency, which are beneficial for overall data integrity.

An "area" in the Area Concept corresponds to a POLYGON in the terms of GIS spatial vector data. A polygon is described by its boundary LINESTRING which in turn consists of discrete POINT features. These points are the most basic geometry elements. For details refer to the essay on Vector Data Models.

Each POINT has a unique geographic coordinate position. Each point is unambiguously defined by its coordinates. It serves as a control point and is shared through all other aggregating geometric constructs (LINESTRING and POLYGON). This means that one specific point does only exist once throughout the whole database. This constraint is implicitly enforced by topological data modelling (see Vector Data Models).

Geometric data types are indicated in the defined reference system as simple features in well-known binary (WKB) or well-known text (WKT) format, in accordance with Open Geospatial Consortium (OGC): Simple Feature Access – Part 1: Common Architecture, Version 1.2.1.

Example for a point-shaped 2-D object as WKT:

Point (605044.419819 5791949.77898)

Example for a linear 3-D object with two control points as WKT:

LineString Z (
  05059.7409 5791956.6 128.12,
  605014.3896 5791935.49 128.22
)

Example for an areal 3-D object with four control points as WKT:

Polygon Z ((
  606556.8 5797302.2 129.7, 606563.5 5797301.6 129.7,
  606563.0 5797297.2 129.7, 606556.5 5797297.7 129.7,
  606556.8 5797302.2 129.7
))

Figure 91 depicts the basic concept of shared POINT geometries within the Area Concept by implementation of an adequate topology model. Most geometric elements store 2-D x/y coordinates. For areal elements the absolute elevation values (z) are derived from the underlying elevation/surface models in the ground layer (see Section 2.1) at runtime. Infrastructural elements are stored with 3-D coordinates defining their absolute height.

Figure 91. Concept of shared geometries of type POINT and how they are used throughout all other geometry layers.

1.4.4. Levels of detail within the Area Concept

Due to the nature of the Area Concept being based on OGC-standardized geometry models (see section Section 1.4.3) it will also benefit from already available geometry processing database functions (Simple Feature Access - Part 2: SQL Option or SQL/MM - Part 3: Spatial). The function set covers various methods which can be used for geometry simplification. This enables transforming complex geometrical structures into more primitive representations "on the fly". This can be used to implement the concept of different levels of detail (LOD). Examples:

Point density reduction of lines or polygons for visualization purposes through function ST_Simplify.
Abstracting a lane polygon into the lane’s center line through function ST_Skeletonize.
Reducing a two- or three-dimensional object to its centroid through function ST_Centroid.
Abstracting the compound structure of a traffic sign mounted to a pole to just a single point.
Grouping multiple objects through function ST_ConcaveHull or ST_ConvexHull.

1.4.5. Layer definitions and linking

In general, the proposed Area Concept distinguishes between mandatory and optional layers (Figure 92). An example for mandatory layers is the traffic area layer. The traffic area layer defines "where traffic happens". The underlying ground layer describes the traffic-relevant terrain surface. In order for robust elevation data retrieval to be possible in all situations, the ground layer shall spatially contain the traffic area layer as well as all other layers which define geometries, see Figure 93. All the other areas "on top of the traffic area layer" should always be covered by the traffic area with the same traffic category. One exception is the infrastructure layer. Infrastructure, such as poles and signs, can be located next to a traffic area. Still, the infrastructure layer shall be covered at least by the ground layer.

Figure 92. Proposed layer structure of the Area Concept for layers defining road geometry elements.

Figure 93. Concept of the traffic area layer (defining three areas) being contained by the ground layer.

Further, layers can be linked. Spatial links are realized by common geometries, such as points, which are shared between geometry layers. These shared geometries implicitly impose spatial relationships on these spatially linked layers. In addition, logical, semantic links are built up on matching data values between tables and can be provided through existing keys on database level — mostly called foreign key constraints. Such logical linkage between all layers can be mandatory, optional or optional with a requirement. These different layer linking options are shown in Figure 94.

Figure 94. Different linking options between mandatory and optional layers.

In the basic example where the traffic area layer is spatially contained by the ground layer the layer linkage between the traffic area layer and the ground layer is mandatory to ensure unambiguous elevation value querying. This mandatory link is a logical link on database level because 2-dimensional spatial overlay properties can be ambiguous in certain cases (bridges, multi-story parking garage). In the Area Concept, most of the other layers are implicitly linked spatially to the underlying traffic area layer. Thus additional logical links are optional (Figure 95).

Figure 95. Simplified linking structure between the major proposed layers with linkage types mandatory (solid), optional (dashed) and optional with a requirement (dashed grey).

An example for a layer linkage optional with a requirement can be the semantic linking of a traffic signal from the mandatory infrastructure layer to a lane via the regulatory layer. The lane layer itself is optional. Thus it must be defined beforehand for the link to be valid.

1.4.6. Out of scope of the concept paper

The detailed modelling description of the area geometries is outside of the scope of this concept paper.
Details on, for example, specific interpolation methods for elevation value estimation, are outside of the scope of this concept paper.
Modelling in regard of unusual driving behavior on traffic area layers, such as vehicles cutting over pedestrian walks or traffic participants driving off-road, is outside of the scope of this concept paper. Thoughts on this topic are addressed in the path layer section Section 2.5.1.

2. Layer description

2.1. Ground layer

Objects of the ground layer are named "ground datasets" and not "ground areas". This is because in our Area Concept the term "area" describes a geometric construct which is implemented by a POLYGON. GIS-based elevation data comes either as regular grids or regular/irregular networks which are both not representable by a plain POLYGON, rendering the term "area" inappropriate. The (derived) outline of such a ground dataset, though, can be represented by a POLYGON.

The ground layer ("floor") serves as the main elevation reference layer for all other traffic-related and geodata-related layers. The ground layer contains one or several ground datasets. Each ground dataset contains elevation information and is defined by a three-dimensional triangulated irregular network (TIN). This facilitates elevation data acquisition because elevation models are broadly available in different resolutions in the public and private sector and can easily be derived from other terrain data. For example, a simple, flat surface can always be represented by a well-compressed TIN of constant elevation. The implementation phase of the Area Concept will cover recommendations of functions and tools for TIN creation and processing.

Multiple or fragmented ground datasets can be merged into one consistent ground dataset with GIS tools.

Figure 96. A three-dimensional triangulated irregular network (TIN).

A ground dataset is geo-referenced and described by a well-defined spatial coordinate system for x, y and z coordinates (see section Coordinate system and spatial reference). Thus it contains absolute elevation values.

All other geometric layers described in this concept are projected onto these ground datasets.

This results in two cases:

Geometric layers do not define any elevation information for features that are meant to be mapped to the ground, such as traffic areas, lanes or road marks.
Geometric layers define elevation information relative to the respective ground dataset for features that are not meant to be mapped to the ground, such as signs or signals.

At runtime, an elevation value can be interpolated easily for any desired x/y location from the ground dataset.

Default interpolation methods (e.g. bilinear, cubic) for elevation values of a TIN are supplied as reference implementations. On the one hand, if an application is not able to deal with interpolation, discrete elevation values must be pre-assigned to the geometry data of "upper layers" (traffic areas etc.). This can be achieved by "burning" all geometry layers into the TIN. This will result in allocation of additional triangulation points in the TIN which can be shared amongst all geometric layers. Though, such additional point saturation of the TIN also requires interpolation of elevation values from neighboring control points in the pre-processing step. Otherwise, new elevation measures would have to be surveyed. On the other hand, such an additional TIN saturation with coordinate sharing makes later editing of overlaying geometry layers cumbersome. Whenever a shared geometry point is moved, its elevation has to be re-interpolated from neighboring points anyway.

The data format of the TIN is currently defined under the standard terms of the GIS domain. An unambiguous triangulation is enforced by the Delaunay Triangulation. For clarification, refer to external literature about Vector File Formats covering TIN. Thoughts on special cases such as on overhangs are covered in section Overhangs and vertical faces.

There can be more than one ground dataset. At least one ground dataset is mandatory because other layers need to be referenced to it ("placed on top of it"). Additional ground datasets can be necessary to define bridges (Figure 97), overpasses, tunnels or multi-story constructions.

The ground layer must at least cover all features from linked geometric layers. Features in linked geometric layers shall not exceed the ground layer.

For the regular use case of supplying data according to the Area Concept the data provider has to ensure that the ground layer with all its ground datasets is well-integrated. This means that no gaps exist where the individual ground datasets intersect. In the intersection zones, the triangle coordinates have to be shared (topological integrity). In order to facilitate integration of additional ground datasets later on, 3-dimensional ground intersection edges for these overlaying ground datasets (see Figure 97) can be specified in an optionally provided layer (refer to Referencing external databases).

In the case of multiple ground datasets, the data must ensure a neat integration of elevation values at the transition zones between these datasets to avoid elevation gaps.

Figure 97. Ground layer (green) with a second ground dataset for a bridge with optional ground intersection edges (blue).

If two ground datasets are defined on top of each other, their elevation values are not added together. Both ground datasets define absolute elevation values. Figure 98 shows how an elevation delta of 8.0 meters between ground datasets 1 and 2 would be defined.

Figure 98. Two ground datasets with absolute elevation values (z) positioned over each other.

One core advantage of triangulated irregular networks in contrast to regular grids is the variable resolution of elevation information. This allows a higher point density at areas of detailed road surface characteristics, such as bumpy surfaces, superelevation, potholes, etc., as well as road infrastructure elements, such as speed bumps, curb stones, traffic islands. If an Area Concept database is initially only supplied with coarse ground datasets, detailed surface description can be integrated later by introducing additional elevation measurement values into these TINs (spatial upsampling). Downsampling of TIN data in order to reduce information density is always possible through spatial functions.

$ground surface layer TIN zoom$

Figure 99. Example of a coarse ground dataset (left) overlaid with a more detailed ground dataset in red (right). A fusion of both has not been applied yet.

2.1.1. Overhangs and vertical faces

In general, modelling of vertical overhangs in GIS using standard elevation data is not possible because these data are usually interpreted as "2.5-dimensional". This means that for a given x/y coordinate just one elevation value is valid (as viewed from above). Triangulated networks consist of three-dimensional anchor points which are triangulated into faces forming a closed surface. In theory, a TIN could be used to implement vertical faces and overhangs which is mostly avoided because GIS software support by spatial functions is not guaranteed. Standardized functions which are commonly used across spatial database implementations (Oracle Spatial, PostGIS, SpatiaLite) are likely to be restricted to 2.5 dimensional data.

Keeping these restrictions in mind while trying not to over-complicate the current data representation we propose to move the modelling of overhangs and vertical faces to a separate layer of "miscellaneous features". Such a "constraint" layer could contain linkage between certain edges which form a vertical face. In general, the use case for representing vertical faces and overhangs intersects with the the domain of visualization. Additionally, handling of such features might be already covered in the CityGML 3.0 standard.

The following examples show two different use cases for overlaying ground datasets. If ground datasets are meant to model overhangs, the implementing triangulated networks must be defined unambiguously to avoid failures, meaning, that triangle faces may not self-intersect.

Figure 100. Two overlaying ground datasets, the upper forming a vertical edge.

Figure 101. Overhanging curbstone, with correct triangulation (white) and wrong (blue). This needs to be solved by an appropriate irregular network later in implementation.

2.2. Traffic area layer

Traffic areas define where road traffic takes place. There shall be one traffic area layer per road user category. These categories could be: motorized, pedestrian, bicycle, trolley, curbstone. Multiple traffic areas can exist at the same location, that is, they can overlap. This ensures simple modeling and flexible extendibility. From the perspective of applications, overlapping polygonal structures (areas) of different layers can easily be merged into one single layer by standardized GIS functions for further processing.

Inside a traffic area there can be sections that are purposely excluded from the traffic layer, see Figure 104. In these sections, no road traffic takes place. These areas may have the type traffic island. A section of the type traffic island defines constructional separations of or between other traffic areas.

Each traffic area is described by the coordinate sequence of its boundary, which describes a closed polygon. The sequence only contains two-dimensional xy-coordinates without elevation information. Elevation is derived from linked ground datasets (see section Ground layer). Each traffic area shall be linked to one ground dataset only. Curbstones can also be modelled as traffic areas of type curbstone. In the end, a two-dimensional traffic area polygon serves just as a mask of the underlying ground dataset which models the traffic surface.

In case of a transition between overlaying ground datasets (ramp) the traffic areas have to be split in order for each to link an individual ground layer.

Traffic areas are not explicitly linked to each other. For information about the linkage, traffic areas that belong to the same category and traffic areas of different categories must be distinguished:

If two traffic areas of the same category are modeled in a way that they are in contact with each other, both shall use shared points where the contact takes place. Such touching areas are implicitly linked to each other on spatial level through topological constraints (see Section 1.4.3). If they are not in contact, it shall be assumed that gaps between these traffic areas are explicitly intended.
If two traffic areas of different categories, for example motorized vehicle and bicycle, are modeled in a way that they appear to be in contact with each other, both may use shared geometries for the benefit of topological consistency, but they do not have to. This means, that traffic areas from different categories are not explicitly linked to each other. However, relations can be derived by applications using standardized spatial functions from the GIS domain, the so-called "overlay operations" or "spatial queries".

Details on linking for navigational or routing purposes are described in Routing layer. The following examples Figure 102 and Figure 103 with corresponding data excerpt in Table 32 show a set of traffic area objects of the geometry type POLYGON linked to different ground layers by a foreign key constraint. A more complex road layout is depicted in Figure 90.

Figure 102. Basic example of four traffic areas of category motorized.

Figure 103. Basic example of traffic areas of category pedestrian.

Table 32. Data table example of different traffic areas.
`TrafficArea`
`id`	`groundDataset`	`category`	`geometry`
`44`	`1`	`motorized`	`POLYGON`
`45`	`1`	`motorized`	`POLYGON`
`46`	`1`	`motorized`	`POLYGON`
`47`	`1`	`motorized`	`POLYGON`
`55`	`2`	`pedestrian`	`POLYGON`
`56`	`1`	`pedestrian`	`POLYGON`
`57`	`3`	`pedestrian`	`POLYGON`
`58`	`1`	`pedestrian`	`POLYGON`
`59`	`4`	`pedestrian`	`POLYGON`

Figure 104 shows an example on how to use traffic areas of type traffic island (orange). Shared boundary points (blue) should contain only x/y values. Elevation values are derived from the linked ground layer. Boundary points can be reused by adjacent traffic areas. In this case, no new points are defined. Depending on accuracy requirements, the format does not require to use the same coordinates, but it recommends to do so to avoid gaps. The underlying topological model can help to maintain data consistency.

Figure 104. Example on how to model traffic areas of type traffic island (source of aerial image: Google LLC).

2.3. Lane layer (optional)

The lane layer can be used to define lanes as "narrow movement corridors" for specific traffic categories. Therefore, a lane is linked to one corresponding traffic area of the same category. A lane shall always be fully contained by this linked traffic area.

Lanes can contain optional type information to add semantics to the traffic category of the referenced traffic area. Examples for possible type values are parking, emergency, exit.

The Area Concept generally stimulates derivation of such additional type semantics from the infrastructure and road mark layers on application side or post-processing.

Lanes are modeled using 2-dimensional polygons like traffic areas. This way, a lane polygon can be seen as a more detailed modeling level of a traffic area polygon. Because lanes depend on linked traffic areas, the modeled POLYGON geometry has to be well-integrated into the traffic area geometry on topology level. Common points and edges are shared among these geometries to avoid gaps, see Figure 105. This topological constraint also ensures determination of transition possibilities between adjacent lanes and traffic areas, see routing layer for additional information. An explicitly modeled gap means "that this lane actually ends here". This can be used to model isolated parking spaces. Elevation information for lanes is always derived from the linked traffic area, which in turn derives its elevation information from the ground layer.

Figure 105. Sharing of common geometries (points, edges) for lane (cyan) and traffic area (blue) layers to avoid gaps. Traffic islands (orange) and road marks (magenta) can be placed differently.

The example in Figure 106 shows lanes on top of traffic areas from Figure 102. The corresponding data excerpt in Table 33 shows the structure with the optional type attribute being NULL for all lanes because the linked traffic areas of type motorized imply that a lane covers the basic case of "driving/moving" inside such a traffic area.

Additional traffic rules and regulations are defined by the regulatory layer which is also used to cross-reference infrastructure elements to a lane. Driving directions should be determined on application level but can optionally be supplied via the path layer.

Figure 106. Basic example of lanes (cyan) on top of traffic areas (blue).

Table 33. Data table example of lanes linked to traffic areas of category `motorized`.
`Lane`
`id`	`trafficArea`	`type`	`geometry`
`61`	`47`	`NULL`	`POLYGON`
`62`	`45`	`NULL`	`POLYGON`
`63`	`44`	`NULL`	`POLYGON`

2.4. Routing layer (optional)

Routing information in terms of a graph is not explicitly provided in the data model of the Area Concept. Due to the superimposed topological constraints on all modelled spatial data, linkage between, for example, consecutive traffic areas or lane areas is implicitly available and queryable at any time via standardized spatial functions. With this base case, a path through the network of complex area geometries for navigational purposes can be obtained through different approaches.

One approach is to spatially join a dataset of the Area Concept with an external navigation layer consisting of a graph of nodes and weighted edges. Such supplementary data can be obtained from free sources, such as OpenStreetMap, and different commercial data providers, such as HERE or TomTom. For a designated path this spatial join will easily return an ordered list of traffic areas to traverse, for example. Further, for lane-level routing, the optional lane layer can be spatially joined with these traffic areas. Because the lane geometries are following topological modeling constraints (see Section 1.4.3) all predecessor, successor and neighbor relations are determinable in real-time during runtime. External sources would also contain information about one-way drivability restrictions along certain edges.

Another approach to derive a graph of explicit connections between traffic areas or lane areas, for example, is via post-processing using standardized spatial functions. The following data example in Figure 107 and Table 34 shows a link table for possible connections between adjacent traffic areas of the same traffic category. A geometry of type LINESTRING representing the shared connection edge can be helpful in spatial queries on application level. For this second approach an additional attribute one-way could be introduced into Table 34 in order to impose driving direction restrictions between area transitions with possible values of left-right or right-left.

Such a connection graph can always be derived from the underlying topological data model.

Figure 107. Connection edges (orange) as shared geometries between adjacent traffic areas.

Table 34. Data table example of traffic area connections
`TrafficAreaConnection`
`id`	`left`	`right`	`geometry`
`300`	`10`	`9`	`LINESTRING`
`301`	`11`	`10`	`LINESTRING`
`302`	`10`	`12`	`LINESTRING`

2.5. Path layer (optional)

The path layer can be used to define specific paths for traffic participants (e.g. car, truck, bus, bicycle). Figure 108 shows a complex road layout of an urban intersection where the lane layout with its road marks insufficiently describes the possible traffic/driving behavior: Following the centerline of the lane would not seem realistic. An additional path could help traversing such an intersection.

Figure 108. Example for a path (yellow) in a complex junction where lane (cyan) and road mark (magenta) layout insufficiently model the possible turn (source of aerial image: Google LLC).

In general, modeling of paths is only advised as supplementary helping construct for such isolated complex situations. The later application which is using the traffic area layer and optional lane layer is responsible to integrate such supplementary paths into the processing.

Though the path layer is not intended to be used as a graph for routing purposes — refer to Routing layer instead — it can, for example, be used to store a post-calculated path network derived from traffic areas or lanes of an Area Concept database on application level.

A path can be linked to lanes or traffic areas intersecting with the path. Each path is contained in exactly one traffic area. The path layer and the lane layer are independent. For example, there is no need to start a new path when a new lane starts (and vice versa). A one-to-many successor relation can be defined. Predecessor relations are not explicitly defined because they can always be derived from the successor relations through simple queries (the whole Area Concept builds up on database implementations with standardized SQL capabilities).

The geometry of a path is defined by a basic LINESTRING geometry in 2-D (see Section 1.4.3). The driving direction of a path is implicitly defined by the point sequence order of the LINESTRING.

2.5.1. Additional thoughts

Modeling in regard of unusual driving behavior on traffic area layers, such as vehicles cutting over pedestrian walks or traffic participants driving off-road, could be modeled through the path layer. However, there is a strong difference between modeling the static vehicle environment, which is the scope of the Area Concept, and modeling driving behavior, which is the scope of a scenario definition. Refer to OpenSCENARIO for additional path definitions.

2.6. Road mark layer

In the road mark layer all road marks are defined. They imply one part of the traffic rule set for all traffic participants. Following the core idea of the Area Concept, road mark elements in this layer are meant to represent "what is visually painted on the road". Thus, road mark attributes and relationships to other layers, which can be derived from visual and geometric properties, are considered optional where possible in order to stimulate "intelligent handling" on application side. Still, referencing of external databases enables simplified linking of supplementary information on database level if needed and the optional regulatory layer can be used to superimpose traffic rules between road marks and other elements (see Figure 95).

Road marks can be described as point information, linear information as well as polygonal information (e.g. restricted areas), see Figure 108 and Figure 109. The geometry type offers the possibility to implement different levels of detail of the road mark modeling. For example, a whole road pictogram could be abstracted to one POINT-shaped centroid while specifying the actual pictogram type through an object attribute (e.g. the texture name). This pictogram’s bounding box could also be modeled with a POLYGON geometry. Such a generic approach is suitable for simplified environment modeling. Alternatively, the whole painted shape of this pictogram could be directly modeled as a complex POLYGON which would allow to retain individual details of the painting. Linear LINESTRING features can be used to model generic longitudinal road marks as in OpenDRIVE 1.x.

Figure 109. Example for different levels of detail of road marks (magenta) differentiated through geometry types: point-shaped for complex pictograms, linear for simple longitudinal marks and polygonal for the actual painted area, e.g. zebra crossing.

Road mark types in the default data model are considered optional. This means that longitudinal road mark types, which are running alongside of lanes, such as solid or broken, are not differentiated explicitly because such information can be derived from the geometric representation (see above). Amongst such longitudinal road mark types, other optional types of non-longitudinal markings can be pedestrian crossing, stop line, waiting line, stopping restriction, zebra crossing, for example (see section 3.5 of the Road2Simulation Guidelines v1.2.1).

Multi-part road marks, such as individual marking stripes of a zebra crossing, can be represented by a grouping outline/concave hull as POLYGON in order to batch-assign traffic rules through the regulatory layer. This aggregation can be performed as pre-processing or via spatial database functions during runtime. Alternatively, spatial intersection with the traffic area layer can be useful because a zebra crossing most probably will be mapped to a traffic area of type pedestrian anyway.

The color of road markings is their main attribute because it carries a meaning about traffic rules. Different colors can have different material properties (e.g. dirt, chemical mixture, reflection) which are specified via the optional material layer.

Road marks are implicitly linked to other geometries by spatial relations, such as traffic areas or lanes. Standardized GIS overlay operations can be used to easily determine relationships on geometry level. Optionally, logical links to one or more traffic areas can be specified (see Figure 95). For example, the logical relationship of a road mark running along the edge between a motorized and a bicycle traffic area and these area geometries, either can be derived on spatial level or can be explicitly specified through an optional 1:n-mapping.

It is intended to align the modeling of road marks with the concept of WP02 Concept B: Geometry modeling in OpenDRIVE and the concepts of the OpenLABEL project.

2.7. Infrastructure layer

The infrastructure layer defines all traffic signs and signals. Furthermore, it defines road furniture, which are static, fixed objects, e.g., guard rails, noise barriers, poles, etc. Infrastructural elements can be point-shaped (e.g. trees, traffic light poles, etc.), linear-shaped (e.g. fence, hedge, guardrail, etc.) or polygonal in case of object outlines. POINT, LINESTRING and POLYGON geometries are defined in three dimensions, containing absolute height values.

From the perspective of a driving simulation application the height of an infrastructure element might seem to be better specified as a relative value above the ground. But as the Area Concept data model is geared to standardized GIS data models, the specification of z values is better supported as absolute values. Calculating back and forth is easily possible on application level at runtime.

Infrastructural elements are always fully contained within the ground layer and thus have to be linked unambiguously to one ground dataset of the ground layer in order to correctly derive a relative element height above the ground from its absolute height definition. Infrastructural elements do not necessarily have to be contained by a traffic area. An explicit logical linking to one or more traffic areas is optional, see Section 1.4.5. Multiple infrastructural elements can share the same location, e.g. a sign being attached to a pole.

Figure 110. Example for linear and point-shaped infrastructure elements (magenta): base points of poles as dots, mounting points of traffic signals with heading as X.

In general, infrastructural elements hold only attributes for the description of their main properties such as the signal and object type. Additionally, a geographic heading in degree can be specified for point-shaped objects.

All regulatory implications on the traffic are optionally modeled in the regulatory layer. With the help of this instrument infrastructural elements can be linked to road mark layer elements such as a traffic light to its corresponding stop line. An optional linkage between the infrastructure and lane layer through the regulatory layer defines, for example, the validity of a traffic light for a lane.

It is intended to align the modeling of the infrastructure with the concept of WP04 International Traffic Sign Model. A possible objects list can be derived from the OpenLABEL project as well as from section 3.6 of the Road2Simulation Guidelines v1.2.1.

Table 35. Data table example of different point-shaped infrastructure elements.
`PointInfrastructure`
`id`	`groundDataset`	`trafficArea`	`type`	`heading`	`geometry`
`10`	`1`	`45`	`traffic light`	`260`	`POINT`
`11`	`1`	`47`	`pole`	`NULL`	`POINT`
`12`	`1`	`NULL`	`hydrant`	`NULL`	`POINT`
`13`	`1`	`47`	`road sign StVO 267`	`177`	`POINT`

Table 36. Data table example of different linear infrastructure elements.
`LinearInfrastructure`
`id`	`groundDataset`	`trafficArea`	`type`	`geometry`
`76`	`1`	`46`	`fence`	`LINESTRING`
`77`	`1`	`45`	`guardrail`	`LINESTRING`

2.8. Regulatory layer (optional)

A separate regulatory layer is optional, as the Area Concept stimulates derivation of road infrastructure’s regulatory semantics from plain geometric and property-based modeling, by, for example, supplying just the heading and type of a traffic sign. It can be used for to model additional regulatory implications of signs, signals, traffic lights etc. which are required by certain driving and traffic simulation applications as well as by automated systems. This modeling is done on database level by cross-referencing between other unique elements in the data model, such as traffic areas, road marks, infrastructure and lanes, and aims at easy extensibility (see Figure 95).

The detailed content of this layer is not yet defined but the implementation of already representable semantics from OpenDRIVE 1.x will be the focus. Further, it is intended to align the modeling of regulatory elements with the infrastructure and the concept of WP04 International Traffic Sign Model. Some examples for the usage of the regulatory layer encompass:

Supplying additional semantics of signals and signs (infrastructure layer) which are not derivable from their unique type definition.
Though it is specifiable by distinct sign types, supplying of supplementary information of a speed limit sign for
- its validity beginning after 100 m or
- its validity being restricted to 100 m, for example.
Linking of a stop sign to a stop line (road mark layer).
Linking of a traffic light to a stop line.
Mapping the validity of a traffic light to a certain lane, e.g., straight or left/right turn (lane layer).
Modeling of dynamic signals/signs.
Country-specific, default speed limits.
Country-specific definition of a left-/right-hand driving direction.
Overriding of the standard driving direction according to time-of-the-day-depending regulations.
Additional usage definitions/restrictions of traffic areas or lanes such as
- prohibition of parking in cases where it is allowed by default (should be signaled by a sign though),
- restrictions to public transport (might be already defined in the traffic area or lane layer).

Figure 111 shows an example where a speed limit pictogram is modeled to be valid only in conjunction with the respective traffic sign. The primitive pictogram itself of the road mark layer (Table 37) does not define any traffic rule, but, by allocating it to the corresponding traffic signal of the infrastructure layer (Table 38) via foreign key relations in the regulatory layer (Table 39), the semantics of the traffic sign can be easily superimposed.

Figure 111. Example for a speed limit pictogram being only valid in conjunction with the respective traffic sign (according to German traffic regulations).

Table 37. Data table snippet of the polygonal pictogram shown in the image above.
`PolygonRoadMark`
`id`	`trafficArea`	`type`	`color`	`geometry`
`132336`	`45`	`pictogram 60`	`white`	`POLYGON`

Table 38. Data table snippet of the traffic sign shown in the image above.
`PointInfrastructure`
`id`	`groundDataset`	`trafficArea`	`type`	`heading`	`geometry`
`556`	`1`	`45`	`274-60`	`180`	`POINT Z`

Table 39. Data table snippet of a regulatory layer allocating the traffic sign in the image above to the pictogram.
`PointInfrastructure`
`id`	`pointInfrastructure`	`polygonRoadMark`
`1337`	`556`	`132336`

2.9. Material layer (optional)

The material layer is optional and does not contain geometry definitions itself. It serves as lookup table for commonly used material properties of geometric features from other layers, such as traffic areas, lanes, road marks. The instances of different materials of the material layer can be referenced from all other layers on database level through simple cross-referencing (foreign-key constraints). Material properties modeling in the Area Concept is restricted to a homogeneous value distribution. For example, just one constant value for reflectivity can be assigned to a road mark element. A more detailed modeling can be achieved by linking against external databases which in turn could implement their own modeling standards.

Material properties are used for visualization in rendering tools, for detection with sensor models, and for direct surface contact, e.g. for tire models. Such material properties can comprise

Type of material (e.g. tarmac, tar, grass, steel, …)
Color
Reflectivity
Roughness
Friction
Adhesion
Density

The level of detail of materials in the material layer can range from simple default information for basic material properties to further references to complex material databases. The material layer is therefore also closely connected to topics in WP02 Environmental Representation.

2.10. Referencing external databases

Additional databases, such as city models, land use data or environment models, should be linkable to the Area Concept. The Area Concept is solely designed to describe the vehicle’s road-focused environment. It is intended to align the linking methodology with WP02 Environmental Representation. Especially the latest development in the CityGML 3.0 Transportation Model is very promising as traffic space is partitioned in a comparable manner to the Area Concept. A future integration of both standards could be targeted.

An example for supplementary, optional data could be the linking of cadastral geo-datasets describing simplified curbstones as LINESTRING in inner city environments where curbstones have not been included in the regular Area Concept data model (ground layer, traffic area layer). For example, this data can be used as additional information for generating parameterized test cases. The basic idea is to enable the optional inclusion of source or intermediate datasets which were used in the synthesis of an Area Concept database.

Regarding curbstones and lane boundaries, an external database could also contain post-processed or provider-supplied continuous geometry definitions where it is necessary for the application, especially where real-time capabilities arise. An example could be paramPoly3 definitions externally linked to individual LINESTRING elements of this GIS-based Area Concept model. Still, we strongly advise that such information is to be calculated on application level where smoothing of paths or geometries is required.

Referring to Ground layer, another example is to supply separate intersection edges with additional ground datasets which are added to an already existing database. Such three-dimensional ground intersection edges can facilitate the integration into other ground datasets to ensure a smooth elevation value transition within the intersection zones. Ground intersection edges are only used if at least two ground datasets are "physically" connected. There can be multiple intersection edges at the very same location as well as multiple intersection edges connecting the same ground datasets. Along such an intersection edge the elevation information of the connected datasets is to be equalized to avoid gaps. A ground intersection edge would be implemented by a LINESTRING of at least two three-dimensional points which are shared by the corresponding TIN datasets to be connected.

Other examples for supplementary databases can be country-specific traffic regulation information which would implement regulatory layers providing additional semantics for the desired elements within a base Area Concept model.

3. Examples and use cases

3.1. Simplified modeling examples

Simple drivable way
One driving lane, drivable in both directions, no superelevation, no additional attributes.

_________________________________
_________________________________ <==>

Modeling

Minimal definition (reality depiction)

Supportive for simulation

Ground layer: flat surface
Traffic area layer: one polygon

Driving lane information supplied by lane layer
Standard driving direction supplied by regulatory layer
Additional traffic rules supplied by infrastructure and regulatory layer

Simple road
Two driving lanes, with RHT, road mark in the middle and on the sides, no superelevation, no additional attributes like friction, road type etc.

_________________________________
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _  <=
_________________________________  =>

Modeling

Minimal definition (reality depiction)

Supportive for simulation

Ground layer: flat surface
Traffic area layer: one rectangular polygon
Road mark layer: continuous LINESTRINGS for solid paintings, individual LINESTRING snippets for the dashed elements

Driving lane information supplied by lane layer
Standard driving direction supplied by regulatory layer
Additional traffic rules supplied by infrastructure and regulatory layer

Simple curved road with sidewalk
Two driving lanes, with RHT, no road marks, no superelevation. The sidewalk is elevated from the road level. No additional attributes.

_________________________________
_________________________________       sidewalk, curved
                                   <=   road, curved
_________________________________  =>

Modeling

Minimal definition (reality depiction)

Supportive for simulation

Ground layer: flat surface with elevated part for sidewalk
Traffic area layer: one polygon for the road and one polygon for the sidewalk

Driving lane information supplied by lane layer
Standard driving direction supplied by regulatory layer
Additional traffic rules supplied by infrastructure and regulatory layer

Simple curved road with superelevation
Two driving lanes, both lanes in the same direction with RHT, no road marks. Road is tilted towards its center by applying superelevation. No additional attributes.

_________________________________
                                   =>  road, curved
_________________________________  =>  applied superelevation

Modeling

Minimal definition (reality depiction)

Supportive for simulation

Ground layer: surface with superelevation as densified TIN
Traffic area layer: one polygon for the road

Driving lane information supplied by lane layer
Standard driving direction supplied by regulatory layer
Additional traffic rules supplied by infrastructure and regulatory layer

Simple road with bridge
Two driving lanes, with RHT, road mark in the middle and on the sides, no superelevation, no additional attributes like friction, road type etc.

_______________]___[_____________
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _  <=
_________________________________  =>
               ]   [ bridge leading over this road

Modeling

Minimal definition (reality depiction)

Supportive for simulation

Ground layer: flat surface, additional ground dataset for the bridge
Traffic area layer: one polygon for the lower road and one for the upper

Driving lane information supplied by lane layer
Standard driving direction supplied by regulatory layer
Additional traffic rules supplied by infrastructure and regulatory layer
Road type bridge could be defined in the traffic area

Motorway
Three driving lanes in each direction, with RHT, and road marks. Guardrails in the middle as separation. No additional attributes.

_________________________________
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _   <=
_________________________________
_________________________________
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _   =>
_________________________________

Modeling

Minimal definition (reality depiction)

Supportive for simulation

Ground layer: flat surface
Traffic area layer: one polygon for both sides of the motorway or two polygons, one for each side; a traffic island as third polygon
Infrastructure layer: guardrails as linear elements

Driving lane information supplied by lane layer
Standard driving direction supplied by regulatory layer
Additional traffic rules supplied by infrastructure and regulatory layer

3.2. Stakeholder requirements

Stakeholder issues

Area Concept

OpenDRIVE 1.x

1. Automotive domain (development of driver assistance and automation systems)

1.1. Driving simulation

Setup of huge synthetic databases

Less simple modelling of synthetic data (adequate tool support required)

Easier modelling of synthetic data (specialized tools are available)

Setup of huge real world databases

Simple modelling of real-world data due to geometric modelling with absolute positioning

Super-complex modelling of real-world data due to geometric modelling with relative positioning

Possible data source

Manually built, derived from road operators, public authorities, directly delivered by map makers and surveying companies

Manually built, inconveniently derived from road operators, public authorities, directly delivered by map makers and surveying companies with high transformation effort

Update/modification of huge databases

Data modification easy due to flat layer structure and absolute positioning

Data modification difficult (adequate tool support required) due to complex hierarchical data model and relative positioning

Compatible with scenario description

Currently not available and has to be developed

Compatible with Open-SCENARIO and tool proprietary formats

Compatible with surface description

Includes a surface description, currently not available for third party formats and has to be developed

Compatible with OpenCRG and tool proprietary formats

Possibility of real-time processing

Spatially indexed data enables real-time processing

Well-proven real-time capability in SIL and HIL simulations

Stakeholder issues

Area Concept

OpenDRIVE 1.x

A.1.1.2. Traffic simulation

Setup of huge databases

Tools have to be extended to support the new file format

Some tools are able to read OpenDRIVE but struggle with huge databases

Combination with additional databases (e.g. city model, vegetation, elevation, auxiliary)

Simple extensibility through custom layers and references to other datasets

Difficult extensibility due to data model restrictions and complex hierarchical data model, no linkage to other datasets possible

Stakeholder issues

Area Concept

OpenDRIVE 1.x

A.1.1.3. Test and approval simulation

Generating variants of test snippets

Less simple modelling of synthetic data (adequate tool support required), could be generated using a domain-specific language

Simple modelling of synthetic data (just build small XML in editor), can be generated using a domain-specific language

Using small real world data test snippets

Simple modelling of small real-world data due to geometric modelling with absolute positioning

Manageable modelling of small real-world data due to geometric modelling with relative positioning

Using huge real world data test snippets

Simple modelling of huge real-world data due to geometric modelling with absolute positioning

Super-complex modelling of huge real-world data due to geometric modelling with relative positioning and XML bloat

Compatible with scenario description

Currently not available and has to be developed

Compatible with Open-SCENARIO and tool proprietary formats

Compatible with surface description

Includes a surface description, currently not available for third party formats and has to be developed

Compatible with OpenCRG and tool proprietary formats

Combination with additional databases (e.g. sensor meta data, vegetation, auxiliary)

Simple extensibility through custom layers and references to other datasets

Difficult extensibility due to data model restrictions and complex hierarchical data model, no linkage to other datasets possible

Stakeholder issues

Area Concept

OpenDRIVE 1.x

A 1.2. Road operator

Management of road infrastructure (e.g. road signs, traffic lights)

Simple due to the use of discrete coordinates, absolute positioning and flat layer structure

Super-complex due to the use of continuous functions, relative position and deep, complex hierarchical data model

Management of additional road infrastructure (e.g. traffic sensors, road condition information)

Simple extensibility through custom layers and references to other datasets

Difficult extensibility due to data model restrictions and complex hierarchical data model, no linkage to other datasets possible

Possible data source

Manually set up based on public authorities, directly delivered by map makers and surveying companies

Only map makers and surveying companies providing with high transformation effort

Management of database updates

Data modification easy due to flat layer structure and absolute positioning

Data modification difficult (adequate tool support required) due to complex hierarchical data model and relative positioning

Management of huge databases

Simple using well-established tools from GIS domain

Currently only prototypes available for including OpenDRIVE into GIS/CAD domain

Stakeholder issues

Area Concept

OpenDRIVE 1.x

A.1.3. Public Authorities

Management of city data (e.g. city model, vegetation, road furniture, cadastral data)

Simple extensibility through custom layers and references to other datasets

Difficult extensibility due to data model restrictions and complex hierarchical data model, no linkage to other datasets possible

Possible data source

Manually set up based on public authorities, directly delivered by map makers and surveying companies

Only map makers and surveying companies providing with high transformation effort

Management of database updates

Data modification easy due to flat layer structure and absolute positioning

Data modification difficult (adequate tool support required) due to complex hierarchical data model and relative positioning

Management of huge databases

Simple using well-established tools from GIS domain

Currently only prototypes available for including OpenDRIVE into GIS/CAD domain

Stakeholder issues

Area Concept

OpenDRIVE 1.x

A.1.4. Surveying companies

Effort for data transformation

Simple using well-established tools from GIS domain, flat layer structure and absolute positioning

Super-complex due to missing modelling tools, deep hierarchical data model and relative positioning

Effort for setting up huge databases

Simple using well-established tools from GIS domain

Super-complex due to missing modelling tools and XML bloat

Effort of updating huge databases

Data modification easy due to flat layer structure and absolute positioning

Data modification difficult (adequate tool support required) due to complex hierarchical data model and relative positioning

Incorporating additional surveying results (e.g. city model, vegetation, sensor meta data)

Simple extensibility through custom layers and references to other datasets

Difficult extensibility due to data model restrictions and complex hierarchical data model, no linkage to other datasets possible

Stakeholder issues

Area Concept

OpenDRIVE 1.x

A.1.5. Map makers

Effort for data transformation

Simple using well-established tools from GIS domain, flat layer structure and absolute positioning

Super-complex due to missing modelling tools, deep hierarchical data model and relative positioning

Compatibility with standard-definition map data

Can be referenced to layers, esp. punctual data

No direct referencing (e.g. to reference lines possible)

Compatibility with high-definition map data

Can be referenced to layers, esp. outlines and punctual data

No direct referencing (e.g. to reference lines possible) due to relative positioning

4. Bibliography

4.1. Bibliography

Richter, Andreas; Scholz, Michael: Road2Simulation Guidelines; https://doi.org/10.5281/zenodo.3375525; 2019
Anonymous authors: Geographic Information System Basics; https://2012books.lardbucket.org/books/geographic-information-system-basics/; v. 1.0; 2012
Open Geospatial Consortium Inc.: Simple Feature Access — Part 1: Common Architecture; https://www.ogc.org/standards/sfa; v. 1.2.1; 2011
Open Geospatial Consortium Inc.: Simple Feature Access — Part 2: SQL Option; https://www.ogc.org/standards/sfs; v. 1.2.1; 2010
ISO/IEC: Information technology — Database languages — SQL multimedia and application packages — Part 3: Spatial; https://www.iso.org/standard/60343.html; 13249-3; 2016

OpenDRIVE: Concept Document

Introduction

1. Overview

2. Motivation

3. Scope

3.1. Working group 1, Junctions

3.2. Working group 2, Environmental representation

3.3. Working group 3, Road geometry

3.4. Working group 4, International traffic sign model

3.5. Working group 5, Area concept

Concept Paper WP01

1. Improved description of the elevation profile of roads in junctions

1.1. Short summary and motivation of the proposal

1.2. Use cases

1.3. Details of the proposal

1.3.1. How is it done in OpenDRIVE 1.6

1.3.2. General description: Junction road

1.3.3. General description: Junction grid

1.3.4. General description: Junction borders

1.3.5. Rules

1.3.6. XML examples

XML example of the concept

Image and XML example for the adaption of virtual junctions

2. Direct Links

2.1. Short summary and motivation of the proposal

2.2. Use cases

2.3. Details of the proposal

2.3.1. How is it solved in OpenDRIVE 1.6?

2.3.2. General description

2.3.3. Rules

2.3.4. XML example

2.4. Out of scope and limitations

3. Specify the length of virtual junctions

3.1. Short summary of the proposal and motivation

3.2. Use cases for the concept

3.3. Details of the proposal

3.3.1. How is it solved in OpenDRIVE 1.6?

3.3.2. General description

3.3.3. Rules

3.3.4. XML examples

Virtual junctions in OpenDRIVE 1.6

Proposed new structure

3.3.5. Images

4. Junction Classes

4.1. Summary of the proposal and motivation

4.2. Use cases

4.3. Detailes of the proposal

4.3.1. How is it solved in in OpenDRIVE 1.6?

4.3.2. General description

JC1 – Non overlapping motorway entry and exit

JC2 - Common junctions

JC3 - Forks and overlapping exit or entries

JC4 - Slip roads

JC5 - Roundabouts

JC6 - Motorway interchange

4.4. Out of scope and limitations

5. Concept postponed for later editing

5.1. Elongated reference line in junctions

5.1.1. Short summary and motivation of the proposal

5.1.2. Notes / Comments / Links

6. Rejected concepts:

6.1. Elevation values for lanes in junctions

6.1.1. Which problem is the concept intended to solve?

6.1.2. What is the idea of the concept?

6.1.3. How is it done in OpenDRIVE 1.6?

6.1.4. Why has the concept been rejected?

6.2. Global reference point

6.2.1. What is the idea of the concept?

6.2.2. Why has the concept been rejected?

Concept paper WP02: Environmental representation

1. Simplifying the data model of OpenDRIVE by implementing modeling paradigms

1.1. Short summary and motivation of the proposal

1.2. Use cases

1.3. Details of the proposal

1.3.1. General description

Introducing a more generalized abstractObject class

Extending the relationship between classes by the methods of aggregation and composition

Implementing naming conventions and name spaces

1.3.2. UML model

1.3.3. XML examples

Introducing a more generalized `abstractObject` class

Example 1. Introducing a more generalized `abstractObject` class

Example of reduced redundancies and the complexity of the OpenDRIVE model using the `lane` chapter