Experts’ Voices: Hacks and the City

September 30th, 2024 | by GEONATIVES

Posted On September 30, 2024

_{(9 min read)}

Describing the real world in computer-readable formats has been part of the business for a very long time. Almost every artifact can be described in a dedicated format. But with the introduction of concepts like Smart Cities it became necessary to connect information across the silos in which they were held.

There are two ways to achieve this. The first is to declare specific formats for each purpose industry-relevant standard, define conversion mechanisms and have everyone adhere to them so that a seamless data exchange is possible. The second is to extend existing formats beyond their original purpose and, thus, have them aggregate concepts and information from other domains.

For two of us GEONATIVES, their first experience with CityGML lay in the “old days” when environments for driving simulation applications were to be created procedurally. At that time, CityGML was considered as one of the target formats in which to store the results of the (procedural) generation of the environment next to the road. Although it had interesting features for describing buildings in several levels of detail (LODs), it was lacking some key features, especially when it came to describing the road network.

But things have changed considerably since then. Let’s first look at the buildings:

CityGML was designed to describe virtual models of the urban environment including buildings, streets, vegetation and other city objects and their arrangement on a city-wide scope. The latest version of the conceptual model of CityGML was published in 2021 and contains revised and extended concepts. Four levels of detail are available, and building interiors may be added in each level. Concepts for the detailed representation of transportation infrastructure, time-dependent information or versioning as well as new concepts for representing constructions have been added. This leads to the question how CityGML models differ from artifacts described in Building Information Modeling (BIM) and its commonly used standard Industry Foundation Classes (IFC). BIM models are used by architects and operators for the detailed description of buildings and other physical structures. So, you would expect that BIM and CityGML interact seamlessly.

But, as Christof explained, there are significant differences. You can image the interior described in a CityGML model as the collection of all details that can be seen when walking through a building or scanning it with a laser scanner. Typically, existing physical objects of urban environments are represented. In contrast, BIM models represent objects over their entire lifecycle from the planning, over construction to deconstruction stage. Artifacts contain also all the hidden features, i.e. what is in the walls, ceilings and floors such as supply and utility lines, ventilation facilities and building support structures. This information is usually derived from the building planning stage.
CityGML data is rather used by city planners, i.e. it reflects what’s needed for cadastral purposes, whereas BIMs are used by building planners. Another difference is the scale typically represented within the two modeling domains. While BIM models literally represent every wall socket or construction joint in a building on the scale of individual sites, CityGML models usually represent whole cities or regions. Depending on the chosen level of detail and the desired application, these city-wide models may model objects such as buildings with more generalized geometries.

BIM is not a good fit to describe structures across large areas, since accurately geo-referencing BIM models can be an issue. The artifacts consisting of individual BIM models are often planned in a local coordinate system or merely use anchor points and orientation for placing a model at a certain location. CityGML models, in contrast, describe geo-referenced aggregations of artifacts on a city scale or even larger areas using absolute world coordinates. This is especially important when at some point even the curvature of earth may become relevant. For example, bridges crossing more than 1 km already have to face a downward deviation by up to 1 cm.

Another difference between IFC and CityGML is the object modeling paradigm typically applied for representing geometries. While BIM models are usually represented using Constructive Solid Geometries (CSG), CityGML uses a Boundary Representation (B-rep). These differences present a challenge when converting models from one format to the other. However, there are some methods for BIM-GIS integration. Usually BIM models are integrated into city models using an ETL process (extract, transform, load).

Extending the standard

But – coming back to our original statement that formats adapt to wider use cases by providing additional features – how do you get additional information into your CityGML model, even though the original format has not foreseen it? Concepts of CityGML can be extended by either defining additional generic classes and attributes or by using the built-in extension mechanism called Application Domain Extensions (ADEs). ADEs are a formal extension to extend the CityGML data model with additional concepts.

The CityGML process for establishing an ADE starts with creating XML schema definitions (XSD) or a UML model and then feeds into the elements required by the CityGML framework. An ADE is a bit like the Wild West in an otherwise orderly world. Anyone who sees a need for extending the original standard format (which is well-managed within the OGC’s processes) can start with an extension. The mechanisms for the extension are a built-in feature of the standard, so the HOW of an extension is managed. Just the what is widely open…

ADEs provide a low bar for adopting the standard to specific use cases, but they are not managed by a supervisory board so that, theoretically, different ADEs may overlap in scope, conflict in terms of concepts, or even be redundant. On the other hand, the effort of establishing an ADE is significant, so that, typically, it will be shared among several experts who should have an interest in not reinventing or contradicting something that is already available. Still, there is some risk involved.

With Christof, we took a quick overview of the available ADEs and, in particular, at the Utility Network ADE. The Utility Network ADE, driven by TUM, describes a city’s infrastructure for supply and disposal in 3d.

The Transportation Module

What caught our attention, though, is CityGML’s transportation layer. Not least because we have all formerly been involved in describing road networks for driving simulation using guidelines and formats like Road2Simulation and ASAM OpenDRIVE.

