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

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

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.

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>`	Section 11.9
`<validity>`	Section 11.9
`<bridge>`	Section 11.10
`<validity>`	Section 11.10
`<signals>`	Section 12
`<signal>`	Section 12
`<validity>`	Section 12.1
`<dependency>`	Section 12.2
`<reference>`	Section 12.3
`<positionRoad>`	Section 12.4
`<positionInertial>`	Section 12.4
`<signalReference>`	Section 12.5
`<validity>`	Section 12.5
`<railroad>`	Section 13
`<switch>`	Section 13.2
`<mainTrack>`	Section 13.2.1
`<sideTrack>`	Section 13.2.2
`<partner>`	Section 13.2.3
`<junction>`	Section 10.1
`<connection>`	Section 10.2
`<laneLink>`	Section 10.2
`<priority>`	Section 10.3.1
`<predecessorSuccessor>`	Section 10.5
`<controller>`	Section 10.7.1
`<surface>`	Section 10.6
`<CRG>`	Section 10.6
`<junctionGroup>`	Section 10.7
`<junctionReference>`	Section 10.7
`<controller>`	Section 12.6
`<control>`	Section 12.6
`<station>`	Section 13.3
`<platform>`	Section 13.3.1
`<segment>`	Section 13.3.2

4.4. Attributes used in the file

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

If units are applicable to an attribute, these are stated according to Section 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.4.1. Enclosing element

The overall enclosing element of the file is:

Table 5. Attributes of the ASAM OpenDRIVE element
Delimiters	`<OpenDRIVE>…</OpenDRIVE>`
Parent	none
Instances	1
Attributes	`xmlns`="https://code.asam.net/simulation/standard/opendrive_schema/"

4.4.2. Header

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

Table 6. 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 ASAM OpenDRIVE format
`revMinor`	ushort	-	7	Minor revision number of ASAM OpenDRIVE format; 7 for ASAM OpenDRIVE 1.7.0
`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.5. General rules and assumptions

4.5.1. Traffic direction

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

5. Additional Data

ASAM 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 ASAM 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 ASAM OpenDRIVE, or data that is needed by an application for a specific reason. Examples are different road textures.

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

Figure 4. UML model ASAM OpenDRIVE Core

5.2. Including Data

ASAM OpenDRIVE allows including external files into the ASAM 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 ASAM OpenDRIVE.

5.3. Using different layout types

ASAM 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 ASAM OpenDRIVE, but in the application.

In ASAM OpenDRIVE, different layout types are represented by <set> elements. They may be stored at any position in ASAM 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 ASAM OpenDRIVE may be of varying quality. It is possible to describe quality and accuracy of external data in ASAM OpenDRIVE.

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

Measurement data derived from external sources like GPS that is integrated in ASAM 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 ASAM OpenDRIVE is described by the <rawData> element within the <dataQuality> element.

6. Coordinate systems

6.1. Coordinate systems overview

ASAM OpenDRIVE uses three types of coordinate systems, as shown in Figure 5 and Figure 6:

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

s

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)

t

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

h

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:

u

Forward matches s

v

Left matches t

z

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:

around v’-axis, where
u’’/v’’-plane = u’/v’-plane

roll
roll = 0.0:

around u’’-axis, where
u’’’/v’’’-plane = u’’/v’’-plane

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

6.6. Georeferencing in ASAM 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 ASAM OpenDRIVE, the information about the geographic reference of an ASAM OpenDRIVE dataset is represented by the <geoReference> element within the <header> element.

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

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.

XML example

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

Rules

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

To apply an offset, use the <offset> element instead of changing all parameter values.

Elements in UML model

t_header_Offset

To avoid large coordinates, an offset of the whole dataset may be applied using the <offset> element. It enables inertial relocation and re-orientation of datasets. The dataset is first translated by @x, @y, and @z. Afterwards, it is rotated by @hdg around the new origin. Rotation around the z-axis should be avoided. In ASAM OpenDRIVE, the offset of a database is represented by the <offset> element within the <header> element.

Table 7. Attributes of the header Offset element
Name	Type	Unit	Description
`hdg`	double	rad	Heading offset (rotation around resulting z-axis)
`x`	double	m	Inertial x offset
`y`	double	m	Inertial y offset
`z`	double	m	Inertial z offset

Rules

The <offset> should be such that the x and y coordinates of ASAM 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.

Figure 18. geoReference and offset

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, ASAM 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 ASAM OpenDRIVE

7.1. Road reference line

The basic element of every road in ASAM 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. The individual parts of a road

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

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

In ASAM 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 8. Attributes of the road planView geometry element
Name	Type	Unit	Description
`hdg`	double	rad	Start orientation (inertial heading)
`length`	t_grZero	m	Length of the element’s reference line
`s`	t_grEqZero	m	s-coordinate of start position
`x`	double	m	Start position (x inertial)
`y`	double	m	Start position (y inertial)

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

Elements in UML model

t_road_planView_geometry_line

A straight line is the simplest geometry element. It contains no further attributes.

In ASAM 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
Roads

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

Elements in UML model

t_road_planView_geometry_spiral

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

Table 9. Attributes of the road planView geometry spiral element
Name	Type	Unit	Description
`curvEnd`	double	1/m	Curvature at the end of the element
`curvStart`	double	1/m	Curvature at the start 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
Road reference line
Generating arbitrary road courses from geometry elements
Roads

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

Elements in UML model

t_road_planView_geometry_arc

An arc describes a road reference line with constant curvature. In ASAM OpenDRIVE, an arc is represented by an <arc> element within the <geometry> element.

Table 10. Attributes of the road planView geometry arc element
Name	Type	Unit	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

Road reference line
Roads

7.5. Generating arbitrary road courses from geometry elements

The combination of all geometry elements available in ASAM 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

Elements in UML model

t_road_planView_geometry_poly3

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

Table 11. Attributes of the road planView geometry poly3 element
Name	Type	Unit	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 30, Figure 31 and Figure 32.

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

Elements in UML model

t_road_planView_geometry_paramPoly3

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

Table 12. Attributes of the road planView geometry paramPoly3 element
Name	Type	Unit	Description
`aU`	double	m	Polynom parameter a for u
`aV`	double	m	Polynom parameter a for v
`bU`	double	1/m	Polynom parameter b for u
`bV`	double	1/m	Polynom parameter b for v
`cU`	double	1/m²	Polynom parameter c for u
`cV`	double	1/m²	Polynom parameter c for v
`dU`	double	1/m³	Polynom parameter d for u
`dV`	double	1/m³	Polynom parameter d for v
`pRange`	e_paramPoly3_pRange		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

Elements in UML model

t_road

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

Table 13. Attributes of the road element
Name	Type	Unit	Description
`id`	string		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		ID of the junction to which the road belongs as a connecting road (= -1 for none)
`length`	t_grZero	m	Total length of the reference line in the xy-plane. Change in length due to elevation is not considered
`name`	string		Name of the road. May be chosen freely.
`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.

UML Model

Figure 33. UML Model for Roads

Figure 34. UML model for Road Geometry

Rules

The following rules apply to roads:

Only roads with the same junction id may overlap on the same level. This does not include roads on different driving levels, for example, bridges.
Roads outside a junction shall not overlap.
A road shall not overlap with itself.

Related topics

Road reference line
Road linkage
Lanes

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 ASAM 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 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 or a predecessor. Isolated roads may omit this element.

t_road_link_predecessorSuccessor

Successors and predecessors can be junctions or roads. For each, different attribute sets shall be used.

Table 14. Attributes of the road link predecessorSuccessor element
Name	Type	Unit	Description
`contactPoint`	e_contactPoint		Contact point of link on the linked element
`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.
`elementId`	string		ID of 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"
`elementType`	e_road_link_elementType		Type of the linked element

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.
For a road as successor or predecessor the @elemetType, @elementId and @contactPoint attributes shall be used.
For a common junction and a direct junction as successor or predecessor the @elemetType and @elementId attributes shall be used.
For a virtual junction as successor or predecessor the @elemetType, @elementId, @elementS and @elementDir attributes shall be used.

Related topics

Road 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 ASAM 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 15. Attributes of the road type element
Name	Type	Unit	Description
`country`	e_countryCode		Country code of the road, see ISO 3166-1, alpha-2 codes.
`s`	t_grEqZero	m	s-coordinate of start position
`type`	e_roadType		Type of the road defined as enumeration

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 ASAM 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 ASAM 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 16. Attributes of the road type speed element
Name	Type	Unit	Description
`max`	t_maxSpeed		Maximum allowed speed. Given as string (only "no limit" / "undefined") or numerical value in the respective unit (see attribute unit). If the attribute unit is not specified, m/s is used as default.
`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.
Objects may influence the road height (see Section 11.11).

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 ASAM 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 17. Attributes of the road elevationProfile elevation element
Name	Type	Unit	Description
`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
`s`	t_grEqZero	m	s-coordinate of start position

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.
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 ASAM 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 18. Attributes of the road lateralProfile superelevation element
Name	Type	Unit	Description
`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
`s`	t_grEqZero	m	s-coordinate of start position

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 superelevation
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 19. Attributes of the road lateralProfile shape element
Name	Type	Unit	Description
`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
`s`	t_grEqZero	m	s-coordinate of start position
`t`	double	m	t-coordinate of start position

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 ASAM OpenCRG, not ASAM OpenDRIVE. It is possible to reference data created by ASAM OpenCRG in ASAM OpenDRIVE. In ASAM OpenDRIVE, the road surface is represented by the <surface> element within the <road> element. Data described in ASAM OpenCRG is represented by the <CRG> element within the <surface> element.

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

Figure 43. Road surface as defined in a CRG file

Beside modeling elevation, CRG data can also be used to model detailed friction values of the road (see Section Defining friction using ASAM OpenCRG).

As the name indicates, CRG (= Curved Regular Grid) data is organized in a regular grid which is laid out along a reference line (comparable to an ASAM OpenDRIVE road’s reference line). At each grid position, it contains the absolute elevation measured along a real road and some additional data which allows for the computation of the delta elevation relative to the reference line. The image below shows the reference line and different coordinate systems of ASAM OpenCRG:

Figure 44. ASAM OpenCRG road surface description using u/v-coordinates and x/y-coordinates

The key to combining ASAM OpenDRIVE and CRG data is to define a correlation between the two reference lines and a rule for using the elevation data of both descriptions. CRG data may be offset from the ASAM OpenDRIVE road’s reference line (see @tOffset) and it may be oriented in the same or opposite direction as the layout direction of the road (see orientation).

Figure 45. Positioning of an ASAM OpenCRG file along the reference line

8.5.1. Modes of combining ASAM OpenDRIVE and ASAM OpenCRG

The CRG data may be applied to a given ASAM OpenDRIVE road in different modes:

Table 20. Modes of connecting ASAM OpenCRG to ASAM OpenDRIVE
Mode	ASAM OpenCRG reference line	Total height	Typical use-case
attached	discarded	ASAM OpenDRIVE height plus ASAM OpenCRG height	Relative road height due to road surface, placement of pot-holes
attached0	discarded	ASAM OpenCRG height only	Absolute height measurement
genuine	shifted and rotated so beginning of reference line matches position given in ASAM OpenDRIVE	ASAM OpenCRG height only	Combining complete ASAM OpenCRG tracks (e.g. racing tracks) with ASAM OpenDRIVE data
global	taken unmodified	ASAM OpenCRG height only	On junctions

@mode = attached:

The reference line of the CRG data set is replaced with the ASAM OpenDRIVE road’s reference line, taking into account the @tOffset and the @sOffset parameters. The CRG local elevation values (calculated by evaluating the CRG grid and applying @zOffset and @zScale) will be added to the surface elevation data of the ASAM OpenDRIVE road (as derived from the combination of elevation, superelevation and crossfall). With this mode, the surface information relative to the original CRG data’s reference line is transferred from an arbitrary CRG road to an ASAM OpenDRIVE road without having to make sure that the overall geometries of the road match. The original position, heading, curvature, elevation and superelevation of the CRG road are disregarded. The CRG grid is evaluated along the ASAM OpenDRIVE reference line instead of the CRG reference line.

The calculation of the height looks as follows (assuming @orientation=same, and using the crgEvaluv2z function from the ASAM OpenCRG C API and a hypothetical laneHeightNoCRG function, which returns what the lane height would be if the CRG file was not present):

\[\begin{align*} & \left( \begin{array}{rrr} u \\ v \\ \end{array}\right)_{CRG} = \left( \begin{array}{rrr} s - s_{Offset} \\ t - t_{Offset} \\ \end{array}\right)_{OpenDRIVE} \\ & \operatorname{totalHeight}(road, s, t) = \operatorname{crgEvaluv2z}(crg, u, v) * z_{Scale} + z_{Offset} + \operatorname{laneHeightNoCRG}(road, s, t) \end{align*}\]

Figure 46. ASAM OpenCRG attachment mode, attached

Figure 47. ASAM OpenCRG attached mode with elevation

@mode = attached0:

This mode is basically the same as the attached mode, with the only exception that only the CRG data’s elevation value is considered (i.e. the ASAM OpenDRIVE elevation is set to zero). To avoid problems set @sStart and @sEnd exactly to the CRG data boundaries. Otherwise gaps with height zero can occur, as shown in Figure 48.

Figure 48. ASAM OpenCRG attached0 mode with elevated reference line

The height calculation is very similar to attached, again assuming @orientation=same:

\[\begin{align*} & \left( \begin{array}{rrr} u \\ v \\ \end{array}\right)_{CRG} = \left( \begin{array}{rrr} s - s_{Offset} \\ t - t_{Offset} \\ \end{array}\right)_{OpenDRIVE} \\ & \operatorname{totalHeight}(road, s, t) = \operatorname{crgEvaluv2z}(crg, u, v) * z_{Scale} + z_{Offset} \end{align*}\]

@mode = genuine:

The start point of the CRG data set’s reference line is positioned relative to the point on the ASAM OpenDRIVE road’s reference line at the position defined by @sStart, @sOffset and @tOffset. By providing offset values for the longitudinal (@sOffset) and lateral (@tOffset) displacement, the heading (@hOffset) and the elevation (@zOffset), the correlation between the two description’s reference lines is clear. In genuine mode, the CRG data will completely replace the ASAM OpenDRIVE elevation data, i.e. the absolute elevation of a given point of the road surface is directly computed from the CRG data. When using this method, it must of course be made sure that the geometry of the CRG data matches – within certain tolerance – the geometry of the underlying ASAM OpenDRIVE road.

The height of a given (x,y) position on the lane is calculated as displayed below. The calculation uses the following helper functions:

st2xyh takes a xy coordinate on the road, and returns the world xy coordinate, plus the heading angle of the reference line at the given s position
crgEvalxy2z is the function from the ASAM OpenCRG C API
REFERENCE_LINE_START_X, REFERENCE_LINE_START_Y and REFERENCE_LINE_START_PHI are road parameters from the CRG file
sOffset, tOffset, hOffset, zOffset and zScale are attributes from the <CRG> element

\[\begin{align*} & (x_{StartCRG}, y_{StartCRG}, h_{StartCRG}) = \operatorname{st2xyh}(road, s_{Offset}, t_{Offset}) \\ & h_{RotAngle} = h_{StartCRG} + h_{Offset} - REFERENCE\_LINE\_START\_PHI \\ & \left( \begin{array}{rrr} x_{CRG} \\ y_{CRG} \\ \end{array}\right) = \left( \begin{matrix}{} \cos(h_{RotAngle}) & \sin(h_{RotAngle}) \\ -\sin(h_{RotAngle}) & \cos(h_{RotAngle}) \\ \end{matrix}\right) \left( \begin{array}{rrr} x_{OpenDRIVE} - x_{StartCRG} \\ y_{OpenDRIVE} - y_{StartCRG} \\ \end{array}\right) + \left( \begin{array}{rrr} REFERENCE\_LINE\_START\_X \\ REFERENCE\_LINE\_START\_Y \\ \end{array}\right) \\ & \operatorname{totalHeight}(x_{OpenDRIVE}, y_{OpenDRIVE}) = \operatorname{crgEvalxy2z}(crg, x_{CRG}, y_{CRG}) * z_{Scale} + z_{Offset} \end{align*}\]

Figure 49. ASAM OpenCRG attachment mode, genuine

@mode = global:

The CRG data set is just referenced from a given track or a junction record but neither translatory nor rotatory transformation is applied. All data in the CRG file remains in its native coordinate system. Elevation data is interpreted as inertial data, i.e. AS IS. The ASAM OpenDRIVE height is completely ignored. This can be used to define heights for junctions. This is also the only mode that can be applied directly to <junction> elements.

The height of a given (x,y) position on the lane is calculated as follows:

\[\operatorname{totalHeight}(x_{OpenDRIVE}, y_{OpenDRIVE}) = \operatorname{crgEvalxy2z}(crg, x_{OpenDRIVE}, y_{OpenDRIVE}) * z_{Scale} + z_{Offset}\]

8.5.2. Switching orientation

In modes attached and attached0, ASAM OpenCRG files can be rotated by 180 degrees, via attribute @orientation:

Figure 50. ASAM OpenCRG orientation

\[\left( \begin{array}{rrr} u \\ v \\ \end{array}\right)_{CRG} = \left( \begin{matrix} 0 & -1 \\ -1 & 0 \\ \end{matrix}\right) \left( \begin{array}{rrr} s - s_{Offset} \\ t - t_{Offset} \\ \end{array}\right)_{OpenDRIVE}\]

The orientation attribute rotates the CRG file at the origin of the u/v coordinate system of the ASAM OpenCRG. The value "same" has a rotation angle of 0° and the value "opposite" has a value of 180°. The t-offset is not affected by the orientation attribute.

8.5.3. Combining ASAM OpenCRG with superelevation

When using modes attached0, genuine or global, the height of the road is determined purely based on the CRG file. It can still be useful (and is allowed by this standard) to add <elevation>, <superelevation>, <height> and similar to the road, to approximate the road height for tools not supporting ASAM OpenCRG.

Elements like <superelevation> do not influence the road height in modes attached0, genuine or global, but they still influence other parts of the road. E.g. <superelevation> will tilt the t axis, and change the projected width of the lane on the ground (see details in Section Superelevation). The calculation for mode attached0 uses the st coordinates as input (see the formula for mode attached0). The conversion from xy to st coordinates always takes <superelevation> and similar elements into account.

8.5.4. Using ASAM OpenCRG on junctions

In principle, ASAM OpenCRG files can be added to junction roads the same way they can be added to other roads. In practice, however, it can be very hard to create a consistent height for overlapping roads with modes attached, attached0 or genuine. Therefore, mode=global should be used for junctions, since with mode=global, CRG files are placed at a global world position (as read from the CRG file), and the CRG file is not influenced by any road reference line or road offset (see the formula for global mode above).

The easiest way to attach a CRG file to a junction is by attaching it directly to the <junction> element, see Section Road surface within junctions. Alternatively, the CRG file can also be attached to all roads comprising the junction.

mode=global was invented for junctions, but may also be used outside of junctions.

8.5.5. Defining friction using ASAM OpenCRG

CRG files can also be used to define friction values for the roads. To do this set @purpose to friction.

Friction values are calculated similarly to elevation values (see formulas above).

Rules

The following additional rules apply:

mode=attached shall not be used together with purpose=friction.
zOffset and zScale shall not be set for friction values. The formulas are calculated as if zOffset=0 and zScale=1.

In other words: if a CRG file with @purpose=friction is added to a road, the values from the CRG file directly replace the friction value set via the <material> element, see Section 9.5.4.

8.5.6. List of attributes and rules

Elements in UML model

t_road_surface_CRG

Data described in OpenCRG is represented by the <CRG> element within the <surface> element.

