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

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