1. Foreword

ASAM OpenCRG provides an exchange format for the description of static road surfaces. The format can be used by applications for tire simulation, vibration simulation and driving simulation. In addition to the data format for storing and exchanging road surface data, OpenCRG includes a tool suite for creating, modifying and evaluating OpenCRG data.

1.1. Deliverables of OpenCRG

The following deliverables are provided for OpenCRG:

User guide

The User Guides help to get started with the OpenCRG APIs and how OpenCRG can be applied

Sample OpenCRG files

These demo files are explanatory examples

C-API including demo files and test scripts

The C-API is capable of reading and evaluating OpenCRG Files

MATLAB library including demo files and test scripts

The Matlab API can create, manipulate, visualize and validate OpenCRG Files

2. Introduction

2.1. Overview

The ASAM OpenCRG format provides a common format for describing road surfaces. The data in an OpenCRG file usually describes road elevation. OpenCRG file can be used for both synthetic or real road surfaces. The main purpose of OpenCRG is to provide a road surface description that can be fed into simulations and to make these road surface descriptions exchangeable.

2.2. Motivation

OpenCRG comprises open file formats and open source tools for the detailed description, creation and evaluation of road surfaces. As basic functionality OpenCRG describes the geometry of the road surface based on a reference line and a height grid (which can also be used for other scalar data). It is intended for vehicle dynamics, tire, vibration and driving simulations. For these purposes the OpenCRG project provides the following features: ASCII and binary file formats with clear-text headers, an open source C-API for data handling and evaluation and open source MATLAB® API for data manipulation and generation and a library of sample data.

OpenCRG is to be understood as a complementary standard to OpenDRIVE. While OpenDRIVE files are describing road networks with respect to all data belonging to the road environment, OpenCRG describes the road surface in detail. OpenDRIVE allows the referencing to OpenCRG files.

2.3. 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 Modal verbs, are normative.

  • Keywords of OpenCRG data structures in "Keyword" sections are normative.

  • Content descriptions of OpenCRG data structures in "Contents" sections are normative.

  • Rules for OpenCRG data structures in "Rules" sections are normative.

  • The OpenCRG toolsuite and its use are non-normative.

  • Examples and use case descriptions are non-normative.

2.4. Conventions

2.4.1. Naming conventions

In this document, the following conventions apply:

data types are given according to IEEE 754 standard.

2.4.2. Units

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

  • position/distance in [m]

  • angles in [rad]

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

2.4.3. Modal verbs

To ensure compliance with the OpenCRG standard, users must be able to distinguish between mandatory requirements, recommendations, permissions, as well as possibilities, capabilities, obligations and necessities.

The following rules for using modal verbs apply:

Table 1. 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 OpenCRG 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 OpenCRG standard.

must
must not

2.4.4. Typographic conventions

This documentation uses the following typographical conventions:

Table 2. Typographical conventions
Mark-up Definition

Code elements

This format is used for code elements, such as technical names of classes and attributes, as well as attribute values.

Code snippets

This format is used for excerpts of code that serve as an example for implementation.

Terms

This format is used to introduce glossary terms, new terms and to emphasize terms.

Mathematical elements

This format is used for calculations and mathematical elements.

2.4.5. 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 OpenCRG within ASAM activities

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

3.2. Relation of ASAM OpenCRG to OpenDRIVE and OpenSCENARIO

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

img1
Figure 1. Relation between OpenDRIVE, OpenCRG, and OpenSCENARIO

3.3. Backward compatibility to earlier releases

ASAM OpenCRG 1.2.0 is backward compatible to OpenCRG 1.1.2.

3.4. References to other standards

  • ISO 8855 for right handed coordinate systems

  • ISO 8601 for time / date

  • ISO 8859-1 for plain-text encoding

  • Georeferencing (ISO DIN 19111)

  • ASAM OpenDRIVE

  • ASAM OpenSCENARIO

  • IEEE 754

4. OpenCRG data format

4.1. Curved regular grids

A curved regular grid represents road surface data in proximity of an arbitrary road centerline. The road surface is tiled into a curved grid. Longitudinal cuts are parallel to the road centerline. Lateral cuts are orthogonal to the road centerline. One road data value is assigned to each tile. Road surface data usually represents road elevation but may also be used for other data, for example friction coefficients.

img2
Figure 2. OpenCRG road surface description using u/v-coordinates and x/y-coordinates.

Curved regular grids use a reference line coordinate system. The road centerline is given by a curved reference line. A curved reference line is defined by series of low-precision heading angles. The u-direction follows the tangent of the reference line. The v-direction is orthogonal to the u-direction. Road surface data is given in z-direction orthogonal to the u/v-plane.

