OpenDRIVE 1.6.1

Disclaimer

This document is the copyrighted property of ASAM e.V. In alteration to the regular license terms, ASAM allows unrestricted distribution of this standard. §2 (1) of ASAM’s regular license terms is therefore substituted by the following clause: "The licensor grants everyone a basic, non-exclusive and unlimited license to use the standard ASAM OpenDRIVE".

1. Foreword

ASAM OpenDRIVE provides the exchange format specification to describe static road networks for driving simulation applications. The primary task of ASAM OpenDRIVE is the road description including objects along the road. The OpenDRIVE Specification covers the description on how to model e.g. roads, lanes, junctions. Dynamic content is not coverd by ASAM OpenDRIVE

1.1. Deliverables of the OpenDRIVE specification

The following deliverables are provided for OpenDRIVE:

File format specification
XML schemas
UML model
Sample files (UseCases and Examples)
Example implementations
Reference implementations spiral
Signal Base catalog for OpenDRIVE

2. Introduction

2.1. Overview

The OpenDRIVE format provides a common base for describing road networks with Extensible Markup Language (XML) syntax, with the file extension xodr. The data that is stored in an OpenDRIVE file describes the geometry of roads as well as features along the roads that influence the logics, for example, lanes and signals. The road networks that are described in the OpenDRIVE file can either be synthetic or real. The main purpose of OpenDRIVE is to provide a road network description that can be fed into simulations and to make these road network descriptions exchangeable.

The format is organized in nodes that can be extended with user defined data. This facilitates a high degree of specialization for individual applications (usually simulations) while maintaining the interoperability that is required for the exchange of data between different applications.

2.2. Normative and non-normative statements and deliverables

This specification uses a standard information structure. The following rules apply regarding normativity of sections:

Statements expressed as requirements, permissions, or prohibitions according to the use of modal verbs, as defined in chapter 2.3.3. Modal verbs, are normative.
UML diagrams from the OpenDRIVE UML model are normative.
Rules for OpenDRIVE data structures in "Rules" sections are normative.
XML examples and use case descriptions are non-normative.

2.3. Conventions

2.3.1. Naming Conventions

In this document, the following conventions apply:

data types are given according to IEEE standard

2.3.2. Units

Unless stated otherwise, all numeric values within this specification are in SI units, for example:

position/distance in [m]
angles in [rad]
time in [s]
speed in [m/s]

Geographic positions are stated in the unit defined by the spatial coordinate system, for example, in accordance with WGS 84 – EPSG 4326 [1].

Some data elements allow you to explicitly state the unit of a given value. If the unit is not given or if there is no means to state the unit, SI units apply. The following units may be used in explicit assignments:

Table 1. Units
Category	Description	Identifier
distance	meter	m
	kilometer	km
	feet	ft
	land mile	mile
Speed	meters per second	m/s
	miles per hour	mph
	kilometers per hour	km/h
Mass	kilogram	kg
Mass	metric tons	t
Slope	percent	%

These optional units shall be used for purposes of signage and speed indication only. They shall not be used as general units, for example, to define road geometry, etc.

2.3.3. Modal verbs

To ensure compliance with the OpenDRIVE standard, users need to be able to distinguish between mandatory requirements, recommendations, permissions, as well as possibilities and capabilities.

The following rules for using modal verbs apply:

Table 2. Rules for using modal verbs
Provision	Verbal form
Requirement Requirements shall be followed strictly in order to be conform to the standard. Deviations are not allowed.	shall shall not
Recommendation Recommendations indicate that among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others.	should should not
Permission Permissions indicate a course of action permissible within the limits of OpenDRIVE deliverables.	may need not
Possibility and capability These verbal forms are used for stating possibilities or capabilities, being technical, material, physical, or others.	can can not
Obligation and necessity These verbal forms are used to describe legal, organizational, or technical obligations and necessities that are not regulated or enforced by the OpenDRIVE standard.	must must not

2.3.4. Typographic conventions

This documentation uses the following typographical conventions:

Table 3. Typographical conventions
Mark-up	Definition
`Code elements`	This format is used for code elements, such as technical names of classes and attributes, as well as attribute values.
`Code snippets`	This format is used for excerpts of code that serve as an example for implementation.
Terms	This format is used to introduce glossary terms, new terms and to emphasize terms.
`Mathematical elements`	This format is used for calculations and mathematical elements.
`<element>`	This describes a tag for an element within the XML specification
@attribute	The "@" identifies an attribute of any OpenDRIVE element

The OpenDRIVE structure diagrams are modeled according to the Unified Modeling Language (UML). For detailed information on UML, see Booch et al. (1997).

Figure 1. UML notation (see ISO TS 19103, Geographic information - Conceptual schema language)

The context that an element takes within an association is indicated by its role. The role is given near the target of the association. For better readability, the OpenDRIVE class diagrams use a color scheme:

The top-level element of a diagram is marked orange. This helps finding the entry point when reading a diagram top-down.
Classes that are marked yellow belong to the UML package that is discussed in the chapter of the specification, where the UML diagram is given.
Classes that are marked blue belong to an OpenDRIVE package that is different from the package that is associated with the yellow color.
Classes that are marked green are classes that contain geometry information.

Mandatory and optional attributes

Figure 2. UML attribute notation

In the UML Model attributes are marked as mandatory and optional. In the above figure the marking of the attributes can be seen. Optional attributes have the UML specific notation [0..1], mandatory attributes do not have any notation.

2.3.5. Use of IDs

The following rules apply to the use of IDs in OpenDRIVE:

IDs shall be unique within a class.
Lane IDs shall be unique within a lane section.
Only defined IDs may be referenced.

2.3.6. Curvature

For curvature indications, the following convention applies:

Positive curvature: left curve (counter-clockwise motion)
Negative curvature: right curve (clockwise motion)

Curvature == 1/radius

3. Relations to other standards

3.1. Positioning of ASAM OpenDRIVE within ASAM activities

ASAM OpenDRIVE is part of the ASAM simulation standards that focus on simulation data for the automotive environment. Next to ASAM OpenDRIVE, ASAM Provides other standards for the simulation domain, like ASAM OpenSCENARIO and ASAM OpenCRG.

