# A Unified Database Solution to Process BIM and GIS Data
## 3 Results
### 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 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 \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**IFC Test Model** & **Objects** & **Floors** & **Rooms** & **Walls** & **Points** \\ \hline 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 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: The number of IFC objects in the test models. 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.