Table 21. Attributes of the road surface CRG element
Name	Type	Unit	Description
`file`	string		Name of the file containing the CRG data
`hOffset`	double	rad	Heading offset between CRG center line and reference line of the road (only allowed for mode genuine, default = 0.0).
`mode`	e_road_surface_CRG_mode		Attachment mode for the surface data, see specification.
`orientation`	e_direction		Orientation of the CRG data set relative to the parent `<road>` element. Only allowed for mode attached and attached0.
`purpose`	e_road_surface_CRG_purpose		Physical purpose of the data contained in the CRG file; if the attribute is missing, data will be interpreted as elevation data.
`sEnd`	t_grEqZero	m	End of the application of CRG (s-coordinate)
`sOffset`	double	m	s-offset between CRG center line and reference line of the road (default = 0.0)
`sStart`	t_grEqZero	m	Start of the application of CRG data (s-coordinate)
`tOffset`	double	m	t-offset between CRG center line and reference line of the road (default = 0.0)
`zOffset`	double	m	z-offset between CRG center line and reference line of the road (default = 0.0). Only allowed for purpose elevation.
`zScale`	double		z-scale factor for the surface description (default = 1.0). Only allowed for purpose elevation.

Rules

The following rules apply for the use of CRG data in ASAM OpenDRIVE:

If more than one CRG entry is given for the same physical property (attribute purpose) at a given location, then the last entry in the sequence of occurrence in the ASAM OpenDRIVE file shall be the relevant one. All others will be ignored (but see below in the Notes section).
If a <junction> element contains a <CRG> definition, none of the connecting roads that belong to this junction shall have a <CRG> definition.
@orientation=opposite shall not be used for modes other than @mode=attached and @mode=attached0.
@hOffset shall not be used for modes other than @mode=genuine.
@sOffset and @tOffset shall not be used with @mode=global.

Notes

Since CRG data may only cover parts of a road’s surface, it must be made sure that outside the valid CRG area, the elevation information derived from ASAM OpenDRIVE data can still be used.
In the future, multiple CRG files at one position may be combined. For compatibility with future versions, each road or junction should only contain one CRG file per s position and @purpose.
ASAM OpenCRG files only have an effect on those roads or junctions from which they are referenced (and only between sStart and sEnd on that road). Example: if one road references a CRG file in global mode, then only this road will be influenced by the CRG file. Other roads will not be affected, even if the CRG file would overlap the road.
If the calculations of the CRG uv or xy coordinates leads to coordinates outside of the defined area of the CRG file, then the normal CRG mechanisms apply (e.g. BORDER_MODE_U and BORDER_MODE_V) and decide which value is returned.
CRG files may be referenced multiple times with different parameters (e.g. CRG file may be placed in mode genuine multiple times, with different zScale values). This should be considered in the implementation, e.g. by NOT applying the SCALE_Z_GRID upon loading the CRG file, but doing the calculation outside the CRG library, so that multiple instantiations of the same file can share the data in the CRG library.

XML example

<surface>
    <CRG file="fancyData.crg" sStart="0.0" sEnd="100.0" orientation="same" mode="attached" tOffset="0.0"></CRG>
</surface>

Related topics

Roads

8.6. Use cases for roads

The following sections contain some sample use cases for modeling roads in ASAM OpenDRIVE.

8.6.1. Modeling a road shape with a linear crossfall

Many roads have a crossfall, for example, to provide a drainage gradient so that water runs off the surface into the gutter.

Figure 51 shows a sample definition of a two-lane road with a crossfall.

Figure 51. Example crossfall modeled with road shape

The linear crossfall has the following properties:

The width of the road start at t=-4. Because the values are 0, nothing changes in the height up to t=-3.
From t=-3 to t=0, there is a linear rise from 0.15 meter per meter. That means, at t=0 (middle of the road), the road has reached a height of 0.45m.
From t=0.45m, the road has a linear fall by 0.1 meter per meter. That means, when reaching t=4, the road has a height of 0.05m (0.45m-0.40m is 0.05m; road loses 0.1 m per meter over a distance of 4m. When starting at 0.45m, the endpoint is at 0.05m).

To describe the crossfall, <shape> elements within <lateralProfile> are used.

Using ASAM OpenDRIVE structures

To model road shapes, shape elements shall start at the right side of the road, that is in positive t-direction. That means, the elements start with negative t-values.

XML example

<lateralProfile>
    <shape  s="0.0000000000000000e+00"
            t="-4.0000000000000000e+00"
            a="0.0000000000000000e+00"
            b="0.0000000000000000e+00"
            c="0.0000000000000000e+00"
            d="0.0000000000000000e+00"/>
    <shape  s="0.0000000000000000e+00"
            t="-3.0000000000000000e+00"
            a="0.0000000000000000e+00"
            b="1.4999999999999999e-01"
            c="0.0000000000000000e+00"
            d="0.0000000000000000e+00"/>
    <shape  s="0.0000000000000000e+00"
            t="0.0000000000000000e+00"
            a="4.5000000000000001e-01"
            b="-1.0000000000000001e-01"
            c="0.0000000000000000e+00"
            d="0.0000000000000000e+00"/>
    <shape  s="0.0000000000000000e+00"
            t="4.0000000000000000e+00"
            a="5.0000000000000003e-02"
            b="0.0000000000000000e+00"
            c="0.0000000000000000e+00"
            d="0.0000000000000000e+00"/>
</lateralProfile>

9. Lanes

In ASAM OpenDRIVE, all roads contain lanes. The minimum road definition requires a center lane and an additional lane with a defined width. The number of lanes per road is not limited.

The center lane has no width and serves as reference for lane numbering. The center lane itself has the lane id 0. The numbering of the other lanes starts at the center lane: Lane numbers descend to the right, meaning negative t-direction, and ascend to the left, meaning positive t-direction.

Figure 52 illustrates the center lane for a road with multiple traffic lanes and different driving directions. In this case, the center lane separates the driving directions, depending on left- and right-hand traffic, specified in Road type. Because no lane offset is used, the center lane is identical to the road reference line.

Figure 52. Center lane for road with lanes of different driving directions

Figure 53 illustrates the center lane for a road with lanes that have the same driving direction, meaning a one-way road.

Figure 53. Center lane for road with lanes of identical driving direction

In ASAM OpenDRIVE, lanes are represented by the <lanes> element within a <road> element.

Figure 54. UML model for lanes

Rules

The following rules apply for the use of lanes:

Each road shall have a center lane and one lane with a width larger than 0.
Roads may have as many lanes as needed.
The center lane shall have no width, meaning that the <width> element shall not be used for the center lane.
The center lane shall have the lane id 0.
Lane numbering shall start with 1 next to the center lane, descend in negative t-direction and ascend in positive t-direction.
Lane numbering shall be consecutive without any gaps.
Lane numbering shall be unique per lane section.
There may be bidirectional lanes. This is specified using the @type attribute of the <lane> element.
Each <lanes> element shall contain at least one <laneSection> element.
The first <laneSection> element shall contain the @s attribute. For this @s attribute a value of 0.0 shall be defined for the start position of the first lane section.

XML example

<lanes>
    <laneSection s="0.0">
        <left>
            <lane id="2" type="border" level="false">
                <link>
                </link>
                <width sOffset="0.0" a="1.0" b="0.0" c="0.0" d="0.0"/>
            </lane>
            <lane id="1" type="driving" level="false">
                <link>
                </link>
                <width sOffset="0.0" a="4.0" b="0.0" c="0.0" d="0.0"/>
            </lane>
        </left>
        <center>
            <lane id="0" type="none" level="false">
                <link>
                </link>
            </lane>
        </center>
        <right>
            <lane id="-1" type="driving" level="false">
                <link>
                </link>
                <width sOffset="0.0" a="4.0" b="0.0" c="0.0" d="0.0"/>
            </lane>
            <lane id="-2" type="border" level="false">
                <link>
                </link>
                <width sOffset="0.0" a="1.0" b="0.0" c="0.0" d="0.0"/>
            </lane>
        </right>
    </laneSection>
</lanes>

Related topics

Lane grouping within lane sections

9.1. Lane grouping within lane sections

For easier navigation through an ASAM OpenDRIVE road description, the lanes within a lane section are grouped into left, center, and right lanes. Within these groups, the lanes are described by <lane> elements. Because lane numbers descend in negative t-direction and ascend in positive t-direction, applications can derive the direction of a lane from the lane id given in the ID attribute, unless @type is bi-directional.

Figure 55. Lane grouping with left, center, right

In ASAM OpenDRIVE, lane groups are represented by <center>, <right> and <left> elements within the <laneSection> element. The ID attribute is defined within the <lane> element that is nested under a <center>, <right>, or <left> element.

Rules

The following rules apply for lane grouping:

Lanes with positive ID run on the left side of the center lane, while lanes with negative ID run on the right side of the center lane.
Each lane section shall contain at least one <right> or <left> element.
One <center> element shall be defined for each s-coordinate.
Each lane section may contain one <center> element.
For better orientation, lanes should be listed from left to right, that is with descending ID.

Related topics

Lane sections
Lanes

9.2. Lane sections

Lanes may be split into multiple lane sections. Each lane section contains a fixed number of lanes. Every time the number of lanes changes, a new lane section is required, as shown in Figure 56. Lane sections are defined in ascending order along the road reference line.

Figure 56 shows a road section that is divided into different lane sections. A new lane section is required when the number of lanes changes.

Figure 56. A road section with lane sections

To simplify the use of lane sections for complex roads, they may be defined for one side of the road only using the @singleSide attribute. This principle is shown in Figure 57.

Figure 57. Lane sections defined separately for both sides of the road

In ASAM OpenDRIVE, lane sections are represented by <laneSection> elements within a <lanes> element.

Elements in UML model

t_road_lanes_laneSection

Lanes may be split into multiple lane sections. Each lane section contains a fixed number of lanes. Every time the number of lanes changes, a new lane section is required. The distance between two succeeding lane sections shall not be zero.

Table 22. Attributes of the road lanes laneSection element
Name	Type	Unit	Description
`s`	t_grEqZero	m	s-coordinate of start position
`singleSide`	t_bool		Lane section element is valid for one side only (left, center, or right), depending on the child elements.

t_road_lanes_laneSection_center

For easier navigation through an ASAM OpenDRIVE road description, the lanes within a lane section are grouped into left, center, and right lanes. Each lane section shall contain one <center> element and at least one <right> or <left> element.

t_road_lanes_laneSection_center_lane

Lane elements are included in left/center/right elements. Lane elements should represent the lanes from left to right, that is, with descending ID.

Table 23. Attributes of the road lanes laneSection center lane element
Name	Type	Unit	Description
`id`	integer		ID of the lane

t_road_lanes_laneSection_left

For easier navigation through an ASAM OpenDRIVE road description, the lanes within a lane section are grouped into left, center, and right lanes. Each lane section shall contain one <center> element and at least one <right> or <left> element.

t_road_lanes_laneSection_left_lane

Lane elements are included in left/center/right elements. Lane elements should represent the lanes from left to right, that is, with descending ID.

Table 24. Attributes of the road lanes laneSection left lane element
Name	Type	Unit	Description
`id`	positiveInteger		ID of the lane

t_road_lanes_laneSection_right

For easier navigation through an ASAM OpenDRIVE road description, the lanes within a lane section are grouped into left, center, and right lanes. Each lane section shall contain one <center> element and at least one <right> or <left> element.

t_road_lanes_laneSection_right_lane

Lane elements are included in left/center/right elements. Lane elements should represent the lanes from left to right, that is, with descending ID.

Table 25. Attributes of the road lanes laneSection right lane element
Name	Type	Unit	Description
`id`	negativeInteger		ID of the lane

Rules

The following rules apply for lane sections:

Each road shall have at least one lane section.
<laneSection> elements shall be defined in ascending order according to the s-coordinate.
The length of lane sections shall be greater than zero.
There shall always be exactly one center lane at each s-position.
Using lanes with a width of 0 for long distances should be avoided.
A new lane section shall be defined each time the number of lanes change.
A lane section shall remain valid until a new lane section is defined.
The properties of lanes inside a lane section may be changed as often as needed.
Lane sections may be defined for one side of the road only using the @singleSide attribute.

Related topics

Lanes
Lane grouping within lane sections
Road reference line

9.3. Lane offset

A lane offset may be used to shift the center lane away from the road reference line. This makes it easier to model local lateral shifts of lanes on roads, for example for left turn lanes.

A combination of lane offset and shape definition can lead to inconsistencies depending on the interpolation used for lane offset. Because linear interpolation is used for the road shape along the reference line, linear interpolation should also be used for the offset definition to enable consistent combined use of both definitions.

Figure 58 shows the offset of the center lane away from the road reference line.

Figure 58. Lane offset

In ASAM OpenDRIVE, a lane offset is represented by a <laneOffset> element within a <lanes> element.

Elements in UML model

t_road_lanes_laneOffset

A lane offset may be used to shift the center lane away from the road reference line.

Table 26. Attributes of the road lanes laneOffset element
Name	Type	Unit	Description
`a`	double	m	Polynom parameter a, offset at @s (ds=0)
`b`	double	1	Polynom parameter b
`c`	double	1/m	Polynom parameter c
`d`	double	1/m²	Polynom parameter d
`s`	t_grEqZero	m	s-coordinate of start position

Calculation

The offset at a given point is calculated with the following polynomial function of the third order:

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

where

offset

is the lateral offset at a given position

a, b, c, d

are the coefficients

ds

is the distance along the road reference line between the start of a new lane offset element and the given position

ds restarts at zero for each element. The absolute position of an offset 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

A new lane offset element is required each time the polynomial function changes.

XML Example

<lanes>
     <laneOffset s="25.0" a="0.0" b="0.0" c="3.9e-03" d="-5.2e-05"/>
     <laneOffset s="75.0" a="3.25" b="0.0" c="0.0" d="0.0"/>
     …
</lanes>

This example can be found in Ex_Simple-LaneOffset.xodr.

Rules

The following rules apply for lane offsets:

Lane offsets shall not be used together with road shapes.
<laneOffset> elements shall be defined in ascending order according to the s-coordinate.
A new lane offset shall start when the underlying polynomial function changes.
There shall be no offset if border definitions are present.

Related topics

Lane borders
Shape definition
Lanes

9.4. Lane linkage

To enable lane navigation, linkage information for lanes may be stored in ASAM OpenDRIVE. Linkage is described by means of <predecessor> and <successor> information for each lane. Lanes may be linked to lanes on the same or another road. A <predecessor> of a given lane is a lane connected to the start of its lane section in its reference line direction. A <successor> of a given lane is a lane connected to the end of its lane section in reference line direction. A lane linkage by a <predecessor> and a <successor> is independent of the driving direction.

Figure 59. Lane links for road with id 10

Table 27. Lane predecessors and successors for road with id 10
Considered road	Lane predecessor	Lane successor
Road 10 with lane id 1	Lane id 1 (Road 30)	Lane id -1 (Road 20)
Road 10 with lane id -1	Lane id -1 (Road 30)	Lane id 1 (Road 20)
Road 10 with lane id -2	Lane id -2 (Road 30)	Lane id 2 (Road 20)

Lane predecessors and successors shall only be used to connect lanes if a physical connection at the beginning or end of both lanes exist. Both lanes have a non-zero width at the connection point and they are semantically connected.

Examples where lane linkage should be used:

a lane that continues across the lane sections shall be connected in both directions
a lane changes its type on a highway from exit to offramp
a parking lane at the roadside ends, the road starts and a vehicle can continue driving from the parking lane on the driving lane

Example where lane linkage should not be used:

a parking lane at the roadside ends and a grass strip begins

Examples where multiple predecessors and successors shall be used:

a bikeway ends and bicycles are expected to continue driving on the driving lane

Figure 60. Example where a bikeway ends and bicycles are expected to continue driving on the driving lane

a driving lane splits into two or more driving lanes abruptly with non-zero width

Figure 61. Example where a driving lane splits into two or more driving lanes abruptly

Example where multiple predecessors and successors shall not be used:

if a new lane appears besides, only the continuing lane shall be connected to the original lane, not the appearing lane

In ASAM OpenDRIVE, lane linkage is represented by the <link> element within the <lane> element. The <predecessor> and <successor> elements are defined within the <link> element.

Figure 62. UML Model t_road_lanes_laneSection_lcr_lane_link

Elements in UML model

t_road_lanes_laneSection_lcr_lane_link

For links between lanes with an identical reference line, the lane predecessor and successor information provide the IDs of lanes on the preceding or following lane section.

For links between lanes with different reference line, the lane predecessor and successor information provide the IDs of lanes on the first or last lane section of the other reference line depending on the contact point of the road linkage.

This element may only be omitted, if lanes end at a junction or have no physical link.

t_road_lanes_laneSection_lcr_lane_link_predecessorSuccessor

Table 28. Attributes of the road lanes laneSection lcr lane link predecessorSuccessor element
Name	Type	Unit	Description
`id`	integer		ID of the preceding / succeeding linked lane

Rules

The following rules apply to lane linkage:

A lane may have another lane as predecessor or successor.
Two lanes shall only be linked if their linkage is clear. If the relationship to a predecessor or successor is ambiguous, junctions shall be used.
Multiple predecessors and successors shall be used if a lane is split abruptly or several lanes are merged abruptly. All lanes that are connected shall have a non-zero width at the connection point.
Lanes that have a width of zero at the beginning of the lane section shall have no <predecessor> element.
Lanes that have a width of zero at the end of the lane section shall have no <successor> element.
The <link> element shall be omitted if the lane starts or ends in a junction or has no link.

Related topics

Road linkage
Junctions
Lanes

9.5. Lane properties

Lane properties describe the use and shape of lanes. Lane properties are defined per lane section but may change within that section. If a property is not specifically defined for a lane section, applications can apply default properties.

Figure 63. UML model lane properties

Examples of lane properties are lane width, lane border, and speed limits.

Rules

The following rules apply for lane properties:

Lane properties shall be defined relative to the start of the corresponding lane section.
A specific lane property shall remain valid until another lane property of that type is defined or the lane section ends.
Lane properties of identical types shall be defined in ascending order.

9.5.1. Lane width

Elements in UML model

t_road_lanes_laneSection_lr_lane_width

The width of a lane is defined along the t-coordinate. The width of a lane may change within a lane section.

Lane width and lane border elements are mutually exclusive within the same lane group. If both width and lane border elements are present for a lane section in the ASAM OpenDRIVE file, the application must use the information from the <width> elements.

In ASAM OpenDRIVE, lane width is described by the <width> element within the <lane> element.

Table 29. Attributes of the road lanes laneSection lr lane width element
Name	Type	Unit	Description
`a`	double	m	Polynom parameter a, width at @s (ds=0)
`b`	double	1	Polynom parameter b
`c`	double	1/m	Polynom parameter c
`d`	double	1/m²	Polynom parameter d
`sOffset`	t_grEqZero	m	s-coordinate of start position of the `<width>` element, relative to the position of the preceding `<laneSection>` element

Calculation

The width at a given point is calculated with the following polynomial function of the third order:

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

where

width

is the width at a given position

a, b, c, d

are the coefficients

ds

is the distance along the road reference line between the start of a new lane width element and the given position

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

s = s_section + offset_start + ds

where

s

is the absolute position in the reference line coordinate system

s_Section

is the start position of the preceding lane section element in the track coordinate system

offset_Start

is the offset of the element relative to the preceding lane section

Figure 64 shows the change in lane width in positive s-direction, starting at different offset positions.

Figure 64. Change of lane width per lane section

XML Example

See the sample file Ex_Lane-Width.xodr

Rules

The following rules apply to lane width:

The width of a lane shall be defined at least once per lane section.
The width of the lane shall be defined for the full length of the lane section. This means that there must be a <width> element for s=0.
The center lane shall have no width, meaning that the <width> element shall not be used for the center lane.
The width of a lane shall remain valid until a new width element is defined or the lane section ends.
A new width element shall be defined when the variables of the polynomial function change.
Width elements shall not be used together with border elements in the same lane group.
<width> elements shall be defined in ascending order according to the s-coordinate.
Width (ds) shall be greater than or equal to zero.

Related topics

Lane sections
Lane grouping within lane sections
Superelevation
Shape definition

9.5.2. Lane borders

Elements in UML model

t_road_lanes_laneSection_lr_lane_border

Lane borders are another method to describe the width of lanes. Instead of defining the width directly, lane borders describe the outer limits of a lane, independent of the parameters of their inner borders. In this case, inner lanes are defined as lanes which have the same sign for their ID as the lane currently defined, but with a smaller absolute value for their ID.

