A Critical Review of the Integration of Geographic Information System and Building Information Modelling at the Data Level

Abstract

The benefits brought by the integration of Building Information Modelling (BIM) and Geographic Information Systems (GIS) are being proved by more and more research. The integration of the two systems is difficult for many reasons. Among them, data incompatibility is the most significant, as BIM and GIS data are created, managed, analyzed, stored, and visualized in different ways in terms of coordinate systems, scope of interest, and data structures. The objective of this paper is to review the relevant research papers to (1) identify the most relevant data models used in BIM/GIS integration and understand their advantages and disadvantages; (2) consider the possibility of other data models that are available for data level integration; and (3) provide direction on the future of BIM/GIS data integration.

1. Introduction

Building Information Modelling (BIM) and Geographic Information Systems (GIS) have their roots in different knowledge areas. BIM serves the Architecture, Engineering, and Construction/Facility Management (AEC/FM) domain by providing detailed 3D building models that could be used throughout the lifecycle of a construction project, including plan, design, construction, operation, and dismantling [1,2], while GIS analyses and visualizes location-related problems in geospatial science, environmental science, and natural resource management by integrating heterogeneous spatial data and various attribute data, and deriving knowledge through various spatial analysis tools and modelling approaches [3,4].

GIS and BIM have both witnessed rapid development in recent times. GIS technologies have been around for more than 50 years since the advent of the first well-recognized GIS application, Canada Geographic Information System (CGIS), in 1966 [5]. Over this period, GIS has evolved from a small specialist technology to one that has broad use and impact across many disciplines. For example, governments in the developed countries of Europe and North America profoundly rely on GIS for disaster management [6,7,8]. A recent report from P&S Market Research shows that the global GIS industry had a value of $8.98 billion in 2016, and is estimated to continue to grow at a compound annual growth rate of 10.1%, to reach $17.51 billion by 2023 [9]. As with GIS, the BIM world is also expanding. It is estimated that the global BIM market will grow from $3.16 billion in 2016 to $7.64 billion by 2022 [10]. Due to the growing importance of BIM, many countries, including Japan, UK, and those in the Euro Union (EU), specify or mandate the use of BIM for publicly funded construction and building projects [11].

Before realizing the necessity for merging BIM and GIS, GIS technology has long been applied in the AEC domain. Cheng developed a GIS-based system for real-time erection process monitoring together with barcodes [12], and ArcSite was designed to determine the optimal location for temporary facilities on construction sites [13]. Li used GIS to manage on-site material and equipment to reduce construction waste and improve construction efficiency [14]. Apart from that, GIS has also been applied to optimize the location of tower cranes on construction sites [15,16] and improve safety during construction [17,18].

There is now a trend towards merging BIM and GIS. Figure 1 presents the sum of citations per year from 2009 to 2017 regarding BIM/GIS integration. Since 2009, the number of citations has increased 100-fold from only 3 to 313 citations in 2017. Behind the rising curve is researchers’ growing interest in BIM/GIS integration, which also reflects the significance of this topic.

The aim of this paper is to (1) identify the most relevant data models used in BIM/GIS integration and understand their advantages and disadvantages; (2) consider the possibility of other data models available for data level integration; and (3) provide direction on the future of BIM/GIS data integration.

The reminder of this paper is organized as follows. Section 2 briefly introduces BIM and GIS, and explores the differences and similarities between them, as well as the motivation for integration. Section 3 presents the levels of integration, common data formats involved, and latest methods adopted for data interoperability. A discussion is given in Section 4 on the data interoperability differences between the geometry level and the semantic level, and directions on future study are given. Finally, Section 5 provides the conclusion of this study.

2. Building Information Modelling (BIM) and Geographic Information System (GIS)

2.1. Differences and Similarities between BIM and GIS

BIM has emerged as a method for creating, sharing, exchanging, and managing information among all stakeholders throughout project life cycle [19]. The term “BIM” has two meanings according to Eastman, who introduced BIM into the AEC/FM domain [20]. One means Building Information Model, while the other is Building Information Modelling. The former refers to virtual 3D building models containing rich building information, while the latter means the process of creating and processing 3D building models. The National Building Information Model Standard Project Committee defines BIM as a digital representation of a facility’s physical and functional characteristics, and a shared knowledge resource for information about a facility forming a reliable basis for decisions during its life-cycle, existing from the earliest concept to demolition [21]. The term “Geographic Information System” was first used by Roger Tomlinson in 1968 in his paper “A Geographic Information System for Regional Planning” [22]. Narrowly speaking, GIS is a platform made up with hardware, software, spatial data, and system manager, with various toolsets for heterogeneous data, especially spatial data, integration, storage, manipulation, analysis, and visualization, to reveal patterns, trends, and relationships that might not be directly seen from the original form [23].

