OpenDRIVE 1.6

The following deliverables are provided for OpenDRIVE:

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

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

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

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

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

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

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

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

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

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

[Burger96] 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

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

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

Multiple files can be combined with an <include> tag at the appropriate locations. Upon parsing this tag, OpenDRIVE readers shall immediately start reading the file specified as attribute of the tag. 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 tag under which the <include> tag occurs must be present in both, the parent file and the included file.

Example:

Original File

Included File

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

For geographic reference, the following convention applies:

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 shows the positive axes and positive directions of the corresponding angles.

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.

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:

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.

Superelevation causes a roll in the 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.

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:

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

Within the local system, the following angles are defined:

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.

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

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

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

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

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

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

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

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

XML example:

Rules:

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

By definition, the reference line runs in s-direction, while the lateral deviation of objects from the reference line runs in t-direction.

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

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

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

Attributes

Rules

The following rules apply to road reference lines:

Related topics

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

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

XML Example

Related topics

A spiral is a clothoid that describes a changing curvature of the reference line, as shown in figure 23. Spirals 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.

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

Attributes

XML Example

Rules

The following rules apply to spirals:

Related topics

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

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

Attributes

XML Example

Rules

The following rules apply to arcs:

Related topics

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

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

XML Example

See the sample file Ex_Line-Spiral-Arc.xodr

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.

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.

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.

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

In OpenDRIVE, road linkage is represented by the <link> element within the <road> element. The <predecessor> and <successor> elements are defined within the <link> element. For virtual and regular junctions, different attribute sets shall be used for the <predecessor> and <successor> elements.

Attributes

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

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

Rules

The following rules apply to road linkage:

Related topics

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

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

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

Attributes

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.

Rules

The following rules apply to road types:

Related topics

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

The types of road elevation are shown in figure 39

The s length does not change with the elevation.

The description of the surface of a road is part of OpenCRG, not OpenDRIVE. It is possible to reference data created by OpenCRG in OpenDRIVE. Neither OpenDRIVE nor OpenCRG contain data regarding the visual representation of the road surface. With OpenCRG it is possible to model detailed road surface attributes, for example cobble stone or pot holes, as shown in figure 43.

As the name indicates, CRG data is organized in a regular grid which is laid out along a reference line (comparable to an 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 key to combining 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 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).

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

@mode = attached:

The reference line of the CRG data set is replaced with the 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 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 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 evalvated along the OpenDRIVE reference line instead of the CRG reference line.

@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 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 the below figure.

@mode = genuine:

The start point of the CRG data set’s reference line is positioned relative to the point on the 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 OpenDRIVE elevation data, i.e. the absolute elevation of a given point of the road surface is directly computed from the CRG data (think of it as combining CRG and OpenDRIVE data with the OpenDRIVE elevation, superelevation and crossfall all being zero). 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 OpenDRIVE road.

@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 co-ordinate system. Elevation data is interpreted as inertial data, i.e. AS IS.

@orientation

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 OpenDRIVE data can still be used. In OpenDRIVE, the road surface is represented by the <surface> element within the <road> element. Data described in OpenCRG is represented by the <CRG> element within the <surface> element.

The orientation attribute rotates the CRG file at the origin of the u/v coordinate system of the 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.

Attributes

XML example

Related topics

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

For easier navigation through an 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 number given in the ID attribute, unless @type is bi-directional.

In 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:

Related topics

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.

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.

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

Attributes

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.

For easier navigation through an 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.

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

t_road_lanes_laneSection_left

For easier navigation through an 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.

For easier navigation through an 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.

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

Rules

The following rules apply for lane sections:

Related topics

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.

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

Attributes

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

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

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

s = sstart + ds

where

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

XML Example

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

Rules

The following rules apply for lane offsets:

Related topics

To enable lane navigation, linkage information for lanes may be stored in OpenDRIVE. Linkage is described by means of predecessor and successor information for each lane. Both lanes and junctions may serve as predecessor or successor of lanes. Lanes may be linked to lanes on the same or another road.

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

Attributes

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. This element may only be omitted, if lanes end at a junction or have no physical link.

The following rules apply to lane linkage:

Related topics

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.

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

Rules

The following rules apply for lane properties:

Lanes on roads can have different lane markings, for example lines of different colors and styles. 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:

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

Attributes

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

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.

Rules

The following rules apply to road markings:

Related topics

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

Attributes

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

Rules

The following rules apply to lane rule:

Related topics

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

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

Attributes

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

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.

XML example

Rules

The following rules apply to incoming roads:

Related topics

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 modelled 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 74 and figure 76 show the connecting roads inside the junction area that connect the incoming and outgoing roads.

XML example

Rules

The following rules apply to connecting roads:

Related topics

Roads may be elevated within a junction. This is accomplished by describing the road surface in correspondence with the descriptions used in 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. Because OpenCRG is not part of OpenDRIVE, the <surface> element is not described in this specification..

Attributes

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.

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

Related Topics

Virtual junctions are used to describe connections within a road that do not require the main road to be split up like in normal junctions. By this, virtual junctions can be placed more easily. Their only use case are driveways that lead to parking lots or residential estates.

Figure 77 show how virtual junctionsare applied. The transparent blue roads (road 2,4,5) are part of a virtual junction.

It is not mandatory for road 99 to be defined; It is sufficient to have the connecting roads only.

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

Attributes

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

XML example

Rules

The following rules apply for virtual junctions:

Related topics

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

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

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

Attributes

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.

References to existing junction elements.

XML example

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

Related topics