A Unified Database Solution to Process BIM and GIS Data

Abstract

For many years, the objective of spatial databases created using Geographic Information System (GIS) technology was to provide information about large spaces and areas outside of buildings. Building Information Modeling (BIM) technology focused mainly on small spaces, indoor and outdoor, targeted at other users and slightly different applications, was developed simultaneously for several dozen years. The significant development of GIS technology and new tools for quick data acquisition (e.g., laser scanning) and growing user needs resulted in the geoinformation modeling of the space inside buildings as well. BIM, on the other hand, began to be used for increasingly larger spaces outside buildings. Technology developers, users, and scientists started to notice that works turned out to be repetitive and that combining two different technologies is necessary; however, it is not simple. The research presented in the article is another attempt at connecting the world of BIM and GIS. The proposed integrated database environment of BIM/GIS spatial data makes it possible to store GIS and BIM data, enabling the use of the same data by both types of systems simultaneously and in a consistent manner. This allows BIM systems to to obtain simultaneous access to BIM and GIS data, which may be needed in, for example, the process of analyzing a building and its immediate surroundings. At the same time, GIS can obtain up-to-date building data necessary for spatial analyses, building management, or route mapping in navigation applications. The concept proposed in this article assumes a pragmatic approach, which is based on sharing Industry Foundation Classes (IFC) and CityGML schemas from a single database for BIM and GIS applications in their practically original form using an additional integrated BIM-GIS schema, called BIGI-S. The research joins some other works in this field, complementing them and adding a new perspective. This paper describes the concept of this solution, including specific data structures, data conversion algorithms, and a prototype solution. The tests carried out by the authors prove the robustness of the adopted concept and its technical feasibility.

1. Introduction

Intensive scientific research on the integration of databases created within GIS (Geographic Information System) and BIM (Building Information Modeling) systems has only been conducted over the last 10 years. This is a relatively short period, considering that GIS systems date back to the 1960s and BIM systems to the beginning of the 1980s. However, in the case of BIM, the terms “building information model” and “building information modeling” (including the BIM acronym) were started to be widely used in the 1990s [1]. In 2002, Autodesk Inc. published a document titled “Building Information Modeling” [2], which popularized the idea of BIM.

For many years, the objective of spatial databases created using GIS technology was to provide information about the space outside of buildings. Significant development of such technology at the beginning of the 21st century, new tools of quick data acquisition (e.g., laser scanning), and growing user needs resulted in the modeling of the space inside buildings as well. Elaborated standards, such as the Building Interior Space Data Model (BISDM) and, later, CityGML, facilitated and encouraged such procedures. BIM technology, targeted at other users and slightly different applications, was developing simultaneously. Technology developers, users, and scientists started to notice, however, that works turned out to be repetitive and that combining two different technologies was not simple. Many applications require continuous (in a spatial sense) access to information inside and outside of buildings (e.g., navigation applications). The significance of this need is evident, among others, in the agreement between the key companies of both branches (i.e., ESRI and Autodesk announcement on 15 November 2017 [3]) and establishing a workgroup on the ISO 19166 standard of BIM–GIS conceptual mapping (B2GM) [4].

From many years of practice in BIM and GIS, the authors conclude that there is a need to display and analyze data from BIM resources in GIS systems without the need to import such data repeatedly after each update of the BIM dataset. The authors’ motivation was to find a solution that makes it easier to handle BIM and GIS data in a uniform environment. Developing a common data model and one format is difficult and will take some time, so this solution is dedicated to software developers, mainly for an interim period until a common standard for BIM–GIS has been developed and accepted. However, even then, there will still be a need to use previously created data resources in their original form. The existing tools and proposals presented in the literature did not solve our problem. Looking for alternative solutions, the authors developed a concept and then conducted a study that showed the possibility to implement it. This article shows the results of research in the area of connecting the world of BIM and GIS. It presents the authors’ concept of using a single database for BIM and GIS systems while preserving the IFC (Industry Foundation Classes) and CityGML source data models typical for them. The research joins some other works in this field, complementing them and adding a new perspective. To prove the concept, practical tests were performed that confirmed the correctness of the assumptions and the viability of the procedure. This research was, among others, a base for a doctoral thesis [5], a project commissioned by the industry, and it was used for the development of an information system on real estate for one of the big universities.

2. Materials and Methods

The basis of the described research was an in-depth analysis of the literature, an analysis of the available BIM and GIS technologies in the field of building modeling, an analysis of the BIM/GIS market, and an organized discussion on the authors’ experiences related to implementation works carried out for many years. The new conceptual approach was then formulated, and technological experiments and practical tests were performed. As a result, conclusions were drawn, and final solutions were proposed.

Since 2007, a growing number of published research activities on data integration and exchange between BIM and GIS have been observed. Examples from 2007 include the authors of [6,7,8]. In the beginning, most of the proposed solutions were based on data migration using IFC and CityGML standards (the first official version in 2008). In the following years, proposals and research results were presented (i.e., in [9,10,11,12,13,14]). Attempts to unify data types in both systems were made [15] in an attempt to facilitate their cooperation, since the structure of data referring to the same class of objects in both models is incompatible. Meanwhile, there were efforts to use GIS 4D technology for construction design [16]. GIS models (e.g., CityGML) were also used to import BIM data from the models of buildings available in KML (Keyhole Markup Language) format [17]. An interesting classification of the method of integration of BIM and GIS into five types was presented in [18], the first three of which refer to the integration at the data level:

