See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/328556923

IFC Model Restructuring Framework for Efficient Bulk-loading to Object-

relational IFC Model Server

Article in KSCE Journal of Civil Engineering · December 2018

DOI: 10.1007/s12205-017-1977-8

CITATION READS

1 575

3 authors, including:

Chi Yon Cho Sungil Ham

Carnegie Mellon University Jeonju University
10 PUBLICATIONS 79 CITATIONS 42 PUBLICATIONS 341 CITATIONS

SEE PROFILE SEE PROFILE

Some of the authors of this publication are also working on these related projects:

the Disaster-Safety Industry Promotion by the Ministry of Interior and Safety (MOIS, Korea) View project

All content following this page was uploaded by Sungil Ham on 21 November 2018.

The user has requested enhancement of the downloaded file.

KSCE Journal of Civil Engineering (2018) 22(12):4930-4939 Information Technology
Copyright ⓒ2018 Korean Society of Civil Engineers
DOI 10.1007/s12205-017-1977-8 pISSN 1226-7988, eISSN 1976-3808
www.springer.com/12205
TECHNICAL NOTE

IFC Model Restructuring Framework for Efficient Bulk-loading

to Object-relational IFC Model Server
Chi Yon Cho*, Jongsung Won**, and Sungil Ham***
Received December 15, 2017/Accepted June 23, 2018/Published Online October 31, 2018

··································································································································································································································

Abstract

This study proposes an IFC model restructuring framework for importing a large IFC model into an Object-Relation-database-
based Industry Foundation Classes (OR-IFC) server. The purpose of using an IFC server is to facilitate collaboration by exchanging
Building Information Modeling (BIM) data among construction project participants. However, the large size of IFC files could
require several days to upload to the server and cause a time delay in terms of information exchange. For example, with a non-
optimized algorithm, it can take several days to import a 111 MB model file into the IFC server and an import failure can occur with
large model files that exceeds 300 MB due to the many cycles of iterations in the search and mapping process for IFC entities and
object identifiers. Therefore, the authors proposed a new restructuring algorithm and a bulk-loading method in order to import IFC
data into the server in a timely manner. The idea of bulk-loading is to presort and group all the IFC instances by IFC class into blocks.
As a result, the import time for a 61 MB model required 56 seconds, and a 111 MB office-building model and a 346 MB building
model were imported in 2 min 37 sec and 14 min 11 sec, respectively. The experimental result have shown that the import speed was
improved by 30 times faster than the previous NoSQL-based approach. Therefore, the proposed method is anticipated to enable
efficient information exchange among project participants in future BIM projects.
Keywords: Industry Foundation Classes (IFC), Object Relational Database (ORDB), IFC model server, Building Information
Modeling (BIM), BIM server, Bulk-loading
··································································································································································································································

1. Introduction still unsatisfactory. One of the reason is because IFC servers

Surveys conducted in the Smart Market Report (McGraw-Hill
Construction, 2009; McGraw-Hill Construction, 2010; McGraw-
Hill Construction, 2012) have identified interoperability issues
between software applications as top obstacles to support
efficient collaboration among project participants and improving
project value when using advanced information technologies
such as BIM. To improve interoperability issues and to support
efficient data exchange for collaborative working environment,
Industry Foundation Classes (IFC) model servers were proposed
as a solution from previous studies (Beetz et al., 2010; Chen et
al., 2005; Faraj et al., 2000; Li et al., 2016). IFC is an “information
model for sharing data in the construction and facilities management
industries (ISO 16739:2013).” An IFC model server is “a
database or model server application that allows a multi-user
database management system to use the IFC schema, an
international standard data model for a building information
model, as the underlying database structure (IFC-Developers,
2017)”. An IFC model server is also referred to as an “IFC
server” or a “Building Information Model (BIM) server”.
However, the performance of current IFC model servers are
were previously developed based on the Relational-database
(RDB) concept. Well-known examples of a RDB-based IFC
server includes the IFC model server (IMsvr) (Adachi, 2002) and
the Eurostep Model Server (Jørgensen et al., 2008). These RDB-
based IFC model servers had slow performance due to the
RDB’s inability to support the object inheritance and aggregation
relations in IFC (Jørgensen et al., 2008; Lee et al., 2014; Plume
and Mitchell, 2007).
Thus, this study utilized the object-relational database (ORDB)
system as a platform instead of a RDB system to improve the
performance of the IFC model server by supporting complex
inheritance and aggregation relations. ORDB is a hybrid database
approach between a RDB and an object-oriented database
(OODB). The ORDB inherits the well-defined standardized
query and management capability from RDB and the object and
multimedia data management capability from OODB. This
advantage led ORDB to emerge in the market (Maatuk et al.,
2016).
There are other IFC model servers today that took different
approaches from RDB or ORDB. Examples include Express
Data Manager Server (EDMmodelServer) (Jotne IT, 2013) and

*Ph.D. Candidate, Dept. of Civil and Environmental Engineering, Carnegie Mellon University, Pittsburgh, United States (E-mail: chiyonc@andrew.cmu.edu)
**Member, Ph.D., Assistant Professor, School of Architecture, Korea National University of Transportation, Chungju 27469, Korea (E-mail: jwon@ut.ac.kr)
***Member, Ph.D. Senior Researcher, Spatial Information Research Institute, Korea Land and Geospatial Informatix Corp., Jeonju 54870, Korea (Corre-
sponding Author, E-mail: siham@lx.or.kr)