Especially when road data is derived from automatic measurements, this type of definition is easier than specifying the lane width because it avoids creating many lane sections.

Lane width and lane border elements are mutually exclusive within the same lane group. If both width and lane border elements are present for a lane section in the ASAM OpenDRIVE file, the application shall use the information from the <width> elements.

In ASAM OpenDRIVE, lane borders are represented by the <border> element within the <lane> element.

Table 30. Attributes of the road lanes laneSection lr lane border element
Name	Type	Unit	Description
`a`	double	m	Polynom parameter a, border position at @s (ds=0)
`b`	double	1	Polynom parameter b
`c`	double	1/m	Polynom parameter c
`d`	double	1/m²	Polynom parameter d
`sOffset`	t_grEqZero	m	s-coordinate of start position of the `<border>` element , relative to the position of the preceding `<laneSection>` element

Calculation

The border position at a given point is calculated with the following polynomial function of the third order:

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

where

t_border

is the t-position of the border at a given ds-position

a, b, c, d

are the coefficients

ds

is the distance along the road reference line between the start of the element and the given position

ds restarts at zero for each element. The absolute position of a border offset value is calculated by

s = s_Section + offset_start+ ds

where

s

is the absolute position in the reference line coordinate system

s_Section

is the start position of the preceding lane section element in the track coordinate system

offset_Start

is the offset of the element relative to the preceding lane section element

Figure 65 illustrates this convention for a lane with varying border shape over a given range:

Figure 65. Lane with varying border shape

XML Example

See the sample file Ex_Lane-Border.xodr

Rules

The following rules apply to lane borders:

Width elements shall not be used together with border elements in the same lane group.
Border elements shall not exist together with lane offset.
A new border element shall be defined when the variables of the polynomial function change.
<border> elements shall be defined in ascending order according to the s-coordinate.
Lane borders shall not intersect inner lanes.

Related topics

Lane sections
Lane grouping within lane sections

9.5.3. Lane type

The lane type is defined per lane. A lane type defines the main purpose of a lane and its corresponding traffic rules.

The available lane types are:

shoulder: Describes a soft border at the edge of the road.
border: Describes a hard border at the edge of the road. It has the same height as the drivable lane.
driving: Describes a "normal" drivable road that is not one of the other types.
stop: Hard shoulder on motorways for emergency stops
none: Describes the space on the outermost edge of the road and does not have actual content Its only purpose is for applications to register that ASAM OpenDRIVE is still present in case the (human) driver leaves the road.
restricted: Describes a lane on which cars should not drive. The lane has the same height as drivable lanes. Typically, the lane is separated with lines and often contains dotted lines as well.
parking: Describes a lane with parking spaces.
median: Describes a lane that sits between driving lanes that lead in opposite directions. It is typically used to separate traffic in towns on large roads.
biking: Describes a lane that is reserved for cyclists.
sidewalk: Describes a lane on which pedestrians can walk.
curb: Describes curb stones. Curb stones have a different height than the adjacent drivable lanes.
exit: Describes a lane that is used for sections that are parallel to the main road. It is mainly used for deceleration lanes.
entry: Describes a lane type that is used for sections that are parallel to the main road. It is mainly used for acceleration lanes.
onramp: A ramp leading to a motorway from rural or urban roads.
offRamp: A ramp leading away from a motorway and onto rural urban roads.
connectingRamp: A ramp that connects two motorways, for example, motorway junctions.

For the use of the lane types, see Figure 66 to Figure 70.

Figure 66. Lane types for a motorway

Figure 67. Lane types for a rural road

Figure 68. Lane types for an urban road

Figure 69. Lane types for motorway exit and entry

Figure 70. Lane types for motorway connecting to another motorway

In ASAM OpenDRIVE, lane types are represented by the attribute @type element within the <lane> element.

Elements in UML model

t_road_lanes_laneSection_lr_lane

Lane elements are included in left/center/right elements. Lane elements should represent the lanes from left to right, that is, with descending ID.

Table 31. Attributes of the road lanes laneSection lr lane element
Name	Type	Unit	Description
`level`	t_bool		"true" = keep lane on level, that is, do not apply superelevation; "false" = apply superelevation to this lane (default, also used if attribute level is missing)
`type`	e_laneType		Type of the lane

Rules

The following rules apply to lane types:

The lane type may be changed as often as needed by using a new lane section.

Related topics

Lanes

9.5.4. Lane material

ASAM OpenDRIVE provides an element to store information on the material of lanes (apart from ASAM OpenCRG), meaning their surface, friction properties, and roughness. If no material is defined, applications can apply default values.

In ASAM OpenDRIVE, lane material is represented by the <material> element within the <lane> element.

Elements in UML model

t_road_lanes_laneSection_lr_lane_material

Stores information about the material of lanes. Each element is valid until a new element is defined. If multiple elements are defined, they must be listed in ascending order.

Table 32. Attributes of the road lanes laneSection lr lane material element
Name	Type	Unit	Description
`friction`	t_grEqZero		Friction coefficient
`roughness`	t_grEqZero		Roughness, for example, for sound and motion systems
`sOffset`	t_grEqZero	m	s-coordinate of start position, relative to the position of the preceding `<laneSection>` element
`surface`	string		Surface material code, depending on application

Rules

The following rules apply to lane material:

The center lane shall have no material elements.
The material elements of a lane shall remain valid until another material element starts or the lane section ends.
<material> elements shall be defined in ascending order according to the s-coordinate.

Related topics

Lanes
Lane sections
Lane grouping within lane sections

9.5.5. Lane speed limit

The maximum speed allowed on a lane may be defined. Lane speed limits overrides road speed limits.

Figure 71. Lane-specific speed limits

In ASAM OpenDRIVE, lane speed is represented by the <speed> element within the <lane> element.

Elements in UML model

t_road_lanes_laneSection_lr_lane_speed

Defines the maximum allowed speed on a given lane. Each element is valid in direction of the increasing s-coordinate until a new element is defined.

Table 33. Attributes of the road lanes laneSection lr lane speed element
Name	Type	Unit	Description
`max`	t_grEqZero		Maximum allowed speed. If the attribute unit is not specified, m/s is used as default.
`sOffset`	t_grEqZero	m	s-coordinate of start position, relative to the position of the preceding `<laneSection>` element
`unit`	e_unitSpeed		Unit of the attribute max

XML example

<lane id="-1" type="driving" level="false">
    <link>
        <successor id="-3"/>
    </link>
    <width sOffset="0.0" a="2.0" b="0.0" c="0.0" d="0.0"/>
    <speed sOffset="0.0" max="80.0" unit="km/h"/>
    <height sOffset="0.0" inner="0.12" outer="0.12"/>
</lane>

Rules

The following rules apply to lane speed limits:

The center lane shall have no speed limit.
The speed limit of a lane shall remain valid until another speed limit is defined or the lane section ends.
<speed> elements shall be defined in ascending order according to the s-coordinate.
Speed limits derived from signals shall always have preference.

Related topics

Lanes
Signals
Speed limits for road types

9.5.6. Lane access

Lanes can be restricted to specific road users, such as trucks or buses. Such restrictions may be defined in ASAM OpenDRIVE in addition to restrictions described by signals.

Figure 72. Lane access, bus lane

ASAM OpenDRIVE provides the <access> element within the <lane> element to describe lane access rules.

Elements in UML model

t_road_lanes_laneSection_lr_lane_access

Defines access restrictions for certain types of road users.

Each element is valid in direction of the increasing s coordinate until a new element is defined. If multiple elements are defined, they shall be listed in ascending order.

Table 34. Attributes of the road lanes laneSection lr lane access element
Name	Type	Unit	Description
`restriction`	e_accessRestrictionType		Identifier of the participant to whom the restriction applies
`rule`	e_road_lanes_laneSection_lr_lane_access_rule		Specifies whether the participant given in the attribute @restriction is allowed or denied access to the given lane
`sOffset`	t_grEqZero	m	s-coordinate of start position, relative to the position of the preceding `<laneSection>` element

XML Example

<lane id="2" type="driving" level="false">
    <link>
        <successor id="2"/>
    </link>
    <width sOffset="0.0" a="2.0" b="0.0" c="0.0" d="0.0"/>
    <access sOffset="0.0" rule="allow" restriction="bus"/>
</lane>

Rules

The following rules apply to lane access rules:

The center lane shall have no access rules.
The access rules of a lane shall remain valid until another access rule is defined or the lane section ends.
<access> elements shall be defined in ascending order according to the s-coordinate.
Lane access elements may start at identical offset positions.
If no <access> element is present within a lane element, then there are no restrictions.
If deny value is present in the <rule> element, all other vehicles are still allowed.
If allow value is present in the <rule> element, all other vehicles are banned.
At a given s-position, either only deny or only allow values shall be given, not mixed.
For a new s-position, all restrictions must be defined again, even if only a subset changes.
The restriction deny=none is used to revert all previous restrictions.

Related topics

Lanes
Lane sections

9.5.7. Lane height

Lane height shall be defined along the h-coordinate. Lane height may be used to elevate a lane independent from the road elevation. Lane height is used to implement small-scale elevation such as raising pedestrian walkways, as shown in Figure 73. Lane height is specified as offset from the road (including elevation, superelevation, shape) in z direction.

Figure 73. Lane height

In ASAM OpenDRIVE, lane height is represented by the <height> element within the <lane> element.

Elements in UML model

t_road_lanes_laneSection_lr_lane_height

Lane height shall be defined along the h-coordinate. Lane height may be used to elevate a lane independent from the road elevation. Lane height is used to implement small-scale elevation such as raising pedestrian walkways. Lane height is specified as offset from the road (including elevation, superelevation, shape) in z direction.

Table 35. Attributes of the road lanes laneSection lr lane height element
Name	Type	Unit	Description
`inner`	double	m	Inner offset from road level
`outer`	double	m	Outer offset from road level
`sOffset`	t_grEqZero	m	s-coordinate of start position, relative to the position of the preceding `<laneSection>` element

XML example

<lane id="-2" type="sidewalk" level="false">
    <link>
        <successor id="-3"/>
    </link>
    <width sOffset="0.0" a="2.0" b="0.0" c="0.0" d="0.0"/>
    <height sOffset="0.0" inner="0.12" outer="0.12"/>
</lane>

Rules

The following rules apply to lane height:

To modify the lane height, for example for curbstones, the <height> element shall be used.
<height> elements shall be defined in ascending order according to the s-coordinate.
The center lane shall not be elevated by lane height.
Lane height shall not be used to define road elevation or superelevation.
Lane height shall be used for small scale elevation only.

Related topics

Road elevation
Lanes
Lane grouping within lane sections

9.5.8. Excluding lanes from road superelevation

Single lanes may be excluded from superelevation to cover use cases like roads with curbstones, borders, or sidewalks without superelevation.

Figure 74 shows the use of the attribute @level, which excludes the outermost lanes of a road from superelevation.

Figure 74. Lanes excluded from road elevation

ASAM OpenDRIVE provides the attribute @level for excluding lanes from road superelevation. When the attribute is set to TRUE for a lane, then this lane is excluded from both superelevation and road shape definition of the road. The elevation of the lane stays on the same height as the inner connecting lane.

There may be multiple outer lanes with level=TRUE, for example, for a bike lane followed by a sidewalk.

Rules

The following rules apply for excluding lanes from road elevation:

If a lane has @level = TRUE, then at least on one side there shall be only lanes with @level = TRUE until the edge of the road is reached.
There may be multiple outer lanes with @level = TRUE.

Related topics

Superelevation
Lane type

9.6. Road markings

Lanes on roads can have different lane markings, for example lines of different colors and styles. ASAM OpenDRIVE provides the <roadMark> element for road markings. The road mark information defines the style of the line at the lane’s outer border. For left lanes, this is the left border, for right lanes the right one. The style of the center line that separates left and right lanes is determined by the road mark element for the center lane.

For each lane within a road cross section, multiple road mark elements may be defined. Several attributes may be used to describe the properties of the lane markings, for example @type, @weight, and @width.

There are two ways to specify the type of road marking:

The @type attribute within the <roadMark> element allows to enter keywords that are stored in the application. They are used to describe simplified road marking types like solid, broken, or grass.
The <type> element contains further <line> elements that allows to describe the road marking in a more detailed way.

In ASAM OpenDRIVE, road markings are represented by <roadMark> elements within <lane> elements.

Figure 75. UML model t_road_lanes_laneSection_lcr_lane_roadMark

Elements in UML model

t_road_lanes_laneSection_lcr_lane_roadMark_type

Each type definition shall contain one or more line definitions with additional information about the lines that the road mark is composed of.

Table 36. Attributes of the road lanes laneSection lcr lane roadMark type element
Name	Type	Unit	Description
`name`	string		Name of the road mark type. May be chosen freely.
`width`	t_grZero	m	Accumulated width of the road mark. In case of several `<line>` elements this @width is the sum of all @width of `<line>` elements and spaces in between, necessary to form the road mark. This attribute supersedes the definition in the `<roadMark>` element.

t_road_lanes_laneSection_lcr_lane_roadMark_type_line

A road mark may consist of one or more elements. Multiple elements are usually positioned side-by-side. A line definition is valid for a given length of the lane and will be repeated automatically.

Table 37. Attributes of the road lanes laneSection lcr lane roadMark type line element
Name	Type	Unit	Description
`color`	e_roadMarkColor		Line color. If given, this attribute supersedes the definition in the `<roadMark>` element.
`length`	t_grEqZero	m	Length of the visible part
`rule`	e_roadMarkRule		Rule that must be observed when passing the line from inside, for example, from the lane with the lower absolute ID to the lane with the higher absolute ID
`sOffset`	t_grEqZero	m	Initial longitudinal offset of the line definition from the start of the road mark definition
`space`	t_grEqZero	m	Length of the gap between the visible parts
`tOffset`	double	m	Lateral offset from the lane border. If `<sway>` element is present, the lateral offset follows the sway.
`width`	t_grZero	m	Line width

Rules

The following rules apply to road markings:

<roadMark> elements shall only be used to describe the outer lane marking.
<roadMark> elements shall be defined in ascending order according to the s-coordinate.
The centerline of the lane marking shall be positioned on the lane’s outer border line in such a way that the outer half of the lane marking is physically placed on the next lane.

Related topics

Road marking types and lines
Explicit road marking types and lines
Offsets in road marking

9.6.1. Road marking types and lines

Detailed information about road marking types and lines may be defined in <type> elements within the <roadMark> element. Each <type> definition contains one or more <line> definitions with additional information about the lines of the road marking.

Road marking information in the <type> element is more specific than the information given in the @type attribute within the <roadMark> element.

The outline of the road marking is described by the attributes @length and @space:

@length represents the visible part of the line.
@space describes the non-visible part.

The position of the road marking in relation to the reference line may be described by defining the lateral offset. A line definition is valid for a given length of the lane and will be repeated automatically. The optional @rule attribute for lines defines the traffic rule for passing the lane from the inside. In ASAM OpenDRIVE, road marking types and lines are represented by <type> elements within <roadmark> elements. The line definitions are contained in <line> elements within the <type> element.

Elements in UML model

t_road_lanes_laneSection_lcr_lane_roadMark

Defines the style of the line at the outer border of a lane. The style of the center line that separates left and right lanes is determined by the road mark element for the center lane.

Table 38. Attributes of the road lanes laneSection lcr lane roadMark element
Name	Type	Unit	Description
`color`	e_roadMarkColor		Color of the road mark
`height`	t_grZero	m	Height of road mark above the road, i.e. thickness of the road mark
`laneChange`	e_road_lanes_laneSection_lcr_lane_roadMark_laneChange		Allows a lane change in the indicated direction, taking into account that lanes are numbered in ascending order from right to left. If the attribute is missing, “both” is used as default.
`material`	string		Material of the road mark. Identifiers to be defined by the user, use "standard" as default value.
`sOffset`	t_grEqZero	m	s-coordinate of start position of the `<roadMark>` element, relative to the position of the preceding `<laneSection>` element
`type`	e_roadMarkType		Type of the road mark
`weight`	e_roadMarkWeight		Weight of the road mark. This attribute is optional if detailed definition is given below.
`width`	t_grEqZero	m	Width of the road mark. This attribute is optional if detailed definition is given by `<line>` element.

Related topics

Road markings
Explicit road marking types and lines
Offsets in road marking

9.6.2. Explicit road marking types and lines

Elements in UML model

t_road_lanes_laneSection_lcr_lane_roadMark_explicit

Irregular road markings that cannot be described by repetitive line patterns may be described by individual road marking elements. These explicit definitions also contain <line> elements for the line definition, however, these lines will not be repeated automatically as in repetitive road marking types. In ASAM OpenDRIVE, irregular road marking types and lines are represented by <explicit> elements within elements. The line definitions are contained in <line> elements within the <explicit> element.

The <explicit> element should specifically be used for measurement data.

t_road_lanes_laneSection_lcr_lane_roadMark_explicit_line

Specifies a single line in an explicit road mark definition.

Table 39. Attributes of the road lanes laneSection lcr lane roadMark explicit line element
Name	Type	Unit	Description
`length`	t_grZero	m	Length of the visible line
`rule`	e_roadMarkRule		Rule that must be observed when passing the line from inside, that is, from the lane with the lower absolute ID to the lane with the higher absolute ID
`sOffset`	t_grEqZero	m	Offset of start position of the `<line>` element, relative to the @sOffset given in the `<roadMark>` element
`tOffset`	double	m	Lateral offset from the lane border. If `<sway>` element is present, the lateral offset follows the sway.
`width`	t_grZero	m	Line width. This attribute supersedes the definition in the `<roadMark>` element.

Related topics

Road markings
Road marking types and lines
Offsets in road marking

9.6.3. Offset in road markings

To describe lane markings that are not straight, but have sideway curves, <sway> elements may be used. A <sway> element relocates the lateral reference position for the following (explicit) type definition and thus defines an offset. The sway offset is relative to the nominal reference position of the lane marking, meaning the lane border.

The main use case for sways are roads leading through construction sites. The driving lanes are between the yellow lines. The white lines are swayed and only markings.

Figure 76. Road marking with sway and offset

Offsets from the lateral reference position are defined by <sway> elements within the <roadMark> element.

Elements in UML model

t_road_lanes_laneSection_lcr_lane_roadMark_sway

Relocates the lateral reference position for the following (explicit) type definition and thus defines an offset. The sway offset is relative to the nominal reference position of the lane marking, meaning the lane border.

Table 40. Attributes of the road lanes laneSection lcr lane roadMark sway element
Name	Type	Unit	Description
`a`	double	m	Polynom parameter a, sway value at @s (ds=0)
`b`	double	1	Polynom parameter b
`c`	double	1/m	Polynom parameter c
`d`	double	1/m²	Polynom parameter d
`ds`	t_grEqZero	m	s-coordinate of start position of the `<sway>` element, relative to the @sOffset given in the `<roadMark>` element

Calculation

For the definition of sways, the lateral reference position at a given point is calculated with the following polynomial function of the third order:

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

where

tOffset

is the lateral offset of the lateral reference position from the lane border at a given ds position

a, b, c, d

are the coefficients

ds

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

ds rds starts at zero for each element and is relative to the sOffset value given in the <roadMark> element.

Related topics

Road markings
Road marking types and lines
Explicit road marking types and lines

9.7. Specific lane rules

It is possible to define special rules for certain lanes that are not specifically defined in the ASAM OpenDRIVE standard and will be stored in the used application. In ASAM OpenDRIVE, a lane rule is represented by the <rule> element within the <lane> element.

Elements in UML model

t_road_lanes_laneSection_lr_lane_rule

Used to add rules that are not covered by any of the other lane attributes that are described in this specification.

Table 41. Attributes of the road lanes laneSection lr lane rule element
Name	Type	Unit	Description
`sOffset`	t_grEqZero	m	s-coordinate of start position, relative to the position of the preceding `<laneSection>` element
`value`	string		Free text; currently recommended values are "no stopping at any time" "disabled parking" "car pool"

Rules

The following rules apply to lane rule:

Applications may have specific lane rules that are only valid in the respective application, but not in ASAM OpenDRIVE.
<rule> elements shall be defined in ascending order according to the s-coordinate.

Related topics