The two systems are quite different in terms of focus, scope of interest, reference system, and data storage. BIM attempts to model every aspect of buildings [1], including their structures and appearances, as well as attributes such as owner, history, and cost, for the purposes of structural analysis [24], energy analysis [25], construction cost estimation [26], or building maintenance [27]. Due to the limited extent of buildings, the spatial scope of BIM is relatively small, and a local planar coordinate system (Cartesian Coordinate System) is usually adopted. On the contrary, GIS usually models regional, national space, or even the entire world, including the oceans, continents, and all types of natural and man-made features in 2D or 3D. As a result, the spheroidal shape of the earth must be taken into account in its coordinate system. Note that GIS could also use a local planar coordinate system; however, this is very rare. Due to different philosophies behind BIM and GIS, they use different data structures to store and exchange data, which will be specified in the next section. All those differences make it difficult to achieve full integration of BIM and GIS.

Despite those differences, BIM and GIS do share some common characteristics with respect to data error checking (clash detection/topology analysis) [2], 4D simulation [28], data contents, and extensibility. For instance, both of systems model spatial information, BIM models focus on indoor space, while GIS models focus on outdoor space [29].

2.2. Drivers for Integration

The motivation for merging the two systems arises from both the GIS and AEC domains.

From the perspective of GIS, it was initially focused on 2D data, and its capability in 3D data has been limited. Taking ESRI, for example, its desktop GIS applications, ArcScene and ArcGlobe, can only create 3D models by extruding 2D drawings, and only simple editing functions (such as move, rotate, scale, split, merge, and union) are provided. The models created could reach Level of Detail 1 according to the standard of City Geography Markup Language (CityGML), which are the most basic block models. By far, the best practice for making 3D models for GIS is still using CAD or BIM software, such as Revit and SketchUp. The detailed 3D models created in BIM could not only help GIS extend its scope by applying spatial analysis at a finer scale, for example, using building models to establish indoor networks for emergency response [30], extending noise assessment from regional-level to room-level [31], and evaluating the influence of flood at building level [32], but also better serve the needs of emerging studies on smart cities and finer grained natural hazard impact assessments [33], as well as widening its application in the AEC/FM domain, such as constructing high energy efficiency buildings [34] and minimizing construction waste [35]. The most important contribution of BIM to GIS would be providing detailed 3D building models, as well as their rich building information. All of these aforementioned examples would be hard to realize for GIS without BIM.

As for AEC domain, BIM is targeted at every building-related activity, including plan, design, construction, operation, and demolition. Apart from modelling buildings, the environment is also closely involved in those construction processes. For instance, in the planning phase, the location of a building is to be determined considering various environment factors, such as light, terrain, and heat; in the construction phase, weather conditions (temperature, rainfall) are monitored, as they may affect the construction progress and safety environment; and before demolition, the environmental impact should be fully investigated. Unfortunately, BIM cannot handle those data efficiently. Another reason BIM will benefit from GIS capability is that it needs some of the rich spatial analysis functions from GIS to extend its capability, such as distance calculation for construction material supplier selection [36].

BIM and GIS are complementary. GIS practitioners are helping BIM link to the outside world, and BIM practitioners are introducing GIS to the indoor environment. They could achieve much more in combination rather than by working separately.

3. Integration of BIM and GIS

3.1. Levels of Integration