− 4930 −
 IFC Model Restructuring Framework for Efficient Bulk-loading to Object-relational IFC Model Server
WISPER (Faraj et al., 2000) which are based on the OODB
approach and BIMserver based on the NoSQL approach. In the
previous study conducted by the BIMserver initiatives (Beetz et
al., 2011), it was noticed from a user survey that the import
capability is one of the most highly ranked external factors that
was limiting the usefulness of the BIMserver which is an open
source software that can be used to create a server working with
IFC data. The import capability will keep on being an issue
because the overall size of IFC will get larger as the new version
of IFC schema being released.
To address this problem, this paper proposed a new restructuring
algorithm and a bulk-loading based approach that enables
importing large IFC model to the server. This research describes
the efficient processing method converting the reference ids into
the form of a bulk-loading file which is a required form for the
OR-IFC server. Therefore, the scope of this study is limited to the
import module which focuses to enhance the import performance of
the IFC model server. As a result, this study compares the import
performance of the proposed algorithm with BIMserver (Beetz
et al., 2010) and O-R IFC storage model (Li et al., 2016).
However, the purpose of this study is not to compete against
these or other ongoing efforts, but to identify a method that can
improve the import performance within the ORDB approach.
This paper is organized as follows. The next section further
reviews previous studies related to the IFC model server. The
third section explains the main components and the mechanism
of the OR-IFC server and general approaches to import an IFC
instance model file into an IFC server. The fourth section explains
the proposed approach in detail. The fifth section reports the
import performance test of the proposed algorithm and also
compares it with the import performance of BIMserver (Beetz et
al., 2010) and the O-R IFC storage model (Li et al., 2016) for
evaluation. Finally, major findings, the advantages, and limitations
of the proposed import algorithm are discussed.
2. Previous and Current IFC Model Servers
In this section, the history of previously developed IFC model
server types are briefly introduced (Fig. 1). In the early 2000s, a
Stanford research team monitored and analyzed the data exchange
process in a new university project in Helsinki Finland, known as
the HUT-600 project (Fischer and Kam, 2002). The HUT-600
project revealed many problems and limitations of file-based data
exchange and recommended Adachi’s new RDB based IFC model
server, called IMsvr, as a prominent solution (Adachi, 2002). Later,
inspired by IMsvr, the Simple Access to Building Lifecycle
Exchange (SABLE) middleware server was developed as a part of
the Building Lifecycle Interoperable Software (BLIS) project.
Around the same period of time, Georgia Institute of Technology
(Georgia Tech) developed a Computer-Integrated Manufacturing
of Constructional Steelwork Integration Standard Version 2
(CIS/2) server (You et al., 2004). In the CIS/2 server, CIS/2, a
standard information model of steel construction, was used as a
schema for the model server instead of IFC. Both CIS/2 and IFC,
Vol. 22, No. 12 / December 2018 − 4931 −
Fig. 1. Previous IFC Model Servers by Type
although their contents are different, were defined using the
Express language, the standard language for specifying product
models (ISO 10303-11:2004). Georgia Tech’s CIS/2 server was
based on the RDB approach.
The RDB concept was proposed in the early 1970s (Codd,
1970), but is still the most Dominant Database Management
System (DBMS) type. RDB, with a long history of development,
has many advantages such as stable system performance based
on various optimization algorithms and a standardized and well-
defined query language called “Structured Query Language
(SQL) (ISO/IEC 9075-1:2016).” Despite various advantages of
RDB, RDB-based IFC model servers could not directly cope
with the complex inheritance and aggregation structures of IFC
without multiple mapping processes because RDB was proposed
and developed in the early 1970s before the concept of inheritance
and aggregation was introduced. These limitations of RDB-
based model servers resulted in slow performance as explained
above (Jørgensen et al., 2008; Plume and Mitchell, 2007).
To overcome these limitations of RDB-based IFC models,
several alternative approaches have been proposed. The first
good example is the EDMmodelServer, a commercial engineering
database. EDMmodelServer is an OODB approach based system
which included the core database engine and also developed the
query languages using the IFC schema as the native data
structure of the server. As a commercial product, it has many
mature-level functions, which have been commercially adopted
by the industry (Jørgensen et al., 2008).
Another effort came from ORDB-based IFC servers such as an
OR-IFC server (Jeong et al., 2010; Kang et al., 2008; Kim and
Lee, 2007) and an O-R IFC Storage Model that utilized an Oracle
database (Li et al., 2016). The OR-IFC server was proposed and
developed by the Building Informatics Group (BIG) at Yonsei
University (Jeong et al., 2010; Kang et al., 2008; Kim and Lee,
2007; Lee et al., 2014). A major advantage of the ORDB
approach over previous RDB and OODB approaches was that
the existing SQL, an international standard language for querying a
database (ISO/IEC 9075-1:2016), could be used without adopting a
 Chi Yon Cho, Jongsung Won, and Sungil Ham
