OpenDRIVE with CityGML

For testing and validation of advanced driver assistant systems and automated driving systems, simulation is used. The complex systems under test do not only need precise and detailed modeling of the road but also a growing amount of information about the roadside environment for sensor simulation, too.

Currently, ASAM OpenDRIVE is fulfilling the task of providing highly accurate (and georeferenced) road descriptions quite well, and it has therefore become the de facto standard in the automotive domain. The newest version, 1.9.0, was published in May 2026. ASAM OpenDRIVE was initially created to describe a road network’s logic for synthetic roads, and modeling “beyond the curbstone” was never in scope. Thus, the reference line-based modeling of ASAM OpenDRIVE causes challenges when it comes to modeling roadside surroundings.

Over time, additional features were introduced to support use cases such as sensor simulation, which require information beyond the road itself, covering roadside environment details and a more comprehensive description of road space. As a result, semantics and geometry for features linked to the road network were incorporated, increasing the overall complexity of the standard.

OGC CityGML is the internationally established standard for storing, modeling, and exchanging semantic 3D city and landscape models at scale. Highly accurate georeferenced, geometric, and topological information, as well as semantic capabilities, are key strengths of OGC CityGML. Different thematic modules are available to cover diverse use cases, including simulations and analyses. The newest version, 3.0, of OGC CityGML was published in September 2021 and contains revised and extended concepts for modeling the street space. Compared to ASAM OpenDRIVE, OGC CityGML follows a fundamentally different geometric modeling paradigm based on polygonal surfaces using explicit coordinates. As a general exchange standard for semantic 3D city and landscape models, OGC CityGML does not cover all automotive domain requirements, such as C² continuous reference lines and the ability to define object geometries relative to them.

Emerging applications, particularly in sensor simulation, place increasing importance on surface and material properties. For a semantically well-defined description of the three-dimensional built and natural environment, OGC CityGML is a suitable candidate. It is widely used for 3D city modeling, supports transformation into visualization-oriented formats such as glTF, and enables interoperability as well as access to existing data sources.

Rather than continuing to expand ASAM OpenDRIVE beyond its core purpose, this concept paper follows a different approach: keeping ASAM OpenDRIVE focused on its strengths while addressing additional requirements through a complementary representation.

The proposal is to continue using ASAM OpenDRIVE for precise road layout modeling (topologic), while representing the appearance of the road (topographic) and especially the surroundings using OGC CityGML. By defining a standardized linkage between ASAM OpenDRIVE and OGC CityGML, use cases that require both a detailed road network and a rich 3D environment can leverage both representations rather than duplicating concepts within a single format. This concept project focuses on:

ASAM OpenDRIVE and OGC CityGML employ fundamentally different geometry modeling paradigms, each well-suited to their respective domains. Consequently, this concept paper treats them as complementary representations with distinct responsibilities.

Given the complementary roles of the two standards, this concept paper retains ASAM OpenDRIVE as the primary entry point for applications accessing road network descriptions, while preserving its full functionality as a standalone solution. If an application requires further information not already contained in ASAM OpenDRIVE, such as the B-Rep geometry of an object, it should be able to retrieve this information from a complementary OGC CityGML dataset. This is achieved by introducing links from ASAM OpenDRIVE objects to their corresponding object representations in OGC CityGML. These links provide complementary geometric, semantic, or appearance information for objects in the roadside environment. Simulation-relevant road infrastructure, such as tunnels, remains represented in ASAM OpenDRIVE so that traffic agents and simulators can access this information without parsing OGC CityGML.

This concept paper focuses on the following principles:

The rationale is that these links constitute a minimal extension to the ASAM OpenDRIVE data model, while applications and simulators relying solely on ASAM OpenDRIVE remain unaffected, as the links are optional. Applications that require a semantic and gap-free representation of the extended road space can operate on the complementary OGC CityGML representation. The complementary OGC CityGML dataset can be directly leveraged by tools from the GIS domain, including spatio-semantic querying in geodatabases, derivation of graphics formats, and streaming to virtual globes. Since the geometry is represented using explicit coordinates, efficient spatial indexes can be constructed to enable rapid geometric queries. As ASAM OpenDRIVE constitutes the primary entry point for road networks, reverse links from OGC CityGML objects to ASAM OpenDRIVE are not necessary.