ASAM OpenDRIVE defines a storage format for the static description of road networks. In combination with ASAM OpenCRG it is possible to add very detailed road surface descriptions to the road network. ASAM OpenDRIVE and ASAM OpenCRG only contains static content. To add dynamic content ASAM OpenSCENARIO is needed. Combined all three standards provide a scenario-driven description of traffic simulation that contains static and dynamic content

Figure 3. Relation between OpenDRIVE, OpenCRG, and OpenSCENARIO

3.2. Backward compatibility to earlier releases

OpenDRIVE 1.6.1 contains elements that were introduced in version 1.5 but are not compatible with version 1.4. To ensure compatibility with versions 1.4 and 1.5, these elements are technically defined as optional in the XML schema of version 1.6.1. They are marked as "Optional for backwards compatibility" in the annotations of the UML model.

During the development of OpenDRIVE 1.6.0 and OpenDRIVE 1.6.1 errors where found in the xsd schemas of version 1.4 and 1.5 with respect to the documentation of these versions. Therefore, backward compatiblity is ensured to the documentation of version 1.4 and 1.5.

3.3. References to other standards

XML 1.0 Schema [4]
UML 2.5.1 Standard[10]
ISO 3166-2 for country codes [8]
ISO 8855 for right handed coordinate systems
ISO 8601 for time / date [7]
Georeferencing (ISO DIN 19111)
ASAM OpenCRG [3]

4. General Architecture

4.1. File Structure

OpenDRIVE data is stored in XML files with the extension .xodr. Compressed OpenDRIVE files have the extension ".xodrz" (compression format: gzip).

The OpenDRIVE file structure conforms to XML rules; the associated schema file is referenced in the XML. The schema file for the OpenDRIVE® format can be retrieved from https://www.asam.net/standards/detail/opendrive/

Elements are organized in levels. Elements with a level that is greater than zero (0) are children of the preceding level. Elements with a level of one (1) are called primary elements.

Each element can be extended with user-defined data. This data is stored in so-called user data elements.

All floating-point numbers used in OpenDRIVE are IEEE 754 double precision floating-point numbers. In order to ensure accurate representation of floating-point numbers in the XML representation, implementations SHOULD use a known correct accuracy preserving minimal floating-point printing algorithm (e.g. [11], [12]), or ensure that 17 significand decimal digits are always produced (e.g. using the "%.17g" ISO C printf modifier). Importing implementations should use a known correct accuracy preserving floating-point reading algorithm (e.g. [13]).

4.2. Combining Files

Multiple files can be combined with an <include> element at the appropriate locations. Upon parsing this element, OpenDRIVE readers shall immediately start reading the file specified as attribute of the element. It is the user’s responsibility to make sure that contents read from an include file are consistent with the context from which the inclusion starts.

The parent element under which the <include> element occurs must be present in both, the parent file and the included file.

Example:

Original File

<planView>
    <include file="planview.xml"/>
</planView>

Included File

<planView>
    <geometry x="-0.014" y="-0.055" hdg="2.88" length="95.89" s="0.0">
        <arc curvature="-0.000490572"/>
    </geometry>
    <geometry x="-92.10" y="26.64" hdg="2.84" length="46.65" s="95.89">
        <spiral curvStart="-0.000490572" curvEnd="-0.004661241"/>
    </geometry>
</planView>

4.3. Attributes used in the file

All attributes that can be used in an OpenDRIVE file are fully annotated in the UML[10] model:

If units are applicable to an attribute, these are stated according to chapter 2.3.2. Units.
Type: Describes the data type of an attribute. It can be either a primitive data type, for example, string, double, float, or a complex data type that refers to an object described within this specification.
Value: Value determines the value range of the given attribute relative to the specified type

4.3.1. Enclosing element

The overall enclosing element of the file is:

Table 4. Attributes of the OpenDRIVE element
Delimiters	`<OpenDRIVE>…</OpenDRIVE>`
Parent	none
Instances	1
Attributes	`xmlns`="http://www.opendrive.org"

4.3.2. Header

The <header> element is the very first element within the <OpenDRIVE> element.

Table 5. Attributes of the header element
Delimiters		`<header>…</header>`
Parent		`<OpenDRIVE>`
Instances		1
Attributes
Name	Type	Unit	Value	Description
`revMajor`	ushort	-	1	Major revision number of OpenDRIVE format
`revMinor`	ushort	-	6	Minor revision number of OpenDRIVE format; 6 for OpenDrive 1.6.1
`name`	string	-	-	Database name
`version`	string	-	-	Version of this road network
`date`	string	-	-	Time/date of database creation according to ISO 8601 (preference: YYYY-MM-DDThh:mm:ss)
`north`	double	m	-	Maximum inertial y value
`south`	double	m	-	Minimum inertial y value
`east`	double	m	-	Maximum inertial x value
`west`	double	m	-	Minimum inertial x value
`vendor`	string	-	-	Vendor name

4.4. General rules and assumptions

4.4.1. Traffic direction

Unless stated otherwise, all examples, figures, and descriptions in this specification assume right-hand traffic.

5. Additional Data

OpenDRIVE offers the possibility to include external data. The processing of this data depends on the application.

Additional data may be placed at any position in OpenDRIVE.

5.1. User Data

Ancillary data should be described near the element it refers to. Ancillary data contains data that are not yet described in OpenDRIVE, or data that is needed by an application for a specific reason. Examples are different road textures.

In OpenDRIVE, ancillary data is represented by <userData> elements. They may be stored at any element in OpenDRIVE.

Figure 4. UML model OpenDRIVE Core

5.2. Including Data

OpenDRIVE allows including external files into the OpenDRIVE file. The processing of the files depends on the application.

Included data is represented by <include> elements. They may be stored at any position in OpenDRIVE

5.3. Using different layout types

OpenDRIVE offers the possibility to integrate user generated layouts for elements like road marks or signals. The design of these alternative layouts is not stored in OpenDRIVE, but in the application.

In OpenDRIVE, different layout types are represented by <set> elements. They may be stored at any position in OpenDRIVE.

Every <set> element may be followed by one or more <instance> element that specifies the layout.

5.4. Description of the data quality

Raw data or data from external sources that is integrated in OpenDRIVE may be of varying quality. It is possible to describe quality and accuracy of external data in OpenDRIVE.