Lanes

10. Junctions

Junctions enable the connection of more than two roads.

Three types of junctions exist:

Common junctions are junctions with drivable lanes that can overlap.
Direct junctions are junctions with non-overlapping linking roads.
Virtual junctions are junctions where the main road is not interrupted.

Table 42. Usage of the different types of junctions
Use case	Common junctions	Direct junctions	Virtual junctions
overlapping lanes	yes	no	no
junctions with traffic lights	yes	no	no
non overlapping entries and exits	yes (not recommended)	yes	no
overlapping entries and exits	yes	no	no
driveways to parking lots	yes	no	yes
driveways to residential estates	yes	no	yes
slip roads	yes	no	no

Rules

The following rules apply to junctions:

No junctions of any type shall overlap each other.
The <connection> element of a junction of @type ="direct" shall not have the @connectingRoad attribute.
The <connection> element of a junction of @type ="default" or @type="virtual" shall not have the @linkedRoad attribute.

10.1. Common junctions

Common junctions are junctions with drivable lanes that can overlap.

Figure 77. Types of roads in a junction (right-hand traffic)

Figure 77 shows two different kinds of roads with relation to junctions.

Incoming roads: These roads contain lanes that lead into a junction.
Connecting roads: These roads represent the paths through a junction.

In ASAM OpenDRIVE, junctions are represented by <junction> elements. Connecting roads are represented by <connection> elements within a <junction> element. Outgoing roads are not specifically defined as an element or attribute in ASAM OpenDRIVE. Incoming roads serve as outgoing roads. These roads are implicitly defined as outgoing by the connecting roads that lead into them.

Figure 78. UML model for junctions

Elements in UML model

t_junction

Contains information about all possible connections between roads meeting at a physical junction.

Table 43. Attributes of the junction element
Name	Type	Unit	Description
`id`	string		Unique ID within database
`mainRoad`	string		The main road from which the connecting roads of the virtual junction branch off. This attribute is mandatory for virtual junctions and shall not be specified for other junction types.
`name`	string		Name of the junction. May be chosen freely.
`orientation`	e_orientation		Defines the relevance of the virtual junction according to the driving direction. This attribute is mandatory for virtual junctions and shall not be specified for other junction types. The enumerator "none" specifies that the virtual junction is valid in both directions.
`sEnd`	t_grEqZero	m	End position of the virtual junction in the reference line coordinate system. This attribute is mandatory for virtual junctions and shall not be specified for other junction types.
`sStart`	t_grEqZero	m	Start position of the virtual junction in the reference line coordinate system. This attribute is mandatory for virtual junctions and shall not be specified for other junction types.
`type`	e_junction_type		Type of the junction. Common junctions are of type "default". This attribute is mandatory for virtual junctions and direct junctions. If the attribute is not specified, the junction type is "default".

Rules

The following rules apply to common junctions:

Junctions shall only be used when roads cannot be linked directly. They clarify ambiguities for the linking. Ambiguities are caused when a road has two or more possible predecessor or successor roads.
Unlike roads, junctions do not have a predecessor or successor.
A junction may have an own name to distinguish it from other junctions.
Junctions should not be used when only two roads meet.
The @mainRoad, @orientation, @sStart and @sEnd attributes shall only be specified for virtual junctions.

Related topics

Incoming roads
Connecting roads
Road linkage
Lane linkage

10.2. Incoming roads

Incoming roads contain lanes that lead into a junction. Because outgoing roads are not specifically defined in ASAM OpenDRIVE, incoming roads may also serve as outgoing roads, see Figure 77.

To specify a road as incoming road, its ID is referenced in the <connection> element using the @incomingRoad attribute.

Elements in UML model

t_junction_connection

Provides information about a single connection within a junction.

Table 44. Attributes of the junction connection element
Name	Type	Description
`connectingRoad`	string	ID of the connecting road
`contactPoint`	e_contactPoint	Contact point on the connecting road
`id`	string	Unique ID within the junction
`incomingRoad`	string	ID of the incoming road
`linkedRoad`	string	ID of the directly linked road. Only to be used for junctions of @type="direct".
`type`	e_connection_type	Type of the connection. Regular connections are @type=“default” . This attribute is mandatory for virtual connections.

t_junction_connection_laneLink

Provides information about the lanes that are linked between an incoming road and a connecting road. It is strongly recommended to provide this element. It is deprecated to omit the <laneLink> element.

Table 45. Attributes of the junction connection laneLink element
Name	Type	Unit	Description
`from`	integer		ID of the incoming lane
`to`	integer		ID of the connection lane

XML example

<junction name="myJunction" id="555" >
    <connection id="0"
        incomingRoad="1"
        connectingRoad="2"
        contactPoint="start">
        <laneLink from="-2" to="-1"/>
    </connection>

Rules

The following rules apply to incoming roads:

Connecting roads shall not be incoming roads.

Related topics

Connecting roads
Junctions
Road linkage

10.3. Connecting roads

Connecting roads link the roads that meet in a junction. They describe the paths that a vehicle can travel across a junction. Connecting roads are modeled in the same way as standard roads.

The paths described by a connecting road base on its lanes. The connecting road specifies the connections between the lanes of an incoming road and the lanes of an outgoing road of the same junction. If the lanes of an incoming and outgoing road are not linked, this means that there is no traversable path between these lanes.

Figure 79. Connecting roads of junction with id 1 (left hand traffic)

Figure 77 and Figure 79 show the connecting roads inside the junction area that connect the incoming and outgoing roads.

The example in the tables 42, 43 and 44 only considers how to cross the junction from the road with id 4.

Table 46. Junction with id 1
Connection id	Incoming road	Connecting road	Contact point	Lane link from	Lane link to
9	4	28	start
				-3	1
10	4	61	start
				-2	1
				-3	2
11	4	64	start
				-1	1

Table 47. Roads
Road id	Predecessor	Contact predecessor	Successor	Contact successor	Junction
1	junction with id 1				-1
2	junction with id 1				-1
3			junction with id 1		-1
4	junction with id 1				-1
28	road with id 4	start	road with id 2	start	1
61	road with id 4	start	road with id 3	end	1
64	road with id 4	start	road with id 1	start	1

Table 48. Lane links
Road id	Lane id	Predecessor’s lane id	Successor’s lane id
28	1	-3	3
61	1	-2	-2
61	2	-3	-3
64	1	-1	1
4	-3	no lane link
4	-2	no lane link
4	-1	no lane link
1	1	no lane link
3	-2		no lane link
3	-3		no lane link
2	3	no lane link

XML example

Ex_LHT-Complex-X-Junction.xodr (left hand traffic)
UC_Simple-X-Junction.xodr (right hand traffic)

Rules

The following rules apply to connecting roads:

Each connecting road shall be represented by exactly one <connection> element. A connecting road may contain as many lanes as required.
An incoming road with multiple lanes may be connected to the lanes of the road leading out off the junction in different ways:
- By multiple connecting roads, each with one <laneLink> element for the connection between two specific lanes. Lane changes within this junction are not possible.
- By one connecting road with multiple <laneLink> elements for the connections between the lanes. Lane changes within this junction are possible.
The linked lanes shall fit smoothly as described for roads (see Section 8.2).
The @connectingRoad attribute shall not be used for junctions with @type="direct".

Related topics

Incoming roads
Junctions
Road linkage
Lane linkage
Priorities of connecting roads within a junction
Lane access

10.3.1. Priorities of connecting roads within a junction

Elements in UML model

t_junction_priority

The junction priority record provides information about the priority of a connecting road over another connecting road. It is only required if priorities cannot be derived from signs or signals in a junction or on tracks leading to a junction.

Table 49. Attributes of the junction priority element
Name	Type	Unit	Description
`high`	string		ID of the prioritized connecting road
`low`	string		ID of the connecting road with lower priority

Rules

The following rules apply for priorities of connecting roads within a junction:

Priority elements should only be used if there are no signals defined.

Related topics

Connecting roads
Junctions

10.3.2. Direction of connecting roads

Connecting roads inside a junction may have different directions. For ease of use, the reference line of the connecting roads should be placed in driving direction if the driving direction is unique.

The attribute @contactPoint inside the <connection> element is used to specify the direction of a connecting road.

Rules

The following rules apply for the direction of connecting roads:

The value "start" shall be used to indicate that the connecting road runs along the linkage indicated in the <laneLink> element.
The value "end" shall be used to indicate that the connecting road runs along the opposite direction of the linkage indicated in the <laneLink> element.

Related topics

Connecting roads
Road type

10.4. Direct junctions

Roads that lead into a junction can directly be linked to roads that lead out of a junction. Direct junctions are intended to model entries and exits without adding additional connecting roads. This approach reduces the number of roads required to model entries and exits in comparison to the common junction modeling approach in Section 10.3.

Figure 80. Direct junctions

Figure 80 shows a road connected to two linked roads. Road 1 is directly linked to road 2 and 3.

XML example

The XML example shows the model that is displayed in Figure 80.

<road name="" length="50" id="1" junction="-1">
    <link>
        <successor elementType="junction" elementId="111"/>
    </link>
</road>
<road name="" length="50" id="2" junction="-1">
    <link>
        <predecessor elementType="junction" elementId="111" />
    </link>
</road>
<road name="" length="50" id="3" junction="-1">
    <link>
        <predecessor elementType="junction" elementId="111" />
    </link>
</road>
<junction name="" type="direct" id="111">
    <connection id="0" incomingRoad="1" linkedRoad="3" contactPoint="start">
        <laneLink from="-4" to="-1"/>
    </connection>
    <connection id="1" incomingRoad="1" linkedRoad="2" contactPoint="start">
        <laneLink from="1" to="1"/>
        <laneLink from="-1" to="-1"/>
        <laneLink from="-2" to="-2"/>
        <laneLink from="-3" to="-3"/>
    </connection>
</junction>

Figure 81. Cases when direct junctions cannot be modeled

Figure 81 shows one road connected to two following roads. Lane -3 of road 2 and lane -1 of road 3 overlap. Direct junctions cannot be used if lanes of entries or exits overlap with lanes of another road. In this case common junctions shall be used (see Section 10.1).

Elements in UML model

For elements in the UML model see Figure 78.

Rules

Direct junctions shall only be used for non-overlapping roads.
The @linkedRoad attribute shall only be used for junctions with @type="direct".
The @connectingRoad attribute shall not be used for junctions with @type="direct".
The linked lanes shall fit smoothly as described for roads (see Section 8.2).
The junction shall be placed where the headings of road and ramp are identical.

Related topics

Incoming roads
Road linkage
Lane linkage

10.5. Virtual junctions

Virtual junctions are junctions that describe connections within a road. Virtual junctions enable to create branches from a road without the need to interrupt the geometry of the road. Virtual junctions are intended as best practice for example for the following use cases:

modeling driveways
modeling entries and exits to parking lots
modeling entries and exits to farm roads

Figure 82. Example of a virtual junction showing a parking lot entry and exit

Figure 82 shows a virtual junction with three connecting roads 2, 4 and 5. The virtual junction connects road 1 with road 99. Road 1 serves as an incoming road for connecting road 2 at the @sStart position s=50m. Road 99 serves as incoming road for road 4 and road 5. Road 1 is successor for the two connecting roads 4 and 5 at @sEnd s=70m. The successor is specified in the road definition of the connecting roads.

Virtual junctions are modeled by <junction> elements with the attribute @type.

Elements in UML model

For elements in the UML model see Figure 78.

t_junction_predecessorSuccessor

Provides detailed information about the predecessor / successor road of a virtual connection. Currently, only the @elementType “road” is allowed.

Table 50. Attributes of the junction predecessorSuccessor element
Name	Type	Description
`elementDir`	e_elementDir	Direction, relative to the s-direction, of the connection on the preceding / succeding road
`elementId`	string	ID of the linked element
`elementS`	t_grEqZero	s-coordinate where the connection meets the preceding / succeding road.
`elementType`	string	Type of the linked element. Currently only "road" is allowed.

XML example

<road name="ConnectingRoad2" length="20" id="2" junction="555">
    <link>
        <predecessor elementType="road" elementId="1" elementS="50.0" elementDir="+"/>
        <successor elementType="road" elementId="99" contactPoint="end"/>
    </link>
    <laneSection s="0.0000000000000000e+00">
        <left/>
        <center/>
        <right>
            <lane id="-1" type="driving" level="false">
                <link>
                    <predecessor id="-2"/>
                    <successor id="1"/>
                </link>
            </lane>
        </right>
    </laneSection>
</road>
<road name="ConnectingRoad4" length="23" id="4" junction="555">
    <link>
        <predecessor elementType="road" elementId="99" contactPoint="end"/>
        <successor elementType="road" elementId="1" elementS="70.0" elementDir="+"/>
    </link>
    <laneSection s="0.0000000000000000e+00">
        <left/>
        <center/>
        <right>
            <lane id="-1" type="driving" level="false">
                <link>
                    <predecessor id="-1"/>
                    <successor id="-1"/>
                </link>
            </lane>
        </right>
    </laneSection>
</road>
<road name="ConnectingRoad5" length="20" id="5" junction="555">
    <link>
        <predecessor elementType="road" elementId="99" contactPoint="end"/>
        <successor elementType="road" elementId="1" elementS="70.0" elementDir="+"/>
    </link>
    <laneSection s="0.0000000000000000e+00">
        <left/>
        <center/>
        <right>
            <lane id="-1" type="driving" level="false">
                <link>
                    <predecessor id="-1"/>
                    <successor id="-2"/>
                </link>
            </lane>
        </right>
    </laneSection>
</road>
...
<junction name="myJunction" type="virtual" id="555" mainRoad="1" sStart="50" sEnd="70" orientation="+">
    <connection id="0" incomingRoad="1" connectingRoad="2" contactPoint="start">
        <laneLink from="-2" to="-1"/>
    </connection>
    <connection id="1" incomingRoad="99" connectingRoad="4" contactPoint="start">
        <laneLink from="-1" to="-1"/>
    </connection>
    <connection id="2" incomingRoad="99" connectingRoad="5" contactPoint="start">
        <laneLink from="-1" to="-1"/>
    </connection>
</junction>

Rules

The following rules apply for virtual junctions:

The main incoming road within a virtual junction does not need to end before the junction area.
Virtual junctions shall not replace common junctions and crossings that connect multiple roads.
Virtual junctions shall be used for branches off the main road only. The main road always has priority.
Virtual junctions shall not have controllers and therefore no traffic lights.
If no incoming road is defined the attribute @incomingRoad has the value -1.
All connecting roads within the virtual junction shall either start or end at @sStart or at @sEnd.
There shall only be one @sStart and one @sEnd definition for the virtual junction.
The heading of the connecting roads and the @mainRoad shall be equal at @sStart and at @sEnd.
The linked lanes shall fit smoothly as described for roads.
The attributes @mainRoad, @sStart, @sEnd, @orientation shall only be valid for junctions of type virtual.

Related topics

Controllers for junctions
Virtual connections
Junctions
Incoming roads
Connecting roads
Road linkage
Lane linkage

10.5.1. Virtual connections

Virtual connections indicate possible connections between two roads or one or more lanes of two roads. Because the indicated connections are only virtual, no real path is defined. That means that the course of the reference line is not changed.

Virtual connections describe topological connections between roads and lanes. They do not need to be geometrically correct.

Virtual connections are modeled by @type within the <junction> element.

The predecessor and successor roads of a virtual connection are described by <predecessor> and <successor> elements within the <connection> element.

Figure 83. Virtual junction with virtual connections

Figure 83 shows a virtual junction with virtual connections.

Elements in UML model

For elements in the UML model see Figure 78.

XML example

<junction name="myJunction" type="virtual" id="555" >
    <connection id="0" incomingRoad="1" connectingRoad="2" contactPoint="start">
        <laneLink from="-2" to="-1"/>
    </connection>
    <connection id="1" incomingRoad="99" connectingRoad="4" contactPoint="start">
        <laneLink from="-1" to="-1"/>
    </connection>
    <connection id="2" incomingRoad="99" connectingRoad="5" contactPoint="start">
        <laneLink from="-1" to="-2"/>
    </connection>
    <connection id="3" type="virtual">
        <predecessor elementType="road" elementId="99" contactPoint="end"/>
        <successor   elementType="road" elementId="1" elementS="60.0" elementDir="-"/>
        <laneLink from="-1" to="1"/>
    </connection>
    <connection id="4" type="virtual">
        <predecessor elementType="road" elementId="99" contactPoint="end"/>
        <successor elementType="road" elementId="1"  elementS="60.0" elementDir="-"/>
        <laneLink from="-1" to="2"/>
    </connection>
    <connection id="5" type="virtual">
        <predecessor elementType="road" elementId="1" elementS="70.0" elementDir="-"/>
        <successor elementType="road" elementId="99" contactPoint="end">
            <laneLink from="1" to="1"/>
        </connection>
    </junction>

Rules

The following rules apply for virtual connections:

Virtual connections shall not replace regular geometrical elements described by road linkage and lane linkage.
Virtual connections shall only be defined in virtual junctions.

Related topics

Virtual junctions
Road linkage
Lane linkage

10.6. Road surface within junctions

Roads may be elevated within a junction. This is accomplished by describing the road surface in correspondence with the descriptions used in ASAM OpenCRG. Using the road surface enables the description of complex elevations within a junction, including overlapping roads. All existing descriptions of road elevation within a junction are superseded by the <surface> element.

Elements in UML model

t_junction_surface

Used to describe the road elevation profile within a junction. When a <junction> element contains a <surface> element, the <surface> element supersedes all elevation data for connecting roads.

t_junction_surface_CRG

Data described in OpenCRG are represented by the <CRG> element within the <surface> element.

Table 51. Attributes of the junction surface CRG element
Name	Type	Unit	Description
`file`	string		Name of the file containing the CRG data
`mode`	e_junction_surface_CRG_mode		Attachment mode for the surface data.
`purpose`	e_road_surface_CRG_purpose		Physical purpose of the data contained in the CRG file; if the attribute is missing, data will be interpreted as elevation data.
`zOffset`	double	m	z offset between CRG center line and inertial xy-plane (default = 0.0)
`zScale`	double		z scale factor for the surface description (default = 1.0)

10.7. Junction groups

Two or more junctions may be grouped in junction groups to indicate that these junctions belong to the same roundabout.

Figure 84 shows how the junctions 1, 2 and 3 are aggregated in junction group A.

Figure 84. Junction group with three junctions

Junction groups are described by <junctionGroup> elements. The junctions that belong to the junction group are specified by <junctionReference> elements.

Figure 85. UML model for junction group

Elements in UML model

t_junctionGroup

Two or more junctions may be grouped in junction groups to indicate that these junctions belong to the same roundabout.

The <junctionGroup> element is split into a header element and a series of member elements.

Table 52. Attributes of the junctionGroup element
Name	Type	Description
`id`	string	Unique ID within database
`name`	string	Name of the junction group. May be chosen freely.
`type`	e_junctionGroup_type	Type of junction group

t_junctionGroup_junctionReference

References to existing <junction> elements.

Table 53. Attributes of the junctionGroup junctionReference element
Name	Type	Unit	Description
`junction`	string		ID of the junction

XML example

See the use case file UC_2Lane-Roundabout-3Arms.xodr

Related topics

Junctions
Controllers for junctions

10.7.1. Controllers for junctions

Controllers may be used to manage signals within a junction, as shown in Figure 86. The use of controllers for signals is described in Section Controllers. The function of the element within the <junction> element is to list the existing controllers and prioritize them in relation to other controllers inside the junction.

Figure 86. X-Junction with four traffic lights and two controllers

Controllers for junctions are described by <controller> elements within the <junction> element.

The @type of control depends on the application and is not specified in ASAM OpenDRIVE.

Figure 87. UML model for controller

Elements in UML model

t_junction_controller

Lists the controllers that are used for the management of a junction.

Table 54. Attributes of the junction controller element
Name	Type	Description
`id`	string	ID of the controller
`sequence`	nonNegativeInteger	Sequence number (priority) of this controller with respect to other controllers in the same junction
`type`	string	Type of control for this junction. Free text, depending on the application.

XML example

See the ucse case file UC_Simple-X-Junction-TrafficLights.xodr

