A method for converting IFC geometric data into GeoSPARQL

Loading...

Taking too long?

Reload document

| Open in new tab

A method for converting IFC geometric data
into GeoSPARQL

Joseph O’Donovan1, Declan O’Sullivan1, and Kris McGlinn1

ADAPT, Trinity College Dublin, Dublin 2, Ireland
odonovj2@tcd.ie
www.adaptcentre.ie

Abstract. Geographic Information System (GIS) can provide impor-
tant contextual information relevant to buildings design, such as related
to flooding, orientation, and even construction materials. Currently there
is a disconnect between 2D GIS and 3D Building Information Modelling
(BIM), as both tend to work from different geometric representations
and coordinate systems hindering seamless integration of these repre-
sentations. This paper presents a method for converting Industry Foun-
dation Classes (IFC) geometries expressed in ifcOWL with additional
GeoSPARQL, based upon the IFC defined geolocation, focusing on walls.
The goal is to align these geometries with their GIS equivalents, so that
an existing IFC model can be overlaid with GIS, or vice versa, allow-
ing for the seamless movement between the geometries in either domain.
This also makes possible the tagging of all BIM geometries with geoloca-
tion. To support the publication of this data, the paper also presents an
export of the resulting GeoSPARQL aligned with the developing stan-
dard the Building Topology Ontology (BOT), thus enabling the linking
of multiple geometric representations to a less verbose building reference
model. A short evaluation of the performance of the algorithm for con-
version is also presented as well as a test case to examine alignment of
BIM with geospatial geometric representations.

Keywords: Linked Data · Industry Foundation Classes · GeoSPARQL.

1

Introduction

Effective management of smart buildings and cities requires building data that
is structured, accessible and reliable [2]. Building Information Modelling (BIM)
is the primary method of providing such building data, representing the physical
and functional characteristics of a building in a 3D model. It is difficult, however,
to describe BIM models in their overall geospatial context. This could result in
important external environmental information being overlooked. Graphical In-
formation Systems (GIS) [10] provide models of the environment and enable 2D
spatial analyses of these areas. The integration of BIM and GIS can provide
benefits in reducing redundant modelling and enabling data flows in both direc-
tions, supporting new applications related to the design and operation of smart
environments [7].

Proceedings of the 7th Linked Data in Architecture and Construction Workshop – LDAC20197 The combination of BIM and Linked Data (LD) [5] has the potential to meet
the requirements for storing, sharing and interlinking BIM with other Linked
Data resources on the web described using the Resource Description Framework
(RDF), such as geospatial data [12]. It remains the case that use of different
geometric representations and coordinate systems in 2D GIS and 3D BIM leads
to difficulties in moving between these representations. The disconnect between
the two representations make it a challenge to relate a 2D GIS building with its
corresponding 3D BIM model. There is as yet no standard process in place to
convert a Cartesian coordinate IFC entity to GIS. New methods of carrying out
this conversion process are required until an agreement is established between
the differing domains on the definition of coordinate systems [13].

This paper presents a process for converting IFC geometries to GeoSPARQL
and Well-known text (WKT) so that the two geometries can exist within a
single coordinate system. Building walls are extracted from the IFC model and
positioned relative to the building geolocation given by the IFC model. This
creates a 2D footprint of the building and provides a bases for the alignment
of 2D GIS geometries with their 3D BIM equivalent. The paper is structured
as follows, section 2 provides state of the art, section 3 provides the design and
implementation of the conversion process, along with a performance evaluation
and examination of a method to align geometries from different domains using
GeoSPARQL, section 4 provides discussion and future work and finally section
5 a conclusion.

2 State of the Art

2.1 Graphical Information Systems

GIS systems are information systems with an added geo-reference [10]. The
geospatial information associated with GIS systems allow for spatial analysis
to be performed on the system. GIS data has a vast array of use cases including
the monitoring of weather systems across a region, predicting population densi-
ties in a city and visualising real time traffic jams in a certain location. Analysis
of GIS data gives important location based insights which may have previously
been overlooked. Geospatial information in a GIS system typically include the
coordinates of features of an object, based on the real world location (geoloca-
tion) of the object. The relationship between features of the object can also be
defined. Such features may include the walls of a building, and how certain walls
relate to one another by being associated with a room within the building. GIS
features are commonly represented in a 2D coordinate system. A building would
be represented by its top-down building footprint. A GIS system representation
of a building will also include the building within the context of other geospatial
features, such as infrastructure and natural features. This makes the information
relevant to both building designers and public planning organisations, planning
for navigation, fire services, energy grids, etc.

Recent research in GIS primarily focuses on the development of 3D GIS [10].
Such systems facilitate the modelling of complex internal structures of buildings,