proprietary query language while supporting the complex inheritance
and aggregation structures of the IFC. The benefit of the ORDB
approach was also noticed by Wuhan University researchers who
indicated that ORDB is suitable for preserving the inheritance
and containment relationships among IFC entities (Li et al.,
2016). ORDB approach also reduces the database complexity by
using fewer tables to store IFC instances and improves data
management efficiency (Li et al., 2016).
Another rapidly emerging IFC server is the BIMserver, which
is being developed by the Netherlands Organization for applied
scientific research TNO and the Eindhoven University of
Technology in the Netherlands (Beetz et al., 2010; BIMServer,
2015). BIMserver adopted the NoSQL approach and uses
BerkeleyDB as the platform (Beetz et al., 2011). NoSQL is also
referred to as a schema-less approach because it ignores the
relations between entities specified in a schema and stores data in
a simplified form of a key and its value (Seeger, 2009). A
shortcoming of the NoSQL approach is that the query requires a
complex restructuring process of relations between entities, and
it becomes challenging when a schema has very complex
inheritance and aggregation structures like IFC. Another study
by Zhang et al. (2014) also developed a semi structured distributed
BIM server using Hadoop Hbase which is also a NoSQL database.
Although many IFC model servers were developed previously,
the import capability was still reported as one of the major issues.
Therefore, this paper focuses on improving the import performance
of an IFC model server developed based on the ORDB approach
by proposing a new restructuring process and mapping method
of IFC data.
3. General Introduction to the IFC Server
Before discussing the restructuring algorithm of IFC data for
importing data into the IFC model server in detail, this section briefly
introduces the main components of the IFC model server and general
approaches of importing an IFC instance model into a server.
3.1 Main Components of the IFC Server
Regardless of the database type, an IFC server is generally
composed of a schema converter, import module, core database
(data storage), and an export module (Fig. 2). The schema
Fig. 2. Overview of the Main Components of an IFC Server
− 4932 −
converter reads in and converts an IFC schema into a native
database structure. The schema converter runs only once to
create empty tables or classes when a new IFC server is setup.
The import module translates an IFC model file into a format
that can be read by the core database and uploads the translated
data to the core database. An IFC file stores model data
according to ISO 10303 Part 21 (ISO 10303-21:2016). The core
database stores and manages the imported IFC-model information.
The export module queries and exports the information queried
from the core database into an IFC file. Among these four
modules, this study focuses on the import module.
3.2 Uploading a Translated IFC Model as an SQL File vs.
an Object File
As described above, the import module usually performs in
two steps. First it translates an IFC model file into a format that
can be read by a core database and then uploads the translated
data to the core database. Regarding the target format, an IFC
instance model file may be translated into a long list of standard
SQL statements. A major drawback of uploading an IFC file
translated into SQL is that it requires one more internal step of
translating SQL statements to a native data structure. This
additional translation process occurs internally, and thus, is
invisible to the users, but greatly slows the performance of
uploading data to a database.
An alternative approach to the SQL approach is to translate an
IFC model file directly into the native object structure of the core
database. This study refers to the file that contains data according
to the native data structure of a core database as an ‘object file’.
The data stored in an object file can be directly "bulkloaded (i.e.,
loaded as a large chunk without an additional translation
process)” into a database management system, and thus, can
greatly reduce the import time. Therefore, this study proposes the
bulk-loading approach for the upload of translated data.
4. Improved Process of Changing the IFC Instance
Model File to a Bulk-loading File
The research team including the authors previously developed
an RDB-based IFC server based on an algorithm developed for
the CIS/2 server (You et al., 2004) before this study to compare
KSCE Journal of Civil Engineering
 IFC Model Restructuring Framework for Efficient Bulk-loading to Object-relational IFC Model Server

