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 ASAM OpenDRIVE Specification covers the description on how to model e.g. roads, lanes, junctions. Dynamic content is not covered by ASAM OpenDRIVE.

1.1. Deliverables of the ASAM OpenDRIVE specification

The following deliverables are provided for ASAM OpenDRIVE:

  • File format specification

  • XML schemas

  • UML model

  • Sample files (Use cases and Examples)

  • Example implementations

  • Reference implementations spiral

  • Signal catalog for ASAM OpenDRIVE

2. Introduction

2.1. Overview

The ASAM 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 ASAM 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 ASAM OpenDRIVE file can either be synthetic or real. The main purpose of ASAM 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 Section Modal verbs, are normative.

  • UML diagrams from the ASAM OpenDRIVE UML model are normative.

  • Rules for ASAM 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 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

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

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 ASAM OpenDRIVE element.

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

img1
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 ASAM 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 ASAM 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

img2
Figure 2. UML attribute notation

In the UML Model attributes are marked as mandatory and optional. In Figure 2 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 ASAM 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.

img3
Figure 3. Relation between ASAM OpenDRIVE, ASAM OpenCRG, and ASAM OpenSCENARIO

3.2. Backward compatibility to earlier releases

ASAM OpenDRIVE 1.7.0 is backward compatible to ASAM OpenDRIVE 1.6.1.

ASAM OpenDRIVE 1.7.0 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.7.0. They are marked as "Optional for backwards compatibility" in the annotations of the UML model.

During the development of ASAM OpenDRIVE 1.6.0 and ASAM 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 compatibility 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

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

The ASAM OpenDRIVE file structure conforms to XML rules; the associated schema file is referenced in the XML. The schema file for the ASAM 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 ASAM 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 significant 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, ASAM 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. Overview of elements

Table 4. Overview of ASAM OpenDRIVE elements
Element Section

<OpenDRIVE>

Section 4.4.1

     <header>

Section 4.4.2

         <geoReference>

Section 6.6

         <offset>

Section 6.6

     <road>

Section 8

         <planView>

Section 7

             <geometry>

Section 7

                 <line>

Section 7.2

                 <spiral>

Section 7.3

                 <arc>

Section 7.4

                 <poly3>

Section 7.6

                 <paramPoly3>

Section 7.7

         <link>

Section 8.2

             <predecessorSuccessor>

Section 8.2

         <type>

Section 8.3

             <speed>

Section 8.3.1

         <lateralProfile>

Section 8.4.2

             <superelevation>

Section 8.4.2

             <shape>

Section 8.4.3

         <elevationProfile>

Section 8.4

             <elevation>

Section 8.4

         <surface>

Section 8.5

             <CRG>

Section 8.5.6

         <lanes>

Section 9

             <laneOffset>

Section 9.3

             <laneSection>

Section 9.2

                 <center>

Section 9.2

                     <lane>

Section 9.2

                 <left>

Section 9.2

                     <lane>

Section 9.2

                 <right>

Section 9.2

                     <lane>

Section 9.2

                 <lr_lane>

Section 9.5.3

                     <width>

Section 9.5.1

                     <border>

Section 9.5.2

                     <link>

Section 9.4

                         <predecessorSuccessor>

Section 9.4

                     <material>

Section 9.5.4

                     <speed>

Section 9.5.5

                     <access>

Section 9.5.6

                     <height>

Section 9.5.7

                     <roadMark>

Section 9.6.1

                         <type>

Section 9.6

                             <line>

Section 9.6

                         <explicit>

Section 9.6.2

                             <line>

Section 9.6.2

                         <sway>

Section 9.6.3

                     <rule>

Section 9.7

         <objects>

Section 11

             <object>

Section 11

                 <repeat>

Section 11.1

                 <outlines>

Section 11.2

                     <outline>

Section 11.2

                         <cornerRoad>

Section 11.2.1

                         <cornerLocal>

Section 11.2.2

                 <material>

Section 11.3

                 <parkingSpace>

Section 11.5

                 <markings>

Section 11.6

                     <marking>

Section 11.6

                         <cornerReference>

Section 11.6

                 <borders>

Section 11.7

                     <border>

Section 11.7

                 <validity>

Section 11.4

                 <surface>

Section 11.11

                     <CRG>

Section 11.11

             <objectReference>

Section 11.8

                 <validity>

Section 11.8

             <tunnel>