A curved regular grid may be placed in an inertial x/y-coordinate system by providing a high-precision start position in x/y-coordinates. To avoid drift when integrating along the reference line, an optional high-precision end position in x/y-coordinates may be provided. If such a position is provided, both forward integration and backward integration can be used for calculating the position of the reference line. The given start and end positions can be compared to the integration results to distribute errors along the reference line.

Figure 2. OpenCRG road surface description using u/v-coordinates and x/y-coordinates. shows an example of an OpenCRG road surface description.

banking_slope
Figure 3. Schematic drawing of banking and slope.

The reference line may be complemented by slope or banking (see Schematic drawing of banking and slope.).

4.2. OpenCRG data files

An OpenCRG file consists of several data sections that represent different aspects of the road surface data described in that file. OpenCRG files are written in plain text using ISO 8859-1 encoding. The actual road data may be provided in a binary format. Each line in a data section is considered a record. Except for the road data section, a record shall have a maximum length of 72 byte for a maximum of 72 characters per record. In the road data section, a record shall have a maximum length of 80 byte.

Each data section shall start with a line containing a $ character followed by a keyword. Each data section shall be terminated by a new line with a $ character as first character. The keyword at the beginning of a data section and the closing $ character at the end of a data section may be followed by inline comments.

Every OpenCRG file shall start with a header information section, describing the contents of the file. If a road data section is present, it shall be the last section in the OpenCRG file. The sequence of the other data sections is not defined. To increase readability, data sections should appear in the sequence recommended in Overview of data sections in recommended sequence..

4.3. Comments

An OpenCRG file may contain comments with further information about the file. These comments shall not substitute the introductory header information.

There are two types of comments in an OpenCRG file:

Block comment

An asterisk (*) at the beginning of a line causes the entire line to be treated as a comment.

Inline comment

An exclamation mark (!) causes all following characters in this line to be treated as a comment.

4.4. Data sections

4.4.1. Header information

The header information section provides information about the file as human-readable text. For example, a header information section may contain:

  • Title of the file

  • Short description of the contents and purpose of the file

  • Information about creators or issuing organization

  • Copyright information

Keyword
$CT
Contents

The header information section contains unstructured plain text.

Rules

  • An OpenCRG data file shall contain a header information section.

  • The header information section shall be the first section in an OpenCRG data file.

  • The header information section should give information about the content of the file.

Examples
$CT
CRG file example for road surface description (width: 3m, length: 22m)
with curved reference line and grid of (0.25m...1.0m) x 1.0m.

A minimalist file can have an empty $CT, a minimalist $ROAD_CRG block,
and no comments marked by asterisk "*" in column 1 or marked by "!" in
other columns. So this file is completely equivalent to its commented
version in handmade_curved.crg .

Copyright 2005-2009 OpenCRG - Daimler AG - Jochen Rauh

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

More Information on OpenCRG open file formats and tools can be found at

    http://www.opencrg.org
$!*********************************************************************

4.4.2. Road parameters

The road parameters section contains information about the reference line necessary for road reconstruction. With OpenCRG, road data is recorded in relation to the reference line. If an OpenCRG file contains a road data section, a road parameters section is therefore mandatory.

The minimum information necessary for creating a reference line is the distance between lateral cross sections. The REFERENCE_LINE_INCREMENT parameter is therefore mandatory. All other parameters are optional.

Curved regular grids may be placed in an inertial x/y-coordinate system and additionally in World Geodetic System WGS 84 by providing start positions or end positions in the respective coordinate system. The geodetic coordinates are purely informative and not suitable for exact geo-referencing.

Integration along the reference line can lead to error accumulation due to low-precision heading angles. To allow the detection and handling of integration errors, high-precision start positions and end positions in x/y-coordinates are necessary. Applications can then compare the integration result to the given positions.

Keyword
$ROAD_CRG
Contents

The road parameters section contains parameters as key-value pairs.

Parameter Values Description

REFERENCE_LINE_START_U

Double-precision floating-point number (default: 0.0)

u-coordinate of start position.

REFERENCE_LINE_END_U

Double-precision floating-point number (default: calculated from road data)

u-coordinate of end position.

REFERENCE_LINE_INCREMENT

Double-precision floating-point number (default: none)

Distance between lateral cross sections.

LONG_SECTION_V_RIGHT

Double-precision floating-point number (default: calculated from road data)

v-coordinate of the outer right border of the road.

LONG_SECTION_V_LEFT

Double-precision floating-point number (default: calculated from road data)

v-coordinate of the outer left border of the road.

