BIM in the City

May 29th, 2025 | by Andreas Richter

Posted On May 29, 2025

_{(5 min read)}

The description of the world next to the curbstone is part of our professional history when we were dealing with environments for driving simulation. Back in these days there was already the question, which format (e.g., CityGML or Building Information Modeling BIM) would be the best one for this use case. We realized that none of them was the right one because procedurally generated environments with just some data to make them look “real” are different from having a precise and correct representation of the surrounding. Nevertheless, the investigated formats could be used to export the generated environment for other use cases. After having had the detailed talk about CityGML and its interaction with BIM we aim now for making the difference clearer (at least for us).

We have already learned that CityGML is not only for modeling single buildings (and their interiors) but also for city blocks, surfaces as well as road scapes and supplying infrastructure, for example. BIM is focusing on buildings (and their infrastructure) on its own, covering ensembles but not city districts. It’s mainly used for building new objects, thus, the most common use case is integrating BIM in city models. The challenge is that both CityGML and BIM have different information models.

• BIM is based on Industry Foundation Classes (IFC). It uses solid modeling (volumes) to represent buildings.
• CityGML is based on 3d surface and boundary representation for buildings and the environment as well as their positioning.

This means that we have to transform geometries to use data from one format in the other one, and this transformation is a challenge.

BIM to CityGML

BIM focusses on representing the whole infrastructure of buildings or sites, whereas CityGML is only modeling these parts based on their physical aspect (i.e., representing everything that is larger than two meters, roughly speaking) — also with respect to the levels of detail. BIM is used for planning construction sites, and for this purpose it is necessary to know how much cement you need to create your concrete walls. It is also important to see if pipes and wires are intersecting each other or if there is plenty of room. Also you do not want to intersect with already installed reinforcement when drilling new holes for mountings. All of that can be pre-planned with a BIM model and its volume-based modeling.

If these volumes are to be converted to surfaces, a lot of filtering of BIM data with respect to the entities which are important for a CityGML model is necessary. Such entities are walls, spaces, doors, windows and various installations etc. If the relevant data are identified they have to be mapped to the corresponding CityGML classes, while a conversion from volume to surface (or multiple surfaces) has to take place. The mapping can be challenging because roughly 800 BIM classes must be mapped to only 70 classes in CityGML. To make it even more complicated, only 17 of them are really useful for representation of BIM data. Nevertheless, an Application Domain Extension (ADE) can provide additional semantic representation that is missing. This semantic mapping covers the properties of classes and their relations.

Because it’s a topic of general interest the mapping from BIM to CityGML got already official documentation. ISO 19166 supports BIM to CityGML mapping by defining mapping requirements, framework and components to export from BIM to CityGML. ISO 23262 aligns the BIM standard with the GIS standard with the aim of avoiding ambiguities. Nevertheless, the effectiveness has still to be validated and confirmed as it is often the case that “best practice” documents are compiled before a lot of “practice” is available (otherwise nobody would need such kind of documentation any more).

Coming back to the integration. After the mapping has identified, which data goes where, the local coordinate system of BIM has to be transformed to the geographic coordinate system of CityGML. Due to the fact that BIM models only a spatially limited environment, often there is no need to care about earth’s curvature, which has to get compensated by projection systems. The challenge here is that converting from a local to a global coordinate system can often cause loss of accuracy.

The last step is to generate the different levels of detail in CityGML. BIM does not need them because it is all about modeling precisely this one building you want to build. CityGML represents huge districts or even entire cities and this needs a good support for memory management. Level of detail generation always means generalizing objects but not distorting the appearance of the object. Thus, the levels of detail should always be generated as if made from one piece and not detached from each other.

CityGML to BIM?

Ok, what about the other way round? Does it make sense to convert CityGML data into BIM? If you were trying to convert CityGML to BIM you would have to extrude all the surfaces of your model with the highest level of detail to generate the volumes (and spaces). This would lead to ambiguities if you tried this in an automated way because the type and thickness information for all the walls, ceilings and pillars, etc. would be missing. It is not easy to derive this information if you only have a “surface scan” available and don’t know the building from the “inside out”. For more details see results from TU Delft, which tried to benchmark the topic based on various documents and by using a handful of datasets.

The generic transformation often fails because the IFC or 3d representation are not fully compliant to their respective standards. National guidelines are established to tackle the tasks but need alignment among themselves. Often interdisciplinary issues are complicating an agreement on the technical level.

CityGML 3 introduced more concepts to improve interoperability. In addition to the Transportation Module we are interested in how the space concept helps because it fits to the “solid” modeling of BIM. On the other hand BIM extended the IFC to represent cadastral concepts. A comprehensive literature research can be found in this paper about challenges and opportunities of integration of BIM and the GIS.

Instead of integration, referencing could be a solution, too. By referencing, only a link is put into the dataset to guide to the right entry point in the other dataset. The application must be able to parse/query both data sources and represent the combined data in e.g., knowledge graphs (Resource Description Framework). A proxy entry could represent the building in general to create a unified building model. The detailed information remains in the original dataset (which can be either BIM or CityGML) to avoid the need for a “world format.” This solution would be kind of generalizing a summary of the data before going into the details. The summary is realized by a generalized knowledge representation whereas the detailed information is stored in a data format which is made for that special purpose. The disadvantage is that an application must be able to interpret multiple complex data formats but the world will continue to get more complex. Polymath became extinct and collaborations such as federal databases and data lakes are taking over if there is the need of combining data… and often there is a good reason for bringing data together.