One Format to Rule the World?

December 17th, 2021 | by Andreas Richter

Posted On December 17, 2021

_{(4 min read)}

In the automotive domain driving simulation as well as validation and verification are heavy users of digital environments. Beginning with artificial virtual worlds the need for extensively recreating reality is rising fast (read more about format development in our feature about format wars). What started with re-creating the road with high accuracy is now developing in more complex simulation use cases that need also the environment next to the road. The question is: How to model the surrounding if the road description formats are defining only roadside infrastructure and peripheral objects?

Developers of self-driving systems seem to have sufficient funding to develop/model everything necessary on their own (e.g. Cruise). Let’s see how this works if the business has to scale.

In previous projects we have already shown that that real world re-creation works with (temporal and spatial, heterogeneous) geodata. We used different data formats in the whole tool chain to reach our goal: On the one hand domain-specific or custom-made “light weight” formats for intermediate storage and data processing, on the other hand complex formats used by the exporters to feed the final processing tools. There was no “world” format to incorporate every important part (terrain, road, traffic infrastructure, road furniture, vegetation, buildings) of our digital twin. Nevertheless a lot of people are looking for such kind of format at least to combine comprehensive road description with substantial surrounding modeling:

• ASAM OpenDRIVE is established in automotive development domain; it allows to describe mathematically complex road layouts.
• CityGML is established at public authorities and city planners; it allows to describe extensively geo-referenced city models in different levels of detail.

There is currently the agreement among experts that it does not make sense to integrate comprehensive environment modeling into OpenDRIVE. Frankly speaking, it would inflate the whole format unnecessarily.

Transform

One solution is r:trån. It provides a “completion” of CityGML with OpenDRIVE content, thus the tools from geographic information system (GIS) domains can be applied. It converts OpenDRIVE elements into CityGML. Using FME the XML-OpenDRIVE data is transformed to TrafficAreas, which can be visualized together with road markings in CityGML web viewers (some examples are published in a journal paper).

A GDAL/OGR extension can be used to visualize OpenDRIVE in GIS applications. It works by discretizing/sampling of OpenDRIVE’s complex geometry elements into OGC’s Simple Features, i.e., into geometry types Point, LinesString and Polygon. This is probably what all OpenDRIVE-consuming libraries do at the latest when it comes to visualization. (But automotive engineers rarely know about OGC and GDAL.) The advantage here is that, by extending GDAL – being the GIS-domain’s Swiss Knife – many well-established GIS tools implicitly learn to read OpenDRIVE data and a whole new world of data querying, data processing and data transformation opens before you. It is planned to push this yet experimental OpenDRIVE extension to become an official GDAL reader in 2022.

Extend

Currently there is work going on to define an Application Domain Extension (ADE) to extend CityGML with concepts of OpenDRIVE. ADE, in general, offer the possibility to extend CityGML’s data model with additional domain-specific concepts. For example, you can find ADE for representing traffic signs or for analysis of traffic noise pollution. The implementation of an OpenDRIVE-specific ADE is really fresh and, unfortunately, you cannot really find information about it, yet.

Link

But why not linking both formats? The linkage of two specialized formats is a good approach but still lets some questions open:

• First, you have to continue dealing with gaps between the road and the rest of the world and this gets more complex if you deal with larger road networks. Sometimes you have to model environment also between the lanes.
• Second, OpenDRIVE remains being OpenDRIVE and, therefore, is getting complex for large real world situations. Geometry modeling using mathematical functions and linearly referencing all road features to a single 2d reference line has drawbacks with respect to interpretation and ambiguities.

Thus, why not inventing something more suitable in one format?

(Re)Invent

CityGML recently introduced in their version 3.0 a rework of their transportation module. They extended the core idea of defining traffic areas (and on top of it traffic space and on top of this traffic clearance as volumes) in a more elaborated way. The traffic area segments are based on their functional usage and a lot of small puzzle stones will result in the overall traffic area. The idea reminds us of the concept in Lanelet2 (we don’t know who came up with the idea first). But for complex intersections it will get very expensive to calculate the lane you want to drive on (especially if you have to calculate your centerline based on the lane additionally). Already for straight-forward roads with bicycle lanes and, for example, pedestrian crossing you get a handful of traffic areas that have to be combined to calculate the lane of interest.

Simplify

Can’t we simplify complexity? Yes, we can (not only as GEONATIVES ;-). In the previous ASAM OpenDRIVE concept project there was also elaborated a work package that promoted a new approach: The Area Concept. It proposed layered stand-alone polygons for the description of the usable area, for example, for transport modes or traffic participant types, which are linked within one layer or between different (also external) layers. The overall idea is to combine the domains of GIS and driving/traffic simulation and make this data available for a larger number of relevant stakeholders. There are already a lot of ideas and solutions for complex situations incorporated in this concept but there also still is work to do (e.g. regarding the tessellation of irregularly shaped 3d surfaces). The Area Concept got approved by ASAM but is not on the current roadmap. However, hope is near: ASAM is about to prepare a concept project to bring together the Area Concept with CityGML because CityGML’s modules are also providing good ideas and solutions for specific modeling applications. There will, hopefully, be a proposal workshop by the end of January 2022… stay tuned and prepare to enroll and shape the future to model the present!

Acknowledgement

The members of GEONATIVES had leading roles in defining OpenDRIVE as well as the mentioned Area Concept.