Related topics

Junction groups
Junctions

11. Objects

Objects are items that influence a road by expanding, delimiting, and supplementing its course. The most common examples are parking spaces, crosswalks, and traffic barriers.

There are two ways to describe the bounding box of objects, as shown in Figure 88:

For an angular object: definition of the width, length and height
For a circular object: definition of the radius and height

Figure 88. A circular and angular object

Complex objects may be further described using <outline> elements. If an <outline> is defined, it supersedes the bounding box.

Objects in ASAM OpenDRIVE do not change their position. They may be declared dynamic or static:

Dynamic objects are static but have one or more movable part. Examples are fans in tunnels or windmills.
Stationary objects are completely static without any movable part. Examples are buildings or trees.

In ASAM OpenDRIVE, objects are represented by the <objects> element within the <object> element. Objects are defined per <road> element.

Figure 89. UML model for objects

Elements in UML model

t_road_objects

Container for all objects along a road.

t_road_objects_object

Describes common 3D objects that have a reference to a given road. Objects are items that influence a road by expanding, delimiting, and supplementing its course. The most common examples are parking spaces, crosswalks, and traffic barriers.

There are two ways to describe the bounding box of objects.

For an angular object: definition of the width, length and height.
For a circular object: definition of the radius and height.

Table 55. Attributes of the road objects object element
Name	Type	Unit	Description
`dynamic`	t_yesNo		Indicates whether the object is dynamic or static, default value is “no” (static). Dynamic object cannot change its position.
`hdg`	double	rad	Heading angle of the object relative to road direction
`height`	t_grEqZero	m	Height of the object’s bounding box. @height is defined in the local coordinate system u/v along the z-axis
`id`	string		Unique ID within database
`length`	t_grZero	m	Length of the object’s bounding box, alternative to @radius. @length is defined in the local coordinate system u/v along the v-axis
`name`	string		Name of the object. May be chosen freely.
`orientation`	e_orientation		"+" = valid in positive s-direction "-" = valid in negative s-direction "none" = valid in both directions (does not affect the heading)
`perpToRoad`	t_bool		Alternative to @pitch and @roll. If true, the object is vertically perpendicular to the road surface at all points and @pitch and @roll are ignored. Default is false.
`pitch`	double	rad	Pitch angle relative to the x/y-plane
`radius`	t_grZero	m	radius of the circular object’s bounding box, alternative to @length and @width. @radius is defined in the local coordinate system u/v
`roll`	double	rad	Roll angle relative to the x/y-plane
`s`	t_grEqZero	m	s-coordinate of object’s origin
`subtype`	string		Variant of a type
`t`	double	m	t-coordinate of object’s origin
`type`	e_objectType		Type of object. For a parking space, the `<parkingSpace>` element may be used additionally.
`validLength`	t_grEqZero	m	Validity of object along s-axis (0.0 for point object)
`width`	double	m	Width of the object’s bounding box, alternative to @radius. @width is defined in the local coordinate system u/v along the u-axis
`zOffset`	double	m	z-offset of object’s origin relative to the elevation of the reference line

Figure 90. Placing objects on roads

Figure 90 shows an object that is not properly placed on a road. Objects that are placed on roads using the <elevationProfile> or <lateralProfile> element should be so small that these objects do not cut or float above the road surface significantly, nor cause skewed ASAM OpenCRG surfaces.

XML example

<objects>
    <object
        type="building"
        name="ExampleBuilding"
        id="1"
        s="80.0"
        t="17.0"
        zOffset="0.0"
        orientation="none"
        length="12.15"
        width="22.415"
        height="11.84"
        hdg="1.44"
        pitch="0.0"
        roll="0.00">
    </object>
</objects>

Rules

The following rules apply to objects:

The type of an object shall be given by the @type attribute.
An object may either be dynamic or static.
Objects derived from ASAM OpenSCENARIO shall not be mixed with objects described in ASAM OpenDRIVE.
The direction for which objects are valid shall be specified.
The origin position of the object shall be described with s- and t-coordinates.
Objects may be of circular or angular shape. The possibilities are mutually exclusive. The shape is defined by the used attributes.

Related topics

Repeating objects
Roads
Object outline

11.1. Repeating objects

To avoid lengthy XML code, objects of the same type may be repeated. The attributes of the repeated object may be changed. This element is mainly used to describe railings, railing posts, street lamp.

Figure 91 shows one larger angular object that repeats another object. Figure 92 and Figure 93 show several smaller repeated objects, angular (Figure 92) and circular (Figure 93).

Figure 91. One larger angular repeated object

Figure 92. Several smaller angular repeated objects

Figure 93. Several smaller circular repeated objects

In ASAM OpenDRIVE, repeating objects are represented by the <repeat> element within the <object> element.

Elements in UML model

t_road_objects_object_repeat

To avoid lengthy XML code, objects of the same type may be repeated. Attributes of the repeated object shall overrule the attributes from the original object. If attributes are omitted in the repeated objects, the attributes from the original object apply.

Table 56. Attributes of the road objects object repeat element
Name	Type	Unit	Description
`distance`	t_grEqZero	m	Distance between two instances of the object; If this value is zero, then the object is treated like a continuous feature, for example, a guard rail, a wall, etc.
`heightEnd`	t_grEqZero	m	Height of the object at @s + @length
`heightStart`	t_grEqZero	m	Height of the object at @s
`length`	t_grEqZero		Length of the repeat area, along the reference line in s-direction.
`lengthEnd`	t_grEqZero	m	Length of the object at @s + @length
`lengthStart`	t_grEqZero	m	Length of the object at @s
`radiusEnd`	t_grEqZero	m	Radius of the object at @s + @length
`radiusStart`	t_grEqZero	m	Radius of the object at @s
`s`	t_grEqZero	m	s-coordinate of start position, overrides the corresponding argument in the original `<object>` record
`tEnd`	double	m	Lateral offset of object’s reference point at @s + @length
`tStart`	double	m	Lateral offset of objects reference point at @s
`widthEnd`	t_grEqZero	m	Width of the object at @s + @length
`widthStart`	t_grEqZero	m	Width of the object at @s
`zOffsetEnd`	double	m	z-offset of the object at @s + @length, relative to the elevation of the reference line
`zOffsetStart`	double	m	z-offset of the object at @s, relative to the elevation of the reference line

XML example

<objects>
    <object
        type="streetLamp"
        name="ExampleStreetLamp"
        id="2"
        s="15.00"
        t="5.0"
        zOffset="0.0"
        orientation="none"
        length="0.14"
        width="1.28"
        height="7.35"
        hdg="0.0"
        pitch="0.00"
        roll="0.0000">
        <repeat
            s="15.0"
            length="180.0"
            distance="60.00"
            tStart="5.0"
            tEnd="5.0"
            widthStart="1.28"
            widthEnd="1.28"
            heightStart="7.35"
            heightEnd="7.35"
            zOffsetStart="0.0"
            zOffsetEnd="0.0"/>
    </object>
</objects>

Rules

The following rules apply to repeating objects:

Parameters of the repeated object may differ from the original object.
Parameters of the repeated object shall overrule the parameters from the original object.

Related topics

Objects
Junction groups

11.2. Object outline

Objects may have an outline that is too complex to be described by parameters for angular and circular objects alone. Therefore, the outline of polygonal objects or non-rectangular objects may be described in a more detailed way.

An outline defines a series of corner points, including the height of the object relative to the road reference line. The inner area of the described outline may be filled with a filling type, such as grass, concrete, asphalt, or pavement.

The definition of the outline of objects is mainly used for traffic islands, irregularly shaped parking spaces and special road marking.

Defining multiple outlines for one object is useful in several cases. A tree for example has a narrow trunk and a wide crown. A driving simulation application might conclude that a vehicle can not pass the tree, if it would just recognize a bounding box representing the tree. Two outlines could be defined, one for the narrow trunk and one for the wide crown of the tree. A driving simulation application in this case could conclude that the vehicle can drive underneath the tree. A further example are street lights which consist of a pole and a light. Traffic islands often require more than one outline, since the outlines represent logical information, such as an area where pedestrians can stay. See example UC_2Lane-RoundAbout-3Arms.xodr in Section Corner local.

Figure 94. Traffic island as object

In ASAM OpenDRIVE, the outline of objects is represented by the <outlines> element within the <object> element.

The <outlines> element serves as a wrapper for the <outline> element, which itself contains further elements to describe, for example, corner roads, bridges and borders.

Elements in UML model

t_road_objects_object_outlines_outline

Defines a series of corner points, including the height of the object relative to the road reference line. For areas, the points should be listed in counter-clockwise order.

An <outline> element shall be followed by one or more <cornerRoad> element or by one or more <cornerLocal> element.

ASAM OpenDRIVE 1.4 outline definitions (without <outlines> parent element) shall still be supported.

Table 57. Attributes of the road objects object outlines outline element
Name	Type	Description
`closed`	t_bool	If true, the outline describes an area, not a linear feature
`fillType`	e_outlineFillType	Type used to fill the area inside the outline
`id`	nonNegativeInteger	ID of the outline. Must be unique within one object.
`laneType`	e_laneType	Describes the lane type of the outline
`outer`	t_bool	Defines if outline is an outer outline of the object

XML example

Ex_TrafficIsland-CornerRoad.xodr

Rules

The following rules apply to outline elements:

An <outline> element shall be followed by one or more <cornerRoad> elements or by one or more <cornerLocal> element.
The <outline> element may represent an area or a line feature.
The inner area of the described outline may be filled with a filling type.
An outline may be specified as an objects outer or inner outline. It may be specified if the described outline is located at the outer border of the object.
It may be specified like which lane type the object is treated by the application.
All points of the <outline> element must be located inside the bounding box.

Related topics

Corner roads
Corner local
Objects

11.2.1. Corner roads

Corner roads are mandatory elements inside an <outline> element. They are used to describe non-linear forms of objects. They are mutually exclusive with <cornerLocal> elements. Corner roads describe the outline of objects relative to the road reference line with their s- and t-coordinates.

The shape of an object may be described by the height of the object at a corner and the difference in height relative to the reference line.

Figure 95 shows a non-linear object with several corner points that is described by the s- and t-coordinates along the reference line. Corner road helps to position objects along a road, for example concrete barriers.

Figure 95. An object described by corner road coordinates

In ASAM OpenDRIVE, corner roads are represented by the <cornerRoad> element within the <outline> element.

Elements in UML model

t_road_objects_object_outlines_outline_cornerRoad

Defines a corner point on the object’s outline in road coordinates.

Table 58. Attributes of the road objects object outlines outline cornerRoad element
Name	Type	Unit	Description
`dz`	double	m	dz of the corner relative to road reference line
`height`	t_grEqZero	m	Height of the object at this corner, along the z-axis
`id`	nonNegativeInteger		ID of the outline point. Must be unique within one outline
`s`	t_grEqZero	m	s-coordinate of the corner
`t`	double	m	t-coordinate of the corner

XML example

Ex_TrafficIsland-cornerRoad.xodr

Rules

The following rules apply to cornerRoad elements:

There shall be at least two <cornerRoad> elements inside an <outline> element.
There shall be no <cornerLocal> element next to a <cornerRoad> element inside the same <outline> element.

Related topics

Corner local
Object outline
Superelevation

11.2.2. Corner local

Corner local are mandatory elements inside an <outline> element. They are used to describe non-linear forms of objects. They are mutually exclusive with <cornerRoad>. Corner local describes the outline of objects within a local u/v-coordinate system.

Figure 96 shows a non-linear object with several corner points that is described within a local coordinate system. Corner local helps to position objects beyond a road, relative to a single point, for example buildings or traffic islands.

Figure 96. An object described by corner local coordinates

In ASAM OpenDRIVE, corner locals are represented by the <cornerLocal> element within the <outline> element.

Elements in UML model

t_road_objects_object_outlines_outline_cornerLocal

Used to describe complex forms of objects. Defines a corner point on the object outline relative to the object pivot point in local u/v-coordinates. The insertion point and the orientation of the object are given by the @s, @t, @zOffset and @hdg attributes of the element.

Table 59. Attributes of the road objects object outlines outline cornerLocal element
Name	Type	Unit	Description
`height`	t_grEqZero	m	Height of the object at this corner, along the z-axis
`id`	nonNegativeInteger		ID of the outline point. Shall be unique within one outline.
`u`	double	m	Local u-coordinate of the corner
`v`	double	m	Local v-coordinate of the corner
`z`	double	m	Local z-coordinate of the corner

XML example

See the use case file UC_2Lane-Roundabout-3Arms.xodr

Rules

The following rules apply to cornerLocal elements:

There shall be at least two <cornerLocal> elements inside an <outline> element.
There shall be no mixture of <cornerRoad> and <cornerLocal> elements inside the same <outline> element.

Related topics

Corner roads
Object outline

11.3. Object material

Objects placed on a road, such as patches, may consist of a different material than the surrounding road. Therefore, the material of the object may be defined separately. In ASAM OpenDRIVE, it is possible to describe the surface, roughness and friction. The values depend on the application and are not defined in ASAM OpenDRIVE.

In ASAM OpenDRIVE, object material is represented by the <material> element within the <object> element

Elements in UML model

t_road_objects_object_material

Describes the material properties of objects, for example, patches that are part of the road surface but deviate from the standard road material. Supersedes the material specified in the <road material> element and is valid only within the outline of the parent road object.

Table 60. Attributes of the road objects object material element
Name	Type	Description
`friction`	t_grEqZero	Friction value, depending on application
`roughness`	t_grEqZero	Roughness, for example, for sound and motion systems, depending on application
`surface`	string	Surface material code, depending on application

Rules

The following rules apply to material for objects:

The material of objects may differ from the surrounding road.

Related topics

Objects

11.4. Lane validity for objects

By default, objects are valid for all lanes of a road. Lane validity offers the possibility to restrict the validity of an object to specific lanes only.

In ASAM OpenDRIVE, lane validity is represented by the <validity> element within the <object> element.

Note that @orientation and <validity> complement each other. The @orientation attribute and the <validity> element are not interchangeable.

@orientation defines the travel direction for which an object is valid. @orientation="+" or @orientation="-" should only be used if the object impacts traffic rules. Otherwise, @orientation="none" should be used.
<validity> defines specific lanes for which an object is valid. It should only be used for objects which are relevant for traffic rules, for example outlines of stoplines.

Elements in UML model

t_road_objects_object_laneValidity

May replace the default validity with explicit validity information for an object. Multiple validity elements may be defined per object.

Table 61. Attributes of the road objects object laneValidity element
Name	Type	Unit	Description
`fromLane`	integer		Minimum ID of the lanes for which the object is valid
`toLane`	integer		Maximum ID of the lanes for which the object is valid

Rules

The following rules apply to validity elements:

An object may be valid for specified lanes.
An object may be valid for one lane only.
The range given by all <validity> elements shall be a subset of the parent’s @orientation attribute:
- For right-hand traffic, @orientation="+" implies that <validity> shall only span negative lane ids, while @orientation="-" implies that <validity> shall only span positive lane ids. If the given <validity> elements span both, positive and negative lane ids, @orientation="none" shall be used.
- For left-hand-traffic, @orientation="-" implies that <validity> shall only span negative lane ids, while @orientation="+" implies that <validity> shall only span positive lane ids. If the given <validity> elements span both, positive and negative lane ids, @orientation="none" shall be used.
The value of the @fromLane attribute shall be lower than or equal to the value of the @toLane attribute.

Related topics

Objects
Object reference

11.5. Access rules to parking spaces

Objects of type parking space are defined as all other object types using the @type=parkingSpace within the <object> element. The outline of the parking space is described by <cornerRoad> or <cornerLocal> elements, as shown in Figure 97.

The access to a specified parking space may be restricted to a certain group, for example handicapped persons or residents, or a certain group of vehicles, for example buses. Further restrictions depend on the application and are user defined text.

Figure 97. Parking spaces rectangular (left figure) and rhomboid (right figure)

In ASAM OpenDRIVE, access rules for parking spaces are represented by the <parkingSpace> element within the <object> element.

Elements in UML model

t_road_objects_object_parkingSpace

Details for a parking space may be added to the <object> element.

Table 62. Attributes of the road objects object parkingSpace element
Name	Type	Unit	Description
`access`	e_road_objects_object_parkingSpace_access		Access definitions for the parking space. Parking spaces tagged with "women" and "handicapped" are vehicles of type car.
`restrictions`	string		Free text, depending on application

XML example

Ex_Parkingspace_Rectangular.xodr Ex_Parkingspace_rhomboid.xdor

Rules

The following rules apply to parkingSpace elements:

The access to a specified parking space may be limited to a specified group of persons or vehicles.
Further access restrictions may be defined, but are not part of ASAM OpenDRIVE.

Related topics

Objects
Corner roads
Corner local

11.6. Object marking

Marking describes the road marks of any objects like crosswalks, stopping-lines, and parking spaces. Marking is defined either in accordance to the bounding box of the element or by referencing outline points of the object.

Figure 98. Crosswalk in ASAM OpenDRIVE

In ASAM OpenDRIVE, the marking of objects is represented by the <markings> element within the <object> element.

The <markings> element serves as a wrapper for the <marking> element, which contains further information about the marking.

The marking may be defined for a straight line from one outline point to another by referencing the ID of the respective outline points. For this purpose, the <cornerReference> element inside the <marking> element is used.

Elements in UML model

t_road_objects_object_markings

Describes the appearance of the parking space with multiple marking elements.

t_road_objects_object_markings_marking

Specifies a marking that is either attached to one side of the object bounding box or referencing outline points.

Table 63. Attributes of the road objects object markings marking element
Name	Type	Unit	Description
`color`	e_roadMarkColor		Color of the marking
`lineLength`	t_grZero	m	Length of the visible part
`side`	e_sideType		Side of the bounding box described in `<object>` element in the local coordinate system u/v
`spaceLength`	t_grEqZero	m	Length of the gap between the visible parts
`startOffset`	double	m	Lateral offset in u-direction from start of bounding box side where the first marking starts
`stopOffset`	double	m	Lateral offset in u-direction from end of bounding box side where the marking ends
`weight`	e_roadMarkWeight		Optical "weight" of the marking
`width`	t_grZero	m	Width of the marking
`zOffset`	t_grEqZero	m	Height of road mark above the road, i.e. thickness of the road mark

t_road_objects_object_markings_marking_cornerReference

Specifies a point by referencing an existing outline point.

Table 64. Attributes of the road objects object markings marking cornerReference element
Name	Type	Unit	Description
`id`	nonNegativeInteger		Identifier of the referenced outline point

XML example

<objects>
    <object type="crosswalk" id="10" s="10.0" t="0.0" zOffset="0.0" orientation="none" length="10.0" width="7.0" hdg="0.0" pitch="0.0" roll="0.0">
        <outlines>
            <outline id="0">
                <cornerRoad s="5.0" t="3.5" dz="0.0" height="4.0" id="0"/>
                <cornerRoad s="8.0" t="-3.5" dz="0.0" height="4.0" id="1"/>
                <cornerRoad s="12.0" t="-3.5" dz="0.0" height="4.0" id="2"/>
                <cornerRoad s="15.0" t="3.5" dz="0.0" height="4.0" id="3"/>
            </outline>
        </outlines>
        <markings>
            <marking width="0.1" color="white" zOffset="0.005" spaceLength ="0.05" lineLength ="0.2" startOffset="0.0" stopOffset="0.0">
                <cornerReference id="0"/>
                <cornerReference id="1"/>
            </marking>
            <marking width="0.1" color="white" zOffset="0.005" spaceLength ="0.05" lineLength ="0.2" startOffset="0.0" stopOffset="0.0">
                <cornerReference id="2"/>
                <cornerReference id="3"/>
            </marking>
        </markings>
    </object>
</objects>

Rules

The following rules apply to object marking elements:

The marking of an object shall either completely or partially be defined on its outline.
The color of the marking shall be defined.
If no outline is used, the @side attribute is mandatory.
If an outline is used at least two <cornerReference> elements are mandatory.
If no outline is used, the <CornerReference> element cannot be used.

Related topics

Object outline
Objects
Object borders

11.7. Object borders

