{"id":1122,"date":"2022-05-18T19:00:00","date_gmt":"2022-05-18T18:00:00","guid":{"rendered":"https:\/\/www.geonatives.org\/?p=1122"},"modified":"2023-08-26T23:03:38","modified_gmt":"2023-08-26T22:03:38","slug":"building-a-better-world","status":"publish","type":"post","link":"https:\/\/www.geonatives.org\/?p=1122","title":{"rendered":"Expert Talk with TrianGraphics: Building a Better World"},"content":{"rendered":"\n

(5 min read)<\/sub><\/p>\n\n\n\n

No, this is not a post about a charitable organization. It\u2019s about the people who have been building digital twins<\/em> for the past 20 years \u2013 triangle by triangle.<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

In late November 2021, we enjoyed a web-meeting with Stephan Ku\u00dfmaul, managing shareholder of TrianGraphics GmbH<\/a>, Berlin. TrianGraphics provides tools for creating 3d environment databases for road, rail, and flight simulation applications from various data sources. This product line is complemented by a service team, which builds custom 3d environments.<\/p>\n\n\n\n

Their Domain<\/h2>\n\n\n\n

Stephan explained that TrianGraphics\u2019s databases are mostly created as replicas of real locations; generic databases are not considered of high relevance to their business and if, they are made with the help of real world data as well (cue: \u201cgeo-typical\u201d). The reason is simple: building something that is known to exist and is, usually, already covered by some data source (e.g., maps, aerial imagery) is less controversial than inventing and justifying purely artificial scenes. Or, in short: nothing beats reality.<\/p>\n\n\n\n

Creating databases is a trade-off between fidelity and efficiency. TrianGraphics\u2019s main focus is efficiency at sufficient fidelity level. This is to be seen in contrast to the content of computer games where each polygon might be highly optimized, but the overall extent of databases is small.<\/p>\n\n\n\n

\"\"
Road database (image by TrianGraphics)<\/em><\/figcaption><\/figure><\/div>\n\n\n\n

Scalability is a big aspect of efficiency. When creating flight databases, whole countries may need to be covered, whereas, when creating driving databases, small details matter. Being able to roll out sufficiently large and realistic databases in rather short time is key to TrianGraphics\u2019s success.<\/p>\n\n\n\n

\"\"
Flight database (image by TrianGraphics)<\/em><\/figcaption><\/figure>\n\n\n\n

Building Blocks<\/h2>\n\n\n\n

How do they build their digital twins? First, they don\u2019t start from scratch. For driving simulation, the key to their virtual worlds is an underlying road network, which may originate from real-world surveys (e.g., by companies such as atlatec<\/a> or 3D Mapping Solutions<\/a>, combined with open-source data from, for example, OpenStreetMap<\/a> and complemented by aerial imagery or 3rd<\/sup> party Shapefiles. Processing these data will lead to visual models of the road networks and the general terrain. For buildings and other infrastructure items, TrianGraphics uses rule sets that help populate the map. Structures may be derived from actual footprints (extracted, again, from e.g. OpenStreetMap or 3rd<\/sup> party sources) and by applying design patterns that take the height and type into account.<\/p>\n\n\n\n

This will not necessarily give you the 100 percent visually correct digital twin of a specific location, but the situation that may be experienced by a system-under-test will be deemed realistic. And, at any time, users who want to see a closer match to reality, may add more information to feed the design patterns or even add so-called landmarks, i.e. highly realistic 3d models of actual structures, directly to their scene. The depth of your pocket is the only limit here.<\/p>\n\n\n\n

When asked about users\u2019 preferences, Stephan confirmed that most users in his market segment are looking for realistic databases but not for the ones that are highly geo-specific in all detail. This was also confirmed by the fact that material attribution, used, for example, in physics-based sensor simulation, is not on top of the requirements list for databases at the moment (although TrianGraphics claims capability to provide per-pixel material attribution in their processing pipeline).<\/p>\n\n\n\n

Quality Matters<\/h2>\n\n\n\n

Hardly anything matters more than quality. Therefore, we asked Stephan the question, which is also central to our post on Marketplaces<\/a>: how is the quality of 3d environments quantified? His simple answer: it\u2019s good enough when a customer can fulfill his use case.<\/p>\n\n\n\n

But, of course, it\u2019s not as simple as this short answer might indicate \u2013 especially if you think about objective quantification of quality.<\/p>\n\n\n\n

When using initial data from surveys or map providers, the spatial accuracy of features in a database (e.g. lanes, road signs, road-side elements) is determined by exactly these data. TrianGraphics\u2019s tools provide means to edit imported data but that won\u2019t necessarily increase their accuracy. Therefore, the old principle of garbage-in\/garbage-out also applies to this processing tool chain<\/a> and you are requested to properly select the source data for your projects.<\/p>\n\n\n\n

It\u2019s in the feature-density of 3d environments, where quality can be influenced most and where, on the downside, substantial workload may be created. Depending on the use case, highly detailed vegetation might be of interest, for example, or country-specific texturing of buildings. And often the driving simulator use cases requesting such databases do not require high accuracy<\/a>. Therefore, with a lack of commonly accepted quality indicators for 3d environments, Stephan\u2019s answer is valid: quality is in the eye of the customer.<\/p>\n\n\n\n

Format Wars<\/h2>\n\n\n\n

Another pet subject of our blog is the large variety of data formats<\/a> that exists in various domains. Most prominently, map formats<\/em> are of key interest to TrianGraphics: OpenDRIVE, HD-Live Map, NDS, OpenStreetMap, custom Shapefiles \u2013 just to name a few. Data in these formats provide the base layer for creating 3d environments.<\/p>\n\n\n\n

Standardization has helped quite a bit (see ASAM OpenDRIVE<\/a>) but, still, any two data providers do not necessarily fill the same data format in identical ways. By working with a rather limited set of data sources, TrianGraphics has \u201cprofiled\u201d (read: \u201ctweaked\u201d) their data importers so that data from any of the known sources can be put to work within their pipeline. But, of course, life would be much easier if the same importer could be used for data from various sources (which is basically the idea of standardization).<\/p>\n\n\n\n

As Stephan told us, Shapefiles have proved to be one very versatile way of describing data sets and seem to impose the least workload when it comes to converting their content to anything that can make it through TrianGraphics\u2019s pipeline.<\/p>\n\n\n\n

A quick side note on Shapefiles:<\/p>\n\n\n\n

When talking about Shapefiles, we as GEONATIVES see it as our duty to remind our receptive readers that Shapefiles are an ancient evil from the past: Among many others, hard limits regarding attribute naming, attribute types and character encoding not seldom lead to bad surprises on data consumer\u2019s side<\/a>. We prefer to exchange vector data with OGC\u2019s GeoPackage<\/a>, especially when dealing with more than just flat data models (e.g. HD road network data).<\/p><\/blockquote>\n\n\n\n

Graphics formats for triangulated data (OSGB, FBX, glTF<\/a>, Universal Scene Description<\/a> etc.) are the same story downstream in the pipeline. An FBX export for one game engine may need to be filled differently than an FBX file for another renderer. So the task, again, is with the tool provider and its capabilities to adapt to specific requirements.<\/p>\n\n\n\n

Therefore, to summarize it, data processing the way TrianGraphics does it, isn\u2019t simply garbage-in\/garbage out, it is:<\/p>\n\n\n\n

garbage in \u2013 deciphering \u2013 creating something meaningful \u2013 adjusting \u2013 result out<\/em><\/p>\n\n\n\n

This, in itself, is a pipeline where the 20+ years Stephan and his colleagues have already been in business are quite beneficial.<\/p>\n\n\n\n

Outlook<\/h1>\n\n\n\n

What\u2019s next? The TrianGraphics team seems to be comfortable in its niche of the market: providing medium to high fidelity 3d environments based on a large variety of source data and exported to a no less impressive list of target formats. All of this packaged in a tool that may be licensed to the end-user or which will otherwise be used within dedicated professional services.<\/p>\n\n\n\n

One trend that we currently see in the automotive industry is the sourcing of real-world scenarios from drone captures and other (quasi-)static sensors. Providers of these data are good at extracting dynamic objects\u2019 characteristics like trajectories, types etc. from the data, but building the 3d environment and\/or the road semantics in the respective target formats may be something that might be easier to solve with established tools and services, especially if the scene that has to be created is rather small. For facilitating this process, drones should generate their output in already established data formats.<\/p>\n\n\n\n

Whatever the direction Stephan\u2019s team takes, we will definitely follow the news on TrianGraphics and will sneak in again before long.<\/p>\n\n\n\n

Thanks to Stephan for taking the time to talk to us.<\/p>\n","protected":false},"excerpt":{"rendered":"

In late November 2021, we enjoyed a web-meeting with Stephan Ku\u00dfmaul, managing shareholder of TrianGraphics GmbH, Berlin. Read more about our insights into data formats, terrain generation etc.<\/p>\n","protected":false},"author":4,"featured_media":1130,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,7,12,8],"tags":[58,45,54,57,18],"class_list":["post-1122","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-data-formats","category-data-processing","category-expert-article","category-tooling","tag-data-format","tag-data-lake","tag-expert-2","tag-procedural-generation","tag-simulation"],"_links":{"self":[{"href":"https:\/\/www.geonatives.org\/index.php?rest_route=\/wp\/v2\/posts\/1122","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\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.geonatives.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1122"}],"version-history":[{"count":5,"href":"https:\/\/www.geonatives.org\/index.php?rest_route=\/wp\/v2\/posts\/1122\/revisions"}],"predecessor-version":[{"id":1137,"href":"https:\/\/www.geonatives.org\/index.php?rest_route=\/wp\/v2\/posts\/1122\/revisions\/1137"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.geonatives.org\/index.php?rest_route=\/wp\/v2\/media\/1130"}],"wp:attachment":[{"href":"https:\/\/www.geonatives.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1122"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.geonatives.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1122"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.geonatives.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1122"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}