• Conversion of BIM data into GIS based on the conversion of the IFC model into the CityGML model. As a result, BIM and GIS data are stored in the CityGML model and managed from the level of GIS software. This solution is often used by authors and users of GIS systems who require detailed data concerning a building. This issue has been discussed in numerous papers (e.g., [10,14,19,20,21,22,23,24,25]).
• Conversion of GIS data into BIM based on the conversion of the CityGML model into the IFC model. As a result, BIM and GIS data are stored according to the IFC model and managed from the level of BIM software. This solution is mostly used in cases when architects or people who manage a building using BIM software require data concerning the building’s surroundings [17,26].
• The unified data model. Solutions in this category concentrate on developing a separate unified model to combine BIM and GIS data for selected analyses and particular applications [15,27,28]. Moreover, the Unified Building Model was proposed to provide two-directional conversion of BIM–GIS data [29,30,31,32].

The next two approaches to integrate BIM and GIS data are at the application level:

4.

Integration of BIM and GIS at the level of the application server. Solutions in this category offer a new concept of approaching the integration of BIM and GIS by introducing new IT (Information Technology) tools and extending existing applications so that it is possible to jointly operate BIM and GIS data. This is usually realized through the GIS application server [11,33,34,35,36,37,38].

5.

Integration at the level of the client application. Solutions in this category depend on transformations of BIM and GIS data downloaded by independent client applications such as GIS or FM (Facility Management) [6,7,39].

This type of classification was analyzed from a slightly different, although generally similar, perspective in [40]. The authors proposed a division into three integration modes: “BIM leads and GIS supports”, “GIS leads and BIM supports”, and “BIM and GIS are equally involved”. In recent years, more and more research has indicated interest in the use of combined BIM and GIS data (e.g., [41,42,43,44]).

An analysis of the literature shows that the issues of BIM and GIS integration are in the area of scientific interest for many research centers, and thus far, there is no single unified approach for solving the problem. The search for more optimal solutions is still needed. Data exchange between GIS and BIM systems is becoming more advanced and easier to use, but the level of actual integration of both solutions can be considered as low. Solving the problem by data conversion may be sufficient only for some applications. Therefore, the authors undertook research to find solutions that would allow a greater integration of both systems. Among the many potential options, the possibility of BIM and GIS applications in a joint database was analyzed to an extent not previously present in the literature. However, it should be noted that the idea of using the database environment as an intermediary layer between BIM and specialized information systems appears in various contexts and applications, e.g., in [45]).

After analyzing the literature and performing a series of analyses of the available BIM and GIS models and experiments involving data combinations, the concept of BIM and GIS integration was proposed, involving the use of one integrated spatial database but without the need to create a new data schema and only through the appropriate use of existing IFC and CityGML schemas. The proposed integration is released primarily at the technological level. The authors focused on finding a solution that facilitates the operation of BIM and GIS data in a uniform environment. Integration in this context means providing easier than before procedures for accessing BIM data from the GIS software level and vice versa. Moreover, guidelines on how to transform a selected data element from IFC to the corresponding elements in CityGML were developed. The guidelines cover a procedure for geometrically transforming IFC data into a GIS-readable form, including a procedure for changing the local coordinate systems used in BIM–GIS. A full description of these issues, however, is too voluminous and goes beyond the possibility of presentation in one article.

To verify the proposed concept, the following procedure was adopted:

• Elaboration of a relational spatial database project with a structure based on the IFC and CityGML data models (two schemas implemented in a single database).
• Creation and testing of automated procedures for importing IFC data into the relational database.
• Experimental transfer of six IFC models into the created relational database.
• Evaluation of the adopted procedure.
• Improvement of the procedure.
• Checking access to the created database from BIM and GIS software.

In the experimental works, BIM models were used, derived from the management systems of the building technical documentation used by the institutions of public administrations and commercial companies in Sweden. The models were selected in such a way as to represent different types of objects and the different levels of complexity of the model.

3. Results

3.1. The Concept of an Integrated BIM/GIS Database Environment