The integration of BIM and GIS could be conducted at several levels. Irizarry, Karan et al. [37] categorized relevant studies into two interrelated levels: the fundamental level and the application level. The fundamental level focuses on data exchange standards and interoperability at the data level, while the application level concentrates on the development of new methods that utilize the full potential of BIM and GIS. Kang and Hong [29] classified them into five groups based on similar subject keywords, namely schema-based, service-based, ontology-based, processes-based, and system-based approaches. Meanwhile, Amirebrahimi, Rajabifard et al. [33] gave a three-level framework, which groups those studies into application, process, and data level. At the data level, data structures are modified to meet the requirements of the other application, or existing data standards are extended. At the process level, both BIM and GIS are adopted in a workflow and cooperate, while the application level develops new applications that incorporate functionalities of both BIM and GIS, or existing applications are extended via plugins. Application level integration is the most difficult and time-consuming, as it will be built on full data interoperability, and by far, there has been no GIS software that could directly read BIM data, or vice versa. Data level integration is the most essential, and should be paid the most attention and effort. In this study, we focus on a review of data level integration (data interoperability). It could be further divided into two sublevels, geometry level, and semantic level. At geometry level, geometric information is translated, while the semantic level puts emphasis on full attribute information translation.

3.2. Typical Data Formats Involved

At the data level, data format is a topic that cannot be avoided. The flow of information from BIM to GIS, or vice versa, always results in a change in data structure (data format). Many data formats could be used to store 3D geometry, such as 3D Studio Max (.3ds), SketchUp (.skp), VRML and GeoVRML (.wrl), Openflight (.flt), and Collada (.dae). However, the most relevant 3D data formats involved in BIM/GIS integration are Industry Foundation Classes (IFC), City Geography Markup Language (CityGML), and multipatch (shapefile).

3.2.1. Industry Foundation Classes (IFC)

The AEC industry is fragmented and information intensive [38], and there exist various 3D data formats from different vendors that hinder information exchange in this area [39]. Even though there exist many open BIM standards, such as BIMXML [40] and COINS [41], IFC is the primary open data schema used for information exchange within AEC/FM domains [33], which is EXPRESS-based and developed by buildingSMART (formerly the International Alliance for Interoperability) [42].

There are three ways for IFC to represent 3D geometry—boundary-representation (b-rep), constructive solid geometry (CSG), and sweep volumes [43]. B-rep represents a 3D object using its bounding surfaces. It is usually used for complex objects, such as doors (IfcDoor) and windows (IfcWindow). In CSG, an object is the result of a series of Boolean operations (difference, union, and intersection) of simpler objects such as spheres, cones, pyramids, or cylinders. In sweep volumes, a 2D surface together with a path is used to define a solid; the path defines the route over which the surface is extruded.

IFC classifies BIM models into five groups according to the details they contain by Levels of Development (LODs), from LOD 100 to LOD 500. Figure 2 shows a precast structural inverted T beam model from LOD 200 to LOD 400. With the increase of LOD, more details are contained in the model. On LOD 200, there is only one solid structure in the model, but on LOD 400, it has already been a complex model with several components, including lifting devices, expansion joints, etc. LOD 100 example is not given, because LOD 100 elements are not geometric representations. Note that LOD 100, 200, 300, 400, and 500 are defined by American Institute of Architects (AIA), while LOD 350 is developed by the BIMForum working group [44], as it was found to be necessary to define a LOD between LOD 300 and LOD 400 for detailed coordination between disciplines, e.g., clash detection/avoidance, layout, etc.

Apart from the EXPRESS-based IFC file, buildingSMART also introduced a XML-based IFC standard, ifcXML. However, an ifcXML file is normally 3–4 times larger [45] for storing the same information and is not as widely used as the EXPRESS-based file [46].

3.2.2. City Geography Markup Language (CityGML)

There are a range of XML-based standards approved by Open Geospatial Consortium (OGC) used for environmental information exchange, including City Geography Markup Language (CityGML) for virtual 3D city models, Geography Markup Language (GML) for geographical features, Keyhole Markup Language (KML) for geographic visualization, and IndoorGML for modelling indoor spaces for navigation purposes. Among them, CityGML is the most common format in terms of BIM/GIS integration.

CityGML is an open standard data model and exchange format to store 3D models of cities and landscapes based on Geography Markup Language defined by the Open Geospatial Consortium (OGC) in Extensible Markup Language (XML) format [31]. It is an application schema for GML 3.1.1 (GML3) that is a standard for sharing or exchanging 2D and 3D geospatial information over the internet [42]. It defines the basic entities, attributes, and relations of a city, which is essential for cost-effective sustainable 3D city model maintenance. Similarly, for most XML-based data models, there are two parts to CityGML—the schema that describes the document and the instance document that contains the actual data. As with IFC, CityGML has definitions for different Levels of Detail (LoDs) from LoD0 to LoD4 to reflect the amount of detail included in a model. Figure 3 presents building models of a single residential building in LoD1 to LoD4. Obviously, more content is included in a model with a higher LoD. LoD0 model is just the footprint of the building (in 2D), while LoD1 models are the basic block model with flat roofs. In LoD3 and LoD4, the models incorporate doors and windows and have close exterior views, while their internal components are quite different. LoD4 contains interior spaces (rooms) and internal walls, while the model in LoD3 does not. However, the building model in CityGML is less complete and mature as in BIM, even in LoD4 [33].