with ORDB based server. The RDB-based IFC server took three
days to import a 5-MB church model. This impractically slow
test result motivated us to switch from the RDB approach to the
ORDB approach, which is more efficient in dealing with the
object inheritance and aggregation structure of IFC than RDB.
As a result, the OR-IFC server (Lee et al., 2014) was developed.
This study used the OR-IFC server as a platform. However, other
ORDB-based servers can also be used. This section explains the
data structure of the object file and the process of converting the
IFC file to an object file format for upload to the OR-IFC server.
4.1 Structure of an Object File for the Proposed OR-IFC
Server
There are various methods to load the data into the database
such as a SQL (Structured Query Language)-based method and
the bulk-loading method which considers the speed when loading
large data or migrating the database. RDB-based databases such as
Oracle and Mysql use the Comma-Separated Values (CSV) file
format which is used to exchange data within various spreadsheet
programs (Shafranovich, 2005). The ORDB-based database was
utilized in this paper and the file that is used for bulk-loading has a
native object structure. This native object file is used for bulk-
loading in this study and will refer this as ‘object file’ from now on.
The object file used in this study is defined based on the IFC
express scheme (ISO 10303-11:2004) and the IFC Instance
model data (ISO 10303-21:2016) in Table 1. The object file is
grouped with each corresponding IFC entity and the first line of
each group is described with the entity name and attribute names
based on the IFC express scheme (ISO 10303-11:2004). For
example, the first line of each group is described in a form such
as ‘%class entity name (attribute name1, attribute name2, …,
attribute namen).’ The subsequent lines apply to the IFC Instance
model (ISO 10303-21:2016) and are described with the instance
name and the attributes. It is formed as “Instance name: attribute1
attribute2 … attributen” and in a case where the attribute is a
reference type, it is expressed as “@entity ID|Instance name”.
The “at” symbol (@) in front of the entity id simply denotes the
beginning of an instance name. The number after the vertical bar
(|) denotes the instance name of the IFC entity. Lastly, the object
file is made by utilizing this form for every entity. This is
because the utilized DBMS requires the loading format to be in
this form. If other DBMSs are deployed, the notation of the
DMBS should be followed accordingly. Table 2 shows the data
structure of the object file and the converted example of the
object file using the IfcExtrudedAreaSolid entity as an example.
Figure 3 shows the conversion process of the #110=
IfcExtrudedAreaSolid(#209, #208, #225, 200) instance. The
conversion process follows several steps. First, the header file is
made which corresponds to the entity name IfcExtrudedAreaSolid
of the #110 instance. The entity IfcExtrudedAreaSolid consists of

Table 1. Structure of the IFC Express Scheme and Instance Model Data
Structure Example
ENTITY IfcExtrudedAreaSolid
IFC express scheme (ISO 10303-11)
SweptArea : IfcProfileDef;
Position : IfcAxis2Placement3D;
ENTITY entity name
ExtrudedDirection : IfcDirection;
attribute name: attribute type;
Depth : IfcPositiveLengthMeasure;
END_ENTITY;
END_ENTITY;
#110 = IfcExtrudedAreaSolid (#209,#218,#225,200);
#209 = IfcArbitraryClosedProfileDef (.AREA.,$,#412);
IFC Instance model data (ISO 10303-21)
#218 = IfcAxis2Placement3D (#6,$,$);
#225 = IfcDirection ((0.,0.,1.));
Instance name = entity name(attribute)
#416 = IfcExtrudedAreaSolid (#414,#415,#19,8.5);
#583 = IfcExtrudedAreaSolid (#580,#582,#19,8.5);

Table 2. Data Structure of the Object File, Example of Object File, and Entity ID Information
Object file structure
%class entity name1 (attribute name1, attribute name2, … , attribute namen)
Instance name1: attribute1 attribute2 … attributen
Instance name2: attribute1 attribute2 … attributen
…
Instance name m: attribute1 attribute2 … attributen

%class entity nameO (attribute name)

Instance name: attribute

* If attribute is a reference type:

@entity ID|Instance name
The Entity ID of each IFC entity is unique and is automatically assigned by the OR-IFC server.
Example of object file Entity ID
%class IfcExtrudedAreaSolid(SweptArea, Position, ExtrudedDirection, Depth) % id IfcArbitraryClosedProfileDef 27
#110: @27|#209 @34|#218 @192|#225 200 % id IfcAxis2Placement3D 34
#416: @27|#414 @34|#415 @192|#225 8.5 % id IfcDirection 192
#583: @27|#580 @34|#582 @192|#225 8.5 % id IfcExtrudedAreaSolid 257

Vol. 22, No. 12 / December 2018 − 4933 −

 Chi Yon Cho, Jongsung Won, and Sungil Ham
Fig. 3. Example of Translating IFC Instance Into Object File Structure
four attributes which are SweptArea, Position, ExtrudedDirection,
and Depth defined by the IFC express scheme (ISO 10303-11:2004).
Thus, the header file is written as “%class IfcExtrudedAreaSolid
(SweptArea, Position, ExtrudedDirection, Depth)”.
Second, the attributes “#209, #218, #225, 200” of instance
#110 are converted. Note that the #209 attribute is a reference type.
As such, this needs to be converted into the form of “@entity
ID|Instance name”. Thus, the instance #209 needs to be searched
and then get the entity name of the instance in order to find the
entity ID of #209. For example, since instance #209 is
“#209=IfcArbitraryClosedProfileDef(.AREA.,$,#412)”, the entity
name is IfcArbitraryClosedProfileDef, and the entity ID of
IfcArbitraryClosedProfileDef is 27 from Table 2. Therefore,
#209 is converted to “27|#209”. Similarly with the preceding,
#218 and #225 are converted to “34|#218” and “192|#225”
respectively since the entity names are ifcAxis2Placement3D
and IfcDirection and their entity ID are 34 and 192, respectively.
The last attribute “200” is not converted since it is not a reference
type. Lastly, instance #110 is converted in the appropriate form
as “#110: @27|#209 @34|#218 @192|#225 200”.
4.2 Implementation of the Conversion Process
In this section, the implementation of the conversion process
(from IFC instance model file to object file) is described. The
key of the conversion process is to rapidly search the numerous
amount of reference IDs within the large-size IFC instance
model file. In general, an iteration-based search method is used
to compare all the information of the instance list in a consecutive
order. Although the implementation of the iteration based method is
simple, it consumes considerable amount of computation time
for searching the IDs. Another searching method is using a ‘hash
table’ which is recently developed in object-oriented programs to
efficiently search through the key and value. A hash table is a
− 4934 −
versatile data structure for performing fast associative lookups,
which requires O(1) average memory accesses per lookup (Song
et al., 2005). One disadvantage of using a hash table method is
that it has the possibility to cause hash collisions if the hash
function creates identical index for more than one key. However,
a hash table that causes no hash collisions was generated in this
study when converting the IFC instances to the form of an
‘object file’ which is used for bulk-loading IFC to the database
‘CUBRID (2017)’. The main role of creating the ‘Hash table’ is
to store the IFC instance name as IDs and to lookup the table
during the conversion process of changing the old IDs to new
IDs. The old ID is the original instance name in IFC and the new
ID is used for storing the ‘object file’ into the database ‘CUBRID’.
The conversion process was implemented using C# which has
a ‘Dictionary’ class that has the ‘hash table’ function. A ‘Dictionary’
class utilizes a ‘Chaining’ method which checks the data in a
bucket and adds a chain node while invoking the next node if
data exists. By using this function, the conversion proceeds in
three steps as the following: (1) load entity names and IDs, (2)
load the parsed IFC instance file to memory, and (3) convert IDs
to generate object file.
1. Load entity name and IDs
The first step is to load the list information of the IFC entity
name and the automatically assigned id (number) by the OR-
IFC server into memory (Fig. 4).
1) Parse the entity name and the id (①)
2) Create the instance ifcEntity of the IFCEntity Class (②)
3) Save the IFCEntity and the string name to the
4) ifcEntityDictionary (instance of Dictionary Class) (③, ④)
2. Parse the IFC instance file and load to memory
The second step is to load the parsed IFC instance file into
memory (Fig. 5).
1) Parse the instance name, ifc entity name, and values (attributes)
KSCE Journal of Civil Engineering
 IFC Model Restructuring Framework for Efficient Bulk-loading to Object-relational IFC Model Server