As discussed in Section 2, many attempts were made to exchange data between BIM and GIS, as well as to create a common database based on a unified data model. The use of the new common data model by BIM and GIS requires the introduction of quite radical changes in the applications available on the market; therefore, the implementation of this solution will likely take many years. The concept proposed in this article assumes a pragmatic approach, which minimizes this shortcoming by using IFC and CityGML schemas in their practically original forms in a single database, later referred to as the Integrated BIM–GIS Database (BIGI-D). The integrated database does not mean in this case a single consistent database in the sense of a conceptual model but a coherent technological environment that allows, depending on the needs, the use of data from both resources by various applications and the improvement of the methods of full information exchange. Thus, the proposed method does not solve the problem of describing the same objects in the BIM and GIS by classes with different structures. On the contrary, it assumes that the conceptual (structured) discrepancies will still exist for some time and that solutions should be sought that accept this situation and improve the coexistence of BIM and GIS until fundamental changes are introduced. At the stage of implementation, BIM data saved in accordance with the IFC conceptual model are processed using tables, perspectives, and stored procedures in the IFC schema. The term schema is used here in two ways—as a data structure and as a place to store tables and procedures in the database. In the proposed technological approach, the use of stored procedures is essential. A stored procedure is a set of SQL (Structured Query Language) statements with its name, which are stored in a database management system as a block. A stored procedure is a subroutine available to applications that access a relational database management system. GIS data recorded according to the CityGML conceptual model are processed using tables, perspectives, and stored procedures in the CityGML schema. In addition, it is proposed to add the BIM–GIS Schema (BIGI-S) for joint storage of the data from IFC and CityGML to facilitate conversion between BIM and GIS and data sharing. All three schemes are implemented in one database.

A model based on dynamic data conversion is an alternative implementation solution. Within this approach, the data are only stored in the BIGI-S. Schemas dedicated to individual BIM and GIS applications (as well as others) are implemented as database views and stored procedures. The schema dedicated for the BIM application is generated on the fly, based on stored procedures that convert data from the BIGI-S. The case with the CityGML schema is similar. The main advantage of this solution is the elimination of data redundancy. Each object is saved in the database once but can be seen using CityGML and IFC views. From the point of view of BIM and GIS applications, the common BIGI-S is, in this case, completely invisible. Each of these applications read data using the appropriate IFC or CityGML model. The weakness of the above solution is the need to create complicated database perspectives that realize the translation of selected data between schemas, in the case of spatial data conversion to IFC, while requiring very fast access to these data. Despite the necessity of creating complex perspectives and stored procedures, the authors claim that avoiding redundancy has significant value; therefore, this solution was selected for the prototype. However, such a solution may adversely affect the efficiency of processing. Therefore, preliminary studies on the effectiveness of using stored procedures for model conversion were performed.

The architecture of the proposed database includes the possibility of creating a number of additional schemas (e.g., a schema for facility management systems) that use both BIM and GIS data. Each of these schemas would allow access to integrated BIM/GIS data from the level of dedicated applications. This approach is easy to implement and allows to minimize the changes needed in the software currently available on the market. Figure 1 presents a diagram of the BIGI-D idea in a configuration that allows consistent use of data by GIS and BIM systems. In the presented concept, it was assumed that data are stored in BIGI-D using the types of geometric data that are standard in GIS systems. Later on in the text, the idea presented in Figure 1 is discussed in detail.

In practice, for a selected building, there may exist three main cases in which the source building model is developed in GIS only, in BIM only, or in both GIS and BIM. In the discussed concept, it was assumed that building models should be converted to an integrated database from the CityGML schema only if there is no source BIM model available for them. Due to the high detail of the BIM model and the fact that the BIM process built around this model provides continuous data updates, it was assumed that the BIM model is the most desirable and complete source of building data.

The following section of the paper describes the experiments that attempted to evaluate the possibilities of implementing the presented concept. They are mostly based on implementing the IFC model into a relational database in a way consistent with the CityGML model and, in the next step, on performing test data imports.

3.2. The Case Study

The first stage of working with the BIGI-D database is feeding it with data. In the case of data from BIM applications, this process involves exporting the data as an IFC file and saving them in the database schema dedicated to the IFC data. This database schema is called IFC, and it contains tables and stored procedures that allow operating on each of the tables. The procedures perform write, read, update, and delete data. After saving the entire model, the data conversion process from IFC to BIGI-S is executed. Data is converted by stored procedures to tables in BIGI-S. When the process is complete, the data in the IFC schema is deleted. This avoids data redundancy.

In the next stage, BIM and GIS applications can work with building models saved in BIGI-D. The BIM application triggers the process of transferring the data for the selected building model from BIGI-S to the IFC database schema. This allows the BIM application to work on this model. Upon completion of the work, the model is converted back to BIGI-S and removed from the IFC schema. At the same time, the GIS system can use data of the same building. In this situation, the data is converted from BIGI-S to the CityGML database schema and is available for the GIS system. If the BIM application works on the same model at the same time, the data stored in the IFC database schema is converted to BIGI-S, the trigger in the database starts the process of updating the data in the CityGML database schema, and the GIS system receives the current data about the object. Similarly, building data saved by the GIS system is automatically available for the BIM application. This is where the data conflict problem arises when both BIM applications and GIS systems attempt to save building data. If the data on the interior of the building is obtained only from the IFC model, the data for the entire model is saved in BIGI-S. Similarly, in the case of obtaining data about the building only from CityGML. If the building data is obtained simultaneously from BIM and GIS, the geometric and descriptive data are taken from IFC and supplemented with the descriptive data from CityGML. This is because the IFC model is much more detailed than CityGML and is a better source of data about the facility. CityGML, on the other hand, can provide descriptive data not available in the IFC model. It was assumed that each building acquired into the database would have a globally unique identifier (GUID). The same building in the IFC and CityGML models will have the same GUID. This will allow BIGI-D to identify buildings in the process of obtaining data. The authors did not conduct further research on this problem.