Objects may have a border, that is a frame of a defined width. Different border types are available, currently concrete and curb, for example for traffic islands.

In ASAM OpenDRIVE, object borders are represented by the <borders> element within the <object> element. The <borders> element serves as a wrapper for the <border> element, which itself contains further attributes to describe the borders.

Elements in UML model

t_road_objects_object_borders

Objects may have a border, that is, a frame of a defined width. Different border types are available.

t_road_objects_object_borders_border

Specifies a border along certain outline points.

Table 65. Attributes of the road objects object borders border element
Name	Type	Unit	Description
`outlineId`	nonNegativeInteger		ID of the outline to use
`type`	e_borderType		Appearance of border
`useCompleteOutline`	t_bool		Use all outline points for border. “true” is used as default.
`width`	t_grEqZero	m	Border width

Rules

The following rules apply to object borders:

If useCompleteOutline is true, <cornerReference> shall not be defined.
If useCompleteOutline is false, at least two <cornerReference> are mandatory.

Related topics

Object outline
Objects
Object marking

11.8. Object reference

It is possible to link an object with one or more roads, signals or other objects. These links represent a logical connection between the two elements.

An object reference is used, for example, if a pedestrian crossing crosses several roads. In this case, the pedestrian crossing is defined for one road only, and then referenced by the other roads that it crosses.

The lane validity element may be used to indicate for which lane the object reference is valid.

In ASAM OpenDRIVE, object reference is represented by the <objectReference> element within the <objects> element.

Elements in UML model

t_road_objects_objectReference

It is possible to link an object with one or more roads, signals or other objects using a <objectReference> element. The referenced objects require a unique ID. The object reference element consists of a main element and an optional lane validity element. The rules for validity elements are the same as for objects.

Table 66. Attributes of the road objects objectReference element
Name	Type	Unit	Description
`id`	string		Unique ID of the referred object within the database
`orientation`	e_orientation		"+" = valid in positive s-direction "-" = valid in negative s-direction "none" = valid in both directions
`s`	t_grEqZero	m	s-coordinate
`t`	double	m	t-coordinate
`validLength`	t_grEqZero	m	Validity of the object along s-axis (0.0 for point object)
`zOffset`	double	m	z offset relative to the elevation of the reference line

t_road_objects_object_laneValidity

May replace the default validity with explicit validity information for an object. Multiple validity elements may be defined per object.

Table 67. Attributes of the road objects object laneValidity element
Name	Type	Unit	Description
`fromLane`	integer		Minimum ID of the lanes for which the object is valid
`toLane`	integer		Maximum ID of the lanes for which the object is valid

Rules

The following rules apply for the purpose of reusing object information:

The value of the @fromLane attribute shall be lower than or equal to the value of the @toLane attribute.

Related topics

Lane validity
Objects

11.9. Tunnels

Tunnels are modeled as objects in ASAM OpenDRIVE. By definition, tunnels are valid for the complete cross section of a road. Different properties of tunnels may be described: length, whether the tunnel represents an underpass and is open to daylight, and the light conditions.

Figure 99 shows a tunnel that is valid for the whole cross section of the road.

Figure 99. A tunnel

In ASAM OpenDRIVE, tunnels are represented by the <tunnel> element within the <objects> element.

Elements in UML model

t_road_objects_tunnel

Tunnels are modeled as objects in ASAM OpenDRIVE. Tunnels apply to the entire cross section of the road within the given range unless a lane validity element with further restrictions is provided as child element.

Table 68. Attributes of the road objects tunnel element
Name	Type	Unit	Description
`daylight`	t_zeroOne		Degree of daylight intruding the tunnel. Depends on the application.
`id`	string		Unique ID within database
`length`	t_grEqZero	m	Length of the tunnel (in s-direction)
`lighting`	t_zeroOne		Degree of artificial tunnel lighting. Depends on the application.
`name`	string		Name of the tunnel. May be chosen freely.
`s`	t_grEqZero	m	s-coordinate
`type`	e_tunnelType		Type of tunnel

t_road_objects_object_laneValidity

May replace the default validity with explicit validity information for an object. Multiple validity elements may be defined per object.

Table 69. Attributes of the road objects object laneValidity element
Name	Type	Unit	Description
`fromLane`	integer		Minimum ID of the lanes for which the object is valid
`toLane`	integer		Maximum ID of the lanes for which the object is valid

XML example

<objects>
    <tunnel
        s="50.0"
        length="100.0"
        name="ExampleTunnel"
        id="1"
        type="standard"
        lighting="0.2"
        daylight="0.9"/>
</objects>

Rules

The following rules apply to tunnel elements:

Tunnels may be restricted to certain lanes, using the <laneValidity> element.
The @type of the tunnel shall be specified.
The value of the @fromLane attribute shall be lower than or equal to the value of the @toLane attribute.

Related topics

Bridges
Road cross section
Lane validity

11.10. Bridges

Bridges are modeled as objects in ASAM OpenDRIVE. By definition, bridges are valid for the complete cross section of a road. Different properties of bridges may be described: length and type, such as concrete, steel, wood or brick.

Figure 100 shows a bridge that is valid for the whole cross section of the road

Figure 100. A bridge

In ASAM OpenDRIVE, bridges are represented by the <bridge> element within the <objects> element.

Elements in UML model

t_road_objects_bridge

Bridges are modeled as objects in ASAM OpenDRIVE. Bridges are valid for the whole cross section of a road unless a lane validity record with further restrictions is provided as child element.

Table 70. Attributes of the road objects bridge element
Name	Type	Unit	Description
`id`	string		Unique ID within database
`length`	t_grEqZero	m	Length of the bridge (in s-direction)
`name`	string		Name of the bridge. May be chosen freely.
`s`	t_grEqZero	m	s-coordinate
`type`	e_bridgeType		Type of bridge

t_road_objects_object_laneValidity

May replace the default validity with explicit validity information for an object. Multiple validity elements may be defined per object.

Table 71. Attributes of the road objects object laneValidity element
Name	Type	Unit	Description
`fromLane`	integer		Minimum ID of the lanes for which the object is valid
`toLane`	integer		Maximum ID of the lanes for which the object is valid

XML example

<objects>
    <bridge
        s="50.0 "
        length="100.0"
        name="ExampleBridge"
        id="1"
        type="concrete"/>
</objects>

Rules

The following rules apply to bridge elements:

Bridges may be restricted to certain lanes, using the <laneValidity> element.
The @type of the bridge shall be specified.
The value of the @fromLane attribute shall be lower than or equal to the value of the @toLane attribute.

Related topics

Road cross section
Lane validity

11.11. Object surface

In driving simulators, the driver should be able to feel both the general road surface and specific, visible features on the road. This includes manhole covers, cracks, and patches. However, these require different resolutions, and it is impractical to model the entire road surface with a fine grid.

To support high-resolution surface features on a low-resolution road, the <surface> element may be included within the <object> element.

Objects with a defined <surface> influence the height of the road. The surface height of the object is added to the road height. In the other direction, it is subtracted if the surface height of the object is negative.

Since CRG data may only cover parts of a road’s surface, it must be made sure that outside the valid CRG area, the elevation information derived from ASAM OpenDRIVE data can still be used. Since the reference line of the CRG file for an object is ignored, a CRG file may be referenced multiple times in different parts of the map. The local coordinate system of an object is rotated with the object. The object surface is thus also rotated.

Figure 101. CRG for Objects

Figure 101 shows how CRG for objects is applied. s/t is the road coordinate system. u/v is the CRG coordinate system. The center point of the object is defined as the origin of the CRG’s coordinate system, which results in positive and negative u/v values.

Elements in UML model

t_road_objects_object_surface

Used to describe the road surface elevation of an object.

t_road_objects_object_surface_CRG

Elevation data described in ASAM OpenCRG are represented by the <CRG> element within the <surface> element.

Table 72. Attributes of the road objects object surface CRG element
Name	Type	Description
`file`	string	Name of the file containing the CRG data.
`hideRoadSurfaceCRG`	t_bool	Determines if the object CRG hides the road surface CRG. Default is true.
`zScale`	double	z-scale factor for the surface description (default = 1.0).

Height calculation

If an ASAM OpenCRG file is referenced, the u/v-coordinates of the object are used directly as u/v-coordinates of the ASAM OpenCRG file. The reference line of the CRG file is unused.

Thus, the surface height of an object is calculated as follows, using the crgEvaluv2z function from the ASAM OpenCRG C-API:

\[\operatorname{objectSurfaceHeight}(object, u, v) = \operatorname{crgEvaluv2z}(crg, u, v) * z_{Scale}\]

The total height at the point of an object CRG depends on the attachment mode of the underlying road surface CRG (t_road_surface_CRG), provided there is one. Table 73 summarizes the calculations for the different combinations. For a review of attachment modes, see Table 20, "Modes of connecting ASAM OpenCRG to ASAM OpenDRIVE" in Section 8.5.

Table 73. Total height calculation by attachment mode
Road surface CRG attachment mode	hideRoadSurfaceCRG = true (default)	hideRoadSurfaceCRG = false
attached	OpenDRIVE height + object CRG	OpenDRIVE height + road surface CRG + object CRG
attached0, genuine, global	not allowed	road surface CRG + object CRG
no road surface CRG	OpenDRIVE height + object CRG	OpenDRIVE height + object CRG

If crgEvaluv2z returns NaN, then the object has no defined height at that position. This is allowed in ASAM OpenCRG. In this case, the height of the road at that position shall be identical to the height defined in the rest of this standard, as if the object CRG is not present. The @hideRoadSurfaceCRG attribute has no effect at positions where crgEvaluv2z returns NaN. This enables the use of non-rectangular objects together with the @hideRoadSurfaceCRG attribute, for example, manhole covers.

XML example

<surface>
    <CRG file="manhole_cover.crg" hideRoadSurfaceCRG="true" zScale="1"></CRG>
</surface>

Rules

The following rules apply for the use of CRG data in objects:

Only objects with angular bounding boxes may contain <surface> elements. Circular objects or objects with <outlines> shall not contain <surface> elements.
Outside the bounding box, CRG data from the object shall be ignored.
The bounding boxes of objects with <surface> elements shall not overlap.
The local coordinate system of the CRG shall be identical to the local coordinate system of the object to which it belongs. The reference line, inertial position, curvature, and heading of the CRG file shall be ignored.
An object with a <surface> element shall be referenced on all roads it overlaps, using <object> and <objectReference>.
An object shall not reference more than one CRG file.
Objects with <surface> elements may repeat discretely, but not continuously. See Section 11.1.
To avoid skewed CRG surfaces, the @perpToRoad attribute should only be used for objects that are smaller than the local radius of the curvature of the road elevation.
The @height and @zOffset attributes of an object with a <surface> element shall be ignored when calculating the surface elevation.
If a road surface CRG is present, that is, the CRG area overlaps the bounding box of the object and has any mode other than attached, then @hideRoadSurfaceCRG shall be false. True shall not be allowed.
If crgEvaluv2z returns NaN, then the road height at that position shall be the ASAM OpenDRIVE height in addition to the road surface CRG, if it is present. The value of @hideRoadSurfaceCRG attribute shall have no influence.

Related topics

Road surface
Road surface within junctions

12. Signals

Signals are traffic signs, traffic lights, and specific road marking for the control and regulation of road traffic, as shown in Figure 102.

Figure 102. Signals in ASAM OpenDRIVE

Signals have different functions and properties:

They are used to control traffic behavior, for example, with speed limits and turn restrictions, and to alert road traffic about dangerous situations.
They can be static or dynamic. Static signals, like stop signs, do not change their meaning. Dynamic signals, like traffic lights, may change their meaning during the simulation. Their state may be defined in ASAM OpenSCENARIO.

Signals shall be placed in relation to a specific road. The position of the signal is described relative to the road reference line, using the s- and t- coordinates. Signals shall be positioned in such a way that it is clear to which road or lane they belong and where their validity starts. Ambiguity about their interpretation shall be avoided.

Traffic rules are different for each country. The country of the signal is specified in the @country attribute. When placing signals in ASAM OpenDRIVE, country-specific legislation and traffic rules should be considered. Legislative changes are indicated by the year when the rules come into force.

Height and width of a signal are not required but are recommended for proper representation of the signal.

Road marks, that are not binding to traffic, are not defined as signals, but only as objects.

A signal with the @type and @subtype attributes is only unique in combination with the @country and @countryRevision attributes.

Figure 103. Width and height for signal

A signal with an @orientation of + applies to traffic traveling in the positive reference line direction. This means the signal with a @hOffset of 0 faces to the drivers traveling in positive reference line direction. Any @hOffset given to this signal is applied counter-clockwise from the negative reference line direction.

A signal with an @orientation of - applies to traffic traveling in the negative reference line direction. This means the signal with a @hOffset of 0 faces to the drivers traveling in negative reference line direction. Any @hOffset given to this signal is applied counter-clockwise from the positive reference line direction.

Figure 104 shows a signal which applies to traffic traveling in positive reference line direction and which is turned counter-clockwise from the negative reference line direction. For the <signal> element the @orientation attribute and @hOffset attribute are defined. To the @orientation attribute the + value is assigned and to the @hOffset attribute a value of 5.7595865 is assigned.

Figure 104. Orientation and hOffset for signal

In ASAM OpenDRIVE, signals are represented by the <signals> element within the <road> element.

Figure 105. UML model for signals

Elements in UML model

t_road_signals

The <signals> element is the container for all signals along a road.

t_road_signals_signal

Used to provide information about signals along a road. Consists of a main element and an optional lane validity element. The element for a signal is <signal>.

Table 74. Attributes of the road signals signal element
Name	Type	Unit	Description
`country`	e_countryCode		Country code of the road, see ISO 3166-1, alpha-2 codes.
`countryRevision`	string		Defines the year of the applied traffic rules
`dynamic`	t_yesNo		Indicates whether the signal is dynamic or static. Example: traffic light is dynamic
`height`	t_grEqZero	m	Height of the signal, measured from bottom edge of the signal
`hOffset`	double	rad	Heading offset of the signal (relative to @orientation, if orientation is equal to “+” or “-“) Heading offset of the signal (relative to reference line, if orientation is equal to “none” )
`id`	string		Unique ID of the signal within the OpenDRIVE file
`name`	string		Name of the signal. May be chosen freely.
`orientation`	e_orientation		"+" = valid in positive s- direction "-" = valid in negative s- direction "none" = valid in both directions
`pitch`	double	rad	Pitch angle of the signal, relative to the inertial system (xy-plane)
`roll`	double	rad	Roll angle of the signal after applying pitch, relative to the inertial system (x’’y’’-plane)
`s`	t_grEqZero	m	s-coordinate
`subtype`	string		Subtype identifier according to country code or "-1" / "none"
`t`	double	m	t-coordinate
`text`	string		Additional text associated with the signal, for example, text on city limit "City\nBadAibling"
`type`	string		Type identifier according to country code or "-1" / "none". See extra document.
`unit`	e_unit		Unit of @value
`value`	double		Value of the signal, if value is given, unit is mandatory
`width`	t_grEqZero	m	Width of the signal
`zOffset`	double	m	z offset from the road to bottom edge of the signal. This represents the vertical clearance of the object. Relative to the reference line.

XML example

<signals>
    <signal
        s="3981.4158159146"
        t="-14.0503"
        id="5000162"
        name="Vorschriftzeichen"
        dynamic="no"
        orientation="+"
        zOffset="3.8835"
        country="DE"
        countryRevision="2017"
        type="274"
        subtype="100"
        value="100"
        unit="km/h"
        height="0.77"
        width="0.77"
        hOffset="5.7595865">
    </signal>
</signals>

Rules

The following rules apply to signals:

Signals shall have a specific type and subtype.
If present, signals shall be used in priority to other traffic rules.
A country code shall be added to refer to country-specific rules using the @country attribute.
The year the traffic rules come into force may be specified in the @countryRevision attribute.
Signals may be valid for one direction or both directions.
Signals may be dynamic or static.

Related topics

Roads
Signal positioning
Controllers

12.1. Lane validity for signals

By default, signals are valid for all lanes of a road, for traffic traveling in the direction indicated by @orientation attribute. Lane validity offers the possibility to restrict the validity of a signal to specific lanes only.

In Figure 106, signals in the shape of a road mark specify the speed limit of different lanes.

Figure 106. Lanes with signals in the shape of road marks

In ASAM OpenDRIVE, lane validity is represented by the <validity> element within the <signal> element.

Note that @orientation attribute and <validity> element complement each other. The @orientation attribute and the <validity> element are not interchangeable.

The @orientation attribute defines the travel direction for which a signal is valid.
The <validity> element defines the lanes for which a signal is valid.

As an example for the difference in using the attribute and the element, speed limits can be mentioned: If traveling in reference line direction, with right-hand-traffic, then a speed limit sign with orientation="+" will apply to a vehicle even if this vehicle is driving on an oncoming lane while overtaking. If the validity is limited to all right lanes, however, then the sign will not apply to the vehicle while it is on an oncoming lane. Therefore, the <validity> element should only be used to limit signals to specific lanes, for example for traffic lights which only apply to certain lanes.

Elements in UML model

t_road_objects_object_laneValidity

May replace the default validity with explicit validity information for an object. Multiple validity elements may be defined per object.

Table 75. Attributes of the road objects object laneValidity element
Name	Type	Unit	Description
`fromLane`	integer		Minimum ID of the lanes for which the object is valid
`toLane`	integer		Maximum ID of the lanes for which the object is valid

Rules

The following rules apply to validity elements:

A signal may be valid for one or more lanes.
The range given by all <validity> elements shall be a subset of the parent’s @orientation attribute:
- For right-hand traffic, @orientation="+" implies that <validity> shall only span negative lane ids, while @orientation="-" implies that <validity> shall only span positive lane ids. If the given <validity> elements span both, positive and negative lane ids, @orientation="none" shall be used.
- For left-hand-traffic, @orientation="-" implies that <validity> shall only span negative lane ids, while @orientation="+" implies that <validity> shall only span positive lane ids. If the given <validity> elements span both, positive and negative lane ids, @orientation="none" shall be used.
The value of the @fromLane attribute shall be lower than or equal to the value of the @toLane attribute.

Related topics

Signals
Signal dependency
Signal positioning

12.2. Signal dependency

Signal dependency means that one signal controls the output of another signal. For example, warning lights can be automatically turned on, when a traffic light goes red.

Figure 107. Lane and type specific speed limit

Rules regarding the type of dependency are defined in the application and are not stored in ASAM OpenDRIVE.

In ASAM OpenDRIVE, signal dependency is represented by the <dependency> element within the <signal> element.

Elements in UML model

t_road_signals_signal_dependency

Signal dependency means that one signal controls the output of another signal. A signal may have multiple dependency elements.

Table 76. Attributes of the road signals signal dependency element
Name	Type	Unit	Description
`id`	string		ID of the controlling signal
`type`	string		Type of the dependency, Free text, depending on application

XML example

<signals>
    <signal
        s="50.0"
        t="-4.0" id="1"
        name="SpeedLimit60"
        dynamic="no" orientation="+"
        zOffset="1.90"
        type="274"
        country="DE"
        countryRevision="2013"
        subtype="56"
        value="60.0"
        unit="km/h"
        hOffset="0.0 "
        pitch="0.0"
        roll="0.0"
        height="0.61"
        width="0.61">
        <dependency id="2"/>
    </signal>
    <signal
        s="50.0"
        t="-4.0"
        id="2"
        name="LorriesOnly"
        dynamic="no"
        orientation="+"
        zOffset="1.56"
        type="1048"
        country="DE"
        countryRevision="2013"
        subtype="12"
        hOffset="0.0"
        pitch="0.0"
        roll="0.0"
        height="0.33"
        width="0.60">
    </signal>
</signals>

Rules

The following rules apply to dependency elements:

A signal may have multiple dependencies.
The type of dependency is not specifically defined in ASAM OpenDRIVE and may be set in the application

Related topics

Links between signals and objects
Controllers
Signals

12.3. Links between signals and objects

ASAM OpenDRIVE offers the possibility to link a signal to an object or another signal.

References to signals and objects are defined within the <signal> element and not the superordinate <signals> element. It is valid for the specific signal only. The type of linkage depends on the application and is not defined within ASAM OpenDRIVE.

