{"id":985,"date":"2021-12-17T07:19:00","date_gmt":"2021-12-17T06:19:00","guid":{"rendered":"https:\/\/www.geonatives.org\/?p=985"},"modified":"2022-01-03T20:58:52","modified_gmt":"2022-01-03T19:58:52","slug":"one-format-to-rule-the-world","status":"publish","type":"post","link":"https:\/\/www.geonatives.org\/?p=985","title":{"rendered":"One Format to Rule the World?"},"content":{"rendered":"\n<p class=\"has-text-align-center\"><sub>(4 min read)<\/sub><\/p>\n\n\n\n<p>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 <a href=\"https:\/\/www.geonatives.org\/?p=813\">format wars<\/a>). What started with re-creating the road with <a href=\"https:\/\/www.geonatives.org\/?p=506\">high accuracy<\/a> 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?<\/p>\n\n\n\n<p>Developers of self-driving systems seem to have sufficient funding to develop\/model everything necessary on their own (e.g. <a rel=\"noreferrer noopener\" href=\"https:\/\/www.youtube.com\/watch?v=7BF34b4EMz8\" target=\"_blank\">Cruise<\/a>). Let\u2019s see how this works if the business has to scale.<\/p>\n\n\n\n<p>In <a rel=\"noreferrer noopener\" href=\"https:\/\/www.dlr.de\/ts\/desktopdefault.aspx\/tabid-11264\/19778_read-46760\/\" target=\"_blank\">previous projects<\/a> 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 <a href=\"https:\/\/www.geonatives.org\/?p=584\">tool chain<\/a> to reach our goal: On the one hand domain-specific or custom-made &#8220;light weight&#8221; 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 &#8220;world&#8221; format to incorporate every important part (terrain, road, traffic infrastructure, road furniture, vegetation, buildings) of our <em>digital twin<\/em>. Nevertheless a lot of people are looking for such kind of format at least to combine comprehensive road description with substantial surrounding modeling:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>ASAM <a rel=\"noreferrer noopener\" href=\"https:\/\/www.asam.net\/standards\/detail\/opendrive\/\" target=\"_blank\">OpenDRIVE<\/a> is established in automotive development domain; it allows to describe mathematically complex road layouts.<\/li><li><a rel=\"noreferrer noopener\" href=\"https:\/\/www.ogc.org\/standards\/citygml\" target=\"_blank\">CityGML<\/a> is established at public authorities and city planners; it allows to describe extensively geo-referenced city models in different levels of detail.<\/li><\/ul>\n\n\n\n<p>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.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Transform<\/h2>\n\n\n\n<p>One solution is <a rel=\"noreferrer noopener\" href=\"https:\/\/rtron.io\/wiki\/opendrive-citygml-duality\/\" target=\"_blank\">r:tr\u00e5n<\/a>. It provides a &#8220;completion&#8221; of CityGML with OpenDRIVE content, thus the tools from geographic information system (GIS) domains can be applied. It converts OpenDRIVE elements into CityGML. Using <a rel=\"noreferrer noopener\" href=\"https:\/\/www.safe.com\/integrate\/citygml\/\" target=\"_blank\">FME<\/a> the XML-OpenDRIVE data is transformed to TrafficAreas, which can be visualized together with road markings in CityGML web viewers (<a rel=\"noreferrer noopener\" href=\"https:\/\/doi.org\/10.3390\/ijgi9100603\" target=\"_blank\">some examples<\/a> are published in a journal paper).<\/p>\n\n\n\n<p>A <a rel=\"noreferrer noopener\" href=\"https:\/\/gdal.org\/faq.html#what-does-gdal-stand-for\" target=\"_blank\">GDAL\/OGR<\/a> extension can be used to <a rel=\"noreferrer noopener\" href=\"https:\/\/github.com\/DLR-TS\/gdal\/blob\/ogr\/xodr\/README.md\" target=\"_blank\">visualize OpenDRIVE in GIS applications<\/a>. It works by discretizing\/sampling of OpenDRIVE&#8217;s complex geometry elements into <a href=\"https:\/\/www.ogc.org\/standards\/sfa\">OGC&#8217;s Simple Features<\/a>, i.e., into geometry types <code>Point<\/code>, <code>LinesString<\/code> and <code>Polygon<\/code>. 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 \u2013 being the GIS-domain&#8217;s Swiss Knife \u2013 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.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Extend<\/h2>\n\n\n\n<p>Currently there is work going on to define an <a rel=\"noreferrer noopener\" href=\"https:\/\/doi.org\/10.1186\/s40965-018-0055-6\" target=\"_blank\">Application Domain Extension<\/a> (ADE) to extend CityGML with concepts of OpenDRIVE. ADE, in general, offer the possibility to extend CityGML&#8217;s data model with additional domain-specific concepts. For example, you can find ADE for representing <a rel=\"noreferrer noopener\" href=\"https:\/\/doi.org\/10.5194\/isprsarchives-XL-1-415-2014\" target=\"_blank\">traffic signs<\/a> or for analysis of <a rel=\"noreferrer noopener\" href=\"https:\/\/www.iirs.gov.in\/iirs\/sites\/default\/files\/StudentThesis\/AMOL__MTech_2013-15.pdf\" target=\"_blank\">traffic noise pollution<\/a>. The implementation of an OpenDRIVE-specific ADE is really fresh and, unfortunately, you cannot really find information about it, yet.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Link<\/h2>\n\n\n\n<p>But why not linking both formats? The linkage of two specialized formats is a good approach but still lets some questions open:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>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.<\/li><li>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.<\/li><\/ul>\n\n\n\n<p>Thus, why not inventing something more suitable in one format?<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">(Re)Invent<\/h2>\n\n\n\n<p>CityGML recently introduced in their version 3.0 a rework of their <a rel=\"noreferrer noopener\" href=\"http:\/\/dx.doi.org\/10.5194\/isprs-annals-VI-4-W1-2020-29-2020\" target=\"_blank\">transportation module<\/a>. They extended the core idea of defining <em>traffic areas <\/em>(and on top of it <em>traffic space <\/em>and on top of this <em>traffic clearance <\/em>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 <a rel=\"noreferrer noopener\" href=\"https:\/\/www.mrt.kit.edu\/z\/publ\/download\/2018\/Poggenhans2018Lanelet2.pdf\" target=\"_blank\">Lanelet2<\/a> (we don\u2019t 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.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" decoding=\"async\" width=\"1024\" height=\"434\" src=\"https:\/\/www.geonatives.org\/wp-content\/uploads\/2021\/12\/LayersAndAreas-1-1024x434.jpg\" alt=\"\" class=\"wp-image-1014\" srcset=\"https:\/\/www.geonatives.org\/wp-content\/uploads\/2021\/12\/LayersAndAreas-1-1024x434.jpg 1024w, https:\/\/www.geonatives.org\/wp-content\/uploads\/2021\/12\/LayersAndAreas-1-300x127.jpg 300w, https:\/\/www.geonatives.org\/wp-content\/uploads\/2021\/12\/LayersAndAreas-1-768x325.jpg 768w, https:\/\/www.geonatives.org\/wp-content\/uploads\/2021\/12\/LayersAndAreas-1-1536x651.jpg 1536w, https:\/\/www.geonatives.org\/wp-content\/uploads\/2021\/12\/LayersAndAreas-1.jpg 1640w\" sizes=\"auto, (max-width: 1024px) 100vw, 1024px\" \/><figcaption><em>Example intersection focusing only on the incoming road from the bottom left using overlapping layers (with lanes) vs. unique traffic areas. Each color codes four specific traffic modes resp. nine transport mode combinations. The gray lines should be considered as helping lines for better understanding. (Taichung, image by Andreas Richter)<\/em><\/figcaption><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Simplify<\/h2>\n\n\n\n<p>Can\u2019t we simplify complexity? Yes, we can (not only as <a href=\"http:\/\/geonatives.com\" data-type=\"URL\" data-id=\"geonatives.com\">GEONATIVES<\/a> ;-). In the previous ASAM OpenDRIVE concept project there was also elaborated a work package that promoted a new approach: The <a href=\"https:\/\/www.asam.net\/index.php?eID=dumpFile&amp;t=f&amp;f=3907&amp;token=fffa694711f0cd3cc37e61f38587b3a308e9a720#_concept_paper_wp05_area_model\">Area Concept<\/a>. 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 <a href=\"https:\/\/www.geonatives.org\/?p=289\">stakeholders<\/a>. 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&#8217;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\u2026 stay tuned and prepare to enroll and shape the future to model the present!<\/p>\n\n\n\n<p><meta charset=\"utf-8\"><strong>Acknowledgement<\/strong><\/p>\n\n\n\n<p>The members of GEONATIVES had leading roles in defining OpenDRIVE as well as the mentioned Area Concept.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>More and more use cases need the environment next to the road. Let&#8217;s see if there is a format that can do both: detailed road description as well as the surroundings<\/p>\n","protected":false},"author":2,"featured_media":1006,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,10],"tags":[58],"class_list":["post-985","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-data-formats","category-in-the-news","tag-data-format"],"_links":{"self":[{"href":"https:\/\/www.geonatives.org\/index.php?rest_route=\/wp\/v2\/posts\/985","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.geonatives.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.geonatives.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.geonatives.org\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.geonatives.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=985"}],"version-history":[{"count":15,"href":"https:\/\/www.geonatives.org\/index.php?rest_route=\/wp\/v2\/posts\/985\/revisions"}],"predecessor-version":[{"id":1061,"href":"https:\/\/www.geonatives.org\/index.php?rest_route=\/wp\/v2\/posts\/985\/revisions\/1061"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.geonatives.org\/index.php?rest_route=\/wp\/v2\/media\/1006"}],"wp:attachment":[{"href":"https:\/\/www.geonatives.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=985"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.geonatives.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=985"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.geonatives.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=985"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}