In this operating mode, data redundancy occurs. The entire building model is saved in BIGI-S; if the BIM application works on it, it is also converted to the IFC database schema. If it is additionally used by a GIS system, the same model is converted to the CityGML database schema. Stored procedures and triggers ensure data consistency, but redundancy is threefold in this situation. This corresponds to the functionality of the version management system—the model is downloaded to the IFC schema to perform editing work (check-out), and after completion, it is loaded into the main repository—BIGI-S (check-in). Similarly, when working with a GIS model. The data is copied (with conversion) to the CityGML schema and edited there. After completing work on the model, the data is transferred to BIGI-S as a new version of the object. The subject of versioning object models in BIGI-D is beyond the scope of this article.

The solution to the problem of redundancy and the need to maintain the consistency of three copies of data is on-the-fly operation. In this case, the IFC and CityGML database schemas do not contain tables but only stored procedures. The process of writing data in the IFC database schema consists of directly converting IFC data to BIGI-S. Reading the data also involves taking the source data from BIGI-S and converting it to IFC format without using intermediate tables in the IFC database schema. The process of working with data by GIS applications looks similar. Data is converted from and to BIGI-S by stored procedures in the CityGML database schema.

3.3. Implementation of the IFC Model in a Relational Database

The first step of the experiment was to create a database structure corresponding to the IFC model. The database model corresponds exactly to the IFC model, which makes it possible to avoid numerous complications in the processes of data writing and reading by application software. It should be remembered that the procedure of processing the data stored in IFC into a relational model is quite complex. The IFC model is not relational and has a number of quite specific features (e.g., multiple local coordinate systems and complex internal references between objects). In order to enable editing operations on the BIM data saved in a relational database, the mechanism of stored procedures was applied. For each class of IFC objects, four stored procedures were prepared for write, read, update, and delete operations. For the purpose of the experiments, the stored procedures enabling writing, reading, modification, and deletion of the data of IFC objects were prepared for more than 100 classes of IFC objects. The procedures were implemented in SQL and PL/pgSQL (Procedural Language/PostgreSQL) languages on the PostgreSQL platform. For comparison, stored procedures for several selected classes of IFC objects in PL/SQL (Procedural Language for SQL) in the Oracle database and T-SQL (Transact SQL) in the Microsoft SQL Server database were also prepared. The purpose of this part of the experiment was to check whether it was possible to create stored procedures that could be triggered in a similar way regardless of which database platform was used. As a result of the experiment, it was confirmed that the triggering of the prepared stored procedures operating on tables in PostgreSQL, Oracle, and SQL Server databases was very similar. Thus, the proposed solution can be used with any of the above relational database management systems.

3.4. Automated Process to Import IFC Data into a Relational Database

The general schema of the data import operation is presented in Figure 2. The process of rewriting data from an IFC file to an IFC schema in the database consisted of three steps: reading data from the IFC file, saving the data in a form readable for the database management system (creating SQL scripts), and loading the data into the database by executing scripts in the database. The data transfer operation is, therefore, a multistep task consisting of the export of data from the BIM program into the IFC format, followed by the import of data from the IFC file to the BIGI-S in the integrated BIM/GIS spatial database. The course of the experiment is shown in Figure 2.

3.5. Implementation of the Common Database Environment for IFC and CityGML Data

The architecture of the proposed solutions assumes the use of several schemas in a single database. Separate IFC and CityGML schemas are dedicated to storing BIM and GIS data, respectively. GIS applications only use data via the CityGML schema, while BIM applications can access data via IFC schema. IFC and CityGML schemas are treated as temporary datasets. The data stored in the IFC schema is converted into a BIGI-S, which allows for lossless saving of the data from the IFC model. Similarly, the data saved by GIS applications in the CityGML schema are also converted into the BIGI-S. It should be emphasized here that the BIGI-S does not mean, in this case, a completely new conceptual data model for the existing BIM and GIS data but, above all, refers to appropriately related IFC and CityGML source schemas. The integrated data model is materialized in the form of a set of tables and stored procedures that are located in the BIGI-S. The differences in the GIS and BIM data conceptual models were taken into account when building the integrated data model.

Table 1. An example of the process of obtaining data for the CityGML model from the Industry Foundation Classes (IFC) model.