Different from IFC, CityGML represents 3D geometry only in b-rep. Also, it supports application domain extension (ADE), a feature that makes this standard extendable. Users could add new features, such as classes, attributes, or relations, to the existing standard to meet their particular needs.

3.2.3. Formats for Integration

IFC is the most used data exchange format in the AEC domain and undoubtedly the priority format to be considered for BIM/GIS integration; however, whether CityGML is the best format is still in question, as it is not an efficient format for analysis, while spatial analysis functionalities are the core of GIS. It has been observed that after transformation to CityGML from IFC, the file size increased by tenfold or more [48]. This is determined by the nature of XML-based data formats. XML is designed for storing and sharing information over the internet in a way that is both readable by human and machine; its mechanism that is used for ensuring the accuracy and consistency of the information conveyed introduces a lot of redundant information, for example, tags are repeatedly used. As with other XML-based formats, CityGML inherits this character and is inefficient for analysis. The selection of a format for GIS that is not useful for analysis is somewhat unusual but understandable. Despite that aspect, CityGML is thought to be an appropriate format for integration of BIM with GIS [30,31,46,49]; it is actually a standard initiated by organizations in the AEC domain, such as Autodesk, Inc. and Bentley Systems, Inc. Their first concern is information exchange, rather than the further data analysis. Usually, the information in CityGML has to be transformed into another form again before it could be used in spatial analysis. An alternative is the multipatch standard developed by ESRI. It is a native open 3D standard in GIS, widely supported by most GIS software, and could be used for spatial analysis directly. One more advantage of multipatch is that it could be exchanged with other non-GIS software packages such as Collaborative Design Activity (COLLADA) and SketchUp [50]. However, multipatch can only represent 3D objects with b-rep, just like CityGML, and it is not a semantic model, which means there are no building components such as roof, room, window, or door defined within it, and it stores geometry information only. Nevertheless, semantics could be attached to it through an external database. Overall, for theoretical study purposes, CityGML is more often studied [51,52,53], while for practical purposes, multipatch is more often adopted [33,54,55].

Since IFC and CityGML are often chosen as the representative data schema for BIM and GIS respectively [46,56], the following discussion regarding data interoperability will mainly be based on them, which means that the transformation of BIM to GIS will mainly refer to the transformation of IFC to CityGML.

3.3. Data Interoperability

Data interoperability between BIM and GIS means the ability to exchange information between the two systems. The ideal, successful data interoperability should be able to fully transfer information from BIM to GIS, or vice versa, in terms of both geometry and semantics without data loss. This must first be a reality before integration of BIM and GIS at application level can be achieved.

Figure 4 shows the levels of integration, including application level and data level. The data level (data interoperability) is detailed and contains two sublevels, geometry level and semantic level, while the application level is omitted, as it is not the focus of this study.

3.3.1. Geometry Level

At the geometry level, the focus is on the translation of information related to geometry. There are three major problems to be addressed in this situation: (1) reference system; (2) 3D geometry; and (3) level of detail.

BIM adopts a local placement system in which objects are defined in local planar coordinate system (3D Cartesian Coordinate System). The local placement system of an object is referenced to that of another object. For instance, the local placement system of a window may refer to the local placement system of a wall. This mechanism facilitates model modification; for example, if the location of wall is to be changed, only the placement system of the wall is to be modified, and the locations of windows or doors attached to it will change automatically without the need to modify them individually. On the contrary, GIS generally uses a geographic coordinate system (GCS) to cover regions, nations, or even the entire world; each object inside it has absolute coordinates in the form of latitude, longitude, and altitude. Note that, GIS could also use a local planar coordinate system, but in most cases it uses a GCS. This reference system gap could usually be bridged by a method proposed by [57]:

$$\left[\begin{array}{c}{B}_x\\ B_y\\ B_z\end{array}\right]=M \times \left[\begin{array}{c}{A}_x\\ A_y\\ A_z\end{array}\right]+ \Delta ,$$

in which vector A and B are coordinates of the same object in different coordinate systems; they could transform from each other using the coordinate system transformation matrix M and the origin difference $\Delta$.

GIS and BIM adopt different approaches to represent 3D geometry as discussed earlier. BIM, to take an IFC file, for example, could use one of, or combination of, CSG, sweep volume, and boundary representation (b-rep) to represent a 3D geometry, while GIS usually only uses boundary representation, such as in CityGML and multipatch. The various natures of those different 3D geometry storing mechanisms set a barrier against easy data transformation. From the perspective of IFC to CityGML, the main obstacle is the transformation of b-rep in one system to b-rep in another, sweep volume to b-rep, and CSG to b-rep. While the b-rep to b-rep issue could be solved by the coordinate system transformation function, the sweep solid to b-rep could be achieved by a cutomized function [46], and CSG to b-rep could be completed by open source computational geometry library VTK; the transformation from clipping geometry (the result of Boolean differences between swept area solids) to b-rep still remains a problem [46].

LoDs in GIS and LODs in BIM reflect the amount of detail contained in a city or building model. Both of them have five levels; however, they have different definitions for corresponding levels. For example, CityGML defines a building model in LoD0 as the footprint or roof edge of the building, while an element defined as LOD100 in IFC may not even be a geometic representation [44]. As a result, those levels cannot be simply mapped, which poses a huge barrier to the complete data interoperability between BIM and GIS. Progress is being made in this concern. In the research conducted by de Laat and Van Berlo, IFC models could be exported to CityGML LoD4 [48]. Donkers et al. developed a method to automatically generate CityGML LoD3 building models from IFC files for the construction of a city model [43], while Deng et al. successfully transformed IFC buildings to CityGML LoD1-LoD4 models [46]. One limit of these studies is that they all focus on building models, which is only one type of those built structures defined in IFC schema. Another limit is those studies could only achieve the transformation of IFC to CityGML. Data exchange in the opposite direction is also important if complete data interoperabiliy is to be achieved. However, it is much more complex, because IFC has defined more classes than CityGML. For example, at least 7 classes, such as beam, column, and stair, could be mapped with “BuildingInstallation” in CityGML. The mapping of “BuildingInstallation” to the corresponding class in IFC could be even more difficult, as one has to first decide to which class of IFC the “BuildingInstallation” is to be mapped. Despite low efficiency, the mapping process may have to be manual prior to an automated algorithm being developed that has the ability to distiguish, for example, stairs, columns, or stairs.

Geometry transformation between BIM and GIS could also be partly completed by some commercial software packages, such as BIMServer, IfcExplorer, Feature Manipulation Engine (FME), and Data Interoperability (DI) extension for ArcGIS, which is actually built on FME. However, none of these tools could fully transfer geometry and semantics between BIM and GIS [58].

Integration at this level is usually for 3D visulization purposes, and an obvious disadvantage by far is the semantic information loss, which is mainly due to semantic mismatch between the two domains. For example, a stair could not be displayed correctly after transformation from IFC to CityGML, as there is no definition for stair in CityGML [48].

3.3.2. Semantic Level

Semantic mismatch between BIM and GIS means (1) they have different definitions for the same object, for example, a window in IFC is defined as “IfcWindow” while it is just “window” in CityGML; or (2) one defines a component while the other does not, for instance, IFC defines beam, column, stair, and so on, while CityGML does not, generalizing them as “BuildingInstallation” [43]. This has brought problems for some applications. In the case of creating an indoor evacuation network, the lack of corresponding connection information between stairs makes it difficult to create geometric links between them and impedes the ability to navigate between floors [54]. The semantic loss often happens on the GIS side, as IFC contains much more information than CityGML. The main effort in sematic level data interoperability is then bridging the gap between the two schemas, which means modification to current schemas is needed. Different strategies are being adopted, such as schema extension, simplification, or new intermediate schema creation.