The description of the data quality is represented by <dataQuality> elements. They may be stored at any position in OpenDRIVE.

Measurement data derived from external sources like GPS that is integrated in OpenDRIVE may be inaccurate. The error range, given in [m], may be listed in the application.

The absolute or relative errors of road data are described by <error> elements within the <dataQuality> element.

Some basic metadata containing information about raw data included in OpenDRIVE is described by the <rawData> element within the <dataQuality> element.

6. Coordinate systems

6.1. Coordinate systems overview

OpenDRIVE uses three types of coordinate systems, as shown in the below figure:

The inertial x/y/z coordinate system
The reference line s/t/h coordinate system
The local u/v/z coordinate system

Figure 5. available coordinate systems in OpenDRIVE

If not indicated otherwise, the local coordinate system is located and oriented relative to the reference line coordinate system. The reference line coordinate system is located and oriented relative to the inertial coordinate system by specifying the origin, as well as the heading, roll, and pitch rotation angles of the origins with respect to each other.

Figure 6. Coordinate systems in OpenDRIVE interacting with another

6.2. Inertial coordinate systems

The inertial system is a right-handed coordinate system according to ISO 8855 [2] with the axes pointing to the following directions (see figure 7):

x ⇒ right
y ⇒ up
z ⇒ coming out of drawing plane

For geographic reference, the following convention applies:

x ⇒ east
y ⇒ north
z ⇒ up

Elements like objects and signals can be placed within the inertial coordinate system by applying a heading, followed by pitch, followed by roll:

Figure 7. Inertial coordinate system with defined rotations

Figure 7 shows the positive axes and positive directions of the corresponding angles.

heading
heading = 0.0:
heading = +π/2:

around z-axis, where
x’ points into direction of x-axis / east
x’ points into direction of y-axis / north

pitch
pitch = 0.0:
pitch = +π/2:

around y’-axis, where
x’’/y’’-plane = x’/y’-plane
direction x’’ = - z’ = -z

roll
roll = 0.0:
roll = +π/2:

around x’’-axis, where
x’’’/y’’’-plane = x’’/y’’-plane
direction z’’’ = - y’’

Figure 8. Inertial coordinate system with defined rotations

x’/y’/(z’=z) denotes the coordinate system after rotating x/y/z with the heading angle around the z-axis. The coordinate system x’’/(y’’=y’)/z’’ denotes the coordinate system after rotating x’/y’/z’ with the pitch angle around the y’-axis. The final rotated coordinate system (x’’’=x’’)/y’’’/z’’’ is obtained after rotating system x’’/y’’/z’’ with roll angle.

6.3. Reference line coordinate systems

The reference line coordinate system applies along the reference line of a road. It is a right-handed coordinate system. The s-direction follows the tangent of the reference line. It has to be noted that the reference line is always located within the x/y-plane defined by the inertial coordinate system. The t-direction is orthogonal to the s-direction. The right-hand system is completed by defining the up-direction h orthogonal to x-axis and y-axis. The following degrees of freedom are defined:

Figure 9. Reference line coordinate system

coordinate along reference line, measured in [m] from the beginning of the road reference line, calculated in the xy-plane (that is, not taking into account the elevation profile of the road)

lateral position, positive to the left within the inertial x/y plane

orthogonal to st plane in a right-handed coordinate system

Figure 10. Reference line system with defined rotations

heading
heading = 0.0:
heading = +π/2:

around h-axis, where
s’ is directed forward along s-direction
s’ is directed to t

roll
roll = 0.0:

around s’-axis, where
s’’’/t’’’-plane = s’/t’-plane

Similar to the inertial system, the s’/t’/h’ and s’’’/t’’’/h’’’ denote the rotated systems around heading and roll angle. The reference line coordinate system can be positioned in the inertial space by providing the origin’s coordinates and the orientation (heading) of the origin with respect to the inertial system, as shown in figure 11.

Figure 11. Heading in reference line

Superelevation causes a roll in the reference line.

Figure 12. Roll in reference line

For the s/t/h coordinate system no pitch is possible, the elevation of the reference line is as follows. Elevation has no effect on the length of s.

Figure 13. Elevation in reference line

6.4. Local coordinate systems

The local system is a right-handed coordinate system according to ISO 8855 with the axes pointing to the following directions. For a non-rotated coordinate system the following applies:

Forward matches s

Left matches t

Up matches h

Elements like objects can be placed within the local coordinate system by applying a heading, followed by pitch, followed by roll:

Figure 14. Local system with defined rotations

Within the local system, the following angles are defined:

heading
heading = 0.0:
heading = +π/2:

around z-axis, 0.0 = east
u’ is directed forward along u-direction
u’ is directed to t

pitch
pitch = 0.0:
pitch = +π/2:

around v’-axis, where
u’’/v’’-plane = u’/v’-plane
direction x’’ = - z’ = -z

roll
roll = 0.0:
roll = +π/2:

around x’’-axis, where
x’’’/y’’’-plane = x’’/y’’-plane
direction z’’’ = - y’’

Figure 15. Local coordinate systems with heading, pitch, roll

Figure 14 shows the positive axes and positive directions of the corresponding angles. The local system can only be positioned in reference line space by providing the origin of the local coordinate system within the reference line system and the orientation (heading) of the local system with respect to the reference line system, as shown in figure 16.

Figure 16. Local coordinate system with respect to reference line system

6.5. Summary of all available coordinate systems

Inertial, reference line and local system are used in OpenDRIVE at the same time. An example for positioning and orientation of the different coordinate systems relative to each other is depicted in figure 17.

Figure 17. Summary of coordinate system in OpenDRIVE

6.6. Georeferencing in OpenDRIVE

Spatial reference systems are standardized by the European Petroleum Survey Group Geodesy (EPSG [5]) and are defined by parameters describing the geodetic datum. A geodetic datum is a coordinate reference system for a collection of positions that are relative to an ellipsoid model of the earth.

A geodetic datum is described by a projection string according to PROJ, that is, a format for the exchange of data between two coordinate systems. This data shall be marked as CDATA, because it may contain characters that interfere with the XML syntax of an element’s attribute.

In OpenDRIVE, the information about the geographic reference of an OpenDRIVE dataset is represented by the <geoReference> element within the <header> element. proj-strings, as shown in figure 18, contain all parameters that define the used spatial reference system:

For detailed information on proj-strings, see https://proj.org/usage/projections.html

There shall be no more than one definition of the projection. If the definition is missing, a local Cartesian coordinate system is assumed.

It is highly recommended to use official parameter sets for proj-strings, which can be found at https://epsg.io/. Parameters should not be changed. Some spatial reference systems, for example, UTM, have implicit false easting and northing, which are defined using the parameters +x_0 and +y_0.

If you want to apply an offset, use the <offset> element instead of changing all parameter values.

XML example

<geoReference>
    <![CDATA[+proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs]]>
</geoReference>

Figure 18. Offset for the geoReference

Rules

The <offset> should be such that the x and y coordinates of OpenDRIVE are approximately centered around (0;0). If the x and y coordinates are too large, applications using float coordinates internally might not be able to process them accurately enough due to the limited precision of IEEE 754 double precision floating point numbers

7. Geometry

Road courses can have many different shapes. There are long, straight roads on open ground, elongated curves on motorways, or narrow turns in the mountains. In order to model all these road courses in a mathematically correct way, OpenDRIVE provides a variety of geometry elements. Figure 19 shows the five possible ways to define the geometry of a road’s reference line:

A straight line
A spiral or a clothoid that has a linearly changing curvature
An arc that has a constant curvature
Cubic polynomials
Parametric cubic polynomials

Figure 19. Geometry elements in OpenDRIVE

7.1. Road reference line

The basic element of every road in OpenDRIVE is the road reference line. All geometry elements that describe the road shape and further properties of the road are defined along the reference line. These properties include lanes and signals.

By definition, the reference line runs in s-direction, while the lateral deviation of objects from the reference line runs in t-direction. The direction of the reference line does not indicate the driving direction.

Figure 20 shows the different parts of a road in OpenDRIVE.

The road reference line
The individual lanes of a road
Features like signals that are placed along the road

Figure 20. the individual parts of a road

In OpenDRIVE, the geometry of a reference line is represented by the <geometry> element within the <planView> element.

The <planView> element is a mandatory element in every <road> element.

Figure 21. UML model Road Geometry including the Reference Line elements

Elements in UML model

t_road_planView_geometry