To ensure compliance with this concept paper, users need to be able to distinguish between requirements, recommendations, permissions, possibilities and capabilities, and external constraints.

The following rules for using modal verbs apply:

ASAM OpenDRIVE is an open, internationally established standard for describing road networks [1]. The current version 1.9.0 was released in May 2026, whereas the prior version 1.8.1 was used by the project group to develop this concept paper. ASAM OpenDRIVE data is encoded using the Extensible Markup Language (XML) with the file extension .xodr. It defines a consistent data model and file format for the structure and attributes of road networks, including geometry, topology, and associated elements.

ASAM OpenDRIVE captures detailed information about road geometry, lane configurations, and road-related objects, such as markings, traffic signs, signals, and roadside features. Practitioners use ASAM OpenDRIVE to represent synthetic as well as real-world road networks. Real-world road networks are georeferenced by offsetting the inertial coordinate system origin using a PROJ-string defined in the header. The standard enables the simulation of accurate and reproducible scenarios and efficient data exchange across tools and platforms.

A central concept in ASAM OpenDRIVE is the continuous reference line, which establishes the road reference line coordinate systems for each respective road. Lanes, markings, traffic signs, signals, and roadside objects are defined relative to the road reference line. Object geometry is typically described parametrically, for example, through cubic polynomials for lane widths or length, width, and height attributes for roadside objects. Object outlines are defined by explicit corner points specified in either the road reference line coordinate system or a local coordinate system. Junctions and lane links model connectivity between roads explicitly and define a coherent, navigable network structure.

ASAM OpenDRIVE uses a modular, extensible design. Its hierarchical XML structure allows elements to include user-defined data through extension mechanisms, for example, the userData element. This design enables domain-specific customization and integration of additional information, such as references to external three-dimensional assets. Interoperability may be limited if tools do not consistently interpret such extensions.

ASAM OpenDRIVE is widely adopted in automotive simulation, testing, and content creation environments as part of the ASAM simulation standards ecosystem. Its standardized, tool-independent format supports the exchange of static road network data between teams and tools.

ASAM OpenCRG is an open standard for describing road surfaces [2]. ASAM OpenCRG defines a file format for the description of road surfaces. The format stores high-precision elevation data from road surface scans. The primary use for this data is in tire, vibration, and driving simulation. Precise elevation data enables realistic endurance simulation of vehicle components or the entire vehicle. For driving simulators, it supports realistic three-dimensional rendering of the road surface. Beyond elevation, the file format can also represent other road surface properties, such as friction coefficients or gray values.

A central concept in ASAM OpenCRG is the curved regular grid (CRG). The CRG method stores road surface data with high memory efficiency, low computation time for file generation and data processing in simulation tools, and high accuracy when positioning the data onto road networks. The basic principle for describing the road surface is to place data into a grid along a road reference line. Line segments are described by a start position and heading angle. The grid is produced by longitudinal cuts (columns) and lateral cuts (rows) along consecutive line segments. Each cell in the grid holds a value, typically the elevation. The road reference line also includes the end position, which can be used to detect and correct potential drift in the placement of data on roads.

ASAM OpenCRG defines ASCII and binary file formats with clear-text headers. The header contains road parameters for the reference line and the overall configuration of the longitudinal sections, a definition of the data format, the sequence of data expected in the trailing data block, and modifier and option parameters. Furthermore, ASAM OpenCRG files may contain references to other files, typically containing the actual data, to handle different parameters for the same dataset.

Data from ASAM OpenCRG can be included in ASAM OpenDRIVE road network descriptions. The dynamic content of driving simulations, such as vehicle maneuvers, can be described with ASAM OpenSCENARIO. Together, the three standards complement each other and cover the static and dynamic content of in-the-loop vehicle simulation applications.