The Transportation Module for adding information about road and other transportation networks (such as predecessor/successor information, junctions and roads sections, holes, etc.) to a CityGML model was already available in CityGML 2.0 but has now – with version 3.0 – been revised and extended. This guarantees management and professional review within the OGC processes. A key intention is to describe road networks to an extent that they may be exchanged with other established formats like ASAM OpenDRIVE and uses ISO 19107 Spatial schema to model the assets e.g., with GM_MultiCurve. Transportation infrastructure can be modeled using different geometric representations including linear, areal or volumetric geometries.

The effort was mainly driven by projects with municipalities (e.g., the city of Munich and more than 100 Japanese cities in a joint project) that wanted to consolidate their cadastral data with lane-accurate road information. The goal is an all-encompassing digital twin of an entire city, that may also be used for traffic simulation (even if this means to export part of the data to OpenDRIVE first).

The Transportation Module allows modeling of features for road, railroad and waterway networks in different hierarchical levels of detail and imports concepts from the previously mentioned format OpenDRIVE. Whether the subset of features chosen for the CityGML model will be sufficient for a seamless exchange or export of data into the other formats, still has to be seen. Fortunately, there has just recently been an ideation workshop at ASAM to address the interoperability of OpenDRIVE and CityGML. It should lead to a consolidated approach.

Despite its promising features, the Transportation Module of CityGML is not yet widely used among the otherwise large user basis of CityGML. According to Christof, this has to do with the fact that CityGML is mainly seen as a tool for modeling the building infrastructure and not so much for the detailed road space. Therefore, lighthouse projects like the one with the city of Munich or upcoming ones with other cities will, hopefully, lead to a breakthrough. Nevertheless, the interest of municipalities in the Transportation Module is growing, supported by advertising the benefits of sharable data. The 3D City DB application is already used in many administrations and, therefore, the new features have already been used.

Assuring quality

There are many data sets publicly available in CityGML format. But when it comes to data, having a lot of them does not necessarily mean they are all good for purpose or described in a consistent way (i.e., “dialects” may exist). Therefore, quality assurance is important. As Christof explained, the quality is highly dependent on the providers. If you look, again, at cities like Munich, the conversion of data from cadastral repositories included a lot of manual verification. So, the high quality of the original cadastral data – which was already checked upon its collection – could make it into the data for the CityGML model.

But countries differ in their processes. Therefore, expect not only lots of data being available but also lots of different quality levels. And if you need to fix your data, tools like CityDoctor2 are available. Additionally, there is a quality working group (AG Qual [fun fact: literally translated from German to English it means “working group agony”]) to support the use and application by defining quality attributes and features and publishing them in user guidelines. Also, CityGML provides a Road2Simulation-like guidelines for modeling roads and corresponding infrastructure. But going further to all-encompassing quality checkers on different levels – especially when it comes to the Transportation Layer – might be necessary. The ASAM Quality Checker project might be a good inspiration and, maybe, blueprint for upcoming CityGML data checkers.

Data exchange

Large sets of high-quality data will also be the key to exchanging data among the stakeholders on a large scale. This is currently not the case and may also have to do with the structure of the current user base: municipalities usually don’t look too far beyond the borders of their administrative areas. When working on the level of buildings only, there are hardly any models that may be re-used identically – not only between cities but also within a single city.

Spatial geo-databases natively support the geometry model used by CityGML and thus enable efficient management of large 3D city models including spatial indexing. Standardized data exchange interfaces such as the OGC Web Feature Service (WFS) are also supported by CityGML.

But when opening the scope to the transportation layer, there are lots of standardized assets (road signs etc.) that may potentially be reused. It is, therefore, expected that user communities will increasingly benefit from the standard, provided they find a way to communicate and a platform to exchange their assets.

Time is running

It took roughly 12 years to get from CityGML2 to today’s CityGML3. In this highly dynamic industry, having some rigid guardrails might be good but the question is whether the development cycles really have to be that long. As of today, nobody is looking into something like CityGML4, and will mostly be focusing on adapting version 3, providing examples and/or the occasional ADE. Now, the focus is on adopting the new features in software and creating corresponding data sets. Flagship projects will highlight the benefits and the Open Data Initiative is supporting the establishing of new data sets.

But the pace also has to do with the parties involved. Many of the users are municipalities that, although they are getting more agile as of lately, are largely caught in the processes of administration. Unless the adoption of CityGML3 is high enough and feedback is collected and new feature requests are identified, starting another version is meaningless.

On the other hand, smart cities are high on the list of politics. Getting the energy transition and digitization done won’t be possible without excellent models of transportation and other infrastructure. This could lead to more pressure on getting new features done earlier.

Conclusion

We very much enjoyed the talk with Christof and Benedikt and, caught by the fascination, we overran our original time slot by 50 percent. CityGML is a great and well-established standard for reflecting the buildings and other components of a city in a 3D model. And it is, for very good reason, looking beyond the buildings and into the entire infrastructure. It may need some time for further adoption by its current users and for an extension of the user basis. But cooperation with other standards will certainly help to get a larger real footprint in a virtual world.

Thanks to Christof and Benedikt for the insights.