Fig. 4. The First Process: Parse Object id File and Load
by each row (①)
2) Use the entuty name (key) to get the ifcEntity which is the
instance of IFCEntity class in the ifcEntityDictionary (②)
3) Create the instance ifcEntityInstance of the IFCEntity_
Instance class by using the instance name, values(attributes), and
ifcEntity (this process corresponds to ③, ④, and ⑤)
4) Store the created ifcEntityInstance into the ifcInstaceDictionary
(instance of Dictionary class) (⑥, ⑦)
5) Lastly, store the ifcEntityInstance into ifcEntityInstanceArraylist
which is the member variable of ifcEntity.
3. ID conversion Process to Generate Object File
The last step is to generate the object file using the IFCEntity
and instances of IFCEntityInstance that are stored into the
memory in the previous steps (Fig. 6).
1) Convert the dictionary which contains instance of IFCEntity
into an array. And then proceed with the convert process by
repeatedly calling the instance ifcEntity of IFCEntity (①)
2) In one ifcEntity, multiple instances that have identical entity
Fig. 5. The Second Process: Parse ifc Instance (model) File and Load
Vol. 22, No. 12 / December 2018 − 4935 −
type are stored in ifcEntityArray. Repeatedly call the ifcEntityInstance
which is the instance of IFCEntityInstance (②)
3) If the value in the value array of ifcEntityInstance is a
reference type ‘instance name’, it is required to check the id
number of the reference IFCEntity. Thus, find the IFCEntityInstance
(referencedIFCEntityInstance) using the instance name in the
ifcInstanceDictionary ( ③, ④).
4) Then generate the new value by combining the id number (⑤)
which is obtained from the variable ifcEntity (referencedIFCEntity
(⑥) of IFCEntityInstance and the instance name(⑦)\
5) Lastly, the object file is generated by repeating the process
above.
5. Performance Test
A performance test was conducted using four different sizes of
IFC model files to measure the time complexity and the space
complexity of the proposed framework. Four different model
files were imported to the server and the total import time was
measured. The total import time is the sum of the ‘IFC-to-object
file’ conversion time and the import time bulk-loading the object
file to the CUBRID database. Then, the results of the total import
time was compared with the import time of BIMserver. Moreover,
the space complexity was measured by checking the consumed
memory during the conversion process to evaluate the trade-off
between time and space (Table 3). The memory consumption
was only checked for the conversion process because the IFC
restructuring process is the main scope of this study and the
authors assumed that the space complexity would not be affected
significantly by the different size of IFC model files during the
bulk-loading process.
For the performance test, the framework was implemented
using CUBRID as a core DBMS, IFC 2 × 3 as the IFC schema,
and C# as a programming language. CUBRID is an open source
ORDBMS owned and used by the largest web portal company in
South Korea (CUBRID, 2017). The proposed import algorithms
 Chi Yon Cho, Jongsung Won, and Sungil Ham

Fig. 6. The Third Process: ID Conversion

can be applied to any version of IFC, but IFC 2 × 3 was used Table 3. The Total Import Time of the OR-IFC Server for Different
since it is still the most commonly used format. Currently IFC4 IFC Model Files
(formerly known as IFC 2x4), which was released in September IFC file size 5 MB 61 MB 111 MB 346 MB
2012, is the latest version of IFC (buildingSMART, 2012). Number of data instances 92,570 878,215 1,893,588 9,732,936
In addition, a small software application was developed to Generated object file size 4 MB 51 MB 91 MB 272 MB
measure the runtime and the memory of the proposed import Conversion Time (a) 2 sec 19 sec 34 sec 126 sec
algorithm to evaluate the performance. The IFC server and the Bulk-loading Time (b) 4 sec 37 sec 123 sec 725 sec
import modules were executed on a regular performance computer Total import time (a+b) 6 sec 56 sec 157 sec 851 sec
with a Windows 7 64 bit operation system. The central processing Space complexity 0.11GB 1.91 GB 3.92GB 11.90 GB
unit was an Intel(R) Core(TM) i7-4790 CPU @ 3.60 GHz and
the memory (RAM) of the computer was 32.0 GB.
bulk-loading time. The ‘conversion time’ is the time it requires
5.1 OR-IFC Server Import Time Measurement to convert the IFC model file into an object file by using the
Four different size of IFC model files (small size of 5 MB, technique explained in section 4. The ‘bulk-loading time’ is the
medium sizes of 61 MB and 111 MB, and large size of 346 MB) runtime to import the object file into the CUBRID database.
were used for testing to measure the time complexity and the Furthermore, the space complexity in Table 3 shows the amount
space complexity of the proposed import framework of the OR- of consumed memory during the conversion process.
IFC server (Table 3). The model files were all from actual While Table 3 shows that the space complexity increases
industry projects and Table 3 shows the amount of resources the dramatically as the IFC model size increases, the conversion
proposed method consumed for each IFC model files. process of the algorithm in terms of time complexity takes linear
The total import time is the sum of the conversion time and the time as shown in Fig. 7. The conversion time requires time