CityGML AbstractBuildingType Class	Multiple IFC Attributes and Classes
class	The class of an object can be determined from the data contained in the attribute sets assigned to the object.
function	The function of an object can be determined from the data contained in the attribute sets assigned to the object.
usage	OccupancyType attribute from the Pset_BuildingCommon property set attached to the building.
yearOfConstruction	YearOfConstruction attribute from the Pset_BuildingCommon property set attached to the building.
yearOfDemolition	The date of decommissioning the building is determined by analyzing the data contained in the property sets assigned to the object if such information is present in the building model.
roofType	ObjectType attribute of the IfcRoof object class assigned to the IfcBuilding object.
measuredHeight	Determining the height of the building takes place through the analysis of geometric objects indicated by the attributes Representation and ObjectPlacement of the IfcBuilding object.
storeysAboveGround, storeysBelowGround	NumberOfStoreys attribute from the Pset_BuildingCommon property set attached to the building or the number of IfcBuildingStorey objects attached to the building. The determination of the number of stories above and below the ground level is made by analyzing the attributes ObjectPlacement of each IfcBuildingStorey object attached to the building.
storeyHeightsAboveGround, storeyHeightsBelowGround	The determination of the height of the stories above and below the ground level is made by analyzing the Representation attributes of the IfcBuildingStorey objects.
lod0FootPrint	The outline of the building on the ground is determined by analyzing the geometric objects indicated by the Representation attribute of the IfcBuilding object.
lod0RoofEdge	The roof edge is determined by analyzing the geometric objects indicated by the Representation attribute of the IfcRoof object assigned to IfcBuilding.
lod1Solid, lod1MultiSurface, lod1TerrainIntersection	The geometry of the building body and its contact with the ground are determined by analyzing the geometric features of the objects indicated by the Representation and ObjectPlacement attributes of the building.
lod2Solid, lod2MultiSurface, lod2MultiCurve, lod2TerrainIntersection	The geometry of the building body and its contact with the ground are determined by analyzing the geometric features of the objects indicated by the Representation and ObjectPlacement attributes of the building.
outerBuildingInstallation	The list of objects related to the building outside of the building body can be obtained on the basis of the relationships that aggregate these objects with the building or IfcSite object.
interiorBuildingInstallation	The list of building-related objects inside the building body can be obtained on the basis of the IfcRelContained aggregating relationships.
boundedBy	The building outline can be obtained from the IfcPolyLoop object defining the building outline.
lod3Solid, lod3MultiSurface, lod3MultiCurve, lod3TerrainIntersection	The geometry of the building body and its contact with the ground are determined by analyzing the geometric features of the objects indicated by the Representation and ObjectPlacement attributes of the building.
lod4Solid, lod4MultiSurface, lod4MultiCurve, lod4TerrainIntersection	The geometry of the building body and its contact with the ground are determined by analyzing the geometric features of the objects indicated by the Representation and ObjectPlacement attributes of the building.
interiorRoom	The list of rooms can be obtained by IfcRelAggregates aggregation.
consistsOfBuildingPart	The list of objects inside the building can be obtained by the IfcRelAggregates and IfcRelContained aggregations.
address	The IfcPostalAddress object related to the IfcBuilding object.

shows selected examples, as well as differences between the methods of storing building data in the CityGML and IFC models. It requires a number of data transformations to convert data between these models via an intermediate model but is, with some simplifications, possible. The stored procedures implemented in the BIGI-S allow to save and read data between the CityGML and IFC models and the integrated model. The presented concept assumes that the data are stored in the BIGI-S in common tables with the use of the geometric data types typically used in GIS systems.

Stored procedures in the BIGI-S allow on-the-fly conversion of data from the IFC schema to the BIGI-S and vice versa, as well as bidirectional data conversion between the CityGML schema and the BIGI-S according to the analysis of both data models briefly presented in Table 1. For objects of the classes inherited from IfcProduct class, the process of converting data from the IFC schema to the BIGI-S includes several steps: rewriting the basic attributes of the object, converting the geometry of the object to the global coordinate system, taking into account the rotation of the coordinate system according to the TrueNorth attribute, saving the individual attributes assigned to the object, and saving the sets of attributes assigned to the object (Figure 3).

The general algorithm of the transformation process of object data from the IFC schema to BIGI-S for each object class inherited from the IfcObjectDefinition class is the same. For example, for an IfcSpace object, this process is as follows:

• Attributes GlobalId, Name, and Description are read from object’s table.
• These attributes are saved in the bigi_s.space table, along with the project GUID.
• The data about author, date, and BIM application used to create the processed object in the IFC model is read from the IfcOwnerHistory class object indicated by the OwnerHistory attribute.
• The data about the source of the object data is saved in the bigi_s.space table.
• The data about relations between the processed object and other objects of the IfcObjectDefinition class are read from the source tables.
• Data about these dependencies are saved in a table in the BIGI-S schema.
• Based on the IfcPropertySet, IfcComplexProperty, and IfcPropertySingleValue objects assigned to an IfcSpace object through the IfcRelDefinesByProperties object, a list of single properties and property sets assigned to this object is determined.
• Data about IfcRelDefinesByProperties, IfcPropertySet, IfcComplexProperty, and IfcPropertySingleValue class objects is stored in the bigi_s.spaceproperties table for reverse conversion to IFC.
• Single properties retrieved from IfcPropertySingleValue objects assigned by IfcRelDefinesByProperties are saved in the bigi_s.spaceproperties table.
• The property sets retrieved from the IfcPropertySet, IfcComplexProperty, and IfcPropertySingleValue objects are saved in the bigi_s.spaceproperties table.
• On the basis of the IfcProductDefinitionShape, IfcShapeRepresentation, IfcExtrudedAreaSolid, IfcArbitraryClosedProfileDef, IfcPolyline, IfcCartesianPoint class objects, the geometry of the object is determined.
• The data of the IfcProductDefinitionShape, IfcShapeRepresentation, IfcExtrudedAreaSolid, IfcArbitraryClosedProfileDef, IfcPolyline, and IfcCartesianPoint class objects are stored in the bigi_s.spacegeometry table in BIGI-S to enable reverse conversion to IFC.
• Based on the IfcAxis2Placement3d, IfcCartesianPoint, IfcDirection, and IfcLocalPlacement classes, the location of the local coordinate system of the room in the local coordinate system of the IfcSite class object is determined. When processing data on the location of the local coordinate system of an object, dependencies of local coordinate systems are taken into account. The geometric elements representing the room are expressed in the local coordinate system of the room, the position of which is determined in the local coordinate system of the floor and that in the local coordinate system of the building, which was expressed in the local coordinate system of the site.
• Data of the IfcAxis2Placement3d, IfcCartesianPoint, IfcDirection and IfcLocalPlacement objects are stored in the table in the BIGI-S schema to enable the reverse conversion to IFC.
• The location of the local coordinate system of an IfcSite object is specified in the global geodetic coordinate system through the RefLatitude, RefLongitude, and RefElevation attributes. The rotation angle of the local coordinate system relative to the geodetic system (TrueNorth) is determined by the IfcGeometricRepresentationContext object referenced from the IfcProject object.
• The geometry of the object expressed in the global coordinate system is stored in the geometry attribute of the bigi_s.spacegeometry table.