Proceedings of the 7th Linked Data in Architecture and Construction Workshop – LDAC20198 tunnels and bridges in the geospatial domain. City Geography Markup Language
(CityGML) is currently the state of the art standard in 3D GIS modelling,
providing an XML based data model for the storage and exchange of 3D models
[9]. This 3D GIS modelling approach is closer to Building Information Modelling
(BIM) than 2D GIS, however work still remains in providing seamless interaction
between the two representations.

2.2 Building Information Modelling

The concept of Building Information Modelling (BIM) has been created to sup-
port the vast amount of data associated with buildings. This data is generated
across the buildings life cycle (BLC) and requires maintenance and manage-
ment throughout the BLC. BIM describes an integrated data model for storing
all information relevant to the BLC, typically relating to the functional and
physical characteristics of a building [6]. This primarily includes a 3D model
of the architectural design, detailing the positions and dimensions of a build-
ings walls, rooms, windows, doors, roof, etc. BIM also facilitates the inclusion
of non-physical building features such as the building costs, accessibility, safety,
security and sustainability [17]. BIM is therefore capable of capturing all as-
pects of a building that exist throughout the BLC, aiding stakeholders at all
stages of the BLC. As the authors state in [10], it is clear that BIM is not just
a piece of software, but also a process that contributes to the workflow and
project delivery process. However, a BIM model lives in isolation, it is oblivi-
ous to the external world that surrounds the building. This is a limitation of
BIM. The lack of geospatial analysis functionality available from a BIM model
restricts the knowledge one may have of a buildings surrounding environment.
The impact a building may have on its environment could be overlooked if the
appropriate geospatial analysis is not performed.

2.3

Interlinking BIM & GIS

There is potential to further improve existing use cases by integrating Build-
ing Information Modelling (BIM) with Geographic Information Systems (GIS).
This integration would enrich BIM datasets, allowing stakeholders to observe
new building features that may not have been visible using BIM alone, in par-
ticular relating to the buildings wider geospatial context. However, the different
geometry representations and coordinate systems used by BIM and GIS make it
challenging to interlink the two data types [12][13]. There is no standard process
currently in place to transform BIM to GIS [10].

2.4

Industry Foundation Classes and Linked Data

Standardisation is an important part of ensuring data interoperability. Industry
Foundation Classes (IFC), developed by buildingSMART, is the current lead-
ing standard for BIM in the Architecture Engineering and Construction (AEC)

Proceedings of the 7th Linked Data in Architecture and Construction Workshop – LDAC20199 industry. In IFC, buildings and their components are modelled as objects. Rela-
tionships and hierarchies between objects are defined, giving a semantically rich
definition of a building. IFC uses the EXPRESS data modelling language to de-
fine a building and its component hierarchy. IFC is also the only BIM currently
an ISO PAS standard (ISO 2013), and so it remains the de-facto standard for
BIM in AEC. The AEC industry relies on IFC for modelling core building pro-
cesses (architecture, structural analysis, control, etc.), enabling information to
be passed between different stakeholders across the BLC. IFC has serializations
in STEP, XML and RDF alongside an OWL version of IFC4, called ifcOWL
[15], which is built upon Linked Data principles.

Linked Data (LD) is an approach to expose, share, and connect related data,
which was not previously linked, on the Web [5]. LD makes us of the Resource
Description Format (RDF) to store and link data, allowing linking between do-
mains across the web. This interlinking of domains has significant potential in
the AEC industry, where data related to different domains are generated and
consumed across the BLC. Each stage of the BLC from design to construction
and maintenance require data sourced from a vast set of domains; building ge-
ometry and topology data, sensor data, behaviour data, geospatial data, etc.
The combination of BIM and LD has the potential to meet the requirements for
storing and sharing those data using RDF.

With the development of ifcOWL the potential for linking ifcOWL, and other
BIM ontologies, with other domains is an active area of research [19]. IFC, how-
ever, has yet to make its expected impact across the AEC industry [8]. One
contributing factor is the complexity of the schema. This complexity arises from
the extensive component hierarchy native to IFC. This component hierarchy
can be challenging for new software developers who are unfamiliar with the IFC
schema. A generic two storey building modelled in IFC can result in an IFC file
thousands of lines long. Simple geometry extractions require prior knowledge of
the IFC schema, which proves as a barrier to its use.

2.5 Building Topology Ontology

The Building Topology Ontology (BOT) [16], currently under development within
the auspices of the Linked Building Data on the Web community group [18], may
be able to address this issue, providing a bridge between software developers and
IFC, and a means to publish data about their buildings easily. BOT provides
descriptions for only the most fundamental properties of a building, in terms of
its topology, in a Linked Data approach. The primary components of a build-
ing topology (walls, storeys, rooms, etc.) are modelled in BOT, avoiding the
complexities observed in IFC. The intention here is to support linking to other
ontologies when details are required for aspects of the building, such as those
related to geolocation, building products, automation and control, HVAC etc.