Rules regarding the type of dependency are defined in the application and are not stored in ASAM OpenDRIVE.

In ASAM OpenDRIVE, signal dependency is represented by the <dependency> element within the <signal> element.

Another example is shown in Figure 109. A speed limit is described as road mark object but referenced as a signal.

In ASAM OpenDRIVE, signal reference is represented by the <reference> element within the <signal> element.

Elements in UML model

t_road_signals_signal_reference

Provides a means to link a signal to a series of other elements (for example, objects and signals).

Table 77. Attributes of the road signals signal reference element
Name	Type	Description
`elementId`	string	Unique ID of the linked element
`elementType`	e_road_signals_signal_reference_elementType	Type of the linked element
`type`	string	Type of the linkage Free text, depending on application

XML example

See Example file Ex_Pedestrian_Crossing.xodr

Rules

The following rules apply to signal reference elements:

A signal may be linked to an object or another signal.

Related topics

Objects
Signals

12.4. Signal positioning

A signal should be placed next to the road for which it is valid, enabling the application to identify the signals validity. This is called the logical position of a signal. The s-position of the signal describes the position on the road where the signal takes effect.

In certain situations, physical and logical position of a signal are different, as shown in Figure 108. ASAM OpenDRIVE offers two possibilities to describe the physical deviation of a signal. The possibilities are mutually exclusive. The positioning of the signal has no influence on its content.

A signal may be positioned at another physical position that is described with a reference line coordinate system.
A signal whose physical position deviates from its logical position is represented by the <positionRoad> element within the <signal> element. That means, the ID of the specified road is referenced, together with the s- and t-coordinates of the road.
Examples are different positions of stop signs and stop lines.
A signal may be positioned at another physical position that is described with an inertial coordinate system. A signal whose physical position deviates from its logical position and is positioned using inertial coordinates is represented by the <positionInertial> element within the <signal> element.
Inertial coordinates are used, for example, if the signal is not placed next to a road, but on the other side of the street or hanging over a junction.

Figure 108. Junction with signals at physical and logical positions

Figure 109. UML Model Physical Position

Elements in UML model

t_road_signals_signal_positionInertial

Describes the reference point of the physical position in inertial coordinates in cases where it deviates from the logical position. Defines the inertial position.

Table 78. Attributes of the road signals signal positionInertial element
Name	Type	Unit	Description
`hdg`	double	rad	Heading of the signal, relative to the inertial system
`pitch`	double	rad	Pitch angle of the signal after applying heading, relative to the inertial system (x’y’-plane)
`roll`	double	rad	Roll angle of the signal after applying heading and pitch, relative to the inertial system (x’’y’’-plane)
`x`	double	m	x-coordinate
`y`	double	m	y-coordinate
`z`	double	m	z-coordinate

t_road_signals_signal_positionRoad

Describes the reference point of the physical position road coordinates in cases where it deviates from the logical position. Defines the position on the road.

Table 79. Attributes of the road signals signal positionRoad element
Name	Type	Unit	Description
`hOffset`	double	rad	Heading offset of the signal (relative to @orientation)
`pitch`	double	rad	Pitch angle of the signal after applying hOffset, relative to the inertial system (x’y’-plane)
`roadId`	string		Unique ID of the referenced road
`roll`	double	rad	Roll angle of the signal after applying hOffset and pitch, relative to the inertial system (x’’y’’-plane)
`s`	t_grEqZero	m	s-coordinate
`t`	double	m	t-coordinate
`zOffset`	double	m	z offset from road level to bottom edge of the signal

XML example

UC_LHT-Complex-TrafficLights.xodr

Rules

The following rules apply to signal positioning:

Signals should be placed next to the road for which they are valid.
The physical position of signals may deviate from their logical position.

Related topics

Signals
Lane validity for signals

12.5. Reuse of signal information

ASAM OpenDRIVE offers the possibility to copy signal information between signals by referencing the signal content. This convenience option avoids inconsistencies when positioning multiple signals of the same type and content. For the signal with copied content, it shall be specified for which direction of the road the signal applies. Signals may be valid for multiple roads at once, typically in a junction. Signals references may be used to attach the physical signal logical to several roads (e.g. traffic lights).

Corresponding to the <signal> element, a signal with copied content may be supplemented with lane validity. This enables to include or exclude certain lanes from the validity range of the signal.

An example of a signal with copied content is a speed limit signal positioned at an incoming road to a junction. The signal is valid for every connection road inside the junction. Signals on the connection road may reference and copy the signal content. This ensures that all signals follow the same speed limit.

In ASAM OpenDRIVE, a reference to another signal for reuse of signal information is represented by the <signalReference> element within the <signal> element.

Figure 110. UML Model Signal Reference

Elements in UML model

t_road_signals_signalReference

Refers to the same, that is, identical signal from multiple roads. The referenced signals require a unique ID. The <signalReference> element consists of a main element and an optional lane validity element.

Table 80. Attributes of the road signals signalReference element
Name	Type	Unit	Description
`id`	string		Unique ID of the referenced signal within the database
`orientation`	e_orientation		"+" = valid in positive s-direction "-" = valid in negative s-direction "none" = valid in both directions
`s`	t_grEqZero	m	s-coordinate
`t`	double	m	t-coordinate

t_road_objects_object_laneValidity

May replace the default validity with explicit validity information for an object. Multiple validity elements may be defined per object.

Table 81. Attributes of the road objects object laneValidity element
Name	Type	Unit	Description
`fromLane`	integer		Minimum ID of the lanes for which the object is valid
`toLane`	integer		Maximum ID of the lanes for which the object is valid

Rules

The following rules apply for the purpose of reusing signal information:

A lane validity element may be added for every <signalReference> element.
Signal reference shall be used for signals only.
For the signal that reuses the content of another signal, the direction for which it is valid shall be specified.
The range given by all <validity> elements shall be a subset of the parent’s @orientation attribute:
- For right-hand traffic, @orientation="+" implies that <validity> shall only span negative lane ids, while @orientation="-" implies that <validity> shall only span positive lane ids. If the given <validity> elements span both, positive and negative lane ids, @orientation="none" shall be used.
- For left-hand-traffic, @orientation="-" implies that <validity> shall only span negative lane ids, while @orientation="+" implies that <validity> shall only span positive lane ids. If the given <validity> elements span both, positive and negative lane ids, @orientation="none" shall be used.
The value of the @fromLane attribute shall be lower than or equal to the value of the @toLane attribute.

Related topics

Lane validity for signals
Signals
Signal positioning

12.6. Controllers

Controllers provides identical states for one or more dynamic signals. Controllers serve as wrappers for the behavior of a group of signals. Controllers are used for dynamic speed control on motorways, and to control traffic light switching phases.

Different from signal dependency, controllers are high-level elements that do not depend on other signals.

Additional content for controllers, such as traffic light phases, is stored outside the ASAM OpenDRIVE file.

Figure 111. Junction with four traffic lights, controlled by two controllers

In ASAM OpenDRIVE, controllers are represented by the <controller> element within the <OpenDRIVE> element.

The ID of the referenced signal is stored in the <control> element within the <controller> element.

Figure 112. UML Model Controller

Elements in UML model

t_controller

Controllers provides identical states for one or more dynamic signals. Controllers serve as wrappers for the behaviour of a group of signals. Controllers are used for dynamic speed control on motorways, and to control traffic light switching phases.

Table 82. Attributes of the controller element
Name	Type	Description
`id`	string	Unique ID within database
`name`	string	Name of the controller. May be chosen freely.
`sequence`	nonNegativeInteger	Sequence number (priority) of this controller with respect to other controllers of same logical level

t_controller_control

Provides information about a single signal controlled by the corresponding controller.

Table 83. Attributes of the controller control element
Name	Type	Unit	Description
`signalId`	string		ID of the controlled signal
`type`	string		Type of control. Free Text, depends on the application.

XML Examples

UC_Simple-X-Junction-TrafficLights.xodr

Rules

The following rules apply to controllers:

Controllers shall be valid for one or more signals.

Related topics

Signal dependency
Controllers for junctions
Signals

13. Railroads

In addition to roads, ASAM OpenDRIVE offers the possibility to model rail-based transport systems, that is, trams and streetcars. ASAM OpenDRIVE cannot be used for complex railway networks and railway signals. ASAM OpenDRIVE describes rail networks only where roads and rails meet. In ASAM OpenDRIVE, railroads are represented by the <railroad> element within the <road> element.

Figure 113. UML Model Railroad

Rules

The following rules apply to railroads:

Each railway track requires one road.

Related topics

Railroad tracks
Switches
Stations

13.1. Railroad tracks

In ASAM OpenDRIVE, rails are always described in connection with the roads on which one pair of rails run. It is not possible to define rails outside roads. Regard less of a tram or sharing the same space with none railway traffic or separate of none railway traffic, it always needs a separate road.

Rails are defined per lane using the @type attribute. Because rail-based traffic differs from road traffic, the following recommendations apply to the modeling of railroads: Figure 114 shows the difference between the use of the reference line for roads and railroads.

Figure 114. Reference lines for roads and railroads

In ASAM OpenDRIVE, railroad tracks are represented by the @type attribute within the <lane> element. The values for railroad tracks are tram and rail.

Rules

The following rules apply to railroads:

The reference line must be in the center of the pair of rails.
There is only one tram or one rail lane per road.
The Width of the lane must be at least the width rail-bound vehicles

Related topics

Railroads
Switches

13.2. Switches

Rail-bound vehicles use switches to change their tracks. In contrast to junctions, a switch can guide the vehicles into two directions only.

There are two different types of switches:

Dynamic switches split the railroad track in two tracks leading in two directions. Dynamic switches can be changed during the simulation.
Static switches split the railroad track in two tracks leading in two directions. Static switches cannot be changed during the simulation.

Switches may be placed at an arbitrary position on a main track.

Figure 115 shows the two partner switches 12 and 32. A side track 2 connects the two main tracks 1 and 3.

Figure 115. Railroad switches

In ASAM OpenDRIVE, switches are represented by the <switch> element within the <railroad> element.

Elements in UML model

t_road_railroad_switch

Table 84. Attributes of the road railroad switch element
Name	Type	Description
`id`	string	Unique ID of the switch; preferably an integer number, see uint32_t
`name`	string	Unique name of the switch
`position`	e_road_railroad_switch_position	Either a switch can be operated (dynamic) or it is in a static position

XML Examples

<railroad>
    <switch name="ExampleSwitch12" id="12" position="dynamic">
        <mainTrack id="1" s="1.0000000000000000e+01" dir="+"/>
        <sideTrack id="2" s="0.0000000000000000e+00" dir="+"/>
        <partner name="ExampleSwitch32" id="32"/>
    </switch>
</railroad>

Rules

The following rules apply to switches:

A switch may be either dynamic or static.

Related topics

Railroad track
Main Track
Side Track
Partner Switchs

13.2.1. Main track

A main track represents the main course for rail bound traffic. A main track has the same properties as a side track. The two track types have been implemented as a convenience function to simplify the modeling of tracks entering and coming out of switches.

For a picture, see Figure 115.

In ASAM OpenDRIVE, main tracks are represented by the <mainTrack> element within the <switch> element.

Elements in UML model

t_road_railroad_switch_mainTrack

Table 85. Attributes of the road railroad switch mainTrack element
Name	Type	Unit	Description
`dir`	e_elementDir		direction, relative to the s-direction, on the main track for entering the side track via the switch
`id`	string		Unique ID of the main track, that is, the `<road>` element. Must be consistent with parent containing this `<railroad>` element.
`s`	t_grEqZero	m	s-coordinate of the switch, that is, the point where main track and side track meet

Rules

The following rules apply to main tracks:

Main tracks shall not be used to connect two switches.

Related topics

Side Track
Partner Switchs

13.2.2. Side track

A side track connects two switches that are placed on main tracks. A side track has the same properties as a main track. The two track types have been implemented as convenience function to simplify the modeling of tracks entering and coming out of switches.

For a picture, see Figure 115.

In ASAM OpenDRIVE, side tracks are represented by the <sideTrack> element within the <switch> element.

Elements in UML model

t_road_railroad_switch_sideTrack

Table 86. Attributes of the road railroad switch sideTrack element
Name	Type	Unit	Description
`dir`	e_elementDir		direction, relative to the s-direction, on the side track for after entering it via the switch
`id`	string		Unique ID of the side track, that is, the `<road>` element
`s`	t_grEqZero	m	s-coordinate of the switch on the side track

Rules

The following rules apply to side tracks:

Side tracks shall be used to link two switches only.

Related topics

Main Track
Partner Switchs

13.2.3. Partner switches

For convenience reasons, two switches may be declared partner switches. This describes a connection between two switches that are linked by a side track. These two switches need to be set consistently.

For a picture, see Figure 115. Here switches 12 and 32 are partner switches.

In ASAM OpenDRIVE, partner switches are represented by the <partner> element within the <switch> element.

Elements in UML model

t_road_railroad_switch_partner

Indicates the switch that leads out of a side track after it has been entered.

Table 87. Attributes of the road railroad switch partner element
Name	Type	Unit	Description
`id`	string		Unique ID of the partner switch
`name`	string		Unique name of the partner switch

Rules

The following rules apply to partner switches:

Partner switches shall be used to indicate that a side track links two switches.
Single switches do not have partner switches.

Related topics

Main Track
Partner Switchs

13.3. Stations

Rail-bound vehicles like trams need stations for people to get on and off. Each station shall have at least one platform, which may be further divided into segments. The platforms determine the physical extent of a station.

The <station> element may also be used for bus stations.

Figure 116 shows two scenarios for stations:

In the first scenario, one platform is referenced by the roads 1 and 3, running in different driving directions. The platform consists of one segment only.
In the second scenario, platform 1 is referenced by road 3 only. Platform 2 is referenced by road 1 and 2. Platform 2 is split into two segments.

Figure 116. Railroad stations

In ASAM OpenDRIVE, stations are represented by the <station> element within the <OpenDRIVE> element.

Figure 117. UML Model Station

Elements in UML model

t_station

Defines stations for tram and railroad applications and for automotive environments. May refer to multiple tracks and is therefore defined on the same level as junctions.

Table 88. Attributes of the station element
Name	Type	Description
`id`	string	Unique ID within database
`name`	string	Unique name of the station
`type`	e_station_type	Type of station. Free text, depending on the application. e.g.: small, medium, large

XML example

Ex_Railway-station.xodr

Rules

The following rules apply to stations:

A <station> element shall be followed by at least one <platform> element.
The type of the station may be further specialized by the @type attribute. The values are stored in the used application.

Related topics

Platforms
Segments
Railroads

13.3.1. Platforms

A station shall contain at least one platform. A platform shall be referenced by one or more railroad track.

See picture in Figure 116.

In ASAM OpenDRIVE, railroads are represented by the <platform> element within the <station> element.

Elements in UML model

t_station_platform

Each <station> element must contain at least one <platform> element. Each <platform> element must contain at least one reference to a valid track segment.

Table 89. Attributes of the station platform element
Name	Type	Unit	Description
`id`	string		Unique ID within database
`name`	string		Name of the platform. May be chosen freely.

Rules

The following rules apply to platforms:

There shall be at least one platform per station.
A platform shall contain at least one segment.

Related topics

Stations
Segments

13.3.2. Segments

Platforms may be further divided into segments. This is useful if a bi-directional railroad track runs along the same platform. A platform shall contain at least one segment.

In ASAM OpenDRIVE, railroads are represented by the <segment> element within the <platform> element.

Elements in UML model

t_station_platform_segment

Each <platform> element is valid on one or more track segments. The <segment> element must be specified.

Table 90. Attributes of the station platform segment element
Name	Type	Unit	Description
`roadId`	string		Unique ID of the `<road>` element (track) that accompanies the platform
`sEnd`	t_grEqZero	m	Maximum s-coordiante on `<road>` element that has an adjacent platform
`side`	e_station_platform_segment_side		Side of track on which the platform is situated when going from sStart to sEnd
`sStart`	t_grEqZero	m	Minimum s-coordinate on `<road>` element that has an adjacent platform

Rules

The following rules apply to segments:

There shall be at least one segment per platform.

Related topics

Stations
Platforms

14. References

14.1. Enumerations

14.1.1. Core

e_unitDistance

Table 91. Attributes of the unitDistance enumeration
Name	Type
`ft`	string
`km`	string
`m`	string
`mile`	string

e_unitSlope

Table 92. Attributes of the unitSlope enumeration
Name	Type
`%`	string

e_dataQuality_RawData_Source

Table 93. Attributes of the dataQuality RawData Source enumeration
Name	Type
`cadaster`	string
`custom`	string
`sensor`	string

e_unitSpeed

Table 94. Attributes of the unitSpeed enumeration
Name	Type
`km/h`	string
`m/s`	string
`mph`	string

e_dataQuality_RawData_PostProcessing

Table 95. Attributes of the dataQuality RawData PostProcessing enumeration
Name	Type
`cleaned`	string
`fused`	string
`processed`	string
`raw`	string

e_unitMass

Table 96. Attributes of the unitMass enumeration
Name	Type
`kg`	string
`t`	string

t_yesNo

Table 97. Attributes of the yesNo enumeration
Name	Type
`no`	string
`yes`	string

14.1.2. Junction

e_junction_type

Table 98. Attributes of the junction type enumeration
Name	Type
`default`	string
`direct`	string
`virtual`	string

e_road_surface_CRG_purpose

Table 99. Attributes of the road surface CRG purpose enumeration
Name	Type
`elevation`	string
`friction`	string

e_junction_surface_CRG_mode

Table 100. Attributes of the junction surface CRG mode enumeration
Name	Type
`global`	string

e_road_surface_CRG_mode

Table 101. Attributes of the road surface CRG mode enumeration
Name	Type
`attached0`	string
`attached`	string
`genuine`	string
`global`	string

e_junctionGroup_type

Table 102. Attributes of the junctionGroup type enumeration
Name	Type
`roundabout`	string
`unknown`	string

e_elementDir

Table 103. Attributes of the elementDir enumeration
Name	Type
`+`	string
`-`	string

e_contactPoint

Table 104. Attributes of the contactPoint enumeration
Name	Type
`end`	string
`start`	string

e_connection_type

Table 105. Attributes of the connection type enumeration
Name	Type
`default`	string
`virtual`	string

14.1.3. Lane

e_roadMarkWeight

Table 106. Attributes of the roadMarkWeight enumeration
Name	Type
`bold`	string
`standard`	string

t_bool

Table 107. Attributes of the bool enumeration
Name	Type
`false`	string
`true`	string

e_roadMarkType

Table 108. Attributes of the roadMarkType enumeration
Name	Type
`botts dots`	string
`broken broken`	string
`broken solid`	string
`broken`	string
`curb`	string
`custom`	string
`edge`	string
`grass`	string
`none`	string
`solid broken`	string
`solid solid`	string
`solid`	string

e_accessRestrictionType

Table 109. Attributes of the accessRestrictionType enumeration
Name	Type
`autonomousTraffic`	string
`bicycle`	string
`bus`	string
`delivery`	string
`emergency`	string
`motorcycle`	string
`none`	string
`passengerCar`	string
`pedestrian`	string
`simulator`	string
`taxi`	string
`throughTraffic`	string
`truck`	string
`trucks`	string

e_road_lanes_laneSection_lr_lane_access_rule

Table 110. Attributes of the road lanes laneSection lr lane access rule enumeration
Name	Type
`allow`	string
`deny`	string

e_laneType

Table 111. Attributes of the laneType enumeration
Name	Type
`HOV`	string
`bidirectional`	string
`biking`	string
`border`	string
`bus`	string
`connectingRamp`	string
`curb`	string
`driving`	string
`entry`	string
`exit`	string
`median`	string
`mwyEntry`	string
`mwyExit`	string
`none`	string
`offRamp`	string
`onRamp`	string
`parking`	string
`rail`	string
`restricted`	string
`roadWorks`	string
`shoulder`	string
`sidewalk`	string
`special1`	string
`special2`	string
`special3`	string
`stop`	string
`taxi`	string
`tram`	string

