Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 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]. 7 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 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, 8 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 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) 9 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 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 10 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 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. 11 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 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 12 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 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 13 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 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 14 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 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 me- tres. 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 [3] and build- ing on open libraries for converting IFC to ifcOWL [15]. The Java implemen- tation generate a GeoSPARQL WKT LINESTRING for each wall based upon the above process. These are also combined at a storey level into a 2D footprint of the building as a WKT MULTILINESTRING. The resulting GeoSPARQL geometries can be exported as an extended ifcOWL model or alternatively to a BOT model for the building. 3.5 Export of ifcOWL geometries as ifcOWL GeoSPARQL The outputs of the converted file AC20-FZK-Haus, taken from an openly avail- able repository of IFC files [1], can be found in the folder ifcOWL here2 called AC20-FZK-Haus geoloc.ttl. As can be seen, ifcBuilding 434 has an associated GeoSPARQL geometry representing its footprint and so too each IfcWallStan- dardCase 18465 has a single line geometry. The same process then again produces the following BOT file, called bot/AC20- FZK-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 files, also taken from [1] (see Table. 1 for their names). Once the ifcOWL (or BOT) file is generated and exported, it is possible to test the output visually. 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 instan- taneous 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 2 http://theme-e.adaptcentre.ie/bim/ 3 https://bimvision.eu/en/free-ifc-model-viewer/ 15 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 parent IFC model. Intricate modes, such as the Barcelona Pavilion.ttl and Du- plex A 20110907 optimized.ttl have a corresponding intricate 2D WKT geom- etry. 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 stan- dard of building geometry representation. A wall in ifcOWL can be defined 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 definition of a wall whereas others did not. Furthermore, buildings had incorrect wall definitions of this predicate. The ifcOWL building smallhouse saref.tll had all walls defined 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 files. An agreement could be made with the owner of a BIM model that requires them to adequately define the nature of building components, whether they are internal or external, before using the WKT building representation solution pro- vided by this project. This would allow for the discovery and representation of external walls. 3.6 Runtime Performance of the Algorithm 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 files 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 file is also given, indicating the complexity of the ifcOWL building representation. It can be seen that as the complexity of the file 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 file 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 file, 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 16 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 approximately 26 minutes to extract all 35 walls. This is not particularly desir- able 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. Table 1. Overview of seven ifcOWL files and time to process local and relative place- ment of IfcWallStandard File Name Triples Triple Diff. LP (ms) RP (ms) smallhouse.ttl 10175 0 44 100 smallhouse saref.ttl 100246 +90071 776 1849 Duplex A 20110907 optimized.ttl 205141 +104895 1945 4576 Simple3-storeytestbuilding.ttl 222545 +17404 2400 5642 20170804 Musterhaus MIT.ttl 239899 +17354 2619 5850 AC20-FZK Haus.ttl 275685 +35786 2991 9900 Barcelona Pavillion.ttl 1033905 +758220 13600 32400 3.7 Test Case: Alignment of IFC Geometries with Geospatial Geometries In order to validate the alignment process, initial work has examined the use of the topological relations supported by GeoSPARQL. These allow for the discov- ery of relationships between geometries, and therefore resources, in a RDF graph such as: equality, disjointness, intersection, touches, within, contains and over- laps [4]. The use of the GeoSPARQL function geof:sfOverlaps, a function that matches geometries that partially overlap, has the potential to support build- ing matching with the combination of additional properties, that is, where two buildings do not align correctly. Using the additional footprint area, a SPARQL Filter function, returns results based on the filter condition. Two filter condi- tions specify that the two returned building WKT geometries overlap (using geof:sfOverlaps) and that the calculated area of one WKT polygon is within +/- 25% the area of the overlapping polygon. Both aligned polygons, representing the same physical building, are returned if these two filter conditions are met. 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 AC20- FZK-Haus.ttl ifcOWL file, after adding WKT geometries, and the BOT version of this file, 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 ge- ometry represents the BOT building. Note, the geometries shown are quite small (YASGUI Geo does not permit a high zoom level), making it difficult to differ- entiate between the red ifcOWL geometry and the green BOT geometry. The 17 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 Fig. 3. SPARQL to align overlapping building geometries. Screenshot is taken from YASGUI, the Geo results page draws the ifcOWL (red) and BOT (green) geometries. 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 Discussion and Future Work This paper has demonstrated a method for converting ifcOWL wall geome- tries into GeoSPARQL and converting the resulting output as ifcOWL with GeoSPARQL and also BOT. It also provided a performance analysis of the al- gorithm. 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 influenced by the complexity of the ifcOWL files, 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 files, and future work will explore this option. It should be noted that this paper does not specifically look at whether the resulting files 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 18 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 A method for converting IFC geometric data into GeoSPARQL 13 misalignment’s. As OSi maintain authoritative sets of geospatial data in Ireland [12], they can provide a ground truth for geolocation of BIM models. 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 Conclusion 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 differing geometric coordinate systems between GIS and BIM geometric representations, by supporting the conversion of BIM geom- etry 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, firmly 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. Prefixes and namespace URIs used in this paper @ p r e f i x i f c :< h t t p : / /www. b u i l d i n g s m a r t −t e c h . o r g /ifcOWL/IFC4 ADD1/ >. @ p r e f i x b o t :< h t t p s : / / w3c−lbd−cg . g i t h u b . i o / b o t / >. @ p r e f i x g e o :< h t t p : / /www. o p e n g e o s p a t i a l . o r g / 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 :< h t t p : / /www. o p e n g i s . n e t / o n t / s f >. References 1. IFC repository, http://smartlab1.elis.ugent.be:8889/IFC-repo/ 2. Big data in the construction industry: A review of present status, opportunities, and future trends. Advanced Engineering Informatics 30(3), 500 – 521 (2016). https://doi.org/https://doi.org/10.1016/j.aei.2016.07.001 3. Api, J.O.: Apache Jena pp. 1–23 (1993), https://jena.apache.org/ 4. Battle, R., Kolas, D.: Enabling the geospatial semantic web with parliament and geosparql. Semantic Web 3(4), 355–370 (Oct 2012), http://dl.acm.org/citation.cfm?id=2590208.2590211 5. Bizer, C., Heath, T., Berners-Lee, T.: Linked Data - The Story So Far. Interna- tional Journal on Semantic Web and Information Systems 5(3), 1–22 (jul 2009). https://doi.org/10.4018/jswis.2009081901 19 Proceedings of the 7th Linked Data in Architecture and Construction Workshop - LDAC2019 6. Borrmann, A., Knig, M., Koch, C., Beetz, J.: Building Information Modeling: Technology Foundations and Industry Practice. Springer International Publishing (2018), ISBN: 978-3-319-92861-6 7. De Laat, Ruben and van Berlo, Leon: Integration of BIM and GIS: The Develop- ment of the CityGML GeoBIM Extension, pp. 211–225. Springer Berlin Heidelberg, Berlin, Heidelberg (2011). https://doi.org/10.1007/978-3-642-12670-3 13 8. Ghaffarianhoseini, A., Tookey, J., Ghaffarianhoseini, A., Naismith, N., Azhar, S., Efimova, O., Raahemifar, K.: Building Information Modelling (BIM) uptake: Clear benefits, understanding its implementation, risks and chal- lenges. Renewable and Sustainable Energy Reviews 75, 1046–1053 (2017). https://doi.org/10.1016/j.rser.2016.11.083 9. Gröger, G., Plümer, L.: CityGML Interoperable semantic 3D city mod- els. ISPRS Journal of Photogrammetry and Remote Sensing pp. 12–33. https://doi.org/https://doi.org/10.1016/j.isprsjprs.2012.04.004 10. Liu, X., Wang, X., Wright, G., Cheng, J.C.P., Li, X., Liu, R.: A state-of-the-art review on the integration of building information modeling (bim) and geographic information system (gis). ISPRS Int. J. Geo-Information 6, 53 (2017) 11. McGlinn, K., Debruyne, C., McNerney, L., O’Sullivan, D.: Integrating Building Information Models with Authoritative Irish Geospatial Information. In: ISWC 2017, the 16th International Semantic Web Conference. pp. 66–74 (2017), ISBN: 978-3-319-68204-4 12. McGlinn, K., Debruyne, C., McNerney, L., O’Sullivan, D.: Integrating Ire- land’s Geospatial Information to Provide Authoritative Building Informa- tion Models. In: Proceedings of the 13th International Conference on Se- mantic Systems - Semantics2017. vol. 13, pp. 57–64. ACM Press (2017). https://doi.org/10.1145/3132218.3132223 13. McGlinn, K., Wagner, A., Pauwels, P., Bonsma, P., Kelly, P., O’Sullivan, D.: Interlinking geospatial and building geometry with existing and de- veloping standards on the web. Automation in Construction pp. 235–250. https://doi.org/https://doi.org/10.1016/j.autcon.2018.12.026 14. Pauwels, P., Krijnen, T., Terkaj, W., Beetz, J.: Enhancing the ifcOWL ontology with an alternative representation for geometric data. Automation in Construction pp. 77–94. https://doi.org/10.1016/j.autcon.2017.03.001 15. Pauwels, P., Terkaj, W.: EXPRESS to OWL for construction industry: Towards a recommendable and usable ifcOWL ontology. Automation in Construction pp. 100–133. https://doi.org/https://doi.org/10.1016/j.autcon.2015.12.003 16. Rasmussen, M.H., Pauwels, P., Hviid, C.A., Karlshj, J.: Proposing a Central AEC Ontology That Allows for Domain Specific Extensions. In: Lean and Com- puting in Construction Congress - Volume 1: Proceedings of the Joint Confer- ence on Computing in Construction. pp. 237–244. Heriot-Watt University (2017). https://doi.org/10.24928/JC3-2017/0153 17. Taylor, J., Bernstein, P.: Paradigm Trajectories of Building Information Modeling Practice in Project Networks. Journal of Management in Engineering - J MANAGE ENG 25 (2009). https://doi.org/10.1061/(ASCE)0742-597X(2009)25:2(69) 18. W3C: Linked Building Data Group (2019), https://www.w3.org/community/lbd/ 19. Zhang, C., Beetz, J.: Querying linked building data using SPARQL with functional extensions. In: Christodoulou, S.E., Scherer, R. (eds.) EWork and eBusiness in Architecture: ECPPM 2016 : Proceedings of the 11th European Conference on Product and Process Modelling (ECPPM 2016), Limassol, Cyprus, 7-9 September 2016. pp. 27–34. CRC Press (2016), ISBN: 978-1-315-38689-8 20