Geographic Information System (GIS) can provide important contextual information relevant to buildings design, such as related to ooding, 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 di erent geometric representations and coordinate systems hindering seamless integration of these representations. This paper presents a method for converting Industry Foundation Classes (IFC) geometries expressed in ifcOWL with additional GeoSPARQL, based upon the IFC de ned 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, allowing for the seamless movement between the geometries in either domain. This also makes possible the tagging of all BIM geometries with geolocation. To support the publication of this data, the paper also presents an export of the resulting GeoSPARQL aligned with the developing standard 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 conversion is also presented as well as a test case to examine alignment of BIM with geospatial geometric representations.
E ective management of smart buildings and cities requires building data that
is structured, accessible and reliable [
The combination of BIM and Linked Data (LD) [
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 di erent domains using GeoSPARQL, section 4 provides discussion and future work and nally section 5 a conclusion. 2 2.1
GIS systems are information systems with an added geo-reference [
Recent research in GIS primarily focuses on the development of 3D GIS [
The concept of Building Information Modelling (BIM) has been created to
support the vast amount of data associated with buildings. This data is generated
across the buildings life cycle (BLC) and requires maintenance and
management 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 [
There is potential to further improve existing use cases by integrating
Building 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
particular relating to the buildings wider geospatial context. However, the di erent
geometry representations and coordinate systems used by BIM and GIS make it
challenging to interlink the two data types [
Standardisation is an important part of ensuring data interoperability. Industry
Foundation Classes (IFC), developed by buildingSMART, is the current
leading standard for BIM in the Architecture Engineering and Construction (AEC)
industry. In IFC, buildings and their components are modelled as objects.
Relationships and hierarchies between objects are de ned, giving a semantically rich
de nition of a building. IFC uses the EXPRESS data modelling language to
dene 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
processes (architecture, structural analysis, control, etc.), enabling information to
be passed between di erent stakeholders across the BLC. IFC has serializations
in STEP, XML and RDF alongside an OWL version of IFC4, called ifcOWL
[
Linked Data (LD) is an approach to expose, share, and connect related data,
which was not previously linked, on the Web [
With the development of ifcOWL the potential for linking ifcOWL, and other
BIM ontologies, with other domains is an active area of research [
The Building Topology Ontology (BOT) [
The ifcOWL and BOT ontologies are used in a Linked Data approach to
support this process of linking domains. The challenge still remains that di ering
domains have di erent representations of geometry, such that it becomes di cult
to reuse a geometry from one domain in another. This paper presents a process
for the extraction of building geometries (building geolocation, building
footprint, wall geometries, etc.) from ifcOWL into GeoSPARQL, and representing
geometries as Well-Known-Text (WKT) as outlined here [
The algorithm presented here is developed to convert geometries described in
ifcOWL into GeoSPARQL. ifcOWL models are generated using the process
developed by [
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 ifcOWL 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 rst 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 building is facing. The true north orientation angle is later used to rotate the building walls to the correct building orientation. The nal step in creating the building footprint is to extract and represent the walls of the building. Each wall in an ifcOWL building is de ned 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.
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 le as an RDF triple. This processed ifcOWL le is now ready for GeoSPARQL querying. 3.2
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 de nes 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
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
building is extracted to determine the world position of the building and assists in the
positioning of a buildings entities, as presented here [
the decimal degrees latitude and longitude in the form POINT(longitude latitude). 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 le. 3.4
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 IfcWallStandardCase (Fig. 1), although it should be noted that this process should theoretically work for all building entities with a geometric representation. The building footprint 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 thickness, or have a non-rectangular cross section. A hierarchy of entity placements de ne 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 Building 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 following process describes the extraction of walls represented as an IfcWallStandardCase. An IfcWallStandardCase is de ned by three high level attributes: a position (local placement), an orientation/direction (de ned by the direction cosine of the Z and X axes) and a length (de ned by a polyline magnitude). The IfcLocalPlacement of a wall speci es the position of a wall relative to the IFC Building Storey it is located on. The position is de ned 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 speci es the wall direction. The direction is de ned 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 speci ed by an IfcProductDe nitionShape. This shape de nes 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 direction rotation, wall global placement and a true north rotation. The two polyline coordinates of each wall are rst rotated to the IfcLocalPlacement direction (see Fig. 2). These, now rotated coordinates, are translated to the local position 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 nal 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 le. Wall coordinates, in the global coordinate space, are next converted to a latitude and longitude decimal degrees value. The conversion process uses the extracted decimal degrees geolocation as a point of reference. The decimal degrees geolocation is transformed to an xy-coordinate using the WGS 84 Web Mercator (EPSG:3857) projection, giving the geolocation as a coordinate in metres. The xy-coordinates of each wall, given in metres, are added to the metres geolocation coordinate. The resulting xy-coordinates for each wall are converted back to decimal degrees using the WGS 84 (EPSG:4326) projection, giving the walls global latitude and longitude in decimal degrees. A WKT LINESTRING() is created for each wall. The latitude and longitude of all walls are accumulated throughout the program and are concatenated at the end to create a WKT MULTILINESTRING().
The algorithm is implemented in Java using the Jena libraries [
The outputs of the converted le AC20-FZK-Haus, taken from an openly
available repository of IFC les [
The same process then again produces the following BOT le, called bot/AC20FZK-Haus bot geo.ttl. The bot:building has two bot:Storey, each of which has a geometry with a WKT MULTILINESTRING. Similarly, each wall is saved as a bot:element, associated with each bot:space, associated with each bot:storey. The bot:element has a geometry with a WKT LINESTRING.
This process was repeated for seven les, also taken from [
The WKT geometries were then evaluated visually by comparing them to their IFC models as seen in a BIM viewer such as BIM Vision3. This is clearly not the most desirable evaluation method, since no accuracy metric is produced, although visually comparing the two building representations gives an instantaneous and clear indication of how well a WKT geometry represents its BIM IFC model. Using this approach it was found that WKT geometries give an accurate representation of the wall structure of their parent IFC models. Walls are positioned in their correct locations and have dimensions that match the
parent IFC model. Intricate modes, such as the Barcelona Pavilion.ttl and Duplex A 20110907 optimized.ttl have a corresponding intricate 2D WKT geometry. However, the drawn WKT geometries contain both internal and external walls from all building storeys. A 2D GIS geometry represents a building as a 2D building footprint outline, disregarding internal walls and typically representing the buildings highest level or roof of the building.
The resulting extracted 2D WKT geometries in this solution should therefore represent the external walls of the IFC building model only, providing similar geometries to those in Google Maps. They would then match the 2D GIS standard of building geometry representation. A wall in ifcOWL can be de ned as being internal or external using the internalOrExternalBoundary IfcRelSpac eBoundary predicate. However, the ifcOWL test data used varied, meaning that some buildings used this predicate in the de nition of a wall whereas others did not. Furthermore, buildings had incorrect wall de nitions of this predicate. The ifcOWL building smallhouse saref.tll had all walls de ned as being external, even though some of the walls are clearly internal walls. The usability of the results provided by this solution therefore depend on the quality of the input ifcOWL les. An agreement could be made with the owner of a BIM model that requires them to adequately de ne the nature of building components, whether they are internal or external, before using the WKT building representation solution provided by this project. This would allow for the discovery and representation of external walls. 3.6
An evaluation of the performance of this solution assists in determining the usability of the solution. The performance can be evaluated by examining the program runtime. A short program runtime is more desirable, allowing users to extract a 2D GIS geometry from their 3D BIM model in a timely manner. The program runtime was recorded for each of the seven ifcOWL les given in Table. 1. A comparison of runtimes can be performed based on the time taken to calculate the Local Placement (LP) of an IfcWallStandardCase, in milliseconds, and the time taken to calculate the Relative Placement (RP) of an IfcWallStandardCase, in milliseconds. The LP and RP runtimes are listed in Table. 1. The triple count of each ifcOWL le is also given, indicating the complexity of the ifcOWL building representation. It can be seen that as the complexity of the le in terms of triple count increases, so too does the time take to determine placement.
Table. 1 shows that as the triple count of an ifcOWL le increases the time taken to extract the local and relative placement of a wall also increases. This is partly due to the time it takes Apache Jena to search through an RDF model of an ifcOWL building. The bigger the RDF model, in terms of volume of RDF triples, the longer Jena takes to search and extract triples. The biggest le, Barcelona Pavilion.ttl, takes over 13 seconds to determine the local placement of a wall and over 32 seconds to determine the relative placement of the same wall. This building contains 35 IfcWallStandardCase walls, therefore totalling approximately 26 minutes to extract all 35 walls. This is not particularly desirable for the owner of a 3D BIM model looking represent their model as a 2D GIS geometry. This is something which must be addressed in futre work.
In order to validate the alignment process, initial work has examined the use of
the topological relations supported by GeoSPARQL. These allow for the
discovery of relationships between geometries, and therefore resources, in a RDF graph
such as: equality, disjointness, intersection, touches, within, contains and
overlaps [
Fig. 3 gives a screenshot of the query used to align an ifcOWL building with a test geometry, based on the two matching conditions. A test geometry was used as currently there is no publicly available IFC model with corresponding geospatial geometry (see future work). This query is performed on the AC20FZK-Haus.ttl ifcOWL le, after adding WKT geometries, and the BOT version of this le, after BOT processing with added WKT geometries. Also given in Fig. 3 is the resulting aligned geometries, as seen in the YASGUI Geo results page. Colouring of the polygons identify the ifcOWL building from the BOT building. The red geometry represents the ifcOWL building and the green geometry represents the BOT building. Note, the geometries shown are quite small (YASGUI Geo does not permit a high zoom level), making it di cult to di erentiate between the red ifcOWL geometry and the green BOT geometry. The green BOT geometry is a rotated version of the ifcOWL geometry and overlays the red ifcOWl geometry. A sliver of red can be seen on the right hand side of the overlapping geometries, representing the underlying ifcOWL building geometry. Managing this alignment process is an important step in providing a means for seamlessly moving from 2D GIS into the BIM, as it is unlikely that the two geometry types will have an exact match. 4
This paper has demonstrated a method for converting ifcOWL wall geometries into GeoSPARQL and converting the resulting output as ifcOWL with GeoSPARQL and also BOT. It also provided a performance analysis of the algorithm. As can be seen, the process can successfully extract geometries for IfcWallStandardCase, convert these to WKT and output as GeoSPARQL. While the performance of the algorithm is strongly in uenced by the complexity of the ifcOWL les, it is intended that this process only be run once, so that the extracted geometries can be exported into other less triple intense models, such as BOT. It may also be possible to improve the performance of this process when working directly with IFC step les, and future work will explore this option.
It should be noted that this paper does not speci cally look at whether the
resulting les match with existing geospatial data. Towards this end further
validation will be conducted by examining existing Irish IFC models of known
structures against geospatial data maintained by the Ordnance Survey Ireland
(OSi), to ensure that they are in fact aligning correctly and to correct any
A method for converting IFC geometric data into GeoSPARQL
13
misalignment's. As OSi maintain authoritative sets of geospatial data in Ireland
[
Future implementations will also support other geometric formats, such as obj, using this approach so that the ifcOWL can be converted into both 2D and 3D geometries and converted into BOT. The desire is to make the conversion method openly available, and therefore provide a method for owners of building data to publish subsets of their building geometry. 5
This paper has demonstrated a method for converting ifcOWL geometries into ifcOWL and BOT aligned with GeoSPARQL. The approach taken sets out to address issues relating to di ering geometric coordinate systems between GIS and BIM geometric representations, by supporting the conversion of BIM geometry into 2D GIS. This opens the door to supporting a range of use cases related to geolocation of building entities, and makes available to BIM the functionality of GeoSPARQL. By aligning BIM models with authoritative building data sets such as those provided by the Ordnance Survey Ireland, BIM owners have the potential to connect their BIM data to a source of ground truth, rmly rooted in the physical geometric coordinates of the building structure. We believe this is an important step towards making seamless movement between these two domains a reality, encouraging re-use of available data.
Some challenges still remain to ensure that models are correctly aligned, and authoritative GIS data sets such as those provided by the Ordnance Survey Ireland are a perfect candidate for doing further analysis. Methods to ensure that alignments are correct are therefore still needed, and this paper presents some initial exploration of these for achieving this.
Listing 1.1. Pre xes and namespace URIs used in this paper @ p r e f i x i f c :< http : / /www. b u i l d i n g s m a r t t e c h . org /ifcOWL/IFC4 ADD1/>. @ p r e f i x bot :< h t t p s : / / w3c lbd cg . g i t h u b . i o / bot />. @ p r e f i x geo :< http : / /www. o p e n g e o s p a t i a l . org / s t a n d a r d s / g e o s p a r q l >. @ p r e f i x s f :< http : / /www. o p e n g i s . net / ont / s f >.