In terms of schema extension, usually the CityGML is to be extended. This could be achieved by ADEs. As mentioned before, the CityGML standard supports ADEs to incorporate new definitions for objects. One example would be GeoBIM developed by de Laat and Van Berlo. It defined “stair” in CityGML, which was not originally included [48]. Sometimes, the IFC is also to be extended. Borrmann, Kolbe et al. extended the IFC model for incorporating multi-scale representation of shield tunnels, which was later transformed into CityGML [59]. Another well-known example is the IFC for GIS (IFG) initiated by the Norwegian Strate Planning Authority (Statens Bygningstekniske Etat) to provide geographic information within the framework of the IFC schema [60]. However, this strategy may encounter problems in terms of visualization. The geometry from a CityGML ADE may not be correctly represented in some 3D viewers such as Autodesk LandExplorer [48].

In some scenarios, the IFC schema is too complex for some specific tasks, for example, indoor navigation, and the shema has to be simplified. The BIM Oriented Indoor Data Model (BO-IDM) was developed by Isikdag et al. for the purpose of facilitating indoor navigation. It eliminates solid elements in the building model, such as holes in the slabs and walls, and only keeps the necessary attributes [61].

The last approach is to establish a new data model, or an intermediate data model, as the bridge for IFC and CityGML. With respect to creating a new data model, an example would be the Urban Flood Model, which is XML-based and designed to faciliate micro-level flood damage assessment [62]. In this case, geometry and semantics from IFC were extracted using DI and BIMServer, respectively, and then merged again using the unique identifier of each element, and finally imported into the designed data model. In the second scenario of creating an intermediate data model, all the information from one end will go through the intermediate data schema in order to reach the other end. This method usually relies on semantic web technology, which is a set of technologies used to represent, publicate, and browse structural data on the web [56]. The core of a semantic web is its ontology, a term that originates from philosophy but has got a new meaning in computer science. An ontology typically consists of a finite list of terms and the relationships between them, used to describe a domain of discourse [63]. A hierarchy structure is usually used to describe an ontology. Figure 5 presents the hierarchy structure of an ontology of indoor location. In this case, the “SpatialThing” has four subclasses, including building, premises, floor, and room, while “room” is divided into lab and metting room. It also shows the relationships between them, for example, building should be located in a premises, while floor should be in a building, and a building could be adjacent to another building.

This approach usually comprises three steps: first, ontologies are constructed for both fields; second, ontology mapping is used to link similar relationships or concepts between the source and target ontologies, which outputs an extended ontology containing all classes and properties from both GIS and BIM domains. Third, GIS data and building elements are translated into semantic web standards, after which a query language, such as SPARQL, could be used to retrieve the information needed from the model [65]. Karan and Irizarry used this approach in an attempt to extend BIM’s scope to the preconstruction planning phase by enabling site layout design that tends to be done by GIS [66]. Deng, Cheng et al. adopted a similar method for creating a reference ontology called Semantic City Model, which serves as an intermediate model for exchanging information between IFC and CityGML, and with which they achieved mapping between BIM and 3D GIS in different levels of detail [46]. Costa, Sicilia et al. developed a District Data Model (DDM), which contains information from IFC and CityGML data as well as contextual data, to support the retrofitting design of energy-efficient districts [67]. Other examples include the Unified Building Model (UBM), which is designed and tested by EI-Mekawy using BIMServer [60] that supports bidirectional information exchange between IFC and CityGML in LoD1-LoD4, and the Integrated Geospatial Information Model (IGIM) by Hor, Jadidi et al. [56].

The semantic web-based method is promising; however, it is often time-consuming to use these techniques, as they are still developing. Moreover, there are very few widely accepted ontologies for the AEC domain, and different projects independently develop their own ontologies, which impairs effective information exchange within this field [66].

4. Discussion

4.1. Difference between Integraion Levels

In this study, discussion is mainly focused on the data level, while the application level is not considered. However, the boundary between them sometimes is not distinct. In some situations, it would be difficult to determine whether a study is at the application level or data level, because studies at application level more or less depend on data interoperability. In this paper, if a study gives detailed descriptions of the integration process, it would be considered as at data level. For example, Costa, Sicilia et al. gave a detailed description on how BIM and GIS data were transformed from IFC or CityGML through Web Ontology Language (OWL) to the formats that could be utilized by simulation applications, such as EnergyPlus and CitySIM for city simulation [67]. On the contrary, if only a few details are given, and the authors focus more on the process, the study then would be treated as at the application level. An example for this scenario is the study conducted by Yamamura, Fan et al. for assessing urban energy performance using BIM and GIS, in which the authors describe the assessment process in detail, but little information was given on how the BIM data was consumed by the GIS [68].