LONG_SECTION_V_INCREMENT

Double-precision floating-point number (default: calculated from road data)

Distance between axial cross sections.

REFERENCE_LINE_START_S

Double-precision floating-point number (default: 0.0)

Slope at start position.

REFERENCE_LINE_END_S

Double-precision floating-point number (default: 0.0)

Slope at end position.

REFERENCE_LINE_START_B

Double-precision floating-point number (default: 0.0)

Banking at start position.

REFERENCE_LINE_END_B

Double-precision floating-point number (default: 0.0)

Banking at end position.

REFERENCE_LINE_START_X

Double-precision floating-point number (default: 0.0)

x-coordinate of start position of the reference line.

REFERENCE_LINE_START_Y

Double-precision floating-point number (default: 0.0)

y-coordinate of start position of the reference line.

REFERENCE_LINE_END_X

Double-precision floating-point number (default: calculated from road data)

x-coordinate of end position of the reference line.

REFERENCE_LINE_END_Y

Double-precision floating-point number (default: calculated from road data)

y-coordinate of end position of the reference line.

REFERENCE_LINE_OFFSET_X

Double-precision floating-point number (default: 0.0)

Global offset for x-coordinates.

REFERENCE_LINE_OFFSET_Y

Double-precision floating-point number (default: 0.0)

Global offset for y-coordinates.

REFERENCE_LINE_START_PHI

Double-precision floating-point number (default: 0.0)

Heading angle at start position.

REFERENCE_LINE_END_PHI

Double-precision floating-point number (default: 0.0)

Heading angle at end position.

REFERENCE_LINE_OFFSET_PHI

Double-precision floating-point number (default: 0.0)

Global offset for heading angle.

REFERENCE_LINE_START_Z

Double-precision floating-point number (default: 0.0)

Elevation at start position.

REFERENCE_LINE_END_Z

Double-precision floating-point number (default: 0.0)

Elevation at end position.

REFERENCE_LINE_OFFSET_Z

Double-precision floating-point number (default: 0.0)

Global offset for elevation.

REFERENCE_LINE_START_LON

Double-precision floating-point number

Longitude of the start position in WGS 84 coordinates.

REFERENCE_LINE_START_LAT

Double-precision floating-point number

Latitude of start position in WGS 84 coordinates.

REFERENCE_LINE_END_LON

Double-precision floating-point number

Longitude of end position in WGS 84 coordinates.

REFERENCE_LINE_END_LAT

Double-precision floating-point number

Latitude of end position in WGS 84 coordinates.

REFERENCE_LINE_START_ALT

Double-precision floating-point number

Altitude of start position in WGS 84 coordinates.

REFERENCE_LINE_END_ALT

Double-precision floating-point number

Altitude of end position in WGS 84 coordinates.
Rules

  • If an OpenCRG file contains a road data section, the file shall also contain a road parameters section.

  • Parameters in the road parameters section shall be provided as key-value pairs using the syntax PARAMETER = value.

  • A road parameters section shall define REFERENCE_LINE_INCREMENT.

  • A road parameters section should define x/y-coordinates of both start position and end position to handle numeric errors in road reconstruction.

  • A road parameters section may define WGS 84 coordinates of the start position and end position if available. These coordinates shall not be used for geo-referencing.

Examples

The following road parameters section defines a 3 m wide road with 45 data points along the reference line. The start of the reference line coincides with the origin of the x/y-coordinate system.

$ROAD_CRG
REFERENCE_LINE_START_U    = 0.0
REFERENCE_LINE_END_U      = 22.0
REFERENCE_LINE_INCREMENT  = 0.5
REFERENCE_LINE_START_X    = 0.0
REFERENCE_LINE_START_Y    = 0.0
LONG_SECTION_V_RIGHT      =-1.50
LONG_SECTION_V_LEFT       = 1.50
$!********************************

4.4.3. Map projection data

The map projection data section contains information necessary for mapping road data to geographic positions. The map projection data section is optional.

A map projection data section shall at least specify a map projection, either by providing the name of the projection or the projection parameters themselves.

If geodetic coordinates use a global ellipsoid other than WGS 84, the ellipsoid shall be specified, either by providing the name of the ellipsoid or the semi-major and the semi-minor axis in case of a user-defined ellipsoid.

A map projection can involve a datum transformation, for example with Gauss-Krüger projections of WGS 84 coordinates. In this case, both a local ellipsoid and a transformation type including all 7 parameters shall be specified.

The map projection parameters PROJ_* are relevant for the generic transverse Mercator projection (PROJ_NM = TM or PROJ_NM = TM_*).