The boundary between geo and BIM is getting fuzzy, but working with IFC models from practice shows that converting BIM data in a format useful in GIS and vice versa is still far from straightforward.
Geographical information systems (geo) data has traditionally been used to model and analyze the living environment at the scale of a city, and Building Information Modelling (BIM) data has been used for the design, construction and management of buildings. In recent years, the boundary between geo and BIM has been quickly getting fuzzy, and there is growing demand to combine both types of data in one integrated environment.
In an integrated environment, an architect (BIM) could take environmental variables (geo) into account while designing a building. And a municipality could then automatically check the design (BIM) against its environmental impact (geo), such as whether it is below the maximum building height, how exposed to noise its residents will be, and how much solar irradiation the building will receive. Building permission procedures would thus become both faster and more reliable, and furthermore 3D city models would be more detailed and up to date: the design of a permitted construction or building is a source for the 3D city model, with added information such as building materials and energy-related attributes that can be used for future planning of the city as well as for the construction’s life-cycle management.
What would it take to realize this vision?
In practice, this integration is not straightforward. Since the 1990s, people have been thinking about reusing BIM (at that time CAD) data in geo applications, and vice versa. But this reuse was still limited to project-based exchanges of data. Even nowadays, the integration of geo and BIM data is still far from straightforward. The geo and BIM worlds have many similarities, but also many differences in their purposes for gathering data, the way they geometrically model identical objects, the level of detail, the software they use, and their open standards: (City)GML and LandInfra/InfraGML for geo and IFC for BIM. Because of these differences, the BIM and Geo data also differ fundamentally from each other, consequently reuse is not trivial.
Semantic mapping
The solutions for the integration of BIM and geo data have so far mainly focused on ‘mapping the semantics’ of features in both data models, or converting geometric objects one-to-one. For example, software such as BIMserver, IfcExplorer and Safe FME all offer the possibility to convert IFC models to CityGML: all elements are converted without selection or post-processing, and geometries are simply converted to a Geo data structure.
This is not a problem for visualization, however, the semantics attached to the boundary surfaces used in geo (e.g. interior wall surface and exterior wall surface) differ from the one of the whole object in BIM (e.g. the solid wall). For meaningful use of IFC data in geo applications, spatial concepts such as ‘rooms’ must be reconstructed by converting, aggregating and simplifying walls and other related elements (modelled in BIM as volumes) into areas that are joined to form a closed volume, (See Figure 1).
What is the aim?
Geo-BIM integration is often brought as a solution, but in practice it is not easy to import any BIM data, structured in the open IFC format, in a meaningful way in geo software, and vice versa. Assuming that the differences between BIM and geo serve a specific purpose, Geonovum, in collaboration with BIM Loket and a number of important stakeholders (Rijkswaterstaat, Kadaster, the municipalities of Rotterdam and The Hague) started a GeoBIM project in 2017 in the Netherlands. This project helped the stakeholders to gain more insight into how BIM data is needed in geo-applications and the other way around, and how an open solution can be developed for these conversions (IFC <-> CityGML) to push the integration further. The research was carried out by research groups from the two respective worlds — 3D Geo-information at TU Delft and BIM at TU Eindhoven.
Also Read: 3D modeling 2.0: Re-imagining the contours of construction
Geometry differences between CityGML and IFC
The project focused on the conversion of the geometry because it is an aspect that seems to have been ignored by previous research (which focused mostly on semantics mapping). Being able to convert the geometry is a necessary step for the reuse of data in software from the other domain; simply mapping them is only a first step, but does not allow use of datasets.
CityGML contains 12 modules for different types of objects such as buildings, bridges, roads, and water (lakes and rivers). They all have an explicit geometry description in 3D. This means that the geometry is described on the basis of boundaries with coordinates. IFC files have many more classes, (more than 1000). Moreover, the geometry is almost never described through an explicit description of the boundary, but much more often by so-called ‘implicit’ geometry. This means that the geometry can be obtained through operations (scaling, translations, rotations, etc). An object is described, for example, on the basis of predefined parametric profiles, (See Figure 2).
The conversion method
The project focused on buildings and there were three IFC models available for (real world) designs in the municipality of The Hague with several thousand (!) elements per file, (See Figure 3). The conversion was developed with the help of two open-source libraries — IfcOpenShell and CGAL.
In the conversion, all relevant (volumetric) elements from the IFC files are converted to CityGML classes with associated geometry. Relevant here means all elements that, according to the IFC standard, form an “important functional part of a building” and are relevant in a Geo context, examples of these are IfcBeam, IfcDoor, IfcChimney, IfcColumn, etc.
Results
Visually, the results obtained were nice. But unfortunately, it had to be concluded that the IFC files, which were exported automatically from BIM software by the architects, contained so many errors (more than 150 per IFC file) that it proved impossible to generate error-free geo geometries that are needed for spatial analysis. Often the conversion was impossible because these invalid objects made the software crash.
These errors were mostly errors from a geo perspective; they pose not per se a problem for BIM professionals. Firstly, because most BIM software can handle these ‘errors’: implicit geometries are only errors after they have been converted to explicit geometries. And secondly, because BIM modellers are focused on designing a digital plan (and not making data for spatial analysis). For this purpose, the geometrical errors are not a problem.
Most common mistakes
The most common (geo) errors in IFC files were: non-planar surfaces, self-intersecting volumes, and intersections between two different elements. Especially the self-intersections were interesting (See Figure 4), because the IFC standard explicitly prohibits them. Apparently, this is not controlled by the BIM software used (or the export to IFC created these).
Further processing of the geometries (as shown in Figure 1) is only possible with correct geometries. Therefore, a detection and repair solution was developed for many of these errors. A solution for all possible errors for the dozens of possible IFC geometry types, however, was not realistic in the scope of this project and consequently an automatic conversion from (any) IFC file to a file that can be used in Geo software was unfortunately not possible.
Another problem that made automatic conversion much more difficult than expected, is that IFC has so many classes and there are no or hardly any validation tools, that in practice IFC models can be very different for identical situations, even within the same file. For example, most walls or columns can be built by sweeping a profile of their base upwards but also by a side profile sideways.
A conversion that takes all possibilities into account is impossible to develop or only for (very) large companies.
In conclusion, a conversion of ‘ideal’ IFC models, generated in a controlled manner is possible (as also frequently studied in science). However, due to the ‘errors’ in real-world IFC models (often exported from BIM software) and the large variation in IFC models, automatic conversions to CityGML for spatial analysis with real-world IFC models are much less straightforward.
The Open Geospatial Consortium confirmed these challenges in a project on the use of IFC and CityGML in urban planning. They identified inconsistencies in coding IFC elements that complicate the transformation to CityGML and conclude that in order to adopt IFC in urban planning, a clear set of specifications needs to be set for the preparation of IFC files.
Guidelines
Instead of investing even more time in detecting and fixing even more errors for even more possible IFC alternatives, it seemed better to formulate guidelines for modeling IFC data so that automatic conversion to Geo data becomes possible (as also recommended in the OGC project).
These guidelines (see box above) could be used as strict requirements for specific use cases, such as those from a licensing process, to more general guidelines that should apply at national or even international level to all IFC files in order to achieve better integration between the BIM and Geo world.
The focus is on preparing IFC data. Of course, it also needs to be considered how geo data can be prepared, so that it is better accessible to BIM applications.
It should be noted that it is mostly the end-user software that does the conversion from its own proprietary data format to IFC without the user having much control over the conversion. Therefore, support of these guidelines in mainstream BIM software will further help GeoBIM integration.
Finally
Geo-BIM integration offers many possibilities, as many studies, pilots and showcases have already shown. But working with IFC models from practice shows that converting BIM data in a format useful in Geo and vice versa is still far from straightforward. An unambiguous and specific modelling of IFC is necessary to be able to automatically convert a model from the BIM domain, consisting of a large number of geometrical elements (often with volumetric and parametrised geometries), to aggregated objects suitable for Geo analyses. Only then will the numerous potential applications of Geo-BIM integration become feasible. Making agreements for such restricted data, expressing these in open standards and strictly following these standards is an important first step.
Acknowledgment
This project received funding from the European Research Council (ERC) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 677312 UMnD: Urban modelling in higher dimensions).
Abdoulaye Diakité, University of New South Wales, [email protected]
Thomas Krijnen, Technical University Eindhoven, [email protected]
Francesca Noardo, Delft University of Technology, [email protected]
Friso Penninga, Geonovum, [email protected]
Jantien Stoter, Delft University of Technology & Kadaster & Geonovum,
[email protected]
Ken Arroyo Ohori, Delft University of Technology, [email protected]
Hugo Ledoux, Delft University of Technology, [email protected]