The reverse conversion involves creating, on the basis of the data stored in the tables in the BIGI-S, sets of attributes assigned to the object, single attributes assigned to the object, and geometry in the local coordinate system of the object obtained from the geometry expressed in the global system, taking into account all local coordinate systems of the host objects. The last step is to create the object itself with its basic attributes (Figure 4).

The general algorithm of the transformation process of the “room” class from the BIGI-S to the IFC schema is as follows:

• Attributes GlobalId, Name, and Description are read from the bigi_s.space table.
• These attributes are saved in the ifc.space table in the IFC schema.
• The data about author, date, and BIM application data used to create the processed object originally derived from the IFC model is read from the bigi_s.space table.
• The data about the source of the object data is saved in the ifc.ownerhistory table.
• The data about relations between the processed object and other objects derived from the IfcObjectDefinition class is read from the table in BIGI-S.
• This data about these dependencies is saved in the ifc.relaggregates table.
• Room properties are read from the bigi_s.spaceproperties table.
• Simple properties are saved in the ifc.propertysinglevalue table.
• Property sets data is saved in the ifc.complexproperty and ifc.propertyset tables.
• Data of the IfcRelDefinesByProperties object aggregating the IfcPropertySet objects with the processed object is saved in the ifc.reldefinesbyproperties table.
• The geometric representation of the room is read from the bigi_s.spacegeometry table.
• Transformation of coordinates from the global geodetic coordinate system to the local coordinate system of the project is performed:
  • The angle between the project North direction and the True North direction for the selected project (TrueNorth) is read from the bigi_s.project table.
  • The coordinates of all points describing the geometry of the room are read from the bigi_s.spacegeometry table.
  • The transformation of coordinates of points by rotating the coordinate system by the angle that TrueNorth is performed.
  • The point with the smallest x and y coordinates is selected as the starting point of the local coordinate system of the object.
  • Transformation of the point coordinate system is performed by moving the coordinate system by the vector w = (-x, -y), where x and y are the coordinates of the selected point as the starting point of the local coordinate system.
  • The x and y coordinates calculated in step 12.d are saved because they allow the position of the local coordinate system of the processed object to be determined in the local coordinate system of the parent object in the hierarchical structure of the building.
• IfcLocalPlacement, IfcDirection, and IfcCartesianPoint class objects that define the location of the local coordinate system of the object in the local coordinate system of the parent object in the hierarchical structure of the building are saved in dedicated tables in BIGI-S.
• IfcAxis2Placement3d, IfcLocalPlacement, IfcCartesianPoint, IfcPolyline, IfcExtrudedAreaSolid, IfcShapeRepresentation, IfcShapeRepresentation, and IfcProductDefinitionShape class objects that define the geometry of the object in its local coordinate system and the location of this object in the local coordinate system are saved in dedicated tables in BIGI-S.
• Reference to the IfcProductDefinitionShape class object is saved in the Representation attribute of the room.

Conversion from the CityGML schema to the BIGI-S is much less complicated. The conversion process involves rewriting the basic data about the object, geometric data, and properties (Figure 5).

The general algorithm for the transformation of data related to the “room” class from the CityGML to BIGI-S is as follows:

• All descriptive attributes (class, function, and usage) are read from the citygml.room table.
• These attributes are saved in the bigi_s.propertysinglevalue table in the appropriate attributes of the property sets attached to the object.
• The geometric elements of Solid and MultiSurface are read from the citygml.space table at the LoD4 detail level.
• The geometric data for LoD4 is saved in the bigi_s.spacegeometry table.

The inverse conversion of data from the BIGI-S to the CityGML schema is analogous. It includes basic object data, object geometry, and properties (Figure 6).

The general algorithm for transforming data related to the “room” class from the BIGI-S to the CityGML scheme is as follows:

