Delft University of Technology
Geo-BIM data integration: easier said than done?
Stoter, Jantien; Arroyo Ohori, Ken; Ledoux, Hugo
Publication date
2018
Document Version
Final published version
Published in
Geospatial World
Citation (APA)
Stoter, J., Arroyo Ohori, K., & Ledoux, H. (2018). Geo-BIM data integration: easier said than done?
Geospatial World, 9(4), 35-38.
Important note
To cite this publication, please use the final published version (if applicable).
Please check the document version above.
Copyright
Other than for strictly personal use, it is not permitted to download, forward or distribute the text or part of it, without the consent of the author(s) and/or copyright holder(s), unless the work is under an open content license such as Creative Commons. Takedown policy
Please contact us and provide details if you believe this document breaches copyrights. We will remove access to the work immediately and investigate your claim.
This work is downloaded from Delft University of Technology.
Geo-BIM data
integration:
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.
By Jantien Stoter, Ken Arroyo Ohori and Hugo Ledoux
G
eographical 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 envi-ronmental 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 reli-able, 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 mate-rials and energy-related attributes that can be used for future planning
Easier said than done?
Geo-BIM data
integration:
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 straight-forward. 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 Neth-erlands. 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. Geometry differences between CityGML and IFC
The project focused on the conversion of the geometry because it is an aspect that seems to
Figure 1: The different modelling approaches of BIM on one hand (a collection of volumetric elements) and geo on the other (spaces are modelled by means of observable surfaces). Source: Claus et al 2009.
Figure 2: IFC has several predefined parametric profiles, such as those based on the characters U, L, Z, C and T (left) or based on trapezoids, rectangles, circles and ellipsoids (right).
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 descrip-tion 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 prede-fined parametric profiles, (See Figure 2).
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 (volumet-ric) elements from the IFC files are con-verted 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.
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-in-tersections 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
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 mod-els are much less straightforward.
The Open Geospatial Consortium con-firmed 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 prepara-tion of IFC files.
Guidelines
Instead of investing even more time in detecting and fixing even more errors for
Figure 3: Two of the three IFC files used in the municipality of The Hague: CUVO Ockenburghstraat, courtesy of KOW architects (left) and Rabarberstraat 144, with thanks to Studioschaeffer (right).
Figure 4: Three examples of errors found in the IFC files
Results
Visually, the results obtained were nice. But unfortunately, it had to be concluded that the IFC files, which were exported automat-ically 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 conver-sion 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 prob-lem 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
of these errors. A solution for all possible errors for the dozens of possible IFC geom-etry 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.
even more possible IFC alternatives, it seemed better to formulate guidelines for modeling IFC data so that automatic conver-sion 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 pro-cess, 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 soft-ware will further help GeoBIM integration. Finally
Geo-BIM integration offers many possibil-ities, 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 para-metrised geometries), to aggregated objects suitable for Geo analyses. Only then will the numerous potential applications of Geo-BIM integration become feasible. Making agree-ments for such restricted data, expressing these in open standards and strictly following these standards is an important first step.
Acknowledgement
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, a.diakite@unsw.edu.au
Thomas Krijnen, Technical University
Eind-hoven, t.f.krijnen@tue.nl
Francesca Noardo, Delft University of
Technology, F.Noardo@tudelft.nl
Friso Penninga, Geonovum,
f.penninga@geonovum.nl
Jantien Stoter, Delft University of Technology & Kadaster & Geonovum, j.e.stoter@tudelft.nl
Ken Arroyo Ohori, Delft University of Technology, g.a.k.arroyoohori@tudelft.nl Hugo Ledoux, Delft University of Technology, h.ledoux@tudelft.nl
Correct use of IFC
The first obvious guideline for IFC modeling for geo is to strictly follow the available regulations for proper use of IFC and to have BIM software support these guidelines. The IFC standard, but also additional implementation guidelines prescribed by the international standard-ization organstandard-ization buildingSMART, prescribe which IFC classes and attribute values are to be used in what cases. They also prescribe that redundant or inter-secting objects should be avoided. Unfor-tunately, these guidelines are not always followed (and assured) in practice. Conse-quently, in practice standardized IFC data, which meet the guidelines required for automatic conversion, do hardly exist. Georeferencing
Another important required guideline concerns the georeferencing of IFC data in a way that is understandable for BIM professionals. Although georeferencing is a fundamental requirement for using IFC data in geo at all, in practice
georefer-encing of BIM data is far from self-evident. In theory, latitude and longitude can be indicated in the IFC file with an offset from the North. However, in practice these values are often set to ‘0’, or they refer to a completely wrong (probably a default) location or to an ‘approximate’ location (a point in the city in question).
Georeferencing is complicated by the fact that different versions of IFC have different notation values for the longi-tude: a positive value is in IFC2x3 east of the 0-meridian and in IFC4 west of the 0-meridian. For architects georeferenc-ing is not always useful, because of their local focus. That is why making architects aware of the value of georeferencing, is an important part of the solution, helped by tools. For example, we developed a web service that reads an IFC model and then shows it at the location recorded in the IFC file.
The user can then see where her IFC file is positioned. If this location is incor-rect, the user can indicate the correct location, after which the coordinate
infor-mation in the IFC file will be overwritten. Formal agreements about modelling methods
Other guidelines that are recommended for generating geometrically valid objects (and enforcing it with a greater availability of validation tools) and for modeling concepts that may not be relevant for an architect, but they are for spatial analysis, and which are very difficult to reconstruct afterwards, e.g. a (correct) geometric representation of ‘spaces’ (rooms, halls and stairways). A final guideline is to make formal agree-ments on how specific situations should be modeled with IFC. In addition, avoid as much as possible the generic class IfcBuildingElementProxy (which seems to be frequently used), but instead use one of the numerous specific classes, preferably a class that can be directly mapped with a CityGML class (such as IfcSlab).
Guidelines for preparing IFC data for better Geo-BIM integration