The ifcOWL and BOT ontologies are used in a Linked Data approach to sup-
port this process of linking domains. The challenge still remains that differing
domains have different representations of geometry, such that it becomes difficult
to reuse a geometry from one domain in another. This paper presents a process

Proceedings of the 7th Linked Data in Architecture and Construction Workshop – LDAC201910 for the extraction of building geometries (building geolocation, building foot-
print, wall geometries, etc.) from ifcOWL into GeoSPARQL, and representing
geometries as Well-Known-Text (WKT) as outlined here [14]. This conversion
process makes all building elements essentially geo-tagged, and provides a mech-
anism to move from 3D geometries to 2D, and back.

3 Design and Implementation of Algorithm for

Conversion of IFC Geometries into GeoSPARQL

The algorithm presented here is developed to convert geometries described in
ifcOWL into GeoSPARQL. ifcOWL models are generated using the process de-
veloped by [15]. The 2D geometry extracted from the 3D IFC model is the
top-down view of the model, where the external walls of the building represent
the building footprint. The motivation behind extracting the 2D building foot-
print geometry is to define the BIM building in a 2D GIS context. This enables
geospatial analysis to be performed on the BIM building, integrating the two
domains. Furthermore, in a Linked Data context, the extracted geometry could
be used to align the building to its corresponding building defined in a differ-
ent Linked Data dataset. The alignment of two building geometries therefore
becomes a method of interlinking Linked Data domains.

3.1 Algorithm Design

The algorithm to extract and represent a 2D building footprint geometry from
an ifcOWL building can be broken down into three steps:

1. Building geolocation extraction
2. True North extraction
3. Building geometry extraction and representation as WKT

The geolocation of a building is useful in determining the exact location of
a building. It allows positioning of a building in the world coordinate system
through use of a latitude and longitude coordinate. The geolocation of an if-
cOWL building is extracted to determine the real world position of the building.
The extracted geolocation also acts as a reference point in the positioning of a
building’s walls. Extraction of the geolocation is the first step in connecting a
BIM building to its corresponding GIS building. The second step is to extract the
buildings true north orientation. This is the real world direction that the build-
ing is facing. The true north orientation angle is later used to rotate the building
walls to the correct building orientation. The final step in creating the building
footprint is to extract and represent the walls of the building. Each wall in an
ifcOWL building is defined by a position, direction and length, all represented
as Cartesian coordinates in metres. These three wall properties, along with the
building geolocation and true north orientation, facilitate the placement of a
wall in its correct real world position. The walls are positioned relative to the
building geolocation and then rotated to the true north orientation angle.

Proceedings of the 7th Linked Data in Architecture and Construction Workshop – LDAC201911 Each external building wall is transformed to its real world position and
represented as a Well-known text (WKT)1 geometry string. WKT is a string
based geometry representation language used to represent 2D vector geometries
on a map. This is ideal for representing the building geometry in a 2D GIS
context. Additionally, GeoSPARQL supports geometry representation as WKT.
This enables the use of GeoSPARQL topology relationship functions in SPARQL
queries to interact with WKT geometries. The WKT geometry representing the
2D building footprint of an ifcOWL building is inserted back into the ifcOWL
file as an RDF triple. This processed ifcOWL file is now ready for GeoSPARQL
querying.

3.2 Extracting True North

A building represented in the IFC format is typically modelled to represent a
real world building, or at least to at some point be used as such. We are not
concerned here with buildings that are intended purely to be used as design
models, without a physical copy. This process is intended for buildings that
have a real world orientation, or direction. An IFC representation of a building
incorporates a buildings orientation with the true north direction of the building.
This is the direction of the true north relative to the underlying coordinate
system, given by a direction within the xy-plane of the coordinate system. If
not given, the true north defaults to the positive direction of the y-axis. The
trueNorth IfcGeometricRepresentationContext defines the true north direction
of an ifcOWL building as an xy-coordinate, where both x and y are greater than
or equal to 0 and less than or equal to 1. The angle between this coordinate and
the positive direction of the y-axis (0, 1) is calculated. The arc tangent of the
positive distance between the true north x-coordinate and 0, and the negative
distance between the true north y-coordinate and 1 gives the angle (in degrees)
between the two coordinates. This angle is later used in the program to rotate
wall coordinates to the true north orientation.

3.3 Extracting Geolocation