• The appropriate attributes from the property sets attached to the room are read from the bigi_s.spacegeometry table.
• The attributes are saved in the citygml.space table.
• The geometric data for LoD4 for the room being processed are read from the bigi_s.spacegeometry table.
• The geometric data are saved in the citygml.space table.

In conclusion, let us analyze the example of room data editing by BIM and GIS applications. The BIM application uses data for a single room. In this case, it calls stored procedures in the IFC database schema allowing to read data about object classes IfcSpace (basic data of the room), IfcProductDefinitionShape, IfcShapeRepresentation, IfcExtrudedAreaSolid, IfcArbitraryClosedProfileDef, IfcPolyline, IfcCartesianPoint, IfcLocalPlacement, IfcAxis2Placement3D, IfcDirection (data on the geometry of the object), IfcRelDefinesByProperties, IfcPropertySet, IfcComplexProperty, and IfcPropertySingleValue (object descriptive data). These stored procedures are ifc.getspace, ifc.getproductdefinitionshape, ifc.getshaperepresentation, ifc.getpropertyset, etc. The routines retrieve relevant data from tables in BIGI-S, convert it to an IFC model, and make it available for BIM application. The modified data is saved by calling the stored procedures: ifc.updatespace, ifc.updateproductdefinitionshape, ifc.updateshaperepresentation, ifc.updatepropertyset, etc. At the same time, the GIS system uses the data of the same room using a stored procedure in the CityGML database schema: citygml.getspace, which retrieves data from tables in BIGI-S and converts it to CityGML format. Data is saved by the citygml.updatespace stored procedure in the CityGML database schema, which converts data from CityGML and saves it in tables in BIGI-S. In this way, assuming the right performance is ensured, conversions can be performed almost invisibly to users of BIM and GIS applications.

3.6. Tests of Access to the Common Database from the Level of BIM and GIS Applications

As part of the research, six IFC models were transferred into an integrated database. The levels of complexity of these buildings, determined by the number of IFC objects in each of their models, are illustrated in

Table 2. The number of IFC objects in the test models.

IFC Test Model	Objects	Floors	Rooms	Walls	Points
Church	98,915	5	52	172	27,432
Office building	100,058	5	0	219	24,154
School	312,705	4	83	427	66,786
Hospital	526,341	6	657	2320	100,991
University building	1,915,427	8	258	1740	331,291
College building	2,846,624	8	480	3005	751,262

.

The test IFC models were assigned globally unique identifiers (GUIDs), unique 128-bit numbers produced by applications to identify a particular component, application, file, database entry, and/or user. For each test model, a schema with a name identical to the GUID was created; then, the IFC model was imported into each schema. The next step was to convert the selected data from the IFC schemas to the BIGI-S. The high number of object classes in the IFC model (approximately 770) resulted in the need to limit the number of prepared stored procedures at the stage of research. Procedures were implemented only for those IFC classes that were used in the test IFC models. Such an approach was sufficient to assess the viability of the task. The most characteristic objects, such as the building, floors, rooms, walls, ceilings, doors, and windows, were selected for the test. The implementation of the procedures for the remaining classes representing the elements of a building was similar. Each of the above-mentioned test models was correctly imported into a relational database according to the adopted concept and procedures. Detailed tests showed good performance results. Saving a single room in the database, along with the conversion to BIGI-S, takes about 50 ms. Similar results were obtained when retrieving a single room from the database. It takes approximately 8 s to write or read a set of 500 objects. The tests were carried out on an environment consisting of a PostgreSQL 9.5 database server running on the CentOS 7 operating system (2 CPU, 4 GB RAM) and a Windows 8.1 workstation (6 CPU, 32 GB RAM). It was decided to use the Revit and ArchiCAD applications for testing, as these are currently widely used to create BIM models. According to the scheme of cooperation between BIM and GIS software with a common relational database presented in Figure 1, the test import process of the IFC models was carried out with the export IFC file from the BIM software and imported to the BIGI-D. Technically, IFC data from the BIM application can be accessed through remote mechanisms, such as ODBC (ODBC—Open Database Connectivity)/JDBC (JDBC—Java Database Connectivity)/OLEDB (OLE DB—Object Linking and Embedding, Database)/ADO (ADO—ActiveX Data Objects). The proposed solution allows BIM applications to communicate with the BIGI-D through the import/export of IFC files and through the data access mechanism. In the latter case, the BIM application that can access the data stored in the database communicates with the database through standard data access protocols. This is a method analogous to the data manipulation performed by GIS applications.

BIM applications that are currently available on the market do not have mechanisms to work with the data stored in a database, so it was impossible to carry out a real, fully comprehensive test of access to the proposed BIGI-D. It was decided to simulate this process. The simulation involved reading and writing data using a special application developed by the authors. The application simulated a module of access to the BIM data recorded in a relational database. In the case of the final implementation of the discussed concept of this type, the module should be added to the existing BIM applications. It should be stressed that the construction of such a module is very simple and inexpensive. The simulation included saving and reading the entire model; reading the data of all objects of the selected class; reading the data of the object with a given identifier; and reading the data of the objects that defined the spatial structure of the BIM project, i.e., the building, floor, and rooms, as well as reading the geometry of the selected object, taking into account its location in the global geodetic coordinate system. In the next step, table contents were visualized in the BIGI-S. The final stage of testing was the reading of the data in the test building models from the CityGML schema. The reading process was seamless. The correctness of the data read in the CityGML model confirmed the correctness of the proposed method.

