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:

  1. Junction road

  2. Junction grid

  3. 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

junction_ref_line
Figure 1. junctionRoad reference line
trafficIsland
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.