e_road_lanes_laneSection_lcr_lane_roadMark_laneChange

Table 112. Attributes of the road lanes laneSection lcr lane roadMark laneChange enumeration
Name	Type
`both`	string
`decrease`	string
`increase`	string
`none`	string

e_roadMarkColor

Table 113. Attributes of the roadMarkColor enumeration
Name	Type
`blue`	string
`green`	string
`orange`	string
`red`	string
`standard`	string
`violet`	string
`white`	string
`yellow`	string

e_roadMarkRule

Table 114. Attributes of the roadMarkRule enumeration
Name	Type
`caution`	string
`no passing`	string
`none`	string

14.1.4. Object

e_tunnelType

Table 115. Attributes of the tunnelType enumeration
Name	Type
`standard`	string
`underpass`	string

e_borderType

Table 116. Attributes of the borderType enumeration
Name	Type
`concrete`	string
`curb`	string

e_sideType

Table 117. Attributes of the sideType enumeration
Name	Type
`front`	string
`left`	string
`rear`	string
`right`	string

e_outlineFillType

Table 118. Attributes of the outlineFillType enumeration
Name	Type
`asphalt`	string
`cobble`	string
`concrete`	string
`grass`	string
`gravel`	string
`pavement`	string
`soil`	string

e_objectType

Table 119. Attributes of the objectType enumeration
Name	Type
`barrier`	string
`bike`	string
`building`	string
`bus`	string
`car`	string
`crosswalk`	string
`gantry`	string
`motorbike`	string
`none`	string
`obstacle`	string
`parkingSpace`	string
`patch`	string
`pedestrian`	string
`pole`	string
`railing`	string
`roadMark`	string
`soundBarrier`	string
`streetLamp`	string
`trafficIsland`	string
`trailer`	string
`train`	string
`tram`	string
`tree`	string
`van`	string
`vegetation`	string
`wind`	string

e_bridgeType

Table 120. Attributes of the bridgeType enumeration
Name	Type
`brick`	string
`concrete`	string
`steel`	string
`wood`	string

e_orientation

Table 121. Attributes of the orientation enumeration
Name	Type
`+`	string
`-`	string
`none`	string

e_road_objects_object_parkingSpace_access

Table 122. Attributes of the road objects object parkingSpace access enumeration
Name	Type
`all`	string
`bus`	string
`car`	string
`electric`	string
`handicapped`	string
`residents`	string
`truck`	string
`women`	string

14.1.5. Railroad

e_station_type

Table 123. Attributes of the station type enumeration
Name	Type
`large`	string
`medium`	string
`small`	string

e_road_railroad_switch_position

Table 124. Attributes of the road railroad switch position enumeration
Name	Type
`dynamic`	string
`straight`	string
`turn`	string

e_station_platform_segment_side

Table 125. Attributes of the station platform segment side enumeration
Name	Type
`left`	string
`right`	string

14.1.6. Road

e_road_link_elementType

Table 126. Attributes of the road link elementType enumeration
Name	Type
`junction`	string
`road`	string

e_paramPoly3_pRange

Table 127. Attributes of the paramPoly3 pRange enumeration
Name	Type
`arcLength`	string
`normalized`	string

e_roadType

Table 128. Attributes of the roadType enumeration
Name	Type
`bicycle`	string
`lowSpeed`	string
`motorway`	string
`pedestrian`	string
`rural`	string
`townArterial`	string
`townCollector`	string
`townExpressway`	string
`townLocal`	string
`townPlayStreet`	string
`townPrivate`	string
`town`	string
`unknown`	string

e_maxSpeedString

Table 129. Attributes of the maxSpeedString enumeration
Name	Type
`no limit`	string
`undefined`	string

e_trafficRule

Table 130. Attributes of the trafficRule enumeration
Name	Type
`LHT`	string
`RHT`	string

e_direction

Table 131. Attributes of the direction enumeration
Name	Type
`opposite`	string
`same`	string

e_countryCode_deprecated

Table 132. Attributes of the countryCode deprecated enumeration
Name	Type
`Austria`	string
`Brazil`	string
`China`	string
`France`	string
`Germany`	string
`Italy`	string
`OpenDRIVE`	string
`Switzerland`	string
`USA`	string

14.1.7. Signal

e_road_signals_signal_reference_elementType

Table 133. Attributes of the road signals signal reference elementType enumeration
Name	Type
`object`	string
`signal`	string

14.2. Data types

14.2.1. Core

e_unit

Table 134. e_unit
Type	Relations
`union`	e_unitDistance e_unitSpeed e_unitMass e_unitSlope

t_grEqZero

Table 135. t_grEqZero
Type	Restriction
`double`	[0;∞[

t_grZero

Table 136. t_grZero
Type	Restriction
`double`	]0;∞[

t_zeroOne

Table 137. t_zeroOne
Type	Restriction
`double`	[0;1]

14.2.2. Road

e_countryCode

Table 138. e_countryCode
Type	Restriction
`string`	[A-Z]{2}

t_maxSpeed

Table 139. t_maxSpeed
Type	Restriction
`e_maxSpeedString`	no limit ; undefined ; [0,∞[

15. List of figures

Figure

Description

Figure 1:

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

Figure 2:

UML attribute notation

Figure 3:

Relation between ASAM OpenDRIVE, ASAM OpenCRG, and ASAM OpenSCENARIO

Figure 4:

UML model ASAM OpenDRIVE Core

Figure 5:

Available coordinate systems in ASAM OpenDRIVE

Figure 6:

Coordinate systems in ASAM OpenDRIVE interacting with another

Figure 7:

Inertial coordinate system with defined rotations

Figure 8:

Inertial coordinate system with defined rotations

Figure 9:

Reference line coordinate system

Figure 10:

Reference line system with defined rotations

Figure 11:

Heading in reference line

Figure 12:

Roll in reference line

Figure 13:

Elevation in reference line

Figure 14:

Local system with defined rotations

Figure 15:

Local coordinate systems with heading, pitch, roll

Figure 16:

Local coordinate system with respect to reference line system

Figure 17:

Summary of coordinate system in ASAM OpenDRIVE

Figure 18:

geoReference and offset

Figure 19:

Geometry elements in ASAM OpenDRIVE

Figure 20:

The individual parts of a road

Figure 21:

UML model Road Geometry including the Reference Line elements

Figure 22:

A straight line

Figure 23:

Road geometry described by a spiral

Figure 24:

Road geometry described by an arc

Figure 25:

Creating a reference line from geometry elements

Figure 26:

A cubic polynom

Figure 27:

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

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

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

Figure 33:

UML Model for Roads

Figure 34:

UML model for Road Geometry

Figure 35:

Allowed, prohibited, and recommended road linkage

Figure 36:

Allowed scenarios of road linkage

Figure 37:

Allowed scenario of road linkage within a junction

Figure 38:

UML model for road linkage

Figure 39:

Types of elevation

Figure 40:

Superelevation

Figure 41:

Minimum t-definition range for road shapes

Figure 42:

Shape definition (left) in combination with superelevation (right)

Figure 43:

Road surface as defined in a CRG file

Figure 44:

ASAM OpenCRG road surface description using u/v-coordinates and x/y-coordinates

Figure 45:

Positioning of an ASAM OpenCRG file along the reference line

Figure 46:

ASAM OpenCRG attachment mode, attached

Figure 47:

ASAM OpenCRG attached mode with elevation

Figure 48:

ASAM OpenCRG attached0 mode with elevated reference line

Figure 49:

ASAM OpenCRG attachment mode, genuine

Figure 50:

ASAM OpenCRG orientation

Figure 51:

Example crossfall modeled with road shape

Figure 52:

Center lane for road with lanes of different driving directions

Figure 53:

Center lane for road with lanes of identical driving direction

Figure 54:

UML model for lanes

Figure 55:

Lane grouping with left, center, right

Figure 56:

A road section with lane sections

Figure 57:

Lane sections defined separately for both sides of the road

Figure 58:

Lane offset

Figure 59:

Lane links for road with id 10

Figure 60:

Example where a bikeway ends and bicycles are expected to continue driving on the driving lane

Figure 61:

Example where a driving lane splits into two or more driving lanes abruptly

Figure 62:

UML Model t_road_lanes_laneSection_lcr_lane_link

Figure 63:

UML model lane properties

Figure 64:

Change of lane width per lane section

Figure 65:

Lane with varying border shape

Figure 66:

Lane types for a motorway

Figure 67:

Lane types for a rural road

Figure 68:

Lane types for an urban road

Figure 69:

Lane types for motorway exit and entry

Figure 70:

Lane types for motorway connecting to another motorway

Figure 71:

Lane-specific speed limits

Figure 72:

Lane access, bus lane

Figure 73:

Lane height

Figure 74:

Lanes excluded from road elevation

Figure 75:

UML model t_road_lanes_laneSection_lcr_lane_roadMark

Figure 76:

Road marking with sway and offset

Figure 77:

Types of roads in a junction (right-hand traffic)

Figure 78:

UML model for junctions

Figure 79:

Connecting roads of junction with id 1 (left hand traffic)

Figure 80:

Direct junctions

Figure 81:

Cases when direct junctions cannot be modeled

Figure 82:

Example of a virtual junction showing a parking lot entry and exit

Figure 83:

Virtual junction with virtual connections

Figure 84:

Junction group with three junctions

Figure 85:

UML model for junction group

Figure 86:

X-Junction with four traffic lights and two controllers

Figure 87:

UML model for controller

Figure 88:

A circular and angular object

Figure 89:

UML model for objects

Figure 90:

Placing objects on roads

Figure 91:

One larger angular repeated object

Figure 92:

Several smaller angular repeated objects

Figure 93:

Several smaller circular repeated objects

Figure 94:

Traffic island as object

Figure 95:

An object described by corner road coordinates

Figure 96:

An object described by corner local coordinates

Figure 97:

Parking spaces rectangular (left figure) and rhomboid (right figure)

Figure 98:

Crosswalk in ASAM OpenDRIVE

Figure 99:

A tunnel

Figure 100:

A bridge

Figure 101:

CRG for Objects

Figure 102:

Signals in ASAM OpenDRIVE

Figure 103:

Width and height for signal

Figure 104:

Orientation and hOffset for signal

Figure 105:

UML model for signals

Figure 106:

Lanes with signals in the shape of road marks

Figure 107:

Lane and type specific speed limit

Figure 108:

Junction with signals at physical and logical positions

Figure 109:

UML Model Physical Position

Figure 110:

UML Model Signal Reference

Figure 111:

Junction with four traffic lights, controlled by two controllers

Figure 112:

UML Model Controller

Figure 113:

UML Model Railroad

Figure 114:

Reference lines for roads and railroads

Figure 115:

Railroad switches

Figure 116:

Railroad stations

Figure 117:

UML Model Station

16. List of tables

Table

Description

Table 1:

Units

Table 2:

Rules for using modal verbs

Table 3:

Typographical conventions

Table 4:

Overview of ASAM OpenDRIVE elements

Table 5:

Attributes of the ASAM OpenDRIVE element

Table 6:

Attributes of the header element

Table 7:

Attributes of the header Offset element

Table 8:

Attributes of the road planView geometry element

Table 9:

Attributes of the road planView geometry spiral element

Table 10:

Attributes of the road planView geometry arc element

Table 11:

Attributes of the road planView geometry poly3 element

Table 12:

Attributes of the road planView geometry paramPoly3 element

Table 13:

Attributes of the road element

Table 14:

Attributes of the road link predecessorSuccessor element

Table 15:

Attributes of the road type element

Table 16:

Attributes of the road type speed element

Table 17:

Attributes of the road elevationProfile elevation element

Table 18:

Attributes of the road lateralProfile superelevation element

Table 19:

Attributes of the road lateralProfile shape element

Table 20:

Modes of connecting ASAM OpenCRG to ASAM OpenDRIVE

Table 21:

Attributes of the road surface CRG element

Table 22:

Attributes of the road lanes laneSection element

Table 23:

Attributes of the road lanes laneSection center lane element

Table 24:

Attributes of the road lanes laneSection left lane element

Table 25:

Attributes of the road lanes laneSection right lane element

Table 26:

Attributes of the road lanes laneOffset element

Table 27:

Lane predecessors and successors for road with id 10

Table 28:

Attributes of the road lanes laneSection lcr lane link predecessorSuccessor element

Table 29:

Attributes of the road lanes laneSection lr lane width element

Table 30:

Attributes of the road lanes laneSection lr lane border element

Table 31:

Attributes of the road lanes laneSection lr lane element

Table 32:

Attributes of the road lanes laneSection lr lane material element

Table 33:

Attributes of the road lanes laneSection lr lane speed element

Table 34:

Attributes of the road lanes laneSection lr lane access element

Table 35:

Attributes of the road lanes laneSection lr lane height element

Table 36:

Attributes of the road lanes laneSection lcr lane roadMark type element

Table 37:

Attributes of the road lanes laneSection lcr lane roadMark type line element

Table 38:

Attributes of the road lanes laneSection lcr lane roadMark element

Table 39:

Attributes of the road lanes laneSection lcr lane roadMark explicit line element

Table 40:

Attributes of the road lanes laneSection lcr lane roadMark sway element

Table 41:

Attributes of the road lanes laneSection lr lane rule element

Table 42:

Usage of the different types of junctions

Table 43:

Attributes of the junction element

Table 44:

Attributes of the junction connection element

Table 45:

Attributes of the junction connection laneLink element

Table 46:

Junction with id 1

Table 47:

Roads

Table 48:

Lane links

Table 49:

Attributes of the junction priority element

Table 50:

Attributes of the junction predecessorSuccessor element

Table 51:

Attributes of the junction surface CRG element

Table 52:

Attributes of the junctionGroup element

Table 53:

Attributes of the junctionGroup junctionReference element

Table 54:

Attributes of the junction controller element

Table 55:

Attributes of the road objects object element

Table 56:

Attributes of the road objects object repeat element

Table 57:

Attributes of the road objects object outlines outline element

Table 58:

Attributes of the road objects object outlines outline cornerRoad element

Table 59:

Attributes of the road objects object outlines outline cornerLocal element

Table 60:

Attributes of the road objects object material element

Table 61:

Attributes of the road objects object laneValidity element

Table 62:

Attributes of the road objects object parkingSpace element

Table 63:

Attributes of the road objects object markings marking element

Table 64:

Attributes of the road objects object markings marking cornerReference element

Table 65:

Attributes of the road objects object borders border element

Table 66:

Attributes of the road objects objectReference element

Table 67:

Attributes of the road objects object laneValidity element

Table 68:

Attributes of the road objects tunnel element

Table 69:

Attributes of the road objects object laneValidity element

Table 70:

Attributes of the road objects bridge element

Table 71:

Attributes of the road objects object laneValidity element

Table 72:

Attributes of the road objects object surface CRG element

Table 73:

Total height calculation by attachment mode

Table 74:

Attributes of the road signals signal element

Table 75:

Attributes of the road objects object laneValidity element

Table 76:

Attributes of the road signals signal dependency element

Table 77:

Attributes of the road signals signal reference element

Table 78:

Attributes of the road signals signal positionInertial element

Table 79:

Attributes of the road signals signal positionRoad element

Table 80:

Attributes of the road signals signalReference element

Table 81:

Attributes of the road objects object laneValidity element

Table 82:

Attributes of the controller element

Table 83:

Attributes of the controller control element

Table 84:

Attributes of the road railroad switch element

Table 85:

Attributes of the road railroad switch mainTrack element

Table 86:

Attributes of the road railroad switch sideTrack element

Table 87:

Attributes of the road railroad switch partner element

Table 88:

Attributes of the station element

Table 89:

Attributes of the station platform element

Table 90:

Attributes of the station platform segment element

Table 91:

Attributes of the unitDistance enumeration

Table 92:

Attributes of the unitSlope enumeration

Table 93:

Attributes of the dataQuality RawData Source enumeration

Table 94:

Attributes of the unitSpeed enumeration

Table 95:

Attributes of the dataQuality RawData PostProcessing enumeration

Table 96:

Attributes of the unitMass enumeration

Table 97:

Attributes of the yesNo enumeration

Table 98:

Attributes of the junction type enumeration

Table 99:

Attributes of the road surface CRG purpose enumeration

Table 100:

Attributes of the junction surface CRG mode enumeration

Table 101:

Attributes of the road surface CRG mode enumeration

Table 102:

Attributes of the junctionGroup type enumeration

Table 103:

Attributes of the elementDir enumeration

Table 104:

Attributes of the contactPoint enumeration

Table 105:

Attributes of the connection type enumeration

Table 106:

Attributes of the roadMarkWeight enumeration

Table 107:

Attributes of the bool enumeration

Table 108:

Attributes of the roadMarkType enumeration

Table 109:

Attributes of the accessRestrictionType enumeration

Table 110:

Attributes of the road lanes laneSection lr lane access rule enumeration

Table 111:

Attributes of the laneType enumeration

Table 112:

Attributes of the road lanes laneSection lcr lane roadMark laneChange enumeration

Table 113:

Attributes of the roadMarkColor enumeration

Table 114:

Attributes of the roadMarkRule enumeration

Table 115:

Attributes of the tunnelType enumeration

Table 116:

Attributes of the borderType enumeration

Table 117:

Attributes of the sideType enumeration

Table 118:

Attributes of the outlineFillType enumeration

Table 119:

Attributes of the objectType enumeration

Table 120:

Attributes of the bridgeType enumeration

Table 121:

Attributes of the orientation enumeration

Table 122:

Attributes of the road objects object parkingSpace access enumeration

Table 123:

Attributes of the station type enumeration

Table 124:

Attributes of the road railroad switch position enumeration

Table 125:

Attributes of the station platform segment side enumeration

Table 126:

Attributes of the road link elementType enumeration

Table 127:

Attributes of the paramPoly3 pRange enumeration

Table 128:

Attributes of the roadType enumeration

Table 129:

Attributes of the maxSpeedString enumeration

Table 130:

Attributes of the trafficRule enumeration

Table 131:

Attributes of the direction enumeration

Table 132:

Attributes of the countryCode deprecated enumeration

Table 133:

Attributes of the road signals signal reference elementType enumeration

Table 134:

e_unit

Table 135:

t_grEqZero

Table 136:

t_grZero

Table 137:

t_zeroOne

Table 138:

e_countryCode

Table 139:

t_maxSpeed

17. Bibliography

[1]

Spatial Reference: EPSG:4326:WGS 84; http://spatialreference.org/ref/epsg/4326/

[2]

ISO: ISO 8855:2011 -Road vehicles --Vehicledynamics and road-holding ability --Vocabulary; www.iso.org/standard/51180.html

[3]

ASAM e.V.: ASAM CRG -Open Curved Regular Grid; www.asam.net

[4]

W3C: Extensible Markup Language (XML) 1.0 (Fifth Edition); www.w3.org/TR/2008/REC-xml-20081126

[5]

Spatial Reference: EPSG:32632:WGS 84 / UTM Zone 32N; http://spatialreference.org/ref/epsg/32632/

[6]

Wikipedia: Euler spiral; http://en.wikipedia.org/wiki/Euler_spiral

[7]

ISO: ISO 8601 -Date and time format; www.iso.org/iso-8601-date-and-time-format.html

[8]

ISO: ISO 3166-1:2013: Codes for the representation of names of countries and their subdivisions --Part 1: Country codes; www.iso.org/standard/63545.html

[9]

ASAM e.V.: Style Guide for ASAM OpenDRIVE Databases; www.asam.net

[10]

Booch, G., Rumbaugh, J., Jacobson, I. (1997): Unified Modeling Language User Guide. Addison-Wesley.

[11]

Robert G. Burger and R. Kent Dybvig: "Printing floating-point numbers quickly and accurately." In proceedings of ACM SIGPLAN 1996 conference on Programming Language Design and Implementation, Philadelphia, PA, USA, May 1996, pp. 108-116

[12]

Ulf Adams: "Ryū: fast float-to-string conversion." ACM SIGPLAN Notices, Vol. 53, No. 4, April 2018, pp. 270-282

[13]

William D. Clinger: "How to Read Floating Point Numbers Accurately." ACM SIGPLAN Notices, Vol. 25, No. 6, June 1990, pp. 92-101