# A Unified Database Solution to Process BIM and GIS Data
## 3 Results
### 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.