− 4936 − KSCE Journal of Civil Engineering

 IFC Model Restructuring Framework for Efficient Bulk-loading to Object-relational IFC Model Server

Fig. 8. Import Performance Test Comparison between BIMserver

Fig. 7. OR-IFC Server Import Performance Test and OR-IFC Server

proportional to the length of the number of data instances. This data structure for data query and export processes since the no-
means that the IFC restructuring algorithm has decent performance schema approach discards a schema structure. Thus, the proposed
considering the increasing number of data instances when the approach in this study can be said to be a significant improvement
IFC model file becomes larger. reducing the import time while maintaining the data structure.

5.2 Comparison between the Proposed OR-IFC Server
and BIMserver
The import performance of BIMserver and the proposed OR-
IFC server was compared using the same four different size of
model files that were used in section 5.1 (Table 4). The release
version of BIMserver was ‘bimserverjar-1.5.61’, which was the
latest version of BIMserver at the time of the test.
As a result, the import time of the OR-IFC server for the small
size 5 MB model test was half the time of the BIMserver.
Furthermore, the import time difference dramatically increases
when the file size becomes larger. For example, the import time
of the OR-IFC server outperformed the BIMserver by 29.9 times
when the 111 MB IFC file was tested (Figure 8). Therefore, the
poor import performance is still an issue when storing large IFC
model files into the previously developed IFC server. Unfortunately,
the import performance test of BIMserver for the 346 MB
building model case could not be completed due to an unknown
BIMserver system error. However, it is possible that the IFC
model itself could have been the problem that caused the error.
The strength of the no-schema approach, which is utilized by
the BIMserver, lies in its simplicity for the data import process
although it may take considerable effort and time to rebuild the
5.3 Import time Comparison with Previous Literatures
To further evaluate the import performance of the proposed
approach, the import time was compared with other previous
studies using the ratios ‘Kilobyte per second’ and ‘Second per
kilobyte’. The performance of several different BIM servers
were compared based on the import time and the IFC model size
(Table 5).
First, the value of IFC model sizes were divided by the import
time. Then the import time values were divided by the IFC
model size. The two columns ‘KB/sec (a / b)’ and ‘sec/KB (b /
a)’ in Table 5 shows the corresponding ratios. The top five results
of each ratio that showed good performance are marked in bold.
Note that the test results above are not to be compared directly
since the test environment were not identical among the studies.
However, we can still observe the present state of the IFC
server’s import performance and thus obtain a general idea.
Especially, it is worth mentioning and comparing these results
with the object-relational storage model that was suggested in Li
et al. (2016) which used ORDB from an Oracle database, but
had poor performance since the consumed time for import took
more than 27 times that of the proposed approach to import a 5
MB IFC model file to the server.

Table 4. Import time Comparison of BIMserver and OR-IFC Server

Total import time Ratio
Test model IFC file size
BIMserver (a) OR-IFC server (b) (a / b)
Church model 5 MB 12 sec 6 sec 2.0
83 sec
University model 61 MB 56 sec 1.5
(1 min 23 sec)
4,697 sec 157 s
Office model 111 MB 29.9
(1 hour 18 min 17 sec) (2 m 37 s)
851 sec
Large size model 346 MB N/A N/A
(14 min 11 sec)

Vol. 22, No. 12 / December 2018 − 4937 −

 Chi Yon Cho, Jongsung Won, and Sungil Ham

Table 5. Performance Comparison Based on Import Time and IFC Model Size
Rank by
Rank by
Database Original IFC Number of Import KB/sec sec/KB import time
Server import speed
type file size (a) instances time (b) (a / b) (b / a) per data
(KB/sec)
(sec/KB)
5,274 KB 92,570 6 sec 879.00 0.0011 3 2
OR-IFC server 62,214 KB 878,215 56 sec 1110.96 0.0009 1 1
ORDB
(Cubrid database) 113,406 KB 1,893,588 157 sec 722.33 0.0014 5 4
354,740 KB 9,732,936 851 sec 416.85 0.0024 7 6
OR-IFC server 31 KB 425 3 sec 10.33 0.0968 12 11
(Oracle database), ORDB 5,298 KB 102,285 166 sec 31.92 0.0313 10 9
Li et al. (2016) 37,568 KB 660,952 669 sec 56.16 0.0178 9 8
5,274 KB 92,570 12 sec 439.50 0.0023 6 5
BIMserver
NoSQL 62,214 KB 878,215 83 sec 749.57 0.0013 4 3
(2015)
113,406 KB 1,893,588 4,697 sec 24.14 0.0414 11 10
BIMISP
(Hadoop Hbase), NoSQL 204,800 KB - 230 sec 890.43 0.0011 2 2
Zhang et al. (2014)
Centralized BIM server,
RDBMS 204,800 KB - 543 sec 377.86 0.0026 8 7
Zhang et al. (2014)

