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’’