The geolocation of a building is useful in determining the exact location of a
building. It allows positioning of a building in a world coordinate system through
use of a latitude and longitude coordinate. The geolocation of an ifcOWL build-
ing is extracted to determine the world position of the building and assists in the
positioning of a buildings entities, as presented here [11]. Entities have a local
placement relative to the geolocation of the building (see Fig. 1). The refLati-
tude IfcSite and refLongitude IfcSite of an ifcOWL building represent the
latitude and longitude of the geolocation. Recursive traversal of both attributes
extract their respective values, given in the format of degrees, minutes, seconds
and millionth of a second. Conversion to decimal degrees is necessary for align-
ment with Well-known text (WKT) geometries. A WKT point is created with

1 http://www.opengeospatial.org/standards/sfa

Proceedings of the 7th Linked Data in Architecture and Construction Workshop – LDAC201912 the decimal degrees latitude and longitude in the form POINT(longitude lati-
tude). A GeoSPARQL hasGeometry property is created for the IfcSite. This
property relates to a GeoSPARQL asWKT property, containing the WKT point
string that represents the building geolocation. These additions to the building
model are subsequently present in the output file.

3.4 Building Geometry Extraction: IfcWallStandardCase

Fig. 1. Overview of IFC and its relationships for describing an entities geometry.

A process for extracting the geometry of an IFC building walls is necessary to
create a building footprint. As such, the focus here is on the IfcWallStandard-
Case (Fig. 1), although it should be noted that this process should theoretically
work for all building entities with a geometric representation. The building foot-
print facilitates alignment of the 3D IFC geometry with a 2D GIS geometry.
IFC geometry models can contain two wall types: IfcWallStandardCase and
IfcWall. The former is used for occurrences of walls that have a non-changing
thickness. The latter is used for occurrences of walls that have a changing thick-
ness, or have a non-rectangular cross section. A hierarchy of entity placements
define where a wall is positioned in the buildings global coordinate system. The
IFC Site of a building sits at the top of the hierarchy.

The IFC Building is then positioned relative to the IFC Site. Each IFC Build-
ing Storey is positioned relative to the IFC Building. All walls on a storey are
placed relative to the IFC Building Storey, completing the hierarchy. The fol-
lowing process describes the extraction of walls represented as an IfcWallStan-
dardCase. An IfcWallStandardCase is defined by three high level attributes:
a position (local placement), an orientation/direction (defined by the direction

Proceedings of the 7th Linked Data in Architecture and Construction Workshop – LDAC201913 cosine of the Z and X axes) and a length (defined by a polyline magnitude).
The IfcLocalPlacement of a wall specifies the position of a wall relative to the
IFC Building Storey it is located on. The position is defined as a xyz-coordinate,
denoting how far the wall is positioned from the origin. This origin is the origin
of the building storey that contains the wall. All test data used in this paper had
the origin of the IFC Building Storey set as the default origin (0, 0, 0), which,
in turn, was the same origin as the IFC Building and IFC Site origins.

The IfcLocalPlacement of a wall also specifies the wall direction. The direc-
tion is defined by a xyz-coordinate. The default value for the direction coordinate
is (0, 0, 0), indicating a negative rotation of 90 degrees around the z-axis. A value
of -1 or 1 for the x-coordinate indicates a negative rotation around the z-axis of
270 or 90 degrees respectively. A value of -1 or 1 for the y-coordinate indicates a
negative rotation around the z-axis of 0 or 180 degrees respectively. The length
of an IfcWallStandardCase is specified by an IfcProductDefinitionShape.
This shape defines the IfcPolyline points that represent the length of the wall.
A polyline is constructed by two xy-coordinate points, the xy-origin (0, 0) and a
length along the positive y-axis (0, Ylength), where Ylength is the length of the
wall. The two polyline coordinates are extracted for each wall of the building.

Positioning of the wall in the global place requires three steps: wall direc-
tion rotation, wall global placement and a true north rotation. The two polyline
coordinates of each wall are first rotated to the IfcLocalPlacement direction
(see Fig. 2). These, now rotated coordinates, are translated to the local posi-
tion of the wall given by the IfcLocalPlacement position. As stated above,
the hierarchy of xyz local placements for each of the IFC Site, IFC Building
and IFC Building Storey are positioned at the global origin. This infers that
the positioning of a wall, based on its local placement, translates the wall to its
correct global position. The final step in global wall placement is the rotation
of a wall to its true north orientation. The true north angle of rotation is used
to rotate wall coordinates to their correct global orientation. This three step
procedure of global wall positioning is executed for each wall extracted from the
ifcOWL file. Wall coordinates, in the global coordinate space, are next converted

Fig. 2. Example rotation and then translation of a wall with initial polyline coordinates
of (0, 0) and (0, 10). The orange line in the image on the left is the resulting rotated line.
The orange line in the image on the right is the resulting translated line, translating
the previously rotated line via the wall position coordinates. Shown in both images is
the x and y axes. The z-axis is represented such that it is coming out of the page

Proceedings of the 7th Linked Data in Architecture and Construction Workshop – LDAC201914