Therefore, the experimental results above show that the proposed
approach of this study has good potential. The technique
described in this study is anticipated to be used in future BIM
projects that consists of large amount of IFC data to process and
to share among project participants when using an IFC model
server.
6. Conclusions
Despite previous and current efforts to develop various IFC
servers, IFC servers are still limited by slow import performance.
As the size of a BIM model becomes larger, the import performance
becomes a non-trivial issue. Current practice in the industry
maintains BIM to be under 150 MB in order to easily manipulate
the model using a BIM authoring tool. However, IFC servers
have difficulties when importing BIM that exceeds 300 MB
mainly due to massive iteration during the mapping processes.
While developing the IFC model restructuring algorithm, it was
discovered that the import performance become exponentially slower
as the model size increases when the algorithm was not optimized.
The poor import performance problem was due to numerous cycles
of iteration in the entity search and mapping process.
To address this issue, the authors proposed a new robust mapping
method and a restructuring algorithm to efficiently import an IFC
model to an ORDB-based server. A hash table was utilized to
pre-process and store the entities and their identifier information.
Then, by using the bulk-loading method the import performance
was significantly improved. It required 56 seconds to import a 61
MB university-building model file on a regular performance
computer and took 2 minutes 37 seconds to import a 111 MB
office-building model file. For a large-sized model file, it
required 14 minutes 11 seconds to import a 346 MB file. The
result (Table 5) shows that the import speed (KB/sec) was
improved 30 times (722.33/24.14) faster than the BIMserver for
the 111 MB test case. Moreover, to the best of our knowledge,
this is the first paper that attempted to import a large IFC model
size that exceeds 300 MB, and also showed that it could be
stored in an IFC server in a timely manner.
The experimental results have shown that the import performance
of the proposed method outperforms the IFC server which is
developed based on a no-schema approach. In addition, the
proposed algorithm has an advantage of maintaining the data
structure and relations between entities, while the no-schema
approach imports data ignoring the data structure.
Although the authors aimed to address the slow import
performance problem in this paper, several issues remain as
limitations. In practice, fourteen minutes to import a 346 MB file
may still not be acceptable. The algorithm should be further
improved in future studies. One possible approach to improve
the performance is to use a high-end computer. A parallel
computing approach can also be deployed. Another option is to
divide the IFC model file into small pieces and simultaneously
translate using multiple processors and then merge the pieces
into one. Another limitation of this study is that the proposed
method consists of two separated processes: the conversion
process and the import process. The reason of the separation was
because the focus of this study was to develop an IFC model
restructuring algorithm and not a bulk-loading import module.
However, the two processes would need to be integrated in order
for the proposed method to be adopted in practice.
Acknowledgements
The authors thank Prof. Ghang Lee for manuscript assistance
and also thank the Building Informatics Group (BIG) at Yonsei
University providing the experiment environment. This research
was supported by the Ministry of Land, Infrastructure, and
Transport in Korea under the Urban Planning and Architecture

− 4938 − KSCE Journal of Civil Engineering

 IFC Model Restructuring Framework for Efficient Bulk-loading to Object-relational IFC Model Server
