Content uploaded by Gonçal Costa
Author content
All content in this area was uploaded by Gonçal Costa on Sep 10, 2016
Content may be subject to copyright.
Simulation model generation combining IFC and CityGML data
G.N. Lilis, G.I. Giannakis & K. Katsigarakis
Department of Production Engineering and Management, Technical University of Crete, Chania, Greece
G. Costa & ´
A. Sicilia
ARC, La Salle Engineering and Architecture, Ramon Llull University, Barcelona, Spain
M. ´
A. Garcia-Fuentes
Department of Energy, CARTIF Foundation, Valladolid, Spain
D.V. Rovas
Institute for Environmental Design and Engineering, University College London, London, UK
ABSTRACT: The energy efficiency requirements at district scale revealed the need for detailed building en-
ergy simulations, with which the overall district energy demand can be estimated with an acceptable degree
of accuracy. In order to meet this need, an automated simulation model generation process is introduced
at the context of the European project OptEEmAL, which includes: a query stage where data are gathered
from IFC, CityGML files, and a transformation stage where a single IDF file is generated for a building
in a district environment, suitable for EnergyPlus simulations. The queried data are assumed to conform
to certain correctness, completeness and consistency conditions across district and building scales. As a
demonstration example, a simulation model is generated for a specific building. Future improvements of
this work are discussed related to the integration of all the data requirements of the proposed process, in a
District Data Model under an ontological framework.
1 INTRODUCTION
The recent building energy footprint reduction re-
quirements highlighted the value and promoted the
use of detailed building thermal energy simula-
tions. Furthermore, since the thermal performance
of buildings in a district environment is affected by
phenomena caused by neighbor building topologies,
treating buildings individually and neglecting their
neighbor building topologies impact (e.g. shading
effects and microclimate), results to reduced ac-
curacy in their simulation results. The need for
accurate thermal energy simulations is met by a
plethora of simulation engines, developed for ei-
ther building-scale simulations (e.g. EnergyPlus),
where detailed building geometry information is re-
quired, or district-level simulations (e.g CitySim),
where the geometry details of buildings are omitted.
The input data to the above programs are formatted
properly according to the specific program require-
ments.
From the input data availability perspective, two
popular data schemas have been developed for dif-
ferent purposes: the first is a BIM scheme called
IFC (ISO 16739, 2013), designed for building-scale
data and promoting interoperability among AEC in-
dustry programs; the other is a GIS schema, called
CityGML (Kolbe et al., 2005), structured in order to
render city scale data. These data sources cannot be
used directly as inputs to thermal energy simulation
programs as they require further processing related
to the generation of the second-level space bound-
ary geometric topology (Bazjanac, 2010).
Incorporating the districts environmental impact
in building-scale simulation programs improves the
quality of their results. Attempts towards this direc-
tion have been reported via the use of co-simulation
(Thomas et al., 2014). In order to perform detailed
building thermal energy simulations including the
buildings district environmental impact, a simula-
tion model generation process is introduced, as the
main subject of the present work. Parts of this pro-
cess will be used at the context of the European
project OptEEmAL 1, which aims at automating the
selection of the best energy conservation refurbish-
ment scenario of a district, according to specific per-
formance indicators. In order to include the dis-
tricts environmental impact to the generated simula-
tion models, input data from GIS and BIM sources
are integrated. This idea of integrating data across
building and district scales has appeared in past re-
search efforts: SEMANCO project (Sicilia et al.,
2014), GeoBIM extension (de Laat & Van Berlo,
2011), ontology-based Unified Building Model (El-
Mekawy & ¨
Ostman, 2012), virtual 3D city model
(D¨
ollner & Hagedorn, 2007).
The rest of the paper is organized into two parts.
In the first part, the current simulation model gener-
ation process is described which uses data from an
IFC file of a building, combined with district data
of surrounding buildings extracted from a CityGML
file, in order to generate inputs suitable for the en-
1https://www.opteemal-project.eu
ergy simulation program EnergyPlus. Initially, the
data requirements of the process are highlighted,
followed by the definition of data quality rules,
these data have to satisfy, in order to be suitable for
simulation model generation. Then, the algorithmic
parts of the process are described, followed by an
application example, on specific district data.
In the second part of the paper, it is discussed
how the current simulation model generation pro-
cess can be improved by moving some of its func-
tional components and organizing its input data, in
a single district data model, using an ontological
framework. Such extensions will introduce interop-
erability possibilities to the process by establishing
semantic connections to other simulation tools.
2 DATA REQUIREMENTS
Building simulation data models require a variety
of data, ranging from pure geometric descriptions,
to operation characteristics of micro-climate control
devices installed in building interiors. In order to
organize such versatile data across building and dis-
trict scales, an initial classification is attempted. Ac-
cording to this classification, the required data for
a simulation model generation in a district environ-
ment can be classified into three categories (as illus-
trated in figure 1): BIM data, GIS data, and Contex-
tual data. The characteristics of each category are
described in the following sections.
Weather
data
Simulation
parameters
GIS data
BIM data
Contextual data
Schedules
Building
Typologies
Energy
prices
Figure 1: Data requirements of the simulation model genera-
tion process.
2.1 BIM data
The required BIM data for simulation model gener-
ation are related to building geometric descriptions,
material thermal properties, and the characteristics
of the systems installed in the buildings. The re-
quired geometric BIM data contain either: the solid
geometric representations of architectural elements
(walls, slabs, roofs, coverings, openings and others,
illustrated in figure 2A), or their respective bound-
ary surface topology (illustrated in figure 2B).
The boundary surface topology is the only ge-
ometric prerequisite of a simulation model gen-
eration process. If it is missing, it can be ob-
tained from the solid geometric representations of
the architectural elements via geometric operations
as illustrated in figure 2 (from a set of architec-
tural element solid representations (part A), the re-
spective boundary surface topology (part B) is pro-
duced). The boundary surface topology consists
of data belonging to three categories: (a) second-
level space boundaries, (b) virtual space partitions
and (c) shading surfaces. The second-level space
boundaries (Bajzanac, 2010), are boundary sur-
face pairs, through which thermal energy flows ei-
ther among building spaces (internal space bound-
aries, green surfaces of figure 2B) or between a
building space and its environment air/ground (ex-
ternal space boundaries, orange surfaces of figure
2B). Virtual space partitions are also boundary sur-
face pairs, which separate virtually internal building
spaces, without the use of a building construction
(blue surfaces of figure 2B). Finally, shading sur-
faces are boundary surfaces which play an indirect
role in a thermal simulation by blocking sunlight.
A. Architectural element set B. Boundary surface topology
Geometric
operations Shading
surfaces
Virtual
space
partitions
Internal space boundaries
External
Space
boundaries
Figure 2: Architectural element set and its second-level space
boundary topology obtained from CBIP.
The thermal properties of the material layers
used in the building constructions are also required
for a simulation model generation, since they pro-
vides necessary information in order to determine
thermal energy exchange among building spaces.
The properties of opaque constructions refer to
values of quantities related to every layer in the con-
struction, such as: thickness, density, thermal con-
ductivity and specific heat and others. If layer bed-
ding information is not available, values of quanti-
ties referring to the whole construction, such as: to-
tal thermal mass and thermal resistance, have to be
specified. For transparent constructions only quan-
tity values referring to the overall construction, such
as: the U-value and the solar transmission coeffi-
cient, are required to be specified as material prop-
erties.
Finally, the operation characteristics of energy
consuming, or self-sufficient devices installed in
buildings which alter their internal thermal condi-
tions, defined in a broad sense as systems, are BIM
data which are also required.
2.2 GIS data
Building simulation models at district scale require
data referring to the overall district, which are not
included in the BIMs and are defined as GIS data.
Similarly to the BIM data types, there are three
GIS data types, characterized as geometric, mate-
rial property and system data types. GIS geomet-
ric data contain descriptions of the district building
envelopes as polygon surface sets. These polygons
are used in neighbor building shading calculations.
GIS material property data contain the reflectivity
coefficients of neighbor building surfaces, used for
solar calculations. Finally, GIS system data refer to
characteristics of district-scale systems which may
be present in the district servicing multiple build-
ings.
2.3 Contextual data
Finally simulation models require data, which can-
not be classified as BIM-related or GIS-related data
and are defined as Contextual data. These data can
be classified into the following five data types:
–Weather data include the values of weather quan-
tities required for building thermal simulations,
such as: Outside dry-bulb temperature and pres-
sure and others, which are contained in weather
files.
–Schedules are vectors formed by a time series
which contains values describing the presence of
users (occupancy) and the operation of passive
and active devices installed in the buildings.
–Simulation parameters are values assigned to
specific parameters required in order for a sim-
ulation to be initiated, such as: warm up time,
starting and ending time instances, time step and
others.
–Energy prices refer to the cost in monetary units
of the energy use in the district.
–Building typologies contain data values which
are fixed for all buildings and are based on the ge-
ographical location, use and other classification
parameters (Vimmr et al., 2013). In case build-
ing data are not available for specific buildings,
they can be inferred using building typologies.
3 DATA QUALITY
The required data, classified as BIM, District or
Contextual data, are obtained either from CityGML
and IFC data sources, or they are inserted manually.
These data pass three stages of data quality checking
operations in order to be suitable for a simulation
model generation. These operations include consis-
tency, correctness and completeness checks and are
explained analytically in the following sections.
3.1 Data consistency
The first checking operation ensures that an in-
serted IFC model is consistent with the underlying
CityGML model. Although BIM geometric data
obtained from an IFC file, might be visually cor-
rect, they may be inconsistent with the CityGML
geometric data, which are described in world co-
ordinates. Such inconsistencies occur when the
geometric definition of a building in IFC model
appear slightly rotated or translated with respect
to the CityGML shell geometric definition of the
same building. The inserted IFC model is consid-
ered CityGML-consistent if all IFC architectural el-
ements are located inside a single CityGML shell.
In any other case an inconsistency is declared and is
communicated back for correction.
3.2 Data correctness
Both IFC and CityGML data should be checked for
correctness, before being used as inputs to the simu-
lation model generation process. Incorrect data have
many causes and the respective errors have different
characteristics, as discussed next.
3.2.1 Error causes
There are three different sources of the errors ap-
pearing in IFC and CityGML data files, which can
be ordered, depending on their causes, as follows:
–Scanning errors. Some of the CityGML geo-
metric data are generated from point clouds ob-
tained from terrestrial or airborne scanning de-
vices, which contain errors related to malefaction
of these devices or incorrect geo-referencing of
the obtained points.
–Design errors. Oftentimes IFC and CityGML
files contain errors caused by incorrect design,
where the designer specifies incorrectly an archi-
tectural element, or material property or system.
–Exporter errors. Finally there are cases where ei-
ther the IFC or the CityGML exporters generate
errors by populating incorrectly the data classes
in the respective IFC and CityGML files.
3.2.2 Error classification
Errors appearing in IFC and CityGML files can be
classified, with respect to their characteristics, into
the following two categories:
–Missing data. There are cases where the data in
IFC or CityGML files are not complete. For ex-
ample, certain data might be omitted from the
specification of the material layer properties of
a construction. These errors are characterized as
missing data errors.
–Incorrect data. Apart from the missing data er-
rors, there are cases where IFC or CtyGML data
are incorrect. For example a solid geometric rep-
resentation of an architectural element, might be
misplaced with respect to other element repre-
sentations.
A more detailed investigation of the geometric er-
rors encountered in IFC files, and correction tech-
niques, can be found in (Lilis et al., 2015).
3.3 Data completeness
Finally, the inserted IFC models are checked for
completeness. More specifically, IFC data have
to satisfy certain minimum data requirements ex-
pressed as a set of conditions in order to be suitable
for simulation model generation, which are:
–Boundary conditions. The boundary surfaces, at
which the buildings of the district are attached to
the outside air and ground, should be explicitly
defined for every building.
–Conditioned spaces. The inserted IFC file should
have at least one conditioned space volume, i.e. a
building space which is going to be studied ther-
mally.
–Material properties and space boundaries. Ev-
ery second level space boundary surface pair of
the boundary surface topology of a building, re-
lated to either a thermal or an opening element,
should be linked semantically to a building con-
struction, characterized by a set of thermal prop-
erties.
Provided that the above conditions are satisfied, the
simulation model generation process can be per-
formed, as described in the following section.
4 SIMULATION MODEL GENERATION
The purpose of the simulation model generation
process is the creation of an Energy Plus compat-
ible input data file <*.idfb>, referring to a build-
ing b, in a district setting, from its IFC file (IFCb)
and a CityGML file describing the geometry of the
district. Both IFCband CityGML data files are as-
sumed to conform to the data quality rules described
in previous sections.
Algorithmically, the simulation model genera-
tion process is divided into three stages: (a) Data
query stage, where data from IFCband CityGML
files are extracted, (b) Boundary Surface topology
generation stage, where the boundary surface topol-
ogy of building b, is generated and augmented with
shading surfaces from neighbor buildings and (c)
Input Data File generation stage, where the aug-
mented space boundary topology and the construc-
tion material property data, are used in order to pro-
duce a single input data file suitable for Energy Plus
simulations. These stages are illustrated in figure 3
and are explained in detail in the following sections.
Java Query
<*_gml_cbip.xml> <*_ifc_cbip.xml>
<*_d_bst.xml>
CityGML
<*.idfb>
(a) DATA QUERY
(b) BOUNDARY SURFACE TOPOLOGY
GENERATION
(c) INPUT DATA FILE
GENERATION
Java Query Java Query
CBIP tool
E+ converter
CBIP district tool
IFCb
<*_materials.xml>
<*_ifc_bst.xml>
Figure 3: Overview of the simulation model generation pro-
cess
4.1 Data query
The required data for the simulation model gen-
eration, of a single building in a district, are ob-
tained from two different meta-models, which both
are defined in a textual format, are usually object-
oriented and tend to be large. The most popular
BIM meta-model is the IFC, which is based on
the EXPRESS data schema, which is available as
a STEP file. Additionally, the most common GIS
meta-model is the CityGML, which is based on a
XML data model language and its schema is de-
fined by a set of XSD files. Because the proposed
query components have been written in Java, which
is an object-oriented language, it is useful to have
on-memory the populated Java objects. In order
to achieve this functionality, third-party frameworks
have been chosen: for the conversion of the IFC
schema the Eclipse Modeling Framework (EMF)
was used and for the CityGML schema, the Java
Architecture for XML Binding (JAXB) was cho-
sen. Specifically, in the case of IFC schema the
BuildingSMART library, which is a part of the BIM
Server project, has been used for the automated gen-
eration of certain Java classes. On the other hand,
in the case of CityGML schema the Reference Im-
plementation (RI) of JAXB, which is a part of the
GlassFish project, has been used. As mentioned be-
fore, these classes are used to store on-memory BIM
and GIS models and pass them to the proposed com-
ponents for further manipulation. Both IFC query
and CityGML data queries are described next.
As far as the CityGML query process is con-
cerned, only geometric surface descriptions con-
tained in the CityGML file, which refer to the dis-
trict building envelopes, are queried while any ap-
pearance related data structures are omitted. Addi-
tionally, elements not related to building envelope
surfaces (transportation objects, vegetation objects
and others), were not taken into account. The coor-
dinates of the points of the building envelope sur-
faces, were gathered and used to populate appro-
priate data structures in the <* gml cbip.xml>data
file (figure 3). Apart from the geometric content of
the envelope surfaces, the semantics of these sur-
faces classifying them as either: wall, ground or
roof surface, were gathered as well in order to be
used for future reference.
Regarding IFC data, two data types are queried:
geometric data and material property data. The ge-
ometric data refer to characteristics of geometric
solid representations of architectural elements con-
tained in the IFC file, such as the extruded area
solid, the manifold and the faceted boundary repre-
sentation. Each architectural element and the char-
acteristics of its solid geometric representation, are
written in the output <* ifc cbip.xml>file, which
is used as an input file to the boundary surface
topology generation process described in section
4.2. Regarding the material property data, cer-
tain thermal property values contained in the IFC
file are queried, referring to building constructions
and their respective layer bedding, as mentioned
in section 2.1. These properties are written in file
<* materials.xml>, which according to the process
diagram of figure 3, is used as input, to the input
data file generation process described in section 4.3.
4.2 Boundary surface topology generation
Sometimes, although IFC files contain the neces-
sary structures to support the geometric data re-
quirements of a simulation model generation pro-
cess, the geometric data of IFC files referring to the
boundary surface topology of buildings, are incor-
rect, or they are missing. In such cases the gen-
eration of the boundary surface topology of build-
ing is required, and is performed using the Common
Boundary Intersection Projection Algorithm (CBIP)
(Lilis et al., 2014). In a nutshell, CBIP receives as
input the geometric solid descriptions of architec-
tural building elements and performs the necessary
geometric operations, illustrated in figure 2, in or-
der to generate the boundary surface topology of
a building described in section 2.1. Additionally,
apart from the boundary surface topology geomet-
ric data requirements referring to a single building,
shading surfaces of neighbor buildings must also be
determined. CBIP process is extended in order to
include such surfaces, as described next.
Algorithmically, the boundary surface topology
generation process in a district environment (illus-
trated by the process block (b) in figure 3), includes
two stages. In the first stage CBIP is used in or-
der to transform the queried IFC architectural ge-
ometric data of the building, contained in xml file
<* ifc cbip.xml>, into an intermediate xml data
file containing the boundary surface topology data
of the building <* ifc bst.xml>. In the second
stage, the CBIP district tool augments the gener-
ated <* ifc bst.xml>file from the first step, by in-
cluding the neighbor shading building surfaces ob-
tained from the queried CityGML data, contained in
<* gml cbip.xml>, and generates a new xml data
file containing the boundary surface topology of the
building in the district environment <* d bst.xml>.
4.3 Input data file generation
In EnergyPlus, input data are defined by two ASCII
(text) files: the Input Data Dictionary (IDD) and the
Input Data File (IDF). The IDD file contains all pos-
sible EnergyPlus classes and descriptions of their
properties. Each version of EnergyPlus has a dif-
ferent IDD file. The IDF file consists of all the nec-
essary data to properly define a thermal simulation
model of a certain building, described using appro-
priate IDD classes.
The input data file generation process aims at
creating an IDF file from boundary surface topol-
ogy data of a building in a district setting, contained
in <* d bst.xml>file and material thermal prop-
erty data, contained in <* materials.xml>file, as
illustrated in the process block (c) in figure 3. This
process is developed using the MATLAB program-
ing environment and includes two stages. In the
first stage, a MATLAB script has been developed
that identifies the version of the IDF file (<*.idf>
file), parses the appropriate IDD file (<*.idd>file)
and creates a library (MatlabIDDxx, where xx is
the EnergyPlus version) of MATLAB classes, cor-
responding to EnergyPlus classes. In the second
stage, the generated MATLAB classes are populated
based on the geometric and material data contained
in <* d bst.xml>and <* materials.xml>files, and
exported into a final input data file (<*.idf>file).
This input data file generation process, referring
to a single building, conforms to certain transforma-
tion rules described thoroughly in (Giannakis et al.,
2015). In summary, certain IDD classes are popu-
lated from data obtained from: (a) CBIPs xml ge-
ometric output and contained in <* ifc bst.xml>
file (figure 3) and (b) material properties queried
from the IFC file contained in <* materials.xml>
file (figure 3). From CBIPs geometric output the
classes Zone, BuildingSurface:Detailed and Fen-
estrationSurface:Detailed are populated, while the
classes Construction, Material and WindowMate-
rial:SimpleGlazing System are populated from the
material property file.
Geometric data referring to neighbor buildings,
which are queried from the CityGML file and added
to the <* ifc bst.xml>file, via the CBIPs district
tool, generating the final boundary surface topology
file <* d bst.xml>of the building in a district en-
vironment (illustrated in figure 3). These geomet-
ric data, are used to populate the IDD class Shad-
ing:Building:Detailed in the final IDF file.
5 EXAMPLE
The proposed simulation model generation process
is demonstrated on a residential district, which is a
part of Santiago de Compostela city in Spain, dis-
played in Figure 4A. The chosen LoD2 CityGML
model of the district consists of 65 building en-
velopes out of which one was selected (indicated in
Figure 4B), in order to be replaced by a more de-
tailed IFC building model geometric representation.
A single IDF file was obtained following the
stages of the described simulation model generation
process. The geometric content of the generated
IDF file is displayed in figure 4C, where different
colors are used, in order to highlight the characteris-
tics of the different surfaces contained in the IDF file
(blue color is used to display external space bound-
aries; green color is used for internal space bound-
aries; purple color for neighbor building shading
surfaces; and yellow color for site boundaries). Al-
though all neighbor building shading surfaces were
considered here as a proof of concept, algorithms
selecting the ones which have considerable impact
to the building simulation, using proximity criteria,
will be developed in the future.
6 FUTURE WORK
6.1 Energy Data Model
Although the simulation generation process men-
tioned earlier is automated for geometry and ma-
terial thermal property input data, building system
characteristics have not yet included in this process
as input data. The versatility of such input data
highlights the need for integrating all these diverse
data sources under a common data model.
A. Aerial photo of Santiago de Compostela district
BuildingSurface:Detailed
Type: Roof / B.C.: Outdoors
BuildingSurface:Detailed
Type: Floor / B.C.: Adiabatic.
BuildingSurface:Detailed
Type: Floor / B.C.: Ground.
BuildingSurface:Detailed
Type: Wall / B.C.: Surface
Shading:Building:Detailed
Selected
building
envelope
B. CityGML model of Santiago de Compostela district
C. Geometric content of the generated IDF file.
FenestrationSurface:Detailed
Figure 4: (A) Aerial photo of Santiago de Compostela district
(B) CityGML model geometric representation, (C) Geometric
content of the generated IDF file (B.C.: Boundary Condition).
A suitable data model towards this direction,
which provides the necessary input data structures
for the Energy Plus simulation program, is the Sim-
Model (O’Donnell, 2013). SimModel is an XML-
based data scheme, which is designed to support
building-scale simulation models and does not con-
tain district-related data structures.
Consequently, in order to integrate the input data
of a district environment, an extension to the cur-
rent SimModel schema is viewed as a potential fu-
ture work path. This extension will be used to pop-
ulate a new Energy Data Model, as illustrated in
figure 5 with a dashed rectangle. Furthermore, ac-
cording to figure 5, the Energy Data Model (EDM),
is visualized as a subset of a District Data Model
(DDM), which will be a central functional compo-
nent of OptEEmAL platform (Izkara et al., 2016),
designed to provide the necessary data to support,
one (for the whole district), or multiple (for every
building) simulations. Additionally, in order to pro-
vide interoperability links to other simulation pro-
grams, an ontology based structure of the DDM is
visualized, as described in the following section.
6.2 Ontology-based district data model design
Data integration based on ontologies can be useful
to effectively combine data from multiple heteroge-
neous data sources (Wache et al., 2001). This way,
by means of ontologies it is possible to integrate
data from different sources when there is an ontol-
ogy that represent them. When these data sources
are based on open standards, such as CityGML and
IFC, is easier to carry out this integration since
there are ontologies already implemented that can
be reused. In this context, ontologies are useful to
facilitate data linking between different data mod-
els.
The use of ontologies to integrate information
to an energy domain is not new. For example,
this approach was applied in SEMANCO project at
the urban level, multi-scale analysis of carbon re-
duction problems and integration of GIS (Sicilia,
et. al., 2014). In the case of OptEEmAL plat-
form, input data from IFC, CityGML files and con-
textual data can be transformed into RDF accord-
ing to existing domain ontologies such as ifcOWL.
Thereby, the District Data Model can be redefined
as an ontology-based framework where the role of
ontologies is to facilitate the integration of these
three input data sources (Costa et al., 2016). In this
framework, the EDM is based on a version of the
SimModel in OWL (SimModelOWL). The EDM is
populated through an ETL process taking data from
the different ontologies of the DDM, as illustrated
in Figure 5.
To carry out this ETL process, the DDM ontolo-
gies has to be aligned to SimModelOWL using on-
tology matching methods. For example, ifcOWL is
aligned with SimModelOWL. Then, the RDF data
derived from the input sources can be transformed
according to the EDM structure. Since the data in
the DDM is already in RDF, it becomes a problem
of RDF reshaping.
This ontological approach also facilitates that in-
tegration of new simulation tools. The generation of
energy simulation models for such tools is a matter
of aligning the EDM which contains all the parame-
ters needed to carry out a detailed energy simulation
with the input model of such tool. This approach
would also be extrapolated to other data model for
other kinds of simulations such as cost analysis.
District Data Model
(designed using ontologies)
Energy Data
Model
CityGML
xml file
Query
IDF file
IFC step file
IFC step file
with BST
IFC
OWL
Contextual
data
CityGML
OWL
Cont. Data
OWL
CBIP
SimModel
Extended
OWL
Figure 5: Illustration of the inclusion of an ontology-based
District Data Model into the current simulation generation pro-
cess (BST: Boundary Surface Topology).
6.3 CBIP as an IFC data completeness tool
The ontological structure of the energy data model,
described earlier, will enable CBIP to be used as an
IFC data completeness tool and not as a part of the
simulation model generation process. Such use is
supported by the fact that CBIPs output, the bound-
ary surface topology (second-level space bound-
aries, virtual space partitions, shading surfaces), can
be adequately described by the IfcRelSpaceBound-
ary2ndLevel and IfcShadingDevice, data structures.
Therefore CBIPs operation can be a part of the
IFC data completeness process, before DDM in-
sertion. During this process, IFC data can be en-
riched by the boundary surface topology, obtained
by CBIP. After the IFC data being enriched, they
can be transformed to RDF using the ifcOWL on-
tologies and become a part of the DDM. A visu-
alization of CBIPs independent operation as a data
completeness tool, is illustrated in figure 5.
7 CONCLUSIONS
A semi-automated simulation model generation
process capable of forming input data files suitable
for Energy Plus calculations in a district environ-
ment, combining data from IFC and CityGML files,
was presented. This process is a part of the Euro-
pean research project OptEEmAL, which aims at
selecting the best according to certain performance
measures, district retrofitting solution. Consistency,
correctness and completeness data quality rules, for
both IFC and CityGML input data files, were also
discussed. Provided that these data quality condi-
tions are met, the three stages of the proposed simu-
lation model generation process, were described in
detail. The overall process was demonstrated suc-
cessfully, on a selected building defined by an IFC
file, in a demo district described by a CityGML file.
Future improvements of the process related to:
the integration of its input data using ontologies into
an energy data model, and the use of the process’
boundary surface topology generation tool, as an
IFC data completeness tool, were also discussed.
Conclusively, there are certain key concepts and
challenges which have to be addressed, arising from
the proposed process, which include: the need
for establishing data quality validation processes,
which will ensure consistency, correctness and com-
pleteness of the available input data; the use of
mechanisms for automating the query of input data
from other sources (apart from BIM and GIS), such
as weather data should also be included; and finally
the possibility of creating links of CBIPs geomet-
ric output to other simulation tools, should also be
examined.
8 ACKNOWLEDGEMENTS
Part of the work presented in this paper is based on
research conducted within the project “Optimised
Energy Efficient Design Platform for Refurbish-
ment at District Level”, which has received funding
from the European Union Horizon 2020 Framework
Programme (H2020/2014-2020) under grant agree-
ment no680676.
REFERENCES
Bazjanac, V., 2010. Space boundary requirements for
modeling of building geometry for energy and other
performance simulation. In proc. of CIB W78, Cairo,
Egypt.
Costa, G., Sicilia, ´
A., Lilis, G. N., Rovas, D. V., & Izkara,
J. L., 2016. A comprehensive ontologies-based frame-
work to support retrofitting design of energy-efficient
districts. In proc. of European Conference on Product
& Process Modelling, Limassol, Cyprus.
de Laat, R. & Van Berlo, L., 2011. Integration of BIM
and GIS: The development of the CityGML GeoBIM
extension. In Advances in 3D geo-information sci-
ences, pp. 211–225. Springer.
D¨
ollner, J. & Hagedorn, B., 2007. Integrating urban
GIS, CAD, and BIM data by servicebased virtual 3d
city models. R. e. al.(Ed.), Urban and Regional Data
Management-Annual, pp. 157–160.
El-Mekawy, M. & ¨
Ostman, A., 2012. Ontology engi-
neering method for integrating building models: The
case of IFC and CityGML. Universal Ontology of
Geographic Space: Semantic Enrichment for Spatial
Data. IGI Global, pp. 151–185.
Giannakis, G. I., Lilis, G. N., Kontes, G., Valmaceda,
C., Garcia-Fuentes, M. ´
A., & Rovas, D. V., 2015. A
methodology to automatically generate geometry in-
puts for energy performance simulation from IFC BIM
models. In proc. of Building Simulation IBPSA con-
ference, pp. 504–511, Hyderabad, India.
ISO 16739, 2013. Industry Foundation Classes (IFC) for
data sharing in the construction and facility manage-
ment industries. <https://www.iso.org/>.
Izkara, J., Prieto, I., Sicilia, ´
A., Costa, G., Madrazo, L.,
Bayili, S., & Katsigarakis, K., 2016. Requirements
and Specification of the District Data Model.
Kolbe, T. H., Gr ¨
oger, G., & Pl¨
umer, L., 2005. CityGML:
Interoperable access to 3d city models. In Geo-
information for disaster management, pp. 883–899.
Springer.
Lilis, G. N., Giannakis, G. I., Kontes, G., & Rovas, D. V.,
2014. Semi-automatic thermal simulation model gen-
eration from IFC data. In proc. of European Confer-
ence on Product & Process Modelling, pp. 503–510,
Vienna, Austria.
Lilis, G. N., Giannakis, G. I., & Rovas, D. V., 2015. De-
tection and semi-automatic correction of geometric in-
accuracies in IFC files. In proc. of Building Simulation
IBPSA conference, pp. 504–511, Hyderabad, India.
O’Donnell, J., 2013. SimModel: A domain data model
for whole building energy simulation. In proc. of Sim-
Build, pp. 382–389, Sydney, Australia.
Sicilia, ´
A., Madrazo, L., & Pleguezuelos, J., 2014. In-
tegrating multiple data sources, domains and tools in
urban energy models using semantic technologies. In
proc. of European Conference on Product & Process
Modelling, pp. 837–844, Vienna, Austria.
Thomas, D., Miller, C., K¨
ampf, J., & Schlueter, A., 2014.
Multiscale co-simulation of EnergyPlus and CitySim
models derived from a building information model. In
proc. of BauSIM IBPSA conference, pp. 469–476.
Vimmr, T., Loga, T., Diefenbach, N., Stein, B., & Ba-
chov´
a, L., 2013. Tabula - Residential Building Ty-
pologies in 12 European Countries - Good practice ex-
ample from the Czech Republic. In proc. of CESB13,
Prague, Czech Republic.
Wache, H., Voegele, T., Visser, U., Stuckenschmidt,
H., Schuster, G., Neumann, H., & H¨
ubner, S., 2001.
Ontology-based integration of information - A survey
of existing approaches. In proc. of IJCAI-01 work-
shop: Ontologies and Information Sharing, pp. 108–
117, Seattle, USA.