ASAM OSI (Open Simulation Interface) is an open standard for exchanging data between components in distributed driving simulations. The latest version 3.8.0 was released in May 2026 [6]. The standard focuses on environmental perception for automated driving functions. It defines standardized interfaces for integrating sensors, perception algorithms, and simulation environments. The interfaces support interchangeable use of components across tools and frameworks.

A key strength of ASAM OSI is a modular, interface-based design that ensures interoperability and interchangeability of simulation components. ASAM OSI provides object-based environment descriptions and well-defined data interfaces, such as GroundTruth, SensorData, and FeatureData, for consistent communication between simulation models. It uses the Protocol Buffers message format for efficient and scalable data exchange.

ASAM OSI aligns with ISO 23150:2023 for the logical interface of environmental perception in virtual scenarios. ASAM OSI simplifies the connection between automated driving systems and virtual testing environments. It improves the accessibility, flexibility, and reproducibility of simulation-based development and validation.

ASAM OpenMATERIAL 3D is an open standard for describing physical material properties and structuring three-dimensional assets used in simulation environments [5]. Version 1.0.0 was released in 2025 and enables physically accurate representation of materials by defining measurable properties, such as reflectivity, roughness, and electromagnetic behavior, rather than relying on simple material labels.

A key strength of ASAM OpenMATERIAL 3D is support for realistic sensor simulation, for example, light detection and ranging (LiDAR), radar, and camera sensors. ASAM OpenMATERIAL 3D models how signals interact with surfaces. It combines this capability with a standardized approach to organizing three-dimensional geometries, including coordinate systems and object hierarchies, while remaining compatible with existing formats, such as FBX, glTF, and USD.

The separation of material data and geometry, together with the extensible and modular design of ASAM OpenMATERIAL 3D, supports flexible workflows and efficient data exchange across tools and organizations. ASAM OpenMATERIAL 3D is part of the ASAM simulation standards ecosystem. It improves interoperability and enables consistent, high-fidelity virtual environments for testing and validation.

glTF is a 3D transmission format developed by the Khronos Group, designed for the efficient exchange of 3D scenes and models. The current version 2.0.1 was published in 2021 [12] and issued as ISO/IEC 12113 standard in 2022 [13]. glTF is based on a hierarchical scene graph with concepts for cameras, meshes, materials, textures, images, skins, and animations. It provides a JSON-based encoding with separate binary and texture assets, and a self-contained binary encoding. The geometry model of glTF is optimized for rendering and comprises triangle meshes, lines, and points, all stored using single-precision floating-point data types.

Meshes can be hierarchically grouped and assigned names. Moreover, glTF provides a mechanism for extensions, allowing the format’s capabilities to be expanded beyond its core specification.

The ISO 19100 series is developed within the ISO Technical Committee 211 (ISO/TC 211) and provides a foundation and framework for the development of geographic information standards. It comprises around 100 standards, which are used by national mapping agencies and supranational initiatives, such as the Infrastructure for Spatial Information in Europe (INSPIRE), to realize their spatial data infrastructures. Since their development began in the mid-1990s and their initial release followed in the early 2000s [14], these standards form the framework for developing interoperable data models in the GIS domain, ensuring compatibility with established GIS software. The standards most relevant to this concept project are briefly summarized below.

The Geography Markup Language (GML) is an XML-based encoding standard for the transport and storage of geographic data. It is jointly developed and maintained by the Open Geospatial Consortium (OGC) and ISO, and is published as ISO 19136. The version 3.2.2 of GML was published in 2016 [27].

GML 3 is a meta-format that provides a modeling framework for defining application-specific exchange formats for geographic information. The standard itself only defines abstract elements and types, along with a wide range of directly usable geometry and topology elements, but does not prescribe a concrete exchange format. Concrete exchange formats result from the definition of application schemas, in which application-specific types and elements are derived from the abstract GML3 types and elements through extension or restriction.