Table 6. Attributes of the planView element
Name	Type	Unit	Value	Description
`s`	t_grEqZero	m	[0;∞[	s-coordinate of start position
`x`	double	m	]-∞;∞[	Start position (x inertial)
`y`	double	m	]-∞;∞[	Start position (y inertial)
`hdg`	double	rad	]-∞;∞[	Start orientation (inertial heading)
`length`	t_grZero	m	[0;∞[	Length of the element’s reference line

Rules

The following rules apply to road reference lines:

Each road shall have a reference line.
There shall be only one reference line per road.
The reference line usually runs in the center of the road but may be laterally offset.
<geometry> elements shall be defined in ascending order along the reference line according to the s-coordinate.
One <geometry> element shall contain only one element that further specifies the geometry of the road.
If two roads are connected without a junction, the reference line of a new road shall always begin at the <contactPoint> of its successor or predecessor road. The reference lines may be directed in opposite directions.
A reference line shall have no leaps
A reference line should have no kinks

Related topics

Straight line
Spirals
Arc
Roads
Lanes

7.2. Straight line

A straight line, as shown in figure 22, is the simplest geometry element. It contains no further attributes.

Figure 22. A straight line

In OpenDRIVE, a straight line is represented by a <line> element within the <geometry> element.

XML Example

<planView>
    <geometry
        s="0.0000000000000000e+00"
        x="-4.7170752711170401e+01"
        y="7.2847983820912710e-01"
        hdg="6.5477882613167993e-01"
        length="5.7280000000000000e+01">
        <line/>
    </geometry>
</planView>

Related topics

Road reference line
Road

7.3. Spiral

A spiral is a clothoid that describes a changing curvature of the reference line, as shown in figure 23. Spirals [6] may be used to describe the transition from a <line> to an <arc> without causing leaps in the curvature.

A spiral is characterized by the curvature at its start position (@curvStart) and the curvature at its end position (@curvEnd). Along the arc length of the spiral (see @length of the <geometry> element), the curvature is linear from the start to the end.

It is also possible to arrange several <line>, <spiral>, and <arc> elements in a sequence in order to describe complex curvatures.

Figure 23. Road geometry described by a spiral

In OpenDRIVE, a spiral is represented by a <spiral> element within the <geometry> element.

Elements in UML model

t_road_planView_geometry_spiral

Table 7. Attributes of the spiral element
Name	Type	Unit	Value	Description
`curvStart`	double	1/m	]-∞;∞[	Curvature at the start of the element
`curvEnd`	double	1/m	]-∞;∞[	Curvature at the end of the element

XML Example

<geometry s="100.0" x="38.00" y="-1.81" hdg="0.33" length="30.00">
    <spiral curvStart="0.0" curvEnd="0.013"/>
</geometry>

Rules

The following rules apply to spirals:

@curvStart and @curvEnd should not be the same.

Related topics

Arc
Reference line
Generating arbitrary road courses from geometry elements
Road

7.4. Arc

An arc, as shown in figure 24, describes a road reference line with constant curvature.

Figure 24. Road geometry described by an arc

In OpenDRIVE, a spiral is represented by a <arc> element within the <geometry> element.

Elements in UML model

t_road_planView_geometry_spiral

Table 8. Attributes of the arc element
Name	Type	Unit	Value	Description
`curvature`	double	1/m	]-∞;∞[	Constant curvature throughout the element

XML Example

<planView>
    <geometry
        s="3.6612031746270386e+00"
        x="-4.6416930098385274e+00"
        y="4.3409250448366459e+00"
        hdg="5.2962250374496271e+00"
        length="9.1954178989066371e+00">
        <arc curvature="-1.2698412698412698e-01"/>
    </geometry>
</planView>

Rules

The following rules apply to arcs:

The curvature should not be zero.

Related topics

Reference line
Road

7.5. Generating arbitrary road courses from geometry elements

The combination of all geometry elements available in OpenDRIVE allows for the creation of a great variety of road courses, as shown in figure 25.

To avoid leaps in the curvature, it is recommended to use spirals to combine lines with arcs and other elements with different curvatures.

Figure 25. Creating a reference line from geometry elements

XML Example

See the sample file Ex_Line-Spiral-Arc.xodr

7.6. Cubic polynom (deprecated)

Cubic polynoms may be used to generate complex road courses that are derived from measurement data. For a given sequence of measured coordinates along the reference line in the x/y-coordinate system, measurement pairs define the polynom limits of the segment.

The reference line of the road is described by a local cubic polynom. Specifying continuity conditions, for example segment continuity, tangent and/or curvature continuity, at the limits of the segment allows to merge several cubic polynom segments and to form a global cubic spline interpolation curve for the entire course of the road. As an additional advantage, routing along polynoms can be realized more efficiently than along clothoids.

7.6.1. Background information on cubic polynoms (deprecated)

The interpolation of a cubic polynom in the x/y-coordinate system is described with the following formula:

y(x) = a + b*x + c*x2 + d*x³

The polynom parameters a, b, c, d in the calculation are used to define the course of the roads. With the help of the parameters a-d, the y-coordinate can be calculated from the x-coordinate at every point in the coordinate system.

Figure 26 shows a cubic polynom in the x/y-coordinate system with the following values:

a = 20
b = 0
c = 0.0005
d = 0.0001

Figure 26. A cubic polynom

7.6.2. Creating roads using cubic polynoms (deprecated)

A cubic polynom described in the x/y-coordinate system is not suitable to describe curved segments with an arbitrary orientation, as shown in figure 27. To handle curved segments with two or more y-coordinates at a given x-coordinate, cubic polynom segments may be defined with respect to a local u/v-coordinate system. Using the local u/v-coordinate system increases flexibility in the curve definition. The following formula is used:

v(u) = a + b*u + c*u2 + d*u³

The orientation of the local u/v-coordinate system should be chosen in such a way that the curve is expressed as a function v(u) at increasing u-coordinates.

Figure 27. A curve which cannot be represented by a cubic polynom w.r.t x parameter

Usually, the u/v-coordinate system is aligned with the s/t-coordinate system at the segment’s start position (@x,@y) and start orientation @hdg, specified in the <geometry> element. This choice results in polynom parameters a=b=0 (see figure 28). As an additional option, the local u/v-coordinate system may be rotated relative to the start point (@x,@y) by specifying a polynom parameter @b that is unequal to zero. Here, the arctan (@b) defines the start heading of the polynom curve with respect to the local u/v-coordinate system. An additional shift of the u/v-coordinate origin along the v-coordinate axis, while (@x,@y) shall be located at u=0, may be achieved by setting the polynom parameter @a unequal to zero (see figure 29). The parameter u may be varied within 0 and the projection of the end point of the curve onto the u-coordinate axis. For the given parameter u, the local coordinate v(u) defines the point on the curve in the local u/v-coordinate system.

v(u) = a + b*u + c*u2 + d*u³

Taking into account shift and rotation parameters @a and @b and the (@x,@y) and @hdg specified in the <geometry> element, the final x/y-curve position at a given u-coordinate, as shown in figure 29

Figure 28. Transformation from a u/v- to a x/y coordinate system with a=b=0

Figure 29. Transformation from a u/v- to a x/y coordinate system with a!=0 and b!=0

In OpenDRIVE, a cubic polynom is represented by a <poly3> element within the <geometry> element.

Elements in UML model

t_road_planView_geometry_poly3

Table 9. Attributes of the poly3 element
Name	Type	Unit	Value	Description
`a`	double	m	]-∞;∞[	Polynom parameter a
`b`	double	1/m	]-∞;∞[	Polynom parameter b
`c`	double	1/m²	]-∞;∞[	Polynom parameter c
`d`	double	1/m³	]-∞;∞[	Polynom parameter d

XML Example

<geometry
    s="0.0000000000000000e+00"
    x="-6.8858131487889267e+01"
    y="4.1522491349480972e-01"
    hdg="6.5004409066736524e-01"
    length="2.5615689718113455e+01">
    <poly3
        a="0.0000000000000000e+00"
        b="0.0000000000000000e+00"
        c="1.4658732624442020e-02"
        d="-5.7746497381565959e-04"/>
</geometry>
<geometry
    s="2.5615689718113455e+01"
    x="-4.8650519031141869e+01"
    y="1.5778546712802767e+01"
    hdg="2.9381264033570398e-01"
    length="3.1394863696852912e+01">
    <poly3
        a="0.0000000000000000e+00"
        b="0.0000000000000000e+00"
        c="-1.9578575382799307e-02"
        d="2.3347864348004167e-04"/>
</geometry>

Rules

The following rules apply to cubic polynoms:

A cubic polynom may be used to describe the course of a road for which measurement data is available
If the local u/v-coordinate system is aligned with the s/t-coordinate system of the start point, the polynom parameter coefficients are a=b=0.
The starting point (@x,@y) of the <geometry> element is located on the v-coordinate axis of the local u/v-coordinate system.
The polynomial parameters a and b should be 0 for a smooth reference line.

Related topics

Parametric cubic curve
Georeferencing
Roads
Generating arbitrary road courses from geometry elements

7.7. Parametric cubic curve

Parametric cubic curves are used for complex curves that are to be generated from measurement data. Parametric cubic curves are more flexible and allow a greater variety of road courses than cubic polynoms. In comparison to cubic polynoms that are defined in a x/y-coordinate system or as local u/v-coordinates, the coordinates x and y are interpolated separately by their own splines with respect to a common interpolation parameter p.

7.7.1. Generating roads using parametric cubic curves

Generating road courses with parametric cubic curves only require x- and y-coordinates. For reasons of consistency to cubic polynoms, they may be calculated simultaneously to cubic polynoms using local u- and v-coordinates.

u(p) = aU + bU*p + cU*p2 + dU*p³
v(p) = aV + bV*p + cV*p2 + dV*p³

Unless otherwise stated, the interpolation parameter p is in the range [0;1]. Alternatively, it may be given in the range [0; @length of <geometry>]. Similar to cubic polynoms, the local coordinate system with the variables u and v may be placed and oriented arbitrarily.

To simplify representation, the local coordinate system should be aligned with the s/t-coordinate system at the start point (@x,@y) and start orientation @hdg:

u points in local s-direction, meaning along the reference line at the start point
v points in local t-direction, meaning in lateral deviation from the reference line at the start point
the parameters @aU, @aV and @bV shall be zero, @bU shall be > 0.

Providing non-zero values for the parameters @aU, @aV and @bV leads to a shift and rotation of the s/t coordinates as shown figure 26, figure 27 and figure 28.

After defining the points of the curve for a given parameter p, the u-values and v-values are transformed into values of the x/y-coordinate system with regard to the shifts and orientation specified by the parameters @aU, @aV, @bU, @bV, the start coordinates (@x,@y) and the start orientation @hdg.

It has to be noted that there is a non-linear relation between the interpolation parameter p and the actual length of the arc between the start point (@x,@y) in the <geometry> element and the point (x(p),y(p)) associated with the parameter p. In general, only the startpoint and endpoint parameter p=0 and p=@length (for the option @pRange=arcLength) will coincide with the actual length of the arc.

Taking into account shift and rotation parameters @a and @b and the (@x,@y) and @hdg specified in the <geometry> element, the final x/y-curve position at a given u-coordinate, as shown in figure 29

Figure 30. A parametric cubic polynom for interpolation of u coordinate

Figure 31. A parametric cubic polynom for interpolation of v coordinate

Figure 32. A parametric cubic polynom

In OpenDRIVE, parametric cubic curves are represented by <paramPoly3> elements within the <geometry> element.

Elements in UML model

t_road_planView_geometry_poly3

Table 10. Attributes of the paramPoly3 element
Name	Type	Unit	Value	Description
`aU`	double	m	]-∞;∞[	Polynom parameter a for U
`bU`	double	1/m	]-∞;∞[	Polynom parameter b for U
`cU`	double	1/m²	]-∞;∞[	Polynom parameter c for U
`dU`	double	1/m³	]-∞;∞[	Polynom parameter d for U
`aV`	double	m	]-∞;∞[	Polynom parameter a for V
`bV`	double	1/m	]-∞;∞[	Polynom parameter b for V
`cV`	double	1/m²	]-∞;∞[	Polynom parameter c for V
`dV`	double	1/m³	]-∞;∞[	Polynom parameter d for V
`pRange`	e_paramPoly3_pRange	1/m³	arcLength ; normalized	Range of parameter p. - Case arcLength: p in [0, @length of `<geometry>`] - Case normalized: p in [0, 1]

XML Example

<planView>
    <geometry
        s="0.000000000000e+00"
        x="6.804539427645e+05"
        y="5.422483642942e+06"
        hdg="5.287405485081e+00"
        length="6.565893957370e+01">
        <paramPoly3
            aU="0.000000000000e+00"
            bU="1.000000000000e+00"
            cU="-4.666602734948e-09"
            dU="-2.629787927644e-08"
            aV="0.000000000000e+00"
            bV="1.665334536938e-16"
            cV="-1.987729787588e-04"
            dV="-1.317158625579e-09"
            pRange="arcLength">
        </paramPoly3>
    </geometry>
</planView>

Rules

The following rules apply to parametric cubic curves:

The local u/v-coordinate system should be aligned with the s/t-coordinate system of the start point (meaning that the curve starts in the direction given by @hdg, and at the position given by @x and @y). To achieve this, the polynom parameter coefficients have to be @aU=@aV=@bV=0, @bU>0.
If @pRange="arcLength", p shall be chosen in [0, @length from <geometry>].
If @pRange="normalized", p shall be chosen in [0, 1].
The actual curve length, as determined by numerical integration over the parameter range, should match @length.

Related topics

Cubic polynom
Georeferencing
Roads
Generating arbitrary road courses from geometry elements

8. Roads

In OpenDRIVE, the road network is represented by <road> elements. Each road runs along one road reference line. A road shall have at least one lane with a width larger than 0. Vehicles may drive in both directions of the reference line. The standard driving direction is defined by the value which is assigned to the @rule attribute (RHT=right-hand traffic, LHT=left-hand traffic).

OpenDRIVE roads may be roads in the real road network or artificial road network created for application use. Each road is described by one or more <road> elements. One <road> element may cover a long stretch of a road, shorter stretches between junctions, or even several roads. A new <road> element should only start if the properties of the road cannot be described within the previous <road> element or if a junction is required.

Related topics

Reference line
Road linkage
Lanes

UML Model

Figure 33. UML Model for Roads

Figure 34. UML model for Road Geometry

Elements in UML model

t_road

Table 11. Attributes of the road element
Name	Type	Unit	Value	Description
`name`	string			Name of the road. May be chosen freely.
`length`	t_grZero			Total length of the reference line in the xy-plane. Change in length due to elevation is not considered
`id`	string		-;[0;∞[	Unique ID within the database. If it represents an integer number, it should comply to uint32_t and stay within the given range.
`junction`	string		-;-1	ID of the junction to which the road belongs as a connecting road (= -1 for none)
`rule`	e_trafficRule		]-∞;∞[	Basic rule for using the road; RHT=right-hand traffic, LHT=left-hand traffic. When this attribute is missing, RHT is assumed.

8.1. Properties for road sections and cross section

Some properties of roads are described based on the cross section of the road. The road cross section is the orthogonal view of the road at a given point on the road reference line. An example of a property that refers to the road cross section is superelevation. Elements that are valid for a road cross section are valid for the whole width of the road at a given point on the reference line.

Other road properties are described based on the plan view of the road. This includes lanes and road elevation. For these properties, the term road section is used. Road sections describe parts of roads and their specific properties along the s-coordinate of the road reference line. Properties that are valid for a road section may not be valid for the whole width of the road, but for specific lanes only.

That means it is possible to create sections for different properties like road type or lane sections. Sections are created by an additional element within the <road> element, using new start s-coordinates. The length of a section is implicitly given by the difference between two given s-start positions. Sections shall be stored in ascending order of s-coordinates.

8.2. Road Linkage

For applications to navigate through a road network, roads must be linked to each other. Roads may be connected to another road or a junction. Isolated roads are not connected to other roads or junctions.

Figure 35 shows scenarios of prohibited, allowed, and recommended road linkage. It is important that the lanes and reference lines of the roads to be linked have a direct linkage to its predecessor or successor. Overlaps or leaps should be avoided but are not prohibited if the reference lines are connected properly.

Figure 35. Allowed, prohibited, and recommended road linkage

Figure 36 shows the allowed scenarios for road linkage outside junctions, with two roads running in the same, opposite, or converging directions. Road linkage is not possible, if the two reference lines are not connected to each other.

Figure 36. Allowed scenarios of road linkage

Figure 37. Allowed scenario of road linkage within a junction

In OpenDRIVE, road linkage is represented by the <link> element within the <road> element. The <predecessor> and <successor> elements are defined within the <link> element. A successor of a given road is an element connected to the end of its reference line. A predecessor of a given road is an element connected to the start of its reference line. For virtual and regular junctions, different attribute sets shall be used for the <predecessor> and <successor> elements.

Figure 38. UML model for road linkage

Elements in UML model

t_road_link

Follows the road header if the road is linked to a successor, a predecessor, or a neighbor. Isolated roads may omit this element.

t_road_link_predecessorSuccessor

For virtual and regular junctions, different attribute sets shall be used. @contactPoint shall be used for regular junctions; @elementS and @elementDir shall be used for virtual junctions.

Table 12. Attributes of the road link predecessorSuccessor element
Name	Type	Unit	Value	Description
`elementId`	string			ID of the linked element
`elementType`	e_road_link_elementType		road ; junction	Type of the linked element
`contactPoint`	e_contactPoint		start ; end	Contact point of link on the linked element
`elementS`	t_grEqZero	m		Alternative to contactPoint for virtual junctions. Indicates a connection within the predecessor, meaning not at the start or end of the predecessor. Shall only be used for elementType "road"
`elementDir`	e_elementDir		+;-	To be provided when elementS is used for the connection definition. Indicates the direction on the predecessor from which the road is entered.

Rules

The following rules apply to road linkage:

Two roads shall only be linked directly, if the linkage is clear. If the relationship to successor or predecessor is ambiguous, junctions shall be used.
A road may have another road or a junction as successor or predecessor. A road may also have no successor or predecessor.
A road may serve as its own predecessor or successor.

Related topics

Reference line
Junctions
Lane linkage

8.3. Road type

The road type defines the main purpose of a road and the associated traffic rules. Example road types are motorways and rural roads. The road type is valid for the entire road cross section.

The road type may be changed as often as needed within a <road> element. This may be done by defining different road types at given points along the reference line. One road type remains valid until another road type is defined.

In OpenDRIVE, the road type is represented by the <type> element within the <road> element. The road type itself is given in the @type attribute.

Elements in UML model

t_road_type

A road type element is valid for the entire cross section of a road. It is valid until a new road type element is provided or until the road ends.

Table 13. Attributes of the road type element
Name	Type	Unit	Value	Description
`s`	t_grEqZero	m	[0;∞[	s-coordinate of start position
`type`	e_roadType			Type of the road defined as enumeration, see UML diagram
`country`	e_countryCode			Country code of the road, see ISO 3166-1, alpha-2 codes

Rules

The following rules apply to road types:

When the type of road changes, a new <type> element shall be created within the parent <road> element.
Country code and state identifier may be added to the <type> element to specify which national traffic rules apply to this road type. The according data is stored in the application and not in OpenDRIVE.
There shall only be ALPHA-2 country codes in use, no ALPHA-3 country codes, because only ALPHA-2 country codes support state identifiers.
Single lanes may have another type than the road they belong to. Road type and lane type represent different properties and are both valid if specified.
<type> elements shall be defined in ascending order according to the s-coordinate.

Related topics

Lane type
Properties for road sections and cross section

8.3.1. Speed limits for road types

A speed limit may be defined for a road type. When the road type changes and a speed limit exists on that road section, a new speed element is required, because road types have no globally valid speed limits. The limit shall be defined for each road type element separately.

In OpenDRIVE, the speed limit is represented by the <speed> element within the <type> element.

Elements in UML model

t_road_type_speed

Defines the default maximum speed allowed in conjunction with the specified road type.

Table 14. Attributes of the road type speed element
Name	Type	Unit	Value	Description
`max`	t_maxSpeed		no limit ; undefined ; [0,∞[	s-coordinate of start position
`unit`	e_unitSpeed			Unit of the attribute max. For values, see chapter "units".

Rules

The following rules apply to speed limits:

A maximum speed may be defined as default value per road type element.
Single lanes may have different speed limits than the road they belong to. They are defined as <laneSpeed>.
Speed limits derived from signals shall always have preference.

Related topics

Road type
Properties for road sections and cross section
Signals

8.4. Methods of Elevation

There are several ways to elevate a road or parts of a road:

Road elevation specifies the elevation along the road reference line, that is in s direction.
The lateral profile, using superelevation and shape definition, specifies the elevation orthogonally to the reference line, that is in t direction.

The types of road elevation are shown in figure 39

Figure 39. Types of elevation

The s length does not change with the elevation.

8.4.1. Road elevation

A road may be elevated along its reference line. Road elevation is defined per road cross section at a given position on the reference line. Elevation is specified in meters. The default elevation of a road is zero. In case georeferencing is used, the definition of zero depends on it.

In OpenDRIVE, elevation is represented by the <elevation> element inside the <elevationProfile> element.

Elements in UML model

t_road_elevationProfile_elevation

Defines an elevation element at a given position on the reference line. Elements shall be defined in ascending order along the reference line. The s length does not change with the elevation.

Table 15. Attributes of the elevation element
Name	Type	Unit	Value	Description
`s`	t_grEqZero	m	[0;∞[	s-coordinate of start position
`a`	double	m	]-∞;∞[	Polynom parameter a, elevation at @s (ds=0)
`b`	double	1	]-∞;∞[	Polynom parameter b
`c`	double	1/m	]-∞;∞[	Polynom parameter c
`d`	double	1/m²	]-∞;∞[	Polynom parameter d

Calculation

Road elevation is calculated with the following polynomial function of the third order:

elev(ds) = a + b*ds + c*ds² + d*ds³

where

elev

is the elevation (inertial z) at a given position

a, b, c, d

are the coefficients

ds

is the distance along the reference line between the start of a new elevation element and the given position.

ds restarts at zero for each element. The absolute position of an elevation value is calculated as follows:

s = s_start + ds

where

s

is the absolute position in the reference line coordinate system

s_start

is the start position of the element in the reference line coordinate system

Rules

The following rules apply to road elevation:

Roads shall be elevated along their reference line.
Road elevation may be defined in combination with superelevation and road shape or standalone.
<elevation> elements shall be defined in ascending order according to the s-coordinate. Because the elevation can go up and down, the elements shall be linked to the respective position on the reference line.
The definition of road elevation remains valid until the next element of this type is defined.

Related topics

Superelevation
Shape definition

8.4.2. Superelevation

Superelevation is part of the lateral profile and describes the cross slope of the road. It may be used, for example, to incline the road to the inner side so that vehicles can drive through them more easily. For superelevated roads, the t axis of a road is not parallel to the underlying terrain, as shown in figure 40. For this reason, a lateral profile is defined for the entire road cross section. Superelevation does not change the actual width of a lane, but it affects the projected width. The default value for superelevation is zero.

Mathematically, superelevation is defined as the roll angle of the road cross section around the reference line. That means, superelevation has positive values for roads falling to the right side and negative values for roads falling to the left side.

In the example in figure 40, the reference line is parallel to the y axis, to simplify the given example.

Figure 40. Superelevation

In OpenDRIVE, superelevation is represented by the <superelevation> element within the <lateralProfile> element.

Elements in UML model

t_road_lateralProfile_superelevation

Defined as the road section’s roll angle around the s-axis. Elements must be defined in ascending order along the reference line. The parameters of an element are valid until the next element starts or the road reference line ends. Per default, the superelevation of a road is zero.

Table 16. Attributes of the superelevation element
Name	Type	Unit	Value	Description
`s`	t_grEqZero	m	[0;∞[	s-coordinate of start position
`a`	double	rad	]-∞;∞[	Polynom parameter a, superelevation at @s (ds=0)
`b`	double	rad/m	]-∞;∞[	Polynom parameter b
`c`	double	rad/m²	]-∞;∞[	Polynom parameter c
`d`	double	rad/m³	]-∞;∞[	Polynom parameter d

Calculation

Superelevation is calculated using the following polynomial function of the third order:

s_Elev (ds) = a + b*ds + c*ds² + d*ds³

where

s_Elev

is the superelevation at a given position

a, b, c, d

are the coefficients

ds

is the distance along the reference line between the start of a superelevation element and the given position.

ds restarts at zero for each element. The absolute position of a superelevation value is calculated as follows:

s = s_start + ds

where

s

is the absolute position in the reference line coordinate system

s_start

is the start position of the element in the reference line coordinate system

Rules

The following rules apply to superelevation:

When superelevation is defined, it shall apply to the entire road cross section.
<superelevation> elements shall be defined in ascending order according to the s-coordinate.
Single lanes of a road may be excluded from superelevation using the @level attribute.
Road elevation may be defined in combination with superelevation.

Related topics

Excluding lanes from road elevation
Road elevation
Shape definition

8.4.3. Shape definition

Some lateral road shapes are too complex to be described by superelevation alone. Shapes describe the elevation of a road’s cross section at a given point on the reference line in a more detailed way. That means, there may be several shape definitions at one s-coordinate that have different t-values, thereby describing the curvy shape of the road.

If shapes are used without superelevation, the actual width of a lane might be changed due to its curvilinear shape. The projected width with respect to the planview is not affected.

If shapes are combined with superelevation as shown in figure 41, the projected width with respect to the superelevated state does not change, but the projected width with respect to the planview is affected.Between shape profiles, at specific s-coordinates, the road shape is interpolated linearly. Combining shapes with non-linear lane offsets should be avoided.

The defined t range must at least cover the maximum t-expansion of the entire <road> element, as shown in the figure 42.

In figure 41 is shown how to calculate the height information between two lateral profiles. In figure 41 The lateral profile at s_R1 has five polynomial definition, while the lateral profile at s_R2 has three polynomial definitions. To calculate a point between two lateral profiles, interpolate linear between those two profiles, use the formulas shown in figure 41.

Figure 41. Minimum t-definition range for road shapes

Typical use cases are curved road surfaces on high-speed test tracks and crossfalls. The default value for shape is zero.

Figure 42. Shape definition (left) in combination with superelevation (right)

Elements in UML model

t_road_lateralProfile_shape

Defined as the road section’s surface relative to the reference plane. There may be several shape definitions at one s-position that have different t-values, thereby describing the curvy shape of the road.

Table 17. Attributes of the shape element
Name	Type	Unit	Value	Description
`s`	t_grEqZero	m	[0;∞[	s-coordinate of start position
`t`	double	m	]-∞;∞[	t-coordinate of start position
`a`	double	m	]-∞;∞[	Polynom parameter a, relative height at @t (dt=0)
`b`	double	1	]-∞;∞[	Polynom parameter b
`c`	double	1/m	]-∞;∞[	Polynom parameter c
`d`	double	1/m²	]-∞;∞[	Polynom parameter d

Calculation

The shape of the lateral profile is calculated with the following polynomial function:

h_Shape (ds)= a + b*dt + c*dt² + d*dt³

where

h_Shape

is the height above the reference plane at a given position

a, b, c, d

are the coefficients

dt

is the distance perpendicular to the reference line between the start of a shape element and the given position

dt restarts at zero for each element. The absolute position of a shape value is calculated as follows:

t = tstart + dt

where

t

is the absolute position in the reference line coordinate system

t_start

is the start position of the element in the reference line coordinate system

Rules

The following rules apply to shapes:

Shapes may be defined in combination with superelevation and road elevation.
There should be no lane offset when using shapes.
<shape> elements shall be defined in ascending order, firstly according to the s-coordinate and secondly according to the t-coordinate.

Related topics

Road elevation
Superelevation
Properties for road sections and cross section

8.5. Road surface

The description of the surface of a road is part of OpenCRG, not OpenDRIVE. It is possible to reference data created by OpenCRG in OpenDRIVE. In OpenDRIVE, the road surface is represented by the <surface> element within the <road> element. Data described in OpenCRG is represented by the <CRG> element within the <surface> element.

Neither OpenDRIVE nor OpenCRG contain data regarding the visual representation of the road surface. With OpenCRG it is possible to model detailed road surface attributes, for example cobble stone or pot holes, as shown in figure 43.