(UPA) research support program and was supervised by the
Korea Agency for Infrastructure Technology Advancement (KAIA)
(17NSIP-B067569-05).
References
Adachi, Y. (2002). “Overview of IFC model server framework.” Eur Conf
Process Prod Model - eWork Ebus Archit Eng Constr, pp. 367-372.
Adachi, Y. (2002). Technical overview of IFC model server 2002, http://
cic.vtt.fi/projects/ifcsvr (accessed May 14, 2018).
Beetz, J., van Berlo, L., de Laat, R., and van den Helm, P. (2010).
bimserver. org–An Open Source IFC Model Server, Proc CIB W78
2010 27th Int Conf Egypt, pp. 16-18.
Beetz, J., van Berlo, L., de Laat, R., Bonsma, P. (2011). “Advances in
the Development and Application of an Open Source Model Server
for Building Information.” Proc CIB W78 Conf Nice 2011.
BIMServer (2015). BIMServer: open source Building Information Model
server 2015. http://bimserver.org/ (accessed November 5, 2017).
Chen, P. H., Cui, L., Wan, C., Yang, Q., Ting, S. K., and Tiong, R. L. K.
(2005). “Implementation of IFC-based web server for collaborative
building design between architects and structural engineers.” Autom
Constr, Vol. 14, No. 1, pp. 115-28, DOI: 10.1016/j.autcon.2004. 08.013.
Codd, E. F. (1970). “A relational model of data for large shared data
banks.” Commun ACM, Vol. 13, pp. 377-387, DOI: 10.1145/
362384.362685.
CUBRID (2017). CUBRID Official Website. http://www.cubrid.org
(accessed November 5, 2017).
Faraj, I., Alshawi, M., Aouad, G., Child, T., and Underwood, J. (2000).
“Industry foundation classes Web-based collaborative construction
computer environment: WISPER.” Autom Constr, Vol. 10, No. 1,
pp. 79-99, DOI: 10.1016/S0926-5805(99)00038-2.
Fischer, M. and Kam, C. (2002). PM4D Final Report. CIFE Tech Rep,
Vol. 143, pp. 0-50 https://web.stanford.edu/group/4D/download/
PM4D_Final_Report.pdf (accessed May 14, 2018).
IFC Model Server. In IFC Wiki, IFC-Developers (2017). http://www.
ifcwiki.org/index.php/IFC-Developers (accessed November 5, 2017).
IFC4 (2012). buildingSMART Official Website 2012. http://www.
buildingsmart-tech.org/specifications/ifc-releases/ifc4-release (accessed
May 14, 2018).
ISO. ISO 10303-11 (2004). Industrial automation systems and integration -
Product data representation and exchange - Part 11: Description
methods: The EXPRESS language reference manual 2004:2, DOI:
https://www.iso.org/standard/38047.html.
ISO. ISO 10303-21 (2016). Industrial automation systems and integration -
Product data representation and exchange - Part 21: Implementation
methods: Clear text encoding of the exchange structure 2016:3,
DOI: https://www.iso.org/standard/63141.html.
ISO. ISO 16739 (2013). Industry Foundation Classes (IFC) for data sharing
in the construction and facility management industries 2013:1, DOI:
https://www.iso.org/standard/51622.html.
ISO. ISO/IEC 9075-1 (2016). Information technology - Database languages
- SQL - Part 1: Framework (SQL/Framework). 2016:5, DOI: https://
www.iso.org/standard/63555.html.
Jeong, J., Lee, G., and Kang, H. (2010). Preliminary Performance Evaluation
of an ORDB-based IFC server and an RDB-based IFC server by
using the BUCKY Benchmark Method, W078-Special Track 18th
CIB World Build. Congr. May 2010 Salford, United Kingdom, 2010,
p. 192.
Vol. 22, No. 12 / December 2018 − 4939 −
View publication stats
Jotne IT. (2013). EDMmodelServer Official Website 2013. http://www.
jotneit.no/products/edm-model-server-ifc (accessed May 14, 2018).
Jørgensen, K. a., Skauge, J., Christiansson, P., Svidt, K., Sørensen, K. B.,
Mitchell, J. (2008). Use of IFC Model Servers-Modelling Collaboration
Possibilities in Practice, Aalborg: Department of Production, Aalborg
University http://vbn.aau.dk/en/publications/use-of-ifc-model-servers--
modelling-collaboration-possibilities-in-practice(68eb55e0-77f1-11dd-
8b88-000ea68e967b).html (accessed May 14, 2018).
Kang, H.-S., Lee, G., and Kim, S. W. (2008). “A framework for developing
an IFC server for supporting Construction Product Life Cycle
Management (CPLM).” Comput. Struct. Eng. Inst. Korea Conf.,
pp. 458-463.
Kim, S. W. and Lee, G. (2007). “Mapping IFC to Object-oriented Relational
Database.' KICEM Conf., Pukyong University, Busan, pp. 301-304.
Lee, G., Jeong, J., Won, J., Cho, C., You, S., Ham, S., Kang, H. (2014).
“Query Performance of the IFC model server using an object-
relational database approach and a traditional relational database
approach.” J Comput Civ Eng, Vol. 28, pp. 210-222, DOI: 10.1061/
(ASCE)CP.1943-5487.0000256.
Li, H., Liu, H., Liu, Y., and Wang, Y. (2016). “An object-relational IFC
storage model based on oracle database.” Int Arch Photogramm
Remote Sens Spat Inf Sci - ISPRS Arch, Vol. XLI, Part B2, pp. 625-
631, DOI: 10.5194/isprsarchives-XLI-B2-625-2016.
Maatuk, A. M., Ali, M. A., Moftah, R. A., and Elkobaisi, M. R. (2016).
“Performance evaluation of an RDB and an ORDB: A comparative
study using the BUCKY benchmark.” Proc - 2016 Int Conf Eng
MIS, ICEMIS 2016, DOI: 10.1109/ICEMIS.2016.7745312.
McGraw-Hill Construction, Bernstein, H. M., Jones, S. A., and Gudgel,
J. E. (2010). “The business value of BIM in europe: Getting building
information modeling to the bottom line in the United Kingdom,
France and Germany.” Smart Market Report, pp. 1-48, DOI:
10.1016/j.autcon.2015.07.004.
McGraw-Hill Construction, Jones, S. A. and Bernstein, H. M. (2012).
“The business value of BIM in North America.” Smart Market Report,
pp. 1-68.
McGraw-Hill Construction, Young, N. W., Jones, S. A., Bernstein, H.
M., and Gudgel, J. E. (2009). “The business value of BIM-Getting
Building Information Modeling to the bottom line.” Smart Market
Report, pp. 1-50.
Plume, J. and Mitchell, J. (2007). “Collaborative design using a shared
IFC building model-Learning from experience.” Autom Constr, Vol. 16,
pp. 28-36, DOI: 10.1016/j.autcon.2005.10.003.
Seeger, M., Ultra-Large-Sites, S. (2009). Key-value stores: a practical
overview, Comput Sci Media 1–21, http://blog.marc-seeger.de/
assets/papers/Ultra_Large_Sites_SS09-Seeger_Key_Value_Stores.pdf
(accessed May 14, 2018).
Shafranovich, Y. (2005). RFC 4180 common format and MIME type for
CSV Files, https://tools.ietf.org/html/rfc4180 (accessed May 14, 2018).
Song, H., Dharmapurikar, S., Turner, J., and Lockwood, J. (2005). “Fast hash
table lookup using extended bloom filter.” ACM SIGCOMM Comput
Commun Rev., Vol. 35, p. 181, DOI: 10.1145/1080091. 1080114.
You, S.-J., Yang, D., and Eastman, C. M. (2004). “Relational DB
implementation of STEP based product model.” Build. Futur. 16th
CIB World Build. Congr., pp. 1-18.
Zhang, J. P., Liu, Q., Yu, F. Q., Hu, Z. Z., and Zaho, W. Z. (2014). “A
framework of cloud-computing based BIM service for building
lifecycle.” Comput Civ. Build Eng., pp. 1514-1521, DOI: 10.1061/
9780784413616.188.