GML is based on standards from the ISO 19100 standards series. The geometry and topology model of GML is based on ISO 19107, providing encodings for all corresponding geometry and topology classes. The feature model follows ISO 19109, which defines AbstractFeature as the base class for all geographic features. Temporal concepts and datatypes are drawn from ISO 19108, and general datatypes such as Date, Time, DateTime, Integer, Real, Vector, URI, and Measure are adopted from ISO 19103.

GML 3 is the most comprehensive standard worldwide for the representation and lossless exchange of geographic data. It supports 0D, 1D, 2D, and 3D geometries, including primitives, complexes, and aggregates, as well as topology, temporal concepts, coverages, and observations. Geographic data models defined in GML can make full use of object-oriented modeling principles, including class hierarchies with aggregation and specialization, complex datatypes, and multiple geometries per geographic object. GML files are both machine and human readable, facilitating automated processing as well as manual inspection. Well-known geospatial application schemas built on GML include OGC CityGML, ALKIS, IndoorGML, AIXM, and the INSPIRE data themes, each defining their own exchange format while applying the same XML mapping rules and shared geometry encodings.

Despite its comprehensiveness, GML has several practical limitations. Its high complexity makes familiarization and implementation laborious, though most GML application schemas mitigate this by defining GML profiles that restrict the full set of possible representations to a manageable subset. Furthermore, GML files tend to be large due to the inherent verbosity of XML, though this can be effectively mitigated through standard compression formats such as GZIP and ZStandard.

The OGC CityGML standard defines a conceptual model [3] and exchange format [4] for the representation, storage, and exchange of virtual 3D city and landscape models. Version 3.0 of the conceptual model was published by the OGC in 2021 and is based on standards from the ISO 19100 standards series. The GML encoding was published in 2023 and implements all concepts from the conceptual model (following ISO 19136). Besides the GML encoding, OGC CityGML data can also be exchanged using CityJSON, which encodes a selected set of the OGC CityGML concepts in JSON, and represented on relational databases, such as the 3DCityDB.

The CityGML standard supports a variety of cross-domain applications in Smart Cities and Urban Digital Twins. City, regional, and state authorities use CityGML to maintain city models encompassing buildings, bridges, tunnels, street furniture, and further urban features. In recent years, official government authorities have released an increasing number of CityGML datasets as open data with stable object identifiers and high absolute accuracy in the low centimeter range while ensuring consistent quality. For example, the entire building stock of Germany, the Netherlands, Poland, Switzerland, and large parts of Japan are available as open data [28, 29].

Figure 2 shows the module structure of OGC CityGML 3.0 from Kolbe et al. Red highlights mark the thematic modules; the horizontal modules contain concepts applicable to all thematic modules. The Core module comprises the class AbstractFeature, which is the abstract superclass of all feature types within the OGC CityGML Conceptual Model and is based on the General Feature Model of ISO 19109. The geometric extent of a feature can be described using the geometry type GM_Envelope, defined in ISO 19107, which represents an Axis-Aligned Bounding Box (AABB). Each feature’s envelope can be used to build spatial indexes and to search for geometries spatially, without evaluating the full geometry.

Figure 3 shows the UML diagram of City Models and City Objects from Kolbe et al. [3]. A city model aggregates different types of objects, including city objects and appearances; each AbstractFeature has a unique identifier valid in the instance document within which it occurs.

The Core module also introduces the space concept shown in Figure 4.

Figure 4 shows the UML diagram of the space concept from Kolbe et al. [3]. A space represents an entity with volumetric extent in the real world; space boundaries delimit and connect spaces. Examples include buildings, rooms, trees, and traffic spaces. Typical space boundaries include wall surfaces that bound buildings and road surfaces that form the boundary of a traffic space to the ground. In addition to physical spaces, logical spaces can be represented by non-physical, virtual boundaries—for example, city districts bounded by administrative boundaries, public areas as opposed to security zones at airports, and urban areas subject to specific planning regulations.