Within the data level, there also exist differences between the geometry and semantic levels.

Table 1. Comparison between integration at geometry and semantic level.

	Geometry Level	Semantics Level
Level of difficulty to achieve	Median	High
Purpose	Visualizaiton	Visualization/Analysis
Direction of information flow	One-way from BIM to GIS	Bidirectional
Richness of information	Low	High
Semantic loss	Yes	No

gives a comparison between the two levels. Data interoperability at the geometry level is mainly for visualization purposes, which are relatively easy to achieve but contain less information, and information tends to flow from BIM to GIS. On the other hand, the information obtained from semantic level integration is relatively rich and thus could be used for analysis, as well as visualization; however, it is more difficult to realize.

Note that at the geometry level, the focus is on geometry transformation, and semantics may get lost. However, this does not necessarily mean all the semantic information would be lost after translation. Some of the attributes would remain, such as GlobalID, Name, Description, Tag, and ifc_parent as shown in a bridge-related project conducted by the authors [69]. The primary lost semantic information is the relationship between objects, or the hierarchy structure of the building model. Take the aforementioned bridge project for example, the transormation process divides the bridge model stored in one IFC file into six subfiles in shapefile format according to the type of component: footing, slab, member, beam, column, and discrete accesory, and the hierachy structure is thus destroyed. However, a field named ifc_parent that records the unique ID of the parent component is retained, which means the hierarchy structure might be restored in some way. At the semantic level, attempts are being made to bridge the gap between semantic mismatches.

At the semantic level, mainly two strategies are being used, i.e., developing new data models that are usually ontology-based using semantic web technology and modifying existing schema including schema simplification and extension. These two strategies have one thing in common that they both rely on existing schemas (IFC/CityGML). Modification is directly conducted against schemas, while in the development of new models, the schemas, to be specific, the classes, relationships, and attributes defined in those schemas, are borrowed to create the ontologies. Even though using existing schemas is not necessary for the construction of ontology, the schema-based ontologies created for integration would be more complete and sound in terms of structure than those built on a single individual’s knowledge, considering that a schema is the knowledge of a group of people.

4.2. Flow of Information

The ultimate goal of BIM/GIS integration is to achieve free information exchange between the two systems, which means both geometry and semantic information flow freely from BIM to GIS, or vice versa. However, this goal is far from being achieved. By far, the information tends to flow unidirectionally from BIM to GIS, or from IFC to CityGML, especially at the geomery level. This might be due to (1) information demand and (2) degree of difficulty for geometry transformation. On one hand, smart city/digital city, sensor network, and Internet of Things are all hot research topics in GIS, while they more or less rely on 3D models. The more detail a 3D model contains, the more GIS could achieve. GIS demands detailed 3D city models urgently to facilitate studies in those areas. On the other hand, geometry transformation from CityGML to IFC is much more complicated than transfotmation in the opposite direction, not only because of the different defintions of level of detail, but also in the difference in approaches adopted to represent 3D geometry. Apart from having to decide how to transform, what to transform is also a question that needs to be answered. CityGML only has one option (b-rep), while IFC has three (CSV, b-rep, sweep volume). At the semantic level, more progress has been made, as some studies have achieved bidirectional information exchange, such as GeoBIM and Semantic City Model; however, the methods proposed in these studies tend to be project-specific, which means the approach proposed in one study could not be directly applied to another. More work needs to be done to achieve a more generic method for bidirectional information exchange.

4.3. The Future of Integration

The future of BIM/GIS is promising, thanks to the increasing demand for detailed 3D city models in the area of smart city/digital city studies. However, some problems have to be settled before the full data interoperability between BIM and GIS can be realized. The authors try to identify the major barriers to full data interoperability of BIM/GIS and provide future direction of this topic.

Table 2. Key issues that need to be focused on during BIM/GIS integration.

	Issues	IFC to CityGML	CityGML to IFC
Geometry	B-rep/b-rep transformation	√	×
	B-rep/CSG transformation	√	×
	B-rep/sweep volume transformation	√	×
Semantics	Classes mapping	√	×
Built structures	Building	√	√
	Bridge	×	×
	Tunnel	×	×