3.7. Evaluation of the Adopted Procedure

The results confirmed the validity of the initial assumption: that it was possible to implement the IFC model in a relational database in a way that allows the use of the IFC data saved in the database by BIM applications, without needing to significantly change the data operation methods that these applications currently perform. At the same time, such an approach allows GIS applications to operate on the same data. The experiment proved that the IFC model can be implemented in a relational database in a way that makes it possible to perform data writing and reading, which is currently done by other methods using BIM applications.

During the research, the advantages and disadvantages of the two methods of converting data within BIGI-D were analyzed: copying data with schema changes and dynamic data conversion to another schema “on the fly”. The advantages of the solution based on data copying include the ease of access to the spatial data saved in the IFC schema by BIM applications (direct reading of IFC data, only saved in a different format). The main disadvantages of this approach are the data redundancy, the time needed for copying, and the required additional computer memory resources. The solution using dynamic data conversion ensures that the data are stored only once in the BIGI-S. CityGML and IFC schemas are created only through perspectives and stored procedures (and, thus, virtually). The main advantage of this solution is, therefore, the elimination of data redundancy. The disadvantage, however, is the necessity to create rather complicated perspectives that translate selected data between schemas in the case of spatial data conversion into the IFC, while requiring very fast access to these data. It was decided that the advantages of the second approach were greater; therefore, this method was used to build the prototype.

4. Discussion

The originality of the proposed solution lies, among other things, in that it allows BIM and GIS applications to “see” their source data as they did before integration, while gaining access to other data consistently. The BIM application sees GIS data and vice versa. This limits the necessary modifications of the BIM and GIS software, because it is sufficient to modify only the data writing format and not the data model. The storage of BIM and GIS data in a uniform database environment is another advantage of this solution. Conversions can be performed very efficiently and even imperceptibly to users.

The authors’ solution involves the use of the spatial data-processing mechanisms available in popular environments of relational database management. Therefore, BIM data can be stored in a relational database management system (e.g., in PostgreSQL with the PostGIS module, Oracle Spatial, and Graph or in the SQL server). For the prototype and testing, it was decided to use the PostgreSQL relational database management system and the PostGIS extension supporting spatial data, spatial indexes, and spatial functions. The advantage of PostgreSQL is the ability to create a hierarchy of dependent tables, which makes it easier to represent the IFC model. Therefore, the IFC class inheritance hierarchy can be restored in the form of inherited tables in the database.

The scenario involving the use of dynamic data conversion requires the implementation of stored procedures that are able to return the data collected from the tables of an integrated spatial database for the given GUID building, transforming them “on the fly” into the IFC model using the perspective mechanism and stored procedures. The advantage of this solution is its continuous access to the current state of data through BIM and GIS applications.

5. Conclusions

This article described research attempting to find an effective, practical, and useful method to integrate BIM and GIS data environments. After a detailed analysis of the various publications and the available BIM software, a new method of BIM and GIS data integration was proposed that used an integrated spatial database, which consisted of three different schemas (in terms of both the structure and the separate places in the database). However, it is not an integrated database in the full meaning of the term based on a uniform conceptual model but, rather, a solution based on the process of on-the-fly integration of data collected in several harmonized application schemes. The research included experimental works, as well as preparation of the solution prototype.

Using a database as storage for IFC data allows GIS systems to use current BIM data without having to import IFC files into their formats/models, which opens up completely new functional possibilities. The proposed integrated database of BIM/GIS spatial data makes it possible to store GIS and BIM data, enabling the use of the same data by both types of systems simultaneously and in a consistent manner. This allows BIM systems to obtain simultaneous access to BIM and GIS data, which may be needed in, for example, the process of analyzing a building and its immediate surroundings. At the same time, GIS can obtain up-to-date building data necessary for spatial analyses, building management, or route mapping in navigation applications. In addition, users of BIM systems gain new technological solutions as follows:

• Providing opportunities for group work offered by the management systems of relational databases with the possibility of using various BIM software while working on a single project.
• Providing standard mechanisms for controlling the access rights to the data offered by relational database management systems.
• Providing mechanisms for the transactional processing of the data offered by relational database management systems.
• Providing backup mechanisms offered by relational database management systems.

The condition for implementing such a solution is to add a database access mechanism to the BIM tools. Such a mechanism could replace the existing BIM application functionality of working on its own data files in binary formats. This is probably one of the simplest solutions, because it requires only a technical modification without the need for integration into the conceptual model. In terms of GIS, virtually no significant modification is necessary, as long as the software supports the CityGML schema. Of course, there is nothing to prevent the proposed concept from being applied to data schemas alternative to CityGML. The proposed concept also makes it possible to create additional thematic schemas that allow access to the integrated BIM/GIS data stored in the BIGI-S in a way readable for other applications using these data, such as applications that support the process of property management.