Spaces and space boundaries can have multiple geometry representations depending on the Level of Detail (LOD), as shown in Figure 5.

Figure 5 shows the UML diagram of geometry and Level of Detail (LOD) concept classes from Kolbe et al. [3]. For example, OGC CityGML’s Construction module defines WallSurface, which inherits from AbstractThematicSurface. An AbstractThematicSurface can be geometrically represented using multi-surfaces in LOD 0, 1, 2, and 3. AbstractOccupiedSpaces can also be represented using implicit geometries, which is useful for semantic objects having the same geometry representation, such as traffic lights, where the geometry is defined once and instantiated at different positions by reference.

In particular, the Building module is widely used, because many national mapping agencies provide their building models at LOD2 as open data [28, 29]. Mapping agencies typically reconstruct these building models from building footprints held in the cadastral registry, and reconstruct the roof shapes from airborne laser scanning point clouds.

Figure 6 illustrates different geometric representations of the same semantic building object at increasing Levels of Detail (from Kolbe et al. [3]). Coarser LODs use simplified envelopes or block models; finer LODs add roof structure, façade detail, and semantic decomposition. This multi-LOD principle allows the same city object to be exchanged at the resolution appropriate to the application, from regional overviews to detailed façade analysis. The Transportation module was substantially revised in version 3.0. It enables the modeling of transportation infrastructure at different levels of granularity, providing a comprehensive, semantic, and gapless representation of the road space [30, 31].

Thematic objects inheriting from AbstractCityObject can be enriched with generic attributes defined in the Generics module. This allows user-specific information not covered by the standard model to be attached to any object. Furthermore, the OGC CityGML data model can be extended through a mechanism called Application Domain Extensions (ADEs), which enable formally defined, schema-level extensions using UML.

Because the geometries are based on ISO 19107, OGC CityGML georeferences all coordinates of geometries to accurately represent real-world cities and landscapes of larger extents. Locally referenced models can also be represented in a local coordinate system, in which case EPSG:0 is typically specified as the coordinate reference system (CRS).

3D Tiles is an open specification for streaming and rendering massive 3D geospatial datasets, organized into hierarchical tilesets using spatial data structures like quadtrees and octrees. The current version 1.1, issued in 2023, uses glTF 2.0 as its tile format [32]. The global coordinate system for a tileset is typically defined in the WGS 84 Earth-centered, Earth-fixed (ECEF) reference frame (EPSG 4978), while it defines individual tile content in glTF 2.0 in a local coordinate system. While the specification defines the data structure and tile formats, the standard leaves visualization decisions to the client, with an optional styling specification available for applying declarative styles to tilesets.

OGC 3D Tiles enables the streaming of massive point clouds and textured meshes to virtual globes. Moreover, the standard is commonly used for web-based and interactive visualization of semantic 3D city models. The derivation of 3D Tiles datasets from OGC CityGML involves selecting information from the object-oriented data structures and mapping it to a glTF scene graph hierarchy. Geometrically, this requires triangulating surface geometries to produce triangle meshes suitable for efficient graphics rendering. Furthermore, relevant visualization attributes must be selected and attached to the resulting mesh geometries in the scene graph.

Traffic simulation predicts or reproduces the movement of many road users in a shared road network over time. It models routes, lane changes, interactions at junctions, and responses to traffic control, rather than the high-frequency tire-road contact mechanics emphasized in vehicle dynamics simulation.

Traffic simulators consume a logical description of drivable space and connectivity, including lanes, lane links, junction areas, and priorities, together with traffic control elements, such as signals, signs, and speed limits. They also require a coherent network without unintended gaps, because discontinuities block valid paths and impair routing and car-following behavior.

The required time resolution depends on the model class and use case, but it is typically coarser than the step sizes used for vehicle dynamics simulation.

Required information includes in particular:

Vehicle dynamics simulation places demanding requirements on environment data.