shows the key issues that need to be focused on with respect to geometry, semantics, and types of built structures, as well as their current status. An issue that has been well studied is indicated by “$\surd$”, or else by “$\times$”.

The future research direction of this topic should be based on the issues identified in the following.

(1)

In terms of geometry, transformation between b-rep and other 3D geometry shapes, including CSG and sweep volume, should be studied. By far, the methods for transferring b-rep to other shapes have been developed, while the transformation of other shapes to b-rep have not, and it is the most essential step to finish geometry transformation from CityGML. Apart from transformation between shape forms, level of detail harmonization is also important. Both IFC and CityGML have 5 definitions for LoD or LOD; however, they could not be matched correspondingly. For instance, the lowest LOD of IFC could not be simply matched with the lowest LoD of CityGML. Appropriate links between them should be well developed.

(2)

CityGML extension. The number of classes defined in CityGML is much less than that of IFC, which is the major cause for semantic mismatch between them. Therefore, in the future, the CityGML standard is better to be upgraded. Even though it supports ADEs to extend existing features, too many customized ADEs would impair information sharing and exchange in the area. A better solution is to upgrade CityGML itself, to add more classes. Additionally, this work could utilize the current ADEs and depends on the effort from OGC. This would also benefit the construction of ontology of GIS, which could be used in the semantic web that is promising for bidirectional information exchange between BIM and GIS.

(3)

Methods for distinguishing objects within the same CityGML class but belonging to different IFC classes. An example would be column, stair, and beam belonging to “BuildingInstallation”. While mapping from column, stair, or beam to “BuildingInstallation” is clear, the opposite way is somewhat blurred. One has to decide to which CityGML class to transfer this feature. Without additional information, this would be impossible. A possible solution may be to add an attribute to CityGML showing its corresponding class in IFC.

(4)

Application exploration. The majority of current studies are targeted at buildings, while bridges, tunnels, and so on are also important parts of a city, and they also deserve to be explored.

In general, the future work should focus on the full data interoperability between BIM and GIS, which means information could flow freely between them in terms of both geometry and semantics. This is a must before application level integration could be realized.

5. Conclusions

Building Information Modelling (BIM) and Geography Information System (GIS) originate from different domains, one from architecture, engineering, and construction (AEC)/facility management (FM), another from geospatial science, and for different purposes. One is for detailed 3D building model creation and sharing, another for geospatial data and non-geospatial data management and analysis. Nevertheless, the benefits brought by the integration of the two systems are being proved by more and more research. This study reviewed relevant papers published recently, as well as those classic papers in the hope of facilitating the integration of BIM and GIS with respect to data interoperability to benefit the community. The main findings include:

(1)

GIS and BIM cannot replace each other for quite a long time, and they will continue to operate as independent but complementary systems. At present, the priority is to achieve full and effective data interoperability between them.

(2)

IFC and CityGML are representative data formats for BIM and GIS, respectively. Even though there are other formats involved, such as (multipatch) shapefile, they are the most studied and accepted exchange formats. Apart from that, they are also complete ontologies for building and city models that could contribute to the construction of the semantic web.

(3)

Geometry translation between BIM and GIS could be achieved to some extent, mainly from BIM to GIS. The output could be used for visualization and some simple analyses, such as indoor navigation and determining the shortest route between suppliers and the construction site.

(4)

The current solutions for semantic information exchange are likely to be project-specific. A more generic approach is needed. Additionally, this may largely rely on the extension of CityGML and the standardization of ontologies of these two areas. As the completion of ontology for a domain requires a good understanding of that domain, the ultimate integration needs the efforts of individuals and organizations from both BIM and GIS.

It is not hard to believe that BIM and GIS could be combined into one, with the advance in information technology and the efforts from individuals and organizations in both domains. At that time, new issues may arise. One that could be envisioned is the impact of huge data handling. In BIM, the size of a complex single building model may reach several GB; the data size of a whole city model comprising hundreds or even thousands of buildings would be enormous and can hardly be handled by present technologies. New techniques are needed to handle this issue, such as innovative methods for reducing data size while keeping semantic information intact. Another challenge might be developing efficient methods for model creation. The current process for creating city models is still cumbersome and time-consuming, especially for those with high level of detail. Even the construction of a simple bridge model would take days, not to mention the creation of a whole city. New efficient methods are needed to facilitate this process if a city model is to be built quickly and efficiently.