Simple vehicle models may use only a small number of road surface requests to determine the vehicle’s orientation in three-dimensional space at each simulation time step. More sophisticated vehicle models, however, require significantly more detailed road surface information. Depending on the vehicle and tire model, several tires and multiple contact points per tire may need to be evaluated in each step, which leads to high demands on the performance of tire-road queries.

These requirements are particularly relevant in real-time and hardware-in-the-loop applications, where simulation step sizes can be as small as 1 ms. In such cases, the required road and terrain information must be available with sufficient accuracy and consistency at every simulation step to support stable vehicle and tire model behavior as well as controller update rates.

Road or terrain information is typically requested for a given horizontal position in inertial coordinates, together with an estimated height value. This height estimate can be used to distinguish between overlapping structures at different levels, for example, on bridges, ramps, or in parking structures.

For vehicle dynamics applications, the queried environment should provide continuous and computationally efficient access to relevant surface properties at all required contact locations. Detailed road surface information for these applications can be represented using ASAM OpenCRG [2]. The format stores elevation profiles, friction coefficients, and other surface properties in a grid along a road reference line, and can be linked to ASAM OpenDRIVE road network descriptions.

Required information includes in particular:

Sensor object simulation comprises the simulation of sensors as devices, modules, or subsystems of vehicles or infrastructure. It supports the development, testing, and validation of sensor-based functionalities, including driver assistance systems, automated driving, and intelligent traffic management.

The physical environment and its semantic description can significantly influence sensor behavior and perception results.

The interface and data exchange aspects of sensor object simulation are primarily addressed by the ASAM Open Simulation Interface (OSI) [6]. Environmental perception sensors rely mainly on static environment objects, while lane detection sensors rely on logical lanes and lane boundaries.

Typical update intervals of environmental perception sensors and corresponding sensor models range from 50 ms to 200 ms, corresponding to frequencies of 20 Hz to 5 Hz. A sensor may acquire data at a specific point in time and use the remaining part of the update interval for processing. Accordingly, the environment representation should support sufficiently consistent and efficient access to the required information.

Required information includes in particular:

Rendering and ray tracing sensor simulation comprises physics-based simulation of sensor behavior for cameras, LiDAR, radar, and comparable modalities using three-dimensional environment data. It supports the development, testing, and validation of automated driving and advanced driver assistance systems across the development lifecycle.

Accurate simulation requires physically consistent geometry and material properties to model energy or signal propagation in a virtual environment. Material definitions, geometry-material association, and standardized three-dimensional asset structures relevant to this application class are specified in ASAM OpenMATERIAL 3D [5].

Required information includes in particular:

Buildings along the roadside are particularly common in urban environments.

Figure 7 shows a roadside building from the LOD3 road space model area in Ingolstadt, captured by the A2D2 test vehicle. The image is taken from the A2D2 dataset [33], licensed under CC BY-ND 4.0. This building is used as a recurring example when comparing ASAM OpenDRIVE and OGC CityGML representations in later sections.

Figure 8 shows a second roadside building from the same LOD3 road space model area, also captured by the A2D2 test vehicle [33] (CC BY-ND 4.0). Its non-cuboid footprint makes it a useful contrast to Figure 7 when evaluating oriented bounding box versus outline geometry in ASAM OpenDRIVE.

Traffic lights are signaling devices that direct traffic participants through a set of colored lights indicating when they must stop, proceed, or prepare to stop. Examples are shown in Figure 9 and Figure 10.

Figure 9 shows traffic lights at an intersection, captured by the A2D2 test vehicle [33] (CC BY-ND 4.0). The pole, signal heads, and mounting geometry illustrate why traffic control installations are often represented with explicit 3D geometry in OGC CityGML when clearance or asset visualization is required beyond signal logic in ASAM OpenDRIVE.

Figure 10 shows a traffic light with a different geometry and housing color, as found in the USA. Photo by Tom Barrett on Unsplash (photo). It demonstrates that signal head shape and color scheme vary internationally, which affects how faithfully a single implicit geometry template can represent real installations.