Towards Effective BIM/GIS Data Integration for Smart City by Integrating Computer Graphics Technique

remote sensing

Article Towards Effective BIM/GIS Data Integration for Smart City by Integrating Computer Graphics Technique

Junxiang Zhu and Peng Wu *

School of Design and the Built Environment, Curtin University, Bentley 6102, Western Australia, Australia; [email protected] * Correspondence: [email protected]; Tel.: +61-8-9266-4723

Abstract: The development of a smart city and digital twin requires the integration of Building Information Modeling (BIM) and Geographic Information Systems (GIS), where BIM models are to be integrated into GIS for visualization and/or analysis. However, the intrinsic differences between BIM and GIS have led to enormous problems in BIM-to-GIS data conversion, and the use of City Geography Markup Language (CityGML) has further escalated this issue. This study aims to facilitate the use of BIM models in GIS by proposing using the shapefile format, and a creative approach for converting Industry Foundation Classes (IFC) to shapefile was developed by integrating a computer graphics technique. Thirteen building models were used to validate the proposed method. The result shows that: (1) the IFC-to-shapefile conversion is easier and more flexible to realize than the IFC-to-CityGML conversion, and (2) the computer graphics technique can improve the efficiency and reliability of BIM-to-GIS data conversion. This study can facilitate the use of BIM information in GIS and benefit studies working on digital twins and smart cities where building models are to be processed and integrated in GIS, or any other studies that need to manipulate IFC geometry in depth. Keywords: Building Information Modeling (BIM); Geographic Information System (GIS); Industry Citation: Zhu, J.; Wu, P. Towards Foundation Classes (IFC); 3D model; smart city; digital twin Effective BIM/GIS Data Integration for Smart City by Integrating Computer Graphics Technique. Remote Sens. 2021, 13, 1889. 1. Introduction https://doi.org/10.3390/rs13101889 Smart city and digital twin require three-dimensional (3D) building models to con- Academic Editor: Joanne N. Hallse stitute a large-scale city model, based on which analysis and decision-making processes regarding city management can be carried out [1]. This virtual city model serves as the Received: 12 April 2021 frame of the digital representation of a physical city, to which other enabling technologies Accepted: 11 May 2021 of the smart city, such as radio frequency identification (RFID) and real-time locating Published: 12 May 2021 systems [2], can be attached. During the construction of such city models, a large number of building models are to be produced and linked via spatial locations [3]. Therefore, one Publisher’s Note: MDPI stays neutral technical requirement of the smart city and digital twin is the creation, management, and with regard to jurisdictional claims in analysis of 3D building models. Many studies have suggested that Building Information published maps and institutional affil- Modeling (BIM) can be a fundamental technique in smart cities due to its strength in iations. producing highly detailed building models, and Geographic Information Systems (GIS) can be prominent in managing and analyzing these models to a large extent via a global spatial reference system [4–6]. Therefore, the integration of BIM and GIS can be a fundamental technique for a smart city and digital twin, where building models produced by BIM are to Copyright: © 2021 by the authors. be integrated into a GIS environment for visualization and analysis. Licensee MDPI, Basel, Switzerland. The integration of BIM and GIS is mainly conducted at two levels, i.e., application This article is an open access article level and data level [7]. Data-level integration focuses on the data exchange between distributed under the terms and BIM and GIS, with the goal of achieving efficient information exchange between these two conditions of the Creative Commons systems, which can facilitate application-level integration of BIM and GIS. Application-level Attribution (CC BY) license (https:// integration, as the title suggests, explores the potential joint application of BIM and GIS to creativecommons.org/licenses/by/ solve practical problems. For example, BIM and GIS have been jointly used in a variety of 4.0/).

Remote Sens. 2021, 13, 1889. https://doi.org/10.3390/rs13101889 https://www.mdpi.com/journal/remotesensing Remote Sens. 2021, 13, 1889 2 of 26

applications related to the smart city, such as building-level flood damage assessment [8], low-energy building design [9], city fire emergence management [10], construction site layout optimization [11], and supply chain management [12]. BIM/GIS integration, as a technique enabling the smart city and digital twin, requires BIM data to be converted into a form/format that is accessible by GIS. There are mainly two common conversion paths available, involving Industry Foundation Classes (IFC), City Geography Markup Language (CityGML), and shapefile. IFC is widely used in the AEC domain for building information exchange and is the representative data standard for the BIM side. On the GIS side, CityGML and shapefile are commonly involved. CityGML is an international standard [13] and has attracted the attention of most researchers working on BIM/GIS integration, whereas shapefile is widely used in the geospatial industry. Shapefile is a native format of ArcGIS, the most frequently used GIS platform in BIM/GIS integration [14], but it is open to the community and supported by many open-source tools, such as QGIS. Accordingly, the two common conversion paths are the IFC-to-CityGML path and the IFC-to-shapefile path [7], both of which are important for BIM/GIS integration. By far, data exchange, or data interoperability, between BIM and GIS is still a challenge [15], especially for the IFC-to-CityGML conversion. From the literature, it can be concluded that this challenge is intrinsically caused by the vast discrepancies between BIM and GIS in data creation, storage, and management [7,16]. These discrepancies have resulted in various data conversion tasks, some of which can be quite challenging, such as the solid-to-surface transformation required by the IFC-to-CityGML conversion [17]. With the emerging studies on the smart city and digital twin, there is a growing need for 3D building models, as well as a reliable and efficient approach for reconstructing or converting these models for their use in GIS. According to Biljecki et al. [3], 3D models have been applied in a variety of applications, from simple visualization to complex spatial analysis, such as indoor localization [18], indoor navigation [19–21], and room-level traffic noise assessment [22]. BIM can be a promising source of 3D building models for GIS. However, the data conversion problem mentioned above has become the bottleneck of using BIM models in GIS. Studies on the smart city and digital twin can be facilitated if the data conversion problem can be well addressed. Computer graphics techniques are promising in addressing this problem. Computer graphics deals with the display of graphics on computer screen, only using explicit points, edges, and faces [23]. Given the fact that IFC models containing implicit geometries can be eventually displayed, it is reasonable to assume that these implicit geometries have been converted in some way into explicit geometries by computer graphics techniques. If these points, edges, and faces generated by computer graphics techniques can be retrieved and interpreted, it is possible to preserve them in a format and use them in GIS. The goal of this study is not to address the intrinsic differences between BIM and GIS in data format/standard but to facilitate the use of BIM models in a GIS environment and thus to benefit the development of the smart city and digital twin. This goal was achieved through two steps. In step one, a literature review was conducted to summarize the data conversion tasks involved in BIM-to-GIS data conversion, before the two common data conversion paths, i.e., IFC-to-CityGML and IFC-to-shapefile, were compared in terms of the number and difficulty of these conversion tasks. In step two, based on the previous comparison, a more efficient approach for data conversion was developed for the IFC-to- shapefile conversion by integrating a computer graphics technique.

2. Related Work 2.1. BIM-to-GIS Data Conversion BIM models consist of geometric information and semantic information. Geometry provides information on the shape, size, and location of objects, while semantics provides information on the properties of objects, such as class type, material, and functions. These two types of information are essential to the integrity of BIM models. Accordingly, data Remote Sens. 2021, 13, 1889 3 of 26

conversion from BIM to GIS usually involves two aspects, i.e., geometry conversion and semantics transfer [7,10,24]. Table1 lists all the general tasks involved in BIM-to-GIS data conversion as well as corresponding studies working on the resolution of these problems. In general, the following tasks can be involved in data conversion: representation conversion, coordinate transformation, geo-referencing, model simpliﬁcation, and semantics transfer [7,25,26].

Table 1. Tasks in data conversion from BIM to GIS.

Specific Tasks General Tasks IFC-to-CityGML IFC-to-Shapefile Converting solid models to surface Converting solid models to solid models (difficult): models: Representation - Converting B-Rep [25] - Converting B-Rep [28] conversion - Converting swept solid [25,27] - Converting swept solid [10,28,29] - Converting CSG/Clipping [19,25] - Converting CSG/Clipping [10,24,28] Coordinate Needed Needed Geometry transformation Needed, if to be integrated with other Needed, if to be integrated with other Geo-referencing spatial data spatial data [16,30,31] Needed, as Level of Detail (LoD) is defined - LoD1 [27,32–34] Model simplification Optional - LoD2 [27,32–34] - LoD3 [25,27,32,34] - LoD4 [27,32,34] Semantics extraction needed, as Class mapping needed, as CityGML Semantics Semantics transfer shapefile is not a semantic data is a semantic data schema [27,34–38] schema

Representation conversion refers to the conversion of implicit Constructive Solid Geometry (CSG) and swept solid representations into the explicit Boundary Representation (B-Rep). This is required due to the difference in modeling paradigm between BIM and GIS [29]. Coordinate transformation refers to the transformation of coordinates of building elements from its local coordinate system to the global coordinate system of the IFC project. This is required due to the use of relative placement in IFC. Geo-referencing is another type of coordinate transformation, which transforms coordinates from the global coordinate system of the IFC project into a coordinate reference system that is related to the physical earth [30]. Geo-referenced BIM models can be integrated with other spatial datasets in GIS. Model simplification refers to the simplification of building models, which is required due to the additional storage space and rendering power required by over-detailed building models. These tasks belong to the category of geometry conversion. Semantic information is another type of important information in BIM that should be properly transferred to GIS [7]. CityGML and shapefile tackle this task in different ways. CityGML is a semantic data model, which means that it defines classes for building components and the relationship between them; these classes have to be mapped with those from IFC in order to properly transfer semantic information. In contrast, shapefile is a more primitive data standard/format, in which class mapping is not required; instead, IFC semantics can be directly inherited and stored as attribute tables in shapefile.

2.2. IFC-to-CityGML Conversion The IFC-to-CityGML conversion has to deal with more conversion tasks, and some of them are quite challenging in both geometry conversion and semantics transfer. The geometry conversion for the IFC-to-CityGML path is more difﬁcult than the IFC-to-shapeﬁle path, as it involves the change of the modeling paradigm (from solid Remote Sens. 2021, 13, 1889 4 of 26

modeling to surface modeling) and the conversion of Level of Detail (LoD). Detailed differences between the surface model and the solid model have been described in [39]. Many studies have attempted to address the geometry conversion issue. For example, in the study by Deng et al. [27], methods were developed to generate surfaces from IFC parameters for models from LoD1 to LoD4. Kang et al. [32,33] used the screen-buffer scanning-based multiprocessing (SB-MP) technique to generate LoD1 to LoD4 CityGML models, and Donkers et al. [25] developed an automatic approach for generating LoD3 CityGML models from IFC models by using a series of geometric operations, such as dilation and erosion. In terms of semantics transfer, class mapping is a unique task that is mandatory for the IFC-to-CityGML conversion. A large amount of work has been carried out to address this problem by developing new data schemas or modifying current data schemas. For example, Deng et al. [27] used semantics from IFC and CityGML to establish the Semantic City Model. Karan et al. [35] used a semantic web technique to combine IFC and CityGML semantics. El-Mekawy et al. [36] developed a unified building model for converting IFC into CityGML. In addition, Application Domain Extensions (ADEs) can be developed for CityGML to receive additional semantic information from IFC [27,37,40,41]. The IFC-to-CityGML path has potential to be the standardized way for accommodating BIM information but is more difficult to realize. Despite the efforts mentioned above, it is still problematic in both geometry conversion and semantics transfer [42]. An easy-to-do and efficient approach for geometry conversion is still absent [16], not to mention that ADEs developed by various projects were project-specific and may not be recognized by some visualization tools [37]. This is probably the reason that CityGML was rarely used in studies on application-level BIM/GIS integration.

2.3. IFC-to-Shapefile Conversion In contrast, the IFC-to-shapefile path is more workable for BIM-to-GIS data conversion, for four reasons. (1) First, there are fewer and easier conversion tasks in IFC-to-shapefile conversion. For example, the challenging solid-to-surface conversion and class mapping, which are mandatory for the IFC-to-CityGML conversion, are not required by the IFC-to- shapefile conversion. In this sense, the data conversion from BIM to GIS can be completed in an easier manner. (2) Second, behind shapefile are mature GIS systems, such as the prevalent ArcGIS. These systems have strong data management and analysis capacity that get shapefile ready for practical use, while CityGML models have to first be converted before they can be used in ArcGIS. (3) Third, in terms of shapefile itself, shapefile supports both solid models and surface models [43], which makes shapefile capable of accommodating 3D IFC geometry, and the relational database technique behind shapefile enables it to store, extend, and query IFC semantic information. (4) Fourth, shapefile is an open format widely used for geospatial data exchange. It has been adopted by researchers, industry, and governments, such as the Landgate of Western Australia [44] and Data.gov.au, which provides open government data in Australia [45]. All of these advantages make the IFC-to- shapefile path more realistic for the use of building models in GIS. This conversion path is, therefore, suggested by this study. In contrast with the IFC-to-CityGML path, there are less studies on the IFC-to-shapefile conversion. Some commercial tools are available for this conversion, such as Feature Manipulation Engine (FME) and Data Interoperability extension for ArcGIS (DIA) [46]. DIA is toolset built on FME, which extends the ability of ArcGIS to read/write more than 100 formats in GIS and computer-aided design (CAD). They are then referred to as DIA/FME in this paper. These tools are able to convert IFC into shapefile. For example, FME has been used in several projects for model conversion, such as in studies by Amirebrahimi et al. [8,47,48] and Boyes et al. [49]. However, their commercial nature has limited their availability and it has also been noticed that they are not sufficiently reliable. DIA/FME can crash due to the incapability in processing some specific IFC representation types [49,50]. Moreover, the semantic information that DIA/FME can transfer is limited. These problems Remote Sens. 2021, 13, 1889 5 of 26

have not been solved by the latest version of DIA/FME, which will be demonstrated later in this paper. Several studies developed their own methods for converting IFC into shapefile, such as studies by Isikdag et al. [10,51] and Zhu et al. [24,28,29]. In the studies by Isikdag et al. [10,51], a package for creating shapefile was developed through an application programming interface (API) for shapefile. In the studies by Zhu et al. [24,28,29], an open- source approach (OSA) was developed to convert IFC geometry into shapefile. These studies realized the conversion of IFC to shapefile but failed to provide a reliable and efficient conversion approach. For example, the study by Isikdag [51] has the following problems: incorrect spatial orientation of transformed building models, long processing time, incomplete conversion of representations, and ineffectiveness in converting clipping geometry. The OSA developed by Zhu et al. [24,28,29] has solved some of these problems, such as incomplete conversion of representations and ineffectiveness in converting clipping geometry, but the overall efficiency of data conversion has not been well addressed due to the lack of an efficient and common way to convert implicit IFC geometries.

2.4. Computer Graphics Technique in BIM-to-GIS Data Integration Concepts of representation types such as B-Rep and CSG used by IFC are originally from areas such as CAD, computational geometry, and computer graphics. These areas deal with the creation and visualization of 3D models using computers. From the perspective of computer graphics, explicit geometries are required for visualization, which requires those implicit geometries in IFC, such as swept solid and CSG, to be converted into explicit points, edges, and faces. This process is referred to as tessellation [52], triangulation [53], or model evaluation [39]. Tools such as Open CASCADE technology (OCCT) have been developed for this purpose. OCCT, which is an open-source software development kit used in the field of CAD, computer-aided manufacturing (CAM), and computer-aided engineering (CAE) [54–56], has been applied for manipulating and visualizing 3D models in a range of applications, such as CAD-based robot path planning and simulation [57] and the preparation of as-damaged models for post-earthquake BIM reconstruction [58]. Via a literature review, it has been noticed that this technique has been integrated into BIM-to-GIS data conversion [16,25,59]. For instance, OCCT was involved in data conversion as a part of IfcOpenShell, which is a common tool for parsing IFC files [25,49] and has been used by many applications, such as BIMserver [60]. For example, in Ar- royo Ohori et al. [16], a data processing pipeline was developed for converting IFC into CityGML, where OCCT/IfcOpenShell was used to convert IFC geometry into a transitional format (Wavefront OBJ), which was later converted into CityGML. Zhao et al. [59] and Chen et al. [61] combined IFC and 3D tiles to create 3D visualization for building models via a web-based GIS system. In this system, OCCT/IfcOpenShell was used to convert IFC into Wavefront OBJ files as a part of data processing. Donkers et al. [25] Remote Sens. 2021, 13, x FOR PEER REVIEW 6 of 26 used OCCT/IfcOpenShell to automatically generate LoD3 CityGML models. The data conversion pipelines in these studies have been generally presented in Figure1.

FigureFigure 1. 1. OCCT/IfcOpenShellOCCT/IfcOpenShell inin BIM BIM-to-GIS-to-GIS data data conversion conversion by by previous previous studies. studies.

TheThe above above studies studies integrated integrated OCCT OCCT in intoto BIM BIM-to-GIS-to-GIS data data conversion, conversion, but but the the long long datadata processing processing pipelines pipelines reflected reflected their inefficiencyinefficiency inin processing processing IFC IFC data. data. These These methods meth- odsare are not not able able to directlyto directly convert conver IFCt IFC into into the the destination destination format; format instead,; instead, they they had had to first to first convert IFC into a well-known intermediate format before they could be further processed. For example, Arroyo Ohori et al. [16] and Zhao et al. [59] had to first convert IFC files into OBJ files, then to Nef polyhedra, and finally to CityGML. This inefficiency in IFC data processing results in potential geometric information loss and a heavier data processing workload [61]. To be specific, the OBJ format used by Ohori et al. [16], Chen et al. [61], and Zhao et al. [59] as a transitional format can lead to serious geometric information loss, as geometries in an IFC file will be merged into a single shape after conversion [50]. In order to overcome this issue, Chen et al. [61], Zhao et al. [59], and Arroyo Ohori et al. [16] had to first split the IFC file into many sub-IFC files to ensure that each geometry was stored in a separate IFC file; these geometries were later combined again in the final format. This workaround not only introduced additional data processing work, but also caused additional data management problems, e.g., thousands of temporary sub-IFC files, or even more, can be generated in this process. These problems made this workaround vulnerable to errors and unsuitable to be used in smart city development, where a large number of complex building models can be involved. This inefficiency is caused by the process-level use of OCCT, whose data exchange module can only export IFC into a finite number of formats, such as IGES, STL, OBJ, and VRML [62]. These formats are mainly used in the area of CAD and mainly focus on the geometric part of models, which made them not suitable for accommodating BIM information due to their insufficient support for semantics. The BIM-to-GIS data conversion can be more efficient and effective if computer graphics techniques, or OCCT, can be integrated into the conversion process at a lower level.

3. Materials and Methods The rest of this paper mainly focuses on developing such a method that uses computer graphics techniques at a low level for converting IFC into shapefile. OCCT is adopted, as Arroyo Ohori et al. [16] found that OCCT is reliable in handling IFC models due to a lower geometry requirement, but other tools of this kind, such as the Computa- tional Geometry Algorithms Library (CGAL), can also be used. The objective was then realized by two steps: (a) investigating OCCT (Section 3.1) and (b) integrating OCCT into the IFC-to-shapefile data conversion process (Section 3.2).

3.1. Investigating OCCT 3.1.1. Computer Graphics and OCCT According to Eck [63], computer graphics is a broad field; it uses computational techniques to manipulate visual and geometric information and is closely related to fields such as computational geometry, computer vision, and applied mathematics. Computer-based systems, such as Autodesk Revit for BIM or ArcGIS for GIS, rely on computer graphics techniques to display geometric information on a computer screen. This visualization process is generally realized by four steps, as shown in Figure 2. (1) Application programs (e.g., Revit (California, United States) and ArcGIS (California, United States)) interpret

Remote Sens. 2021, 13, 1889 6 of 26

convert IFC into a well-known intermediate format before they could be further processed. For example, Arroyo Ohori et al. [16] and Zhao et al. [59] had to first convert IFC files into OBJ files, then to Nef polyhedra, and finally to CityGML. This inefficiency in IFC data processing results in potential geometric information loss and a heavier data processing workload [61]. To be specific, the OBJ format used by Ohori et al. [16], Chen et al. [61], and Zhao et al. [59] as a transitional format can lead to serious geometric information loss, as geometries in an IFC file will be merged into a single shape after conversion [50]. In order to overcome this issue, Chen et al. [61], Zhao et al. [59], and Arroyo Ohori et al. [16] had to first split the IFC file into many sub-IFC files to ensure that each geometry was stored in a separate IFC file; these geometries were later combined again in the final format. This workaround not only introduced additional data processing work, but also caused additional data management problems, e.g., thousands of temporary sub-IFC files, or even more, can be generated in this process. These problems made this workaround vulnerable to errors and unsuitable to be used in smart city development, where a large number of complex building models can be involved. This inefficiency is caused by the process-level use of OCCT, whose data exchange module can only export IFC into a finite number of formats, such as IGES, STL, OBJ, and VRML [62]. These formats are mainly used in the area of CAD and mainly focus on the geometric part of models, which made them not suitable for accommodating BIM information due to their insufficient support for semantics. The BIM-to-GIS data conversion can be more efficient and effective if computer graphics techniques, or OCCT, can be integrated into the conversion process at a lower level.

3. Materials and Methods The rest of this paper mainly focuses on developing such a method that uses computer graphics techniques at a low level for converting IFC into shapeﬁle. OCCT is adopted, as Arroyo Ohori et al. [16] found that OCCT is reliable in handling IFC models due to a lower geometry requirement, but other tools of this kind, such as the Computational Geometry Algorithms Library (CGAL), can also be used. The objective was then realized by two steps: (a) investigating OCCT (Section 3.1) and (b) integrating OCCT into the IFC-to-shapeﬁle data conversion process (Section 3.2).

3.1. Investigating OCCT 3.1.1. Computer Graphics and OCCT According to Eck [63], computer graphics is a broad field; it uses computational techniques to manipulate visual and geometric information and is closely related to fields such as computational geometry, computer vision, and applied mathematics. Computer-based systems, such as Autodesk Revit for BIM or ArcGIS for GIS, rely on computer graphics techniques to display geometric information on a computer screen. This visualization process is generally realized by four steps, as shown in Figure2. (1) Application programs (e.g., Revit (California, United States) and ArcGIS (California, United States)) interpret and parse application data (e.g., IFC or shapefile); (2) the parsed data are converted into an intermediate format (or buffers) by application programs so that they can be processed by a Graphics Processing Unit (GPU) API (Application Programming Interface), such as OpenGL or WebGL [63]; (3) APIs pass buffers and corresponding commands to GPUs, and (4) GPUs process these data and transfer them to screens (display units) for the final visualization. Remote Sens. 2021, 13, x FOR PEER REVIEW 7 of 26

Remote Sens. 2021, 13, x FOR PEER REVIEW 7 of 26

and parse application data (e.g., IFC or shapefile); (2) the parsed data are converted into an intermediateand parse format application (or buffers) data by (e.g.application, IFC or programsshapefile); so (2) that the they parsed can databe processed are converted into by a Graphicsan intermediate Processing Unit format (GPU) (or buffers) API (Application by application Programming programs soInterface), that they such can beas processed OpenGL orby WebGL a Graphics [63] ;Processing (3) APIs pass Unit buffers (GPU) andAPI corresponding(Application Programming commands to Interface), GPUs, such as Remote Sens. 2021, 13, 1889and (4) GPUsOpenGL process or theseWebGL data [63] and; (3) transfer APIs passthem buffers to screens and (display corresponding units) for commands the final to GPUs,7 of 26 visualization.and (4) GPUs process these data and transfer them to screens (display units) for the final visualization.

Figure 2. Information visualization on computer screen via computer graphics technique.

Figure 2. InformationInformation visualization visualization on computer screen via computer graphics technique. OCCT comprises several functional modules, each of which is designed for a specific purpose, such OCCT as model comprise comprises creation,s several geometry functional manipulation, modules, each visualization, of which is and designed data ex- for a specific specific change. Forpurpose, example, such such the asdata as model model exchange creation, creation, module geometry geometry can read/write manipulation, manipulation, various visualization, CADvisualization, data andformat dataands exchange. data ex- and is whatchange.For involv example, Fored inexample, thethe datastudy the exchange by data Arroyo exchange module Ohori module canet al. read/write [16]can read/writefor producing various various CAD OBJ CADfiles. data data formatsA format ands detailed descriptionandis what is what involved of involvOCCT ined has thein been the study studygiven by byin Arroyo [62]Arroyo. OCCT Ohori Ohori can et et al.be al. [involve16 [16]] for ford producing inproducing the whole OBJ OBJ files. files. A process of detailedinformation description visualization, of OCCT but has in beenthis study, given itin mainly[62] [62].. OCCT functions can be at involve involvedstep 1 dand in the whole step 2 for processreading of and information processing visualization, IFC geometries but but into in in this thisbuffers study, study, that it mainlyare to be functions sent to theat step 1 andand GPU API. stepBuffers 2 for can reading be sent andto OpenGL processing in a IFC desktop geometries -based systeminto into buffers buffers or WebGL that that are arein ato web be -sent to the based systemGPU [63,64] API. .BuffersBuffers These bufferscan can be be sent sentcontain to to OpenGL OpenGL primitive in in geometrica a desktop desktop-based -informationbased system system that or or isWebGL WebGL to be in in a a web web-- displayed basedon a computer system [63,64] [ 63screen,64].. ;These Thesetherefore, buffers buffers extracting contain and primitive interpreting geometric these information buffers is vi- that is to be tal to this study.displayed on a computer screen;screen; therefore,therefore,extracting extracting and and interpreting interpreting these these buffers buffers is is vital vi- talto thisto this study. study. 3.1.2. Extracting and Converting IFC Geometry using OCCT Understanding3.1.2. Extracting Extracting IFC, including and and C Convertingonverting its class IFC hierarchy G Geometryeometry and using spatial OCCT structure, is important for informationUnderstanding extraction from IFC, IFC, including especially its itsfor class geometric hierarchy information. and spatial For structure,the purpose is important of data exchangeforfor information information in the extraction extraction AEC domain, from IFC, IFC especially is developed for geometric and maintained information. by build- For the purpose ingSMARTof (formerly data data exchange exchange known in as in the the the AEC International AEC domain, domain, IFC Alliance is IFC developed isfor developed Interoperability) and maintained and maintained as byan buildingSMARTopen, by build- software-neutralingS(formerlyMART standard known (formerly (ISO as the 16739known International-1:2018) as the International[65 Alliance–67]. In IFC, for Alliance Interoperability) a variety for Interoperability)of classes as anregard- open, as software-an open, ing buildingsoftwareneutral and related standard-neutral construction (ISOstandard 16739-1:2018) (ISOactivities 16739 [ 65have-1:2018)–67 been]. In [6 IFC,defined,5–67 a] variety. In among IFC, of a classeswhichvariety regardingonly of classes the building regard- and related construction activities have been defined, among which only the I f cProduct 퐼푓푐푃푟표푑푢푐푡ing class building and its and subclasses related construction have geometric activities representation. have been This defined, study among mainly which fo- only the class and its subclasses have geometric representation. This study mainly focuses on build- cuses on building퐼푓푐푃푟표푑푢푐푡 element class and (퐼푓푐퐵푢푖푙푑푖푛푔퐸푙푒푚푒푛푡 its subclasses have), geometric which is arepresentation. subclass of 퐼푓푐푃푟표푑푢푐푡 This study. mainly fo- ing element (I fcBuildingElement), which is a subclass of I f cProduct. Building elements are Building cuses elements on building are logically element ( contained퐼푓푐퐵푢푖푙푑푖푛푔퐸푙푒푚푒푛푡 in a spatial), which structure is a subclass element of 퐼푓푐푃푟표푑푢푐푡 . logically contained in a spatial structure element (I fcSpatialElement), such as a building (퐼푓푐푆푝푎푡푖푎푙퐸푙푒푚푒푛푡Building ), elementssuch as a building are logically story. Figure contained 3 presents in the a spatialspatial structure structure ele- element story. Figure3 presents the spatial structure elements and how they are linked with each ments and( 퐼푓푐푆푝푎푡푖푎푙퐸푙푒푚푒푛푡how they are linked), withsuch eachas a buildingother. The story. highest Figure level 3 presentsof the spatial the spatial structure structure ele- other. The highest level of the spatial structure is assigned to I f cProject. is assignedments to 퐼푓푐푃푟표푗푒푐 and how푡. they are linked with each other. The highest level of the spatial structure is assigned to 퐼푓푐푃푟표푗푒푐푡.

FigureFigure 3. IFC 3. IFC spatial spatial structure structure elements, elements, i.e., i.e., site, site, building, building, building building story story,, and and space. space. Figure 3. IFC spatial structure elements, i.e., site, building, building story, and space. Building elements have various attributes, and the most important geometry-related attributes are representation (I fcProductDefinitionShape) and its placement (I f cObjectPlacemen). A representation determines the shape and size of an object, whereas the placement determines its location in the world coordinate system of the project. Figure4 illustrates the data structure of a typical building element.

Remote Sens. 2021, 13, x FOR PEER REVIEW 8 of 26

Building elements have various attributes, and the most important geometry-related attributes are representation ( 퐼푓푐푃푟표푑푢푐푡퐷푒푓푖푛푖푡푖표푛푆ℎ푎푝푒 ) and its placement Remote Sens. 2021, 13, 1889( 퐼푓푐푂푏푗푒푐푡푃푙푎푐푒푚푒푛 ). A representation determines the shape and size of an object, 8 of 26 whereas the placement determines its location in the world coordinate system of the project. Figure 4 illustrates the data structure of a typical building element.

Figure 4. RepresentationFigure 4. Representation and placement and placement of a typical of building a typical element. building element.

Based on theBased above on two the structures, above two structures,building elements building as elements well as their as well representations as their representations can be retrievedcan be from retrieved IFC and from converted IFC and using converted OCCT. using The OCCT. result Theof the result conversion of the conversion is a is a group of shapegroup objects of shape (buffers) objects that (buffers) temporarily that temporarily reside in the reside computer in the memory. computer The memory.se These shape objectsshape contain objects very contain primitive very elements primitive of elements geometry, of geometry,referred to referredas triangulation to as triangulation elements inelements OCCT. They in OCCT. are originally They are originally supposed supposed to be sent to to be the sent GPU to the for GPU visualization for visualization [64]. [64]. These Theseshapeshape objects objects were wereclosely closely examined examined in this in study, this study, and anda method a method was wasdevel- developed to oped to rebuildrebuild B-Rep B-Rep from from these these primitive primitive elements. elements. The The rebuilt rebuilt B-Rep B-Rep is referred is referred to as to as OCCT OCCT B-RepB-Rep in this in thisstudy. study. 3.1.3. From Primitive Triangulation Elements to OCCT B-Rep 3.1.3. From Primitive Triangulation Elements to OCCT B-Rep The temporary shape objects contain a group of attributes, such as the unique identiﬁer, The temporary shape objects contain a group of attributes, such as the unique iden- name, and type that are inherited from IFC, and the most important one for rebuilding the tifier, name, and type that are inherited from IFC, and the most important one for rebuild- geometric shape is the ‘geometry’, which has several attributes containing information on ing the geometricvertices, shape edges, is andthe faces.‘geometry’, These which attributes has areseveral originally attributes intended containing for machine infor- processing, mation on vertices,not human edges, reading, and faces. but we These managed attributes to decipher are originally them, as intended shown infor Table machine2. processing, not human reading, but we managed to decipher them, as shown in Table 2. Table 2. Interpretation of raw triangulation elements. Table 2. Interpretation of raw triangulation elements. Interpreted Triangulation Raw TriangulationRaw Triangulation Elements Interpreted Elements Triangulation Elements Elements Shape.geometry.verts 퐿1: (푥1, 푦1, 푧1, … , 푥푛, 푦푛, 푧푛) 푃: ((푥1, 푦1, 푧1), … , (푥푛, 푦푛, 푧푛)) Shape.geometry.edgesShape.geometry.verts 퐿2: (1, 2L, 1, :3(, x…1), y1, z1,..., xn, yn, zn)퐸: ((1, 2P),:(((1,x31),,y…1,)z 1),..., (xn, yn, zn)) L ( ) E (( ) ( ) ) Shape.geometry.facesShape.geometry.edges 퐿3: (1, 2, 3, …2) : 1, 2, 1, 3, . . . 퐹: ((1, 2, 3),:… )1, 2 , 1, 3 ,... Shape.geometry.faces L3 : (1, 2, 3, . . .) F : ((1, 2, 3),...) These attributes in Table 2 are essential for rebuilding geometric shape. The geometry.verts recordsThese a list of attributes numbers in (L1 Table), which2 are are essential the coordinates for rebuilding of all geometricpoints in the shape. shape, The geome- and every threetry.verts numbers records should a list of be numbers grouped (L to1), generate which are a thelist coordinatesof points (P). of The all pointsgeome- in the shape, try.edges recordsand every another three list numbers of numbers should (L2 be), which grouped are to the generate index of a listpoints, of points and every (P). The geome- two numberstry.edges in the recordslist should another be grouped list of numbers to generate (L2), a which list of are edges the index(E), where of points, the first and every two number indicatesnumbers the in start the listof an should edge and be grouped the second to generate indicates a the list end. of edges The (geometry.E), wherefaces the ﬁrst number indicates the start of an edge and the second indicates the end. The geometry.faces records a third list of numbers (L3), which are the index of points, and every three numbers should be grouped to generate a list of faces (F). From these deciphered variables, the geometric shape can be rebuilt using the method presented in Figure5, where only verts and faces are used. Remote Sens. 2021, 13, x FOR PEER REVIEW 9 of 26

records a third list of numbers (L3), which are the index of points, and every three num-

Remote Sens. 2021, 13, 1889 bers should be grouped to generate a list of faces (F). From these deciphered variables,9 of the 26 geometric shape can be rebuilt using the method presented in Figure 5, where only verts and faces are used.

FigureFigure 5. 5.Converting Converting triangulation triangulation elements elements into into geometric geometric shape. shape.

3.2.3.2. IntegratingIntegratingOCCT OCCT into into IFC-to-Shapefile IFC-to-Shapefile Conversion Conversion InIn order order to to integrate integrate OCCT OCCT into into IFC-to-shapefile IFC-to-shapefile data data conversion,conversion, aa methodmethod forfor con-con- vertingverting OCCT OCCT B-Rep B-Rep into into shapefile shapefile B-Rep B-Rep is is required. required. In In spite spite of of the the fact fact that that both both OCCT OCCT andand shapefile shapefile use use B-Rep B-Rep to to represent represent 3D 3D objects, objects, it it is is noticed noticed during during the the investigation investigation that that theythey use use different different sub-types sub-types of of B-Rep. B-Rep.

3.2.1.3.2.1. SubtypesSubtypes ofof B-RepB-Rep InIn general, general, there there are are three three sub-types sub-types of of B-Rep B-Rep depending depending on on how how points points are are organized organized intointo faces, faces, including including (a) (a) explicit explicit polygons polygons (Type (Type 1), 1), (b) (b) polygons polygons defined defined by by pointers pointers into into aa pointpoint listlist (Type 2), 2), and and (c) (c) explici explicitt edges edges (Type (Type 3) 3)[23] [23. Table]. Table 3 shows3 shows the theform formatsats of these of these sub-types, in which F stands for faces, P stands for points, and E stands for edges. sub-types, in which 퐹 stands for faces, 푃 stands for points, and 퐸 stands for edges. (a) (a) Explicit polygons (faces) are explicitly represented by a list of coordinates. (b) In Type 2, Explicit polygons (faces) are explicitly represented by a list of coordinates. (b) In Type 2, a face is defined by a list of pointers (or indexes) into the point list. For example, a face a face is defined by a list of pointers (or indexes) into the point list. For example, a face made up of points 1, 3, 5, and 7 in the point list is represented as F : (1, 3, 5, 7). (c) In the made up of points 1, 3, 5, and 7 in the point list is represented as 퐹: (1, 3, 5, 7). (c) In the third sub-type, a face is represented by a list of pointers into the edge list. For each edge, third sub-type, a face is represented by a list of pointers into the edge list. For each edge, there are two pointers into the point list, as well as another one or two pointers for the there are two pointers into the point list, as well as another one or two pointers for the face(s) to which the edge belongs. face(s) to which the edge belongs. Table 3. Sub-types of B-Rep, including explicit polygons (Type 1), polygons defined by pointers into Table 3. Sub-types of B-Rep, including explicit polygons (Type 1), polygons defined by pointers a point list (Type 2), and explicit edges (Type 3). into a point list (Type 2), and explicit edges (Type 3).

B-Rep SubB-Rep-Type Sub-Type B-Rep Description B-Rep Description

Type 1 Type 1 퐹: ((푥1, 푦1F, 푧:1((),x(1푥,2y,1푦,2z,1푧)2, ()x, …2, y, 2(,푥z푛2,)푦,...,푛, 푧푛()x)n , yn, zn)) 푃: ((푥 , 푦 P, 푧: ((),x…,,y(푥, z, )푦,...,, 푧 ()x) , y , z )) Type 2 Type 2 1 1 1 1 1 푛1 푛 푛 n n n 퐹: (1 ,3 ,5F ,7: ()1 , 3 , 5 , 7) 푃: ((푥1, 푦1, 푧1), … , (푥푛, 푦푛, 푧푛)) P : ((x1, y1, z1),..., (xn, yn, zn)) Type 3 퐸: (푉 , 푉 , 푃 , 푃 ) Type 3 1 2 E 1: (V21, V2, P1, P2) 퐹: (퐸 , … , 퐸 ) 1 F :푛(E 1,..., En)

3.2.2.3.2.2. ConvertingConverting OCCTOCCT B-Rep B-Rep to to Shapefile Shapefile B-Rep B-Rep TheThe actual actual B-Rep B-Rep formats formats used used by by OCCT OCCT and and shapefile shapefile are are slightly slightly different different from from the the threethree generalgeneral sub-types sub-types described described above.above. TheThe OCCTOCCT B-RepB-Rep hashas beenbeen introducedintroduced inin the the previous section, while the shapefile B-Rep is close to Type 1, and the difference is that, in shapefile B-Rep, for each face, the first point and the last point must coincide in order to form a closed ring [43], as follows:

F : ((x1, y1, z1),..., (xn, yn, zn), (x1, y1, z1)). (1) Remote Sens. 2021, 13, x FOR PEER REVIEW 10 of 26

previous section, while the shapefile B-Rep is close to Type 1, and the difference is that, in Remote Sens. 2021, 13, 1889 shapefile B-Rep, for each face, the first point and the last point must coincide in order10 of to 26 form a closed ring [43], as follows: 퐹: ((푥 , 푦 , 푧 ), … , (푥 , 푦 , 푧 ), (푥 , 푦 , 푧 )) 퐹: ((푥1, 푦1, 푧1), … , (푥푛, 푦푛, 푧푛), (푥1, 푦1, 푧1)). (1) When generating generating shapefile shapefile B B-Rep,-Rep, there there are are two two concerns: concerns: (1) (1) points points of faces of faces and and (2) (2)orientation orientation of faces, of faces which, which is determined is determined by by the the order order of of points points in in the the face. face. By By checking shape objects generated by OCCT, it is confirmedconfirmed that thethe secondsecond concernconcern has notnot beenbeen addressed. OCCT OCCT generates generates B- B-RepRep where where points points are arecounter counter-clockwise-clockwise relative relative to an to out- an sideoutside observer observer (see (see Figure Figure 6a6),a), whereas whereas the the order order of of points points in in shapefile shapefile B-RepB-Rep shouldshould bebe clockwise [68,69] [68,69] (see (see Figure Figure 6b). Therefore Therefore,, when when converting converting OCCT OCCT B- B-RepRep to to shapefile shapefile B- B-Rep, the order of points has to be reversed. Rep, the order of points has to be reversed.

Figure 6. Reversing order of points for converting OCCT B-RepB-Rep to shapeﬁleshapefile B-Rep.B-Rep.

The root of this problem is found to be in the fact that the DirectX DirectX,, which is the def defaultault GPU API API used used in in ArcGIS ArcGIS by by ESRI ESRI (i.e., (i.e., the the developer developer of the of theshapefile shapeﬁle format), format), uses uses a left a- handedleft-handed coordinate coordinate system, system, while while the GPU the GPUAPI used API usedby OCCT, by OCCT, i.e., OpenGL i.e., OpenGL,, uses a uses right a- handedright-handed coordinate coordinate system. system. Despite Despite the difference the difference in point in point order, order, the normal the normal of face of face (or (orthe thepositive positive side side of face) of face) is pointing is pointing outward outward in in the the corresponding corresponding system system (see(see Figure Figure 77)),, which is important for calculating surfacesurface area,area, solidsolid volume,volume, andand modelmodel renderingrendering [[39]39]..

Figure 7. Normal of face (outward) in OCCT B-RepB-Rep and shapeﬁleshapefile B-Rep.B-Rep.

The algorithm for converting OCCT B B-Rep-Rep into shapefile shapefile B B-Rep-Rep is graphically pre- pre- sented in Figure 8 8.. InIn thisthis algorithm,algorithm, anan objectobject fromfrom IFCIFC isis firstfirst convertedconverted using using OCCT OCCT into into temporary shape objects. Then, from the shape objects, a point list (푃P) is derived from thethe coordinate listlist ((L퐿11),), and and a a face face list list (F ()퐹 is) is obtained obtained from from the the point point index index list forlist face for face (L3), ( and,퐿3), andfinally,, finally the shapefile, the shapefile B-Rep B is-Rep generated is generated from from the point the point list (P list) and (푃) the and face the list face (F list). (퐹).

Remote Sens. 2021, 13, 1889 11 of 26 Remote Sens. 2021, 13, x FOR PEER REVIEW 11 of 26

FigureFigure 8. 8.Converting Converting OCCT OCCT B-Rep B-Rep to to shapeﬁle shapefile B-Rep. B-Rep.

TheThe keykey PythonPython codescodes forfor geometry geometry conversion conversion andand coordinate coordinate transformation transformation areare presentedpresented inin Table Table4 .4 The. TheOCCT 푂퐶퐶푇__shape푠ℎ푎푝푒refers refers to to the the shape shape objects, objects, the theobjectPlacement 표푏푗푒푐푡푃푙푎푐푒푚푒푛푡is theis the placement placement of object,of object, and and the thekeepTransform 푘푒푒푝푇푟푎푛푠푓표푟푚is a customizedis a customized function function for coordinate for coordi- transformationnate transformation using using parameters parameters directly directly from from IFC. IFC The. T equationhe equation behind behind the the function function is givenis given by by Zhu Zhu et al.et [al.29 ][29] as follows:as follows: −ퟏ [푥′ 푦′ 푧′] = [푥 푦 푧] × ([푥⃗ 푦⃗ 푧⃗]퐓 !)T퐓 + [푥 푦 푧 ] (2) h→ → →iT−1 1 1 1 x0 y0 z0 = [x y z] × x y z + [x y z ] (2) where [푥′ 푦′ 푧′] is the transformed coordinates; [푥 푦 푧] 1is 1 the1 initial coordinates; [푥1 푦1 푧1] denotes the origin shift; 풙⃗⃗⃗, 풚⃗⃗⃗ and 풛⃗⃗ are three perpendicular unit vectors indi- 0 0 0 wherecating[ thex y directionz ] is the of transformed the x-axis, y coordinates;-axis, and z-axis[x y, zrespectively.] is the initial coordinates; [x1 y1 z1] → → → denotes the origin shift; x , y and z are three perpendicular unit vectors indicating the directionTable 4. Python of the codesx-axis, fory-axis, geometry and conversionz-axis, respectively. and coordinate transformation. def OCCTToShapefile(OCCT_shape, objectPlacement): Table parts 4. Python = [] codes for geometry conversion and coordinate transformation. def OCCTToShapeﬁle(OCCT_shape,raw_verts = OCCT_shape.geometry.verts objectPlacement): raw_facesparts = [[] = OCCT_shape.geometry.faces pointsraw_verts = [raw_verts[i:i+3] = OCCT_shape.geometry.verts for i in range(0, len(raw_verts),3)] facesraw_faces = [raw_faces[i:i+3] = OCCT_shape.geometry.faces for i in range(0,len(raw_faces),3)] points = [raw_verts[i:i+3] for i in range(0, len(raw_verts),3)] pointsfaces = = [raw_faces[i:i+3] keepTransform(points, for i in range(0,len(raw_faces),3)] objectPlacement) pointspoints == keepTransform(points,np.mat(points).tolist() objectPlacement) forpoints face = in np.mat(points).tolist() faces: for facering in = faces:[points[face[2]], points[face[1]], points[face[0]], points[face[2]]] ring = [points[face[2]], points[face[1]], points[face[0]], points[face[2]]] parts.append(ring)parts.append(ring) returnreturn partsparts

Using this algorithm, the example given in Figure 5 can be converted (see Figure 9). Using this algorithm, the example given in Figure5 can be converted (see Figure9). Rings are included in the ‘parts’ variable in Table 4. From this variable, together with the Rings are included in the ‘parts’ variable in Table4. From this variable, together with the type of part (ring, indicated by code 5) and the type of shapefile (multipatch, indicated by type of part (ring, indicated by code 5) and the type of shapefile (multipatch, indicated by code 31), shapefiles can be eventually generated. In shapefile, multipatch geometry is code 31), shapefiles can be eventually generated. In shapefile, multipatch geometry is stored stored using several attributes, including multipatch.points, multipatch.z, and mul- using several attributes, including multipatch.points, multipatch.z, and multipatch.parts. Among them, multipatch.points records the x and y coordinates, multipatch.z records the

Remote Sens. 2021, 13, x FOR PEER REVIEW 12 of 26 Remote Sens. 2021, 13, 1889 12 of 26

tipatch.parts. Among them, multipatch.points records the x and y coordinates, mul- z coordinates, while multipatch.parts records the index of points for the start and end of tipatch.z records the z coordinates, while multipatch.parts records the index of points for each ring. the start and end of each ring.

FiFiguregure 9. Converting OCCT B B-Rep-Rep into shapefile shapeﬁle B B-Rep.-Rep.

3.3. Semantic Information Transferring 3.3. SemanticSemantic Information information Transferring in this study refers to non-geometric information of BIM models, suchSemantic as the information type of an object, in this the study relationship refers to non-geometric between objects information, and other of types BIM of mod- at- tributesels, such defined as the by type relationship of an object, entities. the IFC relationship has defined between a large objects, number and of attributes other types for eachof attributes entity through defined byrelationship relationship entities, entities. such IFC as has퐼푓푐푅푒푙퐷푒푓푖푛푒푠퐵푦푃푟표푝푒푟푡푖푒푠 defined a large number of and at- 퐼푓푐푅푒푙퐴푠푠표푐푖푎푡푒푠푀푎tributes for each entity푡푒푟푖푎푙 through. It is possible relationship to extract entities, all attributes such as I from fcRelDefinesByProperties an IFC file; however, inand practice,I fcRelAssociatesMaterial only a small portion. It of is these possible attributes to extract are allneeded attributes by a specific from an project IFC file; [70] how-. ever,In in this practice, study, only the a following small portion essential of these attributes attributes of are building needed components, by a specific projectdefined [70 in]. the BuildingIn this study, Topology the following Ontology essential [71], were attributes extracted, of building including components, IFC class defined name, in story the level,Building building Topology, and Ontologysite. The Python [71], were codes extracted, for retrieving including these IFC attributes class name, have story been level, pre- sentedbuilding, in andAppendix site. The A. PythonThese attributes codes for retrievingare sufficient these to attributes answer questions have been such presented as what in andAppendix whereA an. These object attributes is. In addition, are sufficient the unique to answeridentifier questions of each building such as what component and where was retained,an object so is. that In addition, in cases thewhere unique semantics identifier needs of each to be building extended, component additional was attributes retained, can so bethat extracted in cases from where IFC semantics and linked needs with to the be extended,model. This additional is fully supported attributes by can the be relational extracted databasefrom IFC technique and linked behind with theshapefile model. and This facilitated is fully supportedby the fact bythat the the relational vast property database sets technique behind shapefile and facilitated by the fact that the vast property sets defined defined in IFC are in the form of tables. An example is provided in Figure 10. The benefit in IFC are in the form of tables. An example is provided in Figure 10. The benefit of of transferring semantics in this way is keeping the converted building models in a com- transferring semantics in this way is keeping the converted building models in a compact pact manner but retaining the possibility of semantics extension. This feature is an ad- manner but retaining the possibility of semantics extension. This feature is an advantage vantage of shapefile over those CAD-oriented 3D formats, such as OBJ. Please note that of shapefile over those CAD-oriented 3D formats, such as OBJ. Please note that rigid rigid semantics mapping, which is mandatory for IFC-to-CityGML conversion, is not re- semantics mapping, which is mandatory for IFC-to-CityGML conversion, is not required quired by IFC-to-shapefile conversion, which further simplifies the process of semantics by IFC-to-shapefile conversion, which further simplifies the process of semantics transfer. transfer.

Remote Sens. 2021, 13, x FOR PEER REVIEW 13 of 26

Remote Sens. 2021, 13, 1889 13 of 26 Remote Sens. 2021, 13, x FOR PEER REVIEW 13 of 26

Figure 10. Essential semantics and extended semantics.

3.4. An Overview of the Proposed Approch for IFC-to-Shapefile Conversion An overview of the final approach for data conversion from IFC to shapefile is given in Figure 11. The geometric information and semantic information are converted/transferred separately into a .shp file and .dbf file and linked via the .shx file, which are the three main files of shapefile. In this process, OCCT converts IFC objects into temporary shape objects (buffers); these shape objectsFigure are interpreted 10. Essential semanticsinto OCCT and B - extendedRep and semantics. converted into shapefile B-Rep using the proposed method. Some algorithms developed in OSA were also used in this study, such 3.4.as those An Overview for coordinate of the P roposedtransformation Approch (CT)for IFC and-to -shapefileShapefile C creation.onversion This ap- 3.4. An Overview of the Proposed Approch for IFC-to-Shapefile Conversion proach is thus referredAn overview to as OCCT of the-OSA final in approach this study, for for data the conversion purpose of from an easier IFC to discus- shapefile is given sion. The generatedin FigureAn building overview 11. The models ofgeometric the final can information approachbe managed for andin data two semantic conversion ways, i.e., information from either IFC using to are shapefile a converted/trans- sin- is given in gle shapefileferredFigure for all separately11 the. The building geometric into elementsa .shp information file or and one and.dbf shapefile semantic file an d for informationlinked each via buildin the are .shxg converted/transferred element. file, which are the While both ofthreeseparately these main two intofiles ways a of .shp can shapefile. filebe realized, and .dbf in file this and study, linked the via first the strategy .shx file, was which adopted, are the three main for easier datafiles management. ofIn shapefile.this process, OCCT converts IFC objects into temporary shape objects (buffers); these shape objects are interpreted into OCCT B-Rep and converted into shapefile B-Rep using the proposed method. Some algorithms developed in OSA were also used in this study, such as those for coordinate transformation (CT) and shapefile creation. This approach is thus referred to as OCCT-OSA in this study, for the purpose of an easier discussion. The generated building models can be managed in two ways, i.e., either using a single shapefile for all the building elements or one shapefile for each building element. While both of these two ways can be realized, in this study, the first strategy was adopted, for easier data management.

Figure Figure11. Overview 11. Overview of the proposed of the proposed approach approach for IFC for-to- IFC-to-shapeﬁleshapefile conversion. conversion.

3.5. Data In this process, OCCT converts IFC objects into temporary shape objects (buffers); these Four publiclyshape objectsavailable are BIM interpreted models from into OCCTthe Karlsruhe B-Rep andInstitute converted of Technology into shapefile (KIT) B-Rep using and Open IFCthe R proposedepository method.have been Some used algorithms to develop developedand validate in the OSA proposed were also method, used in this study, including twosuch house as those models for and coordinate two building transformation models. Figure (CT) and 12 shapefileshows these creation. BIM mod- This approach is els, includingthus (a) House referred 1, to(b) as Institute, OCCT-OSA (c) House in this 2, study,and (d) for Smiley. the purpose House of1, Institute an easier, and discussion. The Smiley are fromgenerated KIT [72] building; they were models created can be as managed examples in of two quality ways, IFC i.e., models either using. House a single 2 shapefile is a model fromFigurefor allthe 11. the Open Overview building IFC Model of elements the proposedRepository or one approach (OIMR) shapefile for [73] IFC for. -Detailedto each-shapefile building information conversion. element. about While both of these two ways can be realized, in this study, the first strategy was adopted, for easier 3.5.data Data management.

3.5. DataFour publicly available BIM models from the Karlsruhe Institute of Technology (KIT) and Open IFC Repository have been used to develop and validate the proposed method, Four publicly available BIM models from the Karlsruhe Institute of Technology (KIT) including two house models and two building models. Figure 12 shows these BIM mod- and Open IFC Repository have been used to develop and validate the proposed method, els, including (a) House 1, (b) Institute, (c) House 2, and (d) Smiley. House 1, Institute, and including two house models and two building models. Figure 12 shows these BIM models, Smiley are from KIT [72]; they were created as examples of quality IFC models. House 2 is a model from the Open IFC Model Repository (OIMR) [73]. Detailed information about

Remote Sens. 2021, 13, 1889 14 of 26

Remote Sens. 2021, 13, x FOR PEER REVIEW 14 of 26

Remote Sens. 2021, 13, x FOR PEER REVIEW 14 of 26 including (a) House 1, (b) Institute, (c) House 2, and (d) Smiley. House 1, Institute, and Smiley are from KIT [72]; they were created as examples of quality IFC models. House 2 is athese model models from can the be Open found IFC in Model [72]. Table Repository 5 lists the (OIMR) type and [73]. quantity Detailed of information building elements about thesein each models building can model. be found in [[72]72].. Table 5 5 lists lists the the type type and and quantity quantity of of building building elements elements in each building model.model.

Figure 12. BIM models used in this study for validation. FigureFigure 12.12. BIM models used inin thisthis studystudy forfor validation.validation. Table 5. Quantity of building elements in each model.

Table 5.5. QuantityQuantity ofof buildingbuilding elementselements inin eacheach model.model. Quantity of Components IFC Class House 1 QuantityHouse of2 ComponentsInstitute Smiley IFC Class Quantity of Components IFC ClassIfcBeam House4 1 House39 2 Institute- Smiley10 House 1 House 2 Institute Smiley IfcBuildingElementProxyIfcBeam 4- 398 - 10- IfcBeam 4 39 - 10 IfcBuildingElementProxyIfcColumn - 108 2- 20- IfcBuildingElementProxy - 8 - - IfcDoor 5 14 77 170 IfcColumnIfcColumn -- 1010 22 20 20 IfcDoorIfcMemberIfcDoor 5425 1414- 7777- 170170- IfcMemberIfcMemberIfcRailing 42422 -6- -12- - 120- IfcRailingIfcRailingIfcRoof 22- 616 1212- 120120- IfcRoofIfcSlab -4 18 -26 - 120 IfcSlabIfcRoof 4- 81 26- 120 - IfcStairIfcStairIfcSlab 114 448 4264 30 12030 IfcWallIfcWallIfcStair -1- 57574 -4- 28128130 IfcWallStandardCaseIfcWallStandardCaseIfcWall 1313- 464657 121121- 270270281 IfcWindowIfcWindow 1111 2525 206206 80 80 IfcWallStandardCase 8213 172 46 448121 831270 IfcWindow 8211 17225 448206 83180 82 172 448 831 4. Results 4. ResultsThese fourfour modelsmodels werewere ﬁrst first assessed assessed using using OCCT OCCT alone alone to to ensure ensure that that they they could could be processed and visualized. The following steps were used: (a) extracting shape representa- be processed and visualized. The following steps were used: (a) extracting shape repre- tionsThese of building four models elements were from first IFC, assessed (b) processing using OCCT these shapealone representationsto ensure that they into shapecould sentations of building elements from IFC, (b) processing these shape representations into objects,be processed (c) sending and visualized. shape objects The to following Open GL, steps and (d)were creating used: (a) a window extracting on theshape screen repre- to shape objects, (c) sending shape objects to Open GL, and (d) creating a window on the displaysentations the of processed building model. elements The from result IFC, of this(b) processing assessment these is presented shape representations in Figure 13, where into screen to display the processed model. The result of this assessment is presented in Figure modelsshape objects, are preliminarily (c) sending rendered shape objects using randomto Open colors.GL, and (d) creating a window on the 13screen, where to display models the are processed preliminarily model. rendered The result using of randomthis assessment colors. is presented in Figure 13, where models are preliminarily rendered using random colors.

FigureFigure 13. Models 13. Models processed processed and andvisualized visualized using using OCCT. OCCT. Figure 13. Models processed and visualized using OCCT. After the initial test, these four building models were then processed using the pro- posedAfter approachapproach the initial andand thetest,the resultresult these shows showsfour building that that they they models can can be be successfullywere successfully then processed converted converted using into into shapefile the shape- pro- models.fileposed models. approach Figure Figure 14 and presents 14 the presents result the showsthe converted converted that shapefilethey shapefile can be models successfully models for (a)for Houseconverted(a) House 1, (b) into1, Institute,(b) shape- Insti- (c)tute,file House models. (c) House 2, andFigure 2 (d), and 14 Smiley, presents(d) Smile including they, includingconverted exterior, exterior, shapefile interior, interior, indoormodels indoor spacefor (a) (if spaceHouse defined), (if 1, defined),(b) and Insti- an exampleandtute, an(c) exampleHouse floor plan 2 , floorand for the(d) plan groundSmile for y, the floor.including ground These floor.exterior, models These interior, were models visualized indoor were usingspace visualized ArcScene.(if defined), using ArcScene.and an example floor plan for the ground floor. These models were visualized using ArcScene.

Remote Sens. 2021Remote, 13, x Sens. FOR2021 PEER, 13 REVIEW, 1889 15 of 26 15 of 26

Figure 14. ConvertedFigure 14. buildingConverted models, building i.e., (a models,) House i.e., 1, (b (a)) Institute, House 1, ( (cb)) House Institute, 2, and (c) House(d) Smiley. 2, and (d) Smiley.

Tables 6 andTables 7 present6 and the7 present processing the processingtime, file size, time, and ﬁle quantity size, and of quantitybuilding ofcompo- building components beforenents and after before conversion. and after conversion. From the quantity From the of quantity components, of components, it can be it asserted can be asserted that that the geometrythe geometry of all building of all building elements elements and building and building components components have been have retaine beend. retained. The The convertedconverted building building components components for those for models those modelshave been have presented been presented in Figure in 15 Figure. 15.

Table 6. ProcessingTable 6.timeProcessing and file timesize of and converted ﬁle size ofmodels converted. models.

House 1 House 1House 2 House 2Smiley SmileyInstitute Institute Time (s) Time (s)8.5 8.54.6 4.655.2 55.217.9 17.9 Size (KB) Size (KB)2,878.2 2878.21,640.6 1640.62,4097.2 24097.25,318.0 5318.0

Table 7. Quantity of building components before and after conversion. Table 7. Quantity of building components before and after conversion. House 1 House 2 Institute Smiley IFC Class House 1 House 2 Institute Smiley IFC ClassBefore After Before After Before Converted Original Converted Before After Before After Before Converted Original Converted IfcBeam 4 4 39 39 - - 10 10 IfcBuildingElementProxyIfcBeam - - 48 48 39- 39- -- -- 10 10 IfcBuildingElementProxy - - 8 8 - - - - IfcColumn IfcColumn- - -10 -10 102 102 220 220 20 20 IfcDoor IfcDoor5 5 514 514 1477 1477 77170 77170 170 170 IfcMember 42 42 ------IfcMember IfcRailing42 42 2- 2- 6- 6- 12- 12- 120 120 IfcRailing IfcRoof2 2 -6 -6 112 112 -120 -120 - - IfcSlab 4 4 8 8 26 26 120 120 IfcRoof IfcStair- - 11 11 4- 4- 4- 4- 30 30 IfcSlab IfcWall4 4 -8 -8 5726 5726 -120 -120 281 281 IfcStair IfcWallStandardCase1 1 134 134 464 464 12130 12130 270 270 IfcWindow 11 11 25 25 206 206 80 80 IfcWall Total quantity- - 8257 8257 172- 172- 448281 448 281 831 831 IfcWallStandardCase 13 13 46 46 121 121 270 270 IfcWindow 11 11 25 25 206 206 80 80 Total quantity 82 82 172 172 448 448 831 831

Remote Sens. 2021, 13, 1889 16 of 26 Remote Sens. 2021, 13, x FOR PEER REVIEW 16 of 26

Figure 15. Converted building components in shapeﬁleshapefile for (a) House 1,1, ((b)) Institute,Institute, ((cc)) HouseHouse 2,2, andand ((dd)) Smiley.Smiley.

The original original building building components components in in IFC IFC are are presented presented in Figure in Figure 16, 16which, which were were vis- visualizedualized using using FZKViewer. FZKViewer. The The comparison comparison between between the the converted converted building building components and the the original original building building component componentss shows shows that that all allbuilding building components components have have beenbeen gen- generated.erated. Some Some doors doors and windows and windows of these of thesemodels models in Figure in Figure 16 are 16open, are which open, is which a feature is a featureof the FZKViewer of the FZKViewer that can that show can the show status the of status doors of and doors windows and windows.. When Whenvisualized visualized using usingAutodesk Autodesk Revit, Revit,these doors these doorsand windows and windows are closed. are closed.

Remote Sens. 2021, 13, 1889 17 of 26 Remote Sens. 2021, 13, x FOR PEER REVIEW 17 of 26

Figure 16. BBuildinguilding components in IFC for ( a)) House 1, ( b) Institute, ( c) House 2 2,, and (d) Smiley.

5. Discussion 5.1.5. Discussion Comparing OCCT-OSA with Previous Methods 5.1. Comparing OCCT-OSA with Previous Methods In order to assess the performance of the proposed method, it is compared with the OSA Inand order the toprevalent assess the commercial performance tool, of i.e., the DIA/FME, proposed method,in terms itof isprocessing compared time with and the fileOSA size and of the the prevalent converted commercial models. The tool, efficie i.e., DIA/FME,ncy of data in conversion terms of processing is assessed time using and pro- file cessingsize of the time. converted A longer models. processing The efficiencytime indicates of data a lower conversion efficiency. is assessed using processing time. A longer processing time indicates a lower efficiency. 5.1.1. Comparison between OCCT-OSA and OSA 5.1.1. Comparison between OCCT-OSA and OSA (1) Efficiency of data conversion. Table 8 presents the comparison in processing time (1) Efficiency of data conversion. Table8 presents the comparison in processing time between OCCT-OSA and OSA as well as the improvement in efficiency. between OCCT-OSA and OSA as well as the improvement in efficiency.

Remote Sens. 2021, 13, 1889 18 of 26 Remote Sens. 2021, 13, x FOR PEER REVIEW 18 of 26

Table 8. Processing time by OCCT-OSA and OSA. Table 8. Processing time by OCCT-OSA and OSA. Processing Time (Seconds) Processing Time (Seconds) House 1 House 2 Smiley Institute Average House 1 House 2 Smiley Institute Average OSA (a) 25.2 40.7 245.9 90.5 - OCCT-OSAOSA (a) (b)25.2 8.540.7 4.6245.9 55.290.5 17.9- - OCCTImprovement-OSA (b) (a-b)/b 8.5 196%4.6 785%55.2 346%17.9 406% 433%- Improvement (a-b)/b 196% 785% 346% 406% 433% The result shows that OCCT-OSA took less time than OSA to process all these models, whichThe indicates result thatshows OCCT-OSA that OCCT has-OSA a higher took efficiency.less time than In the OSA House to process 2 model, all for these example, mod- OCCT-OSAels, which indicates only used that 4.6 OCCT s, while-OSA OSA has used a higher 40.7 s, efficiency. indicating In an the efficiency House 2 increase model, byfor 785%.example, In this OCCT study,-OSA the only efficiency used 4.6 of datas, while conversion OSA used has 40.7 increased s, indicating by between an efficiency 196% and in- 785%crease and, by 785%. on average, In this by study, 433%. the efficiency of data conversion has increased by between 196%(2) and File 785% size. and Table, on9 average,presents by the 433%. comparison between OCCT-OSA and OSA in file size.(2) OCCT-OSA File size. generatedTable 9 presents models the with comparison larger file between sizes for OCCT these models.-OSA and For OSA example, in file thesize. file OCCT size- ofOSA House generated 1 from models OCCT-OSA with islarger 2878.2 file KB, sizes which for these is almost models. twice For that example, of the modelthe file generated size of House by OSA. 1 from This OCCT is due- toOSA the is fact 2878.2 that OCCT-OSAKB, which is generates almost twice more that geometric of the details—formodel generated example, by OSA. for doors This andis due windows, to the fact as that shown OCCT in Figure-OSA generates17. On average, more geomet- models generatedric details— byfor OCCT-OSA example, for use doors 68% moreand windows, storage space as shown than in OSA. Figure 17. On average, models generated by OCCT-OSA use 68% more storage space than OSA. Table 9. File size of models generated by OCCT-OSA and OSA. Table 9. File size of models generated by OCCT-OSA and OSA. File Size (KB) File size (KB) House 1 House 2 Smiley Institute Average House 1 House 2 Smiley Institute Average OSA (a) 1503.6 1120.0 14,305.5 3206.4 - OSA (a) 1503.6 1120.0 14,305.5 3206.4 - OCCT-OSA (b) 2878.2 1640.6 24,097.2 5318.0 - ComparisonOCCT-OSA (b-a)/a (b) 91%2878.2 46%1640.6 24 68%,097.2 5318.0 66% 68%- Comparison (b-a)/a 91% 46% 68% 66% 68%

FigureFigure 17.17. HouseHouse 11 modelmodel generatedgenerated byby ((aa)) OCCT-OSAOCCT-OSA andand ((bb)) OSA. OSA.

(3)(3) The precision precision problem problem.. Geometric Geometric errors errors are are observed observed in the in theHouse House 2 model 2 model con- convertedverted by byOSA OSA (see (see Figure Figure 18 18b).b). These These errors errors were were caused caused by by the the precision precision problem [[24]24],, whichwhich hashas beenbeen recognizedrecognized byby researchersresearchers inin thethe areaarea ofof computationalcomputational geometrygeometry [[74]74]that that cancan leadlead geometric geometric algorithms algorithms to to crash, crash, loop loop forever, forever, or simplyor simply output output incorrect incorrect results results [75]. This[75]. problemThis problem is rooted is rooted in the factin the that, fact in that, computer in computer systems, systems, infinite realinfinite numbers real numbers have to behave squeezed to be squeezed (or rounded) (or rounded) into the into finite the floating-point finite floating numbers.-point numbers. In the case In the of case IFC, of when IFC, thewhen modeling the modeling precision precision of BIM of models BIM models does notdoes meet not themeet requirement, the requirement, which which is the is case the ofcase House of House 2, the 2, generated the generated shapefile shapefile models models are prone are prone to geometric to geometric errors, errors, which which impairs im- thepairs quality the quality of the convertedof the converted BIM models. BIM models. In this study,In this OCCT-OSAstudy, OCCT can-OSA effectively can effectively handle thishandle problem. this problem. In the case In ofthe House case of 2, OCCT-OSAHouse 2, OCCT generated-OSA generated the model withoutthe model geometric without errorsgeometric (see Figureerrors (see18a). Figure 18a).

RemoteRemote Sens.Sens.2021 2021, ,13 13,, 1889 x FOR PEER REVIEW 1919of of 2626

Remote Sens. 2021, 13, x FOR PEER REVIEW 19 of 26

FigureFigure 18.18. WallsWalls generatedgenerated byby ((aa)) OCCT-OSAOCCT-OSA and and ( b(b)) OSA. OSA. Figure 18. Walls generated by (a) OCCT-OSA and (b) OSA. 5.1.2.5.1.2. ComparisonComparison betweenbetween OCCT-OSAOCCT-OSA andand DIA/FMEDIA/FME 5.1.2.The TheComparison latest version between of of DIA/FME DIA/FME OCCT-OSA was was and used used DIA/FME for for the the comparison. comparison. Table Table 10 shows 10 shows the pro- the processingcessingThe time latest time of version OCCT of OCCT-OSA -ofOSA DIA/FME and and DIA/FME, was DIA/FME, used which for which the indicates comparison. indicates that thatOCCT Table OCCT-OSA -10OSA shows is more the is more pro- effi- cessingefﬁcientcient than time than DIA/FME of DIA/FME OCCT in-OSA processing in processingand DIA/FME, those those models. which models. Even indicates Even though thoughthat the OCCT conversion the conversion-OSA is can more be can com-effi- be cientcompletedpleted than by DIA/FME byDIA/FME, DIA/FME, in the processing thegenerated generated those models, models, models. unfortunately, unfortunately, Even though contain containthe conversion geometric geometric can errors,erro be com-rs, asas pletedshownshown by inin FigureFigureDIA/FME, 1919,, whichwhich the generated indicatesindicates thatmodels,that DIA/FMEDIA/FME unfortunately, is still not contain sufﬁcientlysufficiently geometric reliable.reliable. erro rs, as shown in Figure 19, which indicates that DIA/FME is still not sufficiently reliable. TableTable 10. 10.Processing Processing time time between between OCCT-OSA OCCT-OSA and and DIA/FME. DIA/FME. Table 10. Processing time between OCCT-OSA and DIA/FME. Processing TimeProcessing (Seconds Time) (Seconds) House 1 HouseProcessingHouse 2 1 Time House (SecondsSmiley 2) SmileyInstitute Institute House 1 House 2 Smiley Institute DIA/FME (a) DIA/FME25.4 (a)25.9 25.4 25.9118.1 118.1136.7 136.7 OCCTDIA/FME-OSA (a) (b) OCCT-OSA25.48.5 (b)25.94.6 8.5 4.6118.155.2 55.2136.717.9 17.9 ImprovementOCCT-OSA (a(b)-b)/b Improvement199%8.5 (a-b)/b463%4.6 199% 463%114%55.2 114%664%17.9 664% Improvement (a-b)/b 199% 463% 114% 664%

Figure 19. Models generated by DIA/FME. FigureFigure 19.19. ModelsModels generatedgenerated byby DIA/FME.DIA/FME. 5.1.3. Comparative Summary for Methods in IFC-to-Shapefile Conversion 5.1.3. Comparative Summary for Methods in IFC-to-Shapefile Conversion 5.1.3.Table Comparative 11 presents Summary a comparative for Methods summary in IFC-to-Shapefile for methods used Conversion in IFC-to-shapefile conversion,Table including 11 presents OCCT a comparative-OSA, OSA, summary the method for proposed methods byused Isikdag in IFC [51]-to-,shapefile and commer- con- Table 11 presents a comparative summary for methods used in IFC-to-shapefile conversion,cial tools, including in terms OCCT of geometry-OSA, OSA, conversion, the method semantic proposed information by Isikdag transfer, [51], and the commer-ability to version, including OCCT-OSA, OSA, the method proposed by Isikdag [51], and commercial cialhandle tools, precision in terms problem, of geometry and if conversion, the method semantic is automatic. information Compared transfer, with previous the ability stud- to tools, in terms of geometry conversion, semantic information transfer, the ability to handle handleies, the precision proposed problem, OCCT-OSA and ifcan the automatically method is automatic. convert allCompared types of withrepresentations, previous stud- in- precision problem, and if the method is automatic. Compared with previous studies, the ies,cluding the proposed B-Rep, swept OCCT solid,-OSA and can CSG/Clipping,automatically convertand the all precision types of problem representations, can be effi- in- proposed OCCT-OSA can automatically convert all types of representations, including B- cludingciently handledB-Rep, swept to guarantee solid, andthe qualityCSG/Clipping, of the converted and the models.precision problem can be effi- cientlyRep, swept handled solid, to and guarantee CSG/Clipping, the quality and of the the precision converted problem models. can be efficiently handled to guarantee the quality of the converted models. Table 11. Comparative summary for methods in IFC-to-shapefile conversion. Table 11. Comparative summary for methods in IFC-to-shapefile conversion. Geometry Conversion Geometry Conversion Semantic Infor- Handling Preci- Swept Semantic Infor- Handling Preci- Automatic B-Rep Swept CSG/Clipping mation Transfer sion Problem Automatic B-Rep Solid CSG/Clipping mation Transfer sion Problem FME [76], DIA  Solid * * NA  FMEIsikdag [76], [51]DIA NA  ** ** NANA  * OSAIsikdag [24,28,29] [51] NA  * ** NAX ** OSAOCCT [24,28,29]-OSA    ** X * OCCT-OSA  : solved, *: partly solved, X: not solved, NA:* not assessed.   : solved, *: partly solved, X: not solved, NA: not assessed.

Remote Sens. 2021, 13, 1889 20 of 26

Table 11. Comparative summary for methods in IFC-to-shapeﬁle conversion.

Geometry Conversion Semantic Information Handling Precision Swept Automatic B-Rep CSG/Clipping Transfer Problem Solid √ √ √ √ √ FME [76], DIA √ √* √* NA √ Isikdag [51] NA√ √ √* √* NA √* OSA [24,28,29] √ √ √ √*X√ √* OCCT-OSA * √ √ : solved, *: partly solved, X: not solved, NA: not assessed.

5.3. Contributions, Implications, Limitations, and Future Work This study managed to integrate computer graphics techniques, or OCCT, into the conversion of IFC into shapefile; the main contributions of this study are as follows. (1) Exploring and developing an innovative way of using computer graphics techniques at a low level in IFC-to-shapefile conversion. This study creatively used the temporary shape objects (buffers) generated by OCCT for the IFC-to-shapefile conversion, where these buffers were retrieved, reorganized, and preserved in shapefile for use in other applications, despite their original purpose being for visualization. The developed method can also avoid problems in previous studies that are introduced by their inability to efficiently manipulate IFC geometry. These studies used existing tools at process level to build long and sometime complex pipelines for data conversion, which made the conversion process inefficient and prone to errors, such as in studies by Arroyo Ohori et al. [16] and Zhao et al. [59]. (2) Providing a reliable and efficient approach for IFC-to-shapefile conversion. OCCT has been used by many CAD or BIM programs as a 3D modeling kernel, such as the FreeCAD and BIMserver, which makes the proposed method as reliable as these programs. As long as BIM models can be processed and visualized using these programs, they can be converted and used in GIS. Remote Sens. 2021, 13, x FOR PEER REVIEW 20 of 26

5.2. Validation Using Other Models Additional BIM models were used to further test OCCT-OSA, including three models from ongoing real projects and six models from the OIMR. Information about these models and data conversion are presented in Table 12. The file size of these models ranges from 70KB to 349.1MB, and the number of building components ranges from 61 to 1906. It can also be noticed that many models do not meet the modeling precision requirement Remote Sens. 2021, 13, 1889 21 of 26 of IFC, but OCCT-OSA can handle all these models with a processing time ranging from 0.55 s to 967.56 s, depending on the size and complexity of these models. Figure 20 presents the converted shapefile models visualized using random colors in ArcScene. Table 12. Additional BIM models used in validation. Table 12. Additional BIM models used in validation. Number of Modeling Time Data Model File Size Number of Model File Size ComponentsModelingPrecision Precision Time(Seconds) (Seconds) DataSource Source Components 1 bridge1.ifc 70.0 KB 61 1 × 10−4 0.6 Project 1 bridge1.ifc 70.0 KB 61 1 × 10−4 0.6 Project 2 bridge2.ifc 845.0 KB 609 1 × 10−5 8.7 Project −5 2 3bridge2.ifc T18001_Zonghelou.ifc 845.0 KB 2.6 MB609 253 1 × 101 × 10−2 7.38.7 ProjectProject −2 3 4 20160125OTC-Conference-Center.ifcT18001_Zonghelou.ifc 2.6 MB 226.6 MB253 1728 1 × 101 × 10−4 525.87.3 OIMRProject 4 5 20160125OTC20200109rac_advanced_sample_project.ifc-Conference-Center.ifc 226.6 MB103.0 MB1728 925 1 × 101 ×−4 10−2 244.5525.8 OIMROIMR 5 620200109rac_advanced_sample_project.ifc 20191126AZUMA9.ifc 103.0 MB 20.3 MB925 96 1 × 101 ×−2 10−5 244.532.0 OIMROIMR 6 7 20190228201620_Svaleveien_8_Hus_A.ifc20191126AZUMA9.ifc 20.3 MB 17.3 MB96 120 1 × 101 ×−5 10−5 38.632.0 OIMROIMR 7 820190228201620_Svaleveien_8_Hus_A.ifc 20160125Autodesk_Hospital_Parking.ifc 17.3 MB 14.3 MB120 1085 1 × 101 ×−5 10−4 37.438.6 OIMROIMR 8 920160125Autodesk_Hospital_Parking.ifc 20180731Dubal-Herrera-limpio.ifc 14.3 MB 349.1 MB1085 1906 1 × 101 ×−4 10−5 967.637.4 OIMROIMR 9 20180731Dubal-Herrera-limpio.ifc 349.1 MB 1906 1 × 10−5 967.6 OIMR

FigureFigure 20.20.Additional Additional modelsmodels convertedconverted byby OCCT-OSA.OCCT-OSA.

TheThese implication models were of thisnot studyused in includes the comparison the following between aspects. the proposed (1) For method the area and of BIM/GISOSA, because integration, (a) these BIM models models were can mainly now intended be integrated to further into aassess GIS environmentthe performance in an of easierthe proposed way. While method, the IFC-to-CityGML and (b) OSA alone conversion cannot process is still problematicsome of these in models, both geometry as OSA conversionwas developed and using semantics well- transferbuilt BIM [7 ,models42], this (with study well proposes-defined to modeling use the IFC-to-shapefile precision), such conversionas those from path, KIT, which and may makes have the problems BIM-to-GIS in handling data conversion models with easier geometric and more errors flexible that toare realize. common In among addition, models the techniqueused by real developed projects in[16,25] this. studyThis additional for the in-depth validation use fur- of OCCTther justifies can also the be reliability used by studiesof the proposed working method. on IFC-to-CityGML conversion, as these two conversion paths share a common first step, i.e., interpreting IFC geometry. Moreover, the method5.3. Contributions, developed I inmplications, this study L canimitations be the foundation, and Future ofW system-levelork BIM/GIS integration, whereThis information study managed systems to are integrate developed computer by incorporating graphics technique both GISs, andor OCCT, BIM features. into the The method has the potential to enable a desktop-based GIS system to directly read and conversion of IFC into shapefile; the main contributions of this study are as follows. (1) interpret IFC data. (2) For the emerging concept of the smart city and digital twin, where a Exploring and developing an innovative way of using computer graphics techniques at a large number of 3D building models from BIM are required to be processed and used in low level in IFC-to-shapefile conversion. This study creatively used the temporary shape GIS and the conversion of such a volume of models can consume an enormous amount of time, this fully automatic, reliable, and efficient conversion approach can improve the overall efficiency of projects on these topics. (3) This study can complement other 3D model acquisition techniques for the smart city and digital twin, such as photogrammetry and laser scanning [77]. While existing acquisition techniques capture the surface information of buildings and can be time-consuming and error-prone when reconstructing surface- based building models [78], this study can provide highly detailed solid building models. (4) In a broad sense, the method and new knowledge created in this study for manipulating IFC geometry can be reused by any studies where IFC models are involved. This study currently mainly focuses on geometry and only preserves the essential semantic information. Even though additional semantic information can be extracted Remote Sens. 2021, 13, 1889 22 of 26

and linked afterwards with the geometric model in the form of attribute tables, some types of semantic information, such as the topology information of building components, cannot be well maintained. Moreover, the lack of a semantic data schema of shapefile makes the standardization operation more complex. A better solution for semantics transfer is thus needed. Methods using ontology techniques, such as a graph database, should be investigated, as studies have preliminarily demonstrated that the ontology technique is promising in lossless semantic information transfer. Another concern of the proposed method is that it only produces as-is BIM models without the ability to manipulate models, e.g., for the purpose of model simplification, which is important for multi-scale representation in GIS for the sake of reducing storage space and saving rendering power [79]. Lastly, shapefile has been successfully used in this study as a repository for solid building models, but due to its intrinsic limitations on file size and attribute database, as well as its vulnerable data structure, such a format alone may not be suitable for large projects, and a better way of managing such data should be investigated— for example, by using geodatabases. These concerns are the main limitations of this study, which should be addressed in future work.

6. Conclusions This study primarily aims to facilitate the use of BIM models in GIS and focuses on developing a reliable and efficient approach for addressing the fundamental BIM-to-GIS data conversion problem. To achieve this, first, the commonly used IFC-to-CityGML path and the IFC-to-shapefile path were compared in terms of the number and difficulty of data conversion tasks. Second, a more efficient and reliable approach was developed for the IFC-to-shapefile path by integrating a computer graphics technique, i.e., OCCT, in the conversion process. In order to achieve this, the format of the temporary shape object generated by OCCT was investigated and an algorithm was developed to convert OCCT B-Rep to shapefile B-Rep. The proposed method is referred to as OCCT-OSA. Four building models have been used to develop and validate the proposed approach. Nine additional models from real projects or online sources have been used to further test the reliability of the proposed method. The main findings of this study are as follows. (1) The IFC-to-shapefile conversion is easier and more flexible to realize than the IFC-to-CityGML conversion, in terms of the number and difficulty of involved conversion tasks. (2) Computer graphics techniques can be integrated into IFC-to-shapefile conversion at a low level to improve the efficiency and reliability of BIM-to-GIS data conversion. The developed OCCT-OSA is more efficient than previous methods, and the generated building models contain more geometric details. (3) OCCT-OSA can transform all types of representations, including B-Rep, swept solid, and CSG/Clipping, in a fully automatic manner and effectively handle the precision problem. It can be used to process those not-well-built models that are common in real projects. The contribution of this study includes the following aspects. (1) A reliable data conversion method for BIM/GIS integration is provided. When the IFC-to-CityGML path for data conversion is still problematic in both geometry conversion and semantics transfer due to mismatches in semantics and modeling method, this study provides an automatic, efficient, and effective data conversion path to ensure that BIM data can effectively flow into GIS. (2) An investigation into OCCT was conducted in depth, and a method for the in-depth use of OCCT in IFC geometry manipulation has been developed, which can also benefit studies on IFC-to-CityGML conversion or any other studies where IFC models are involved, given that OCCT is widely involved in open BIM and CAD. The proposed method is fundamental, which facilitates the use of BIM models in GIS and supports studies on the smart city and digital twin in a broad sense. The main limitation of this study is that the proposed method currently only generates as-is models without the ability to edit/modify model geometry, while model simplification is important for GIS. In addition, the semantics transfer problem should be better addressed in the future. Remote Sens. 2021, 13, 1889 23 of 26

Author Contributions: Conceptualization, J.Z. and P.W.; methodology, J.Z.; software, J.Z.; validation, J.Z.; writing—original draft preparation, J.Z.; writing—review and editing, J.Z. and P.W.; funding acquisition, P.W. All authors have read and agreed to the published version of the manuscript. Funding: This research was funded by the Australian Research Council, grant number DP180104026. Data Availability Statement: Data available in a publicly accessible repository that does not issue DOIs. Publicly available datasets were analyzed in this study. This data can be found here: https: //www.ifcwiki.org/index.php?title=IFC_Wiki (accessed on 11 May 2021), and http://openifcmodel. cs.auckland.ac.nz (accessed on 11 May 2021). Acknowledgments: The authors would like to thank the anonymous reviewers for their comments and suggestions that helped to improve the comprehensiveness and clarity of our paper. Conﬂicts of Interest: The authors declare no conﬂict of interest.

Appendix A Python Codes for Retrieving Essential Attributes

def findSpatialStrcture(buildingElement): #determine the type of buildingElement if buildingElement.is_a() == ‘IfcSpace’: firstStructure = buildingElement.Decomposes[0].RelatingObject elif buildingElement.is_a() == ‘IfcSite’: firstStructure = buildingElement else: firstStructure = buildingElement.ContainedInStructure[0].RelatingStructure if firstStructure.is_a() == ‘IfcBuildingStorey’: storeyEle = findStoreyLevel(firstStructure) storeyName = firstStructure.Name bldName = firstStructure.Decomposes[0]. RelatingObject.Name.encode(‘ascii’,‘ignore’) siteName = firstStructure.Decomposes[0]. RelatingObject.Decomposes[0].RelatingObject.Name elif firstStructure.is_a() == ‘IfcBuilding’: storeyEle = None storeyName = None bldName = firstStructure.Name siteName = firstStructure.Decomposes[0].RelatingObject.Name elif firstStructure.is_a() == ‘IfcSite’: storeyEle = None storeyName = None bldName = None siteName = firstStructure.Name result = [storeyEle, storeyName, bldName, siteName] return result

References 1. Ketzler, B.; Naserentin, V.; Latino, F.; Zangelidis, C.; Thuvander, L.; Logg, A. Digital twins for cities: A state of the art review. Built Environ. 2020, 46, 547–573. [CrossRef] 2. Li, H.; Chan, G.; Wong, J.K.W.; Skitmore, M. Real-time locating systems applications in construction. Autom. Constr. 2016, 63, 37–47. [CrossRef] 3. Biljecki, F.; Stoter, J.; Ledoux, H.; Zlatanova, S.; Çöltekin, A. Applications of 3D city models: State of the art review. ISPRS Int. J. Geo Inf. 2015, 4, 2842–2889. [CrossRef] 4. Shirowzhan, S.; Tan, W.; Sepasgozar, S.M. Digital twin and CyberGIS for improving connectivity and measuring the impact of infrastructure construction planning in smart cities. Int. J. Geo Inf. 2020, 9, 240. [CrossRef] 5. El-Hallaq, M.A.; Alastal, A.I.; Salha, R.A. Enhancing sustainable development through web based 3D smart city model using GIS and BIM. Case study: Sheikh hamad city. J. Geogr. Inf. Syst. 2019, 11, 321. [CrossRef] 6. Yamamura, S.; Fan, L.; Suzuki, Y. Assessment of urban energy performance through integration of BIM and GIS for smart city planning. Procedia Eng. 2017, 180, 1462–1472. [CrossRef] 7. Zhu, J.; Wright, G.; Wang, J.; Wang, X. A critical review on the integration of geographic information system and building information modelling at the data level. ISPRS Int. J. Geo Inf. 2018, 7, 66. [CrossRef] 8. Amirebrahimi, S.; Rajabifard, A.; Mendis, P.; Ngo, T. A framework for a microscale ﬂood damage assessment and visualization for a building using BIM–GIS integration. Int. J. Digit. Earth 2016, 9, 363–386. [CrossRef] Remote Sens. 2021, 13, 1889 24 of 26

9. Niu, S.; Pan, W.; Zhao, Y. A BIM-GIS integrated web-based visualization system for low energy building design. Procedia Eng. 2015, 121, 2184–2192. [CrossRef] 10. Isikdag, U.; Underwood, J.; Aouad, G. An investigation into the applicability of building information models in geospatial environment in support of site selection and fire response management processes. Adv. Eng. Inform. 2008, 22, 504–519. [CrossRef] 11. Irizarry, J.; Karan, E.P. Optimizing location of tower cranes on construction sites through GIS and BIM integration. J. Inf. Technol. Constr. 2012, 17, 351–366. 12. Irizarry, J.; Karan, E.P.; Jalaei, F. Integrating BIM and GIS to improve the visual monitoring of construction supply chain management. Autom. Constr. 2013, 31, 241–254. [CrossRef] 13. Kutzner, T.; Chaturvedi, K.; Kolbe, T.H. CityGML 3.0: New functions open up new applications. PFG J. Photogramm. Remote Sens. Geoinf. Sci. 2020, 88, 43–61. [CrossRef] 14. Ma, Z.; Ren, Y. Integrated application of BIM and GIS: An overview. Procedia Eng. 2017, 196, 1072–1079. [CrossRef] 15. Shirowzhan, S.; Sepasgozar, S.M.; Edwards, D.J.; Li, H.; Wang, C. BIM compatibility and its differentiation with interoperability challenges as an innovation factor. Autom. Constr. 2020, 112, 103086. [CrossRef] 16. Arroyo Ohori, K.; Diakité, A.; Krijnen, T.; Ledoux, H.; Stoter, J. Processing BIM and GIS models in practice: Experiences and recommendations from a GeoBIM project in the Netherlands. ISPRS Int. J. Geo Inf. 2018, 7, 311. [CrossRef] 17. Hijazi, I.; Donaubauer, A.; Kolbe, T. BIM-GIS integration as dedicated and independent course for geoinformatics students: Merits, challenges, and ways forward. ISPRS Int. J. Geo Inf. 2018, 7, 319. [CrossRef] 18. Acharya, D.; Khoshelham, K.; Winter, S. BIM-PoseNet: Indoor camera localisation using a 3D indoor model and deep learning from synthetic images. ISPRS J. Photogramm. Remote Sens. 2019, 150, 245–258. [CrossRef] 19. Isikdag, U.; Zlatanova, S.; Underwood, J. A BIM-Oriented Model for supporting indoor navigation requirements. Comput. Environ. Urban Syst. 2013, 41, 112–123. [CrossRef] 20. Tashakkori, H.; Rajabifard, A.; Kalantari, M. A new 3D indoor/outdoor spatial model for indoor emergency response facilitation. Build. Environ. 2015, 89, 170–182. [CrossRef] 21. Teo, T.-A.; Cho, K.-H. BIM-oriented indoor network model for indoor and outdoor combined route planning. Adv. Eng. Inform. 2016, 30, 268–282. [CrossRef] 22. Deng, Y.; Cheng, J.C.; Anumba, C. A framework for 3D traffic noise mapping using data from BIM and GIS integration. Struct. Infrastruct. Eng. 2016, 12, 1267–1280. [CrossRef] 23. Foley, J.D.; Van Dam, A. Fundamentals of Interactive Computer Graphics; Addison-Wesley Publishing Company: Menlo Park, CA, USA, 1982. 24. Zhu, J.; Wu, P.; Chen, M.; Kim, M.J.; Wang, X.; Fang, T. Automatically processing IFC clipping representation for BIM and GIS integration at the process level. Appl. Sci. 2020, 10, 2009. [CrossRef] 25. Donkers, S.; Ledoux, H.; Zhao, J.; Stoter, J. Automatic conversion of IFC datasets to geometrically and semantically correct CityGML LOD3 buildings. Trans. GIS 2016, 20, 547–569. [CrossRef] 26. Zhu, J.; Tan, Y.; Wang, X.; Wu, P. BIM/GIS integration for web GIS-based bridge management. Ann. GIS 2021, 27, 99–109. [CrossRef] 27. Deng, Y.; Cheng, J.C.; Anumba, C. Mapping between BIM and 3D GIS in different levels of detail using schema mediation and instance comparison. Autom. Constr. 2016, 67, 1–21. [CrossRef] 28. Zhu, J.; Wang, X.; Chen, M.; Wu, P.; Kim, M.J. Integration of BIM and GIS: IFC geometry transformation to shapefile using enhanced open-source approach. Autom. Constr. 2019, 106, 1–18. [CrossRef] 29. Zhu, J.; Wang, X.; Wang, P.; Wu, Z.; Kim, M.J. Integration of BIM and GIS: Geometry from IFC to shapefile using open-source technology. Autom. Constr. 2019, 102, 105–119. [CrossRef] 30. Zhu, J.; Tan, Y.; Wang, J.; Wang, X. An economical approach to geo-referencing 3D model for integration of BIM and GIS. In Proceedings of the International Conference on Innovative Production and Construction (IPC 2017), Perth, Australia, 30 November–1 December 2017. 31. Diakite, A.A.; Zlatanova, S. Automatic geo-referencing of BIM in GIS environments using building footprints. Comput. Environ. Urban Syst. 2020, 80, 101453. [CrossRef] 32. Kang, T.W.; Hong, C.H. IFC-CityGML LOD mapping automation using multiprocessing-based screen-buffer scanning including mapping rule. KSCE J. Civ. Eng. 2018, 22, 373–383. [CrossRef] 33. Kang, T.W.; Hong, C.H. A study on software architecture for effective BIM/GIS-based facility management data integration. Autom. Constr. 2015, 54, 25–38. [CrossRef] 34. Isikdag, U.; Zlatanova, S. Towards defining a framework for automatic generation of buildings in CityGML using building Information Models. In 3D Geo-Information Sciences; Springer: Berlin/Heidelberg, Germany, 2009; pp. 79–96. 35. Karan, E.P.; Irizarry, J. Extending BIM interoperability to preconstruction operations using geospatial analyses and semantic web services. Autom. Constr. 2015, 53, 1–12. [CrossRef] 36. El-Mekawy, M.; Östman, A.; Shahzad, K. Towards interoperating CityGML and IFC building models: A unified model based approach. In Advances in 3D Geo-Information Sciences; Springer: Berlin/Heidelberg, Germany, 2011; pp. 73–93. 37. De Laat, R.; Van Berlo, L. Integration of BIM and GIS: The development of the CityGML GeoBIM extension. In Advances in 3D Geo-Information Sciences; Springer: Berlin/Heidelberg, Germany, 2011; pp. 211–225. Remote Sens. 2021, 13, 1889 25 of 26

38. Knoth, L.; Scholz, J.; Strobl, J.; Mittlböck, M.; Vockner, B.; Atzl, C.; Rajabifard, A.; Atazadeh, B. Cross-domain building models—A step towards interoperability. ISPRS Int. J. Geo Inf. 2018, 7, 363. [CrossRef] 39. LaCourse, D.E. Handbook of Solid Modeling; McGraw-Hill: New York, NY, USA, 1995. 40. Hijazi, I.; Ehlers, M.; Zlatanova, S.; Becker, T.; van Berlo, L. Initial investigations for modeling interior Utilities within 3D Geo Context: Transforming IFC-interior utility to CityGML/UtilityNetworkADE. In Advances in 3D Geo-Information Sciences; Kolbe, T.H., König, G., Nagel, C., Eds.; Springer: Berlin/Heidelberg, Germany, 2011; pp. 95–113. 41. Zhang, C.; Liu, Y.; Lin, C.; Zhou, L.; Lin, B.; Che, M. Development of a CityGML application domain extension for simulating the building construction process. ISPRS Int. J. Geo Inf. 2019, 8, 576. [CrossRef] 42. Stouffs, R.; Tauscher, H.; Biljecki, F. Achieving complete and near-lossless conversion from IFC to CityGML. Isprs Int. J. Geo Inf. 2018, 7, 355. [CrossRef] 43. ESRI. The Multipatch Geometry Type an Esri White Paper. Available online: https://www.esri.com/library/whitepapers/pdfs/ multipatch-geometry-type.pdf (accessed on 31 July 2020). 44. Landgate. Landgate Western Australia’s Land Information Authority. Available online: https://www0.landgate.wa.gov.au/ (accessed on 14 February 2021). 45. Australian Government. Australian Government Data.Gov.Au. Available online: https://data.gov.au/ (accessed on 14 February 2021). 46. Safe Software. Powering the Flow of Data. Available online: https://www.safe.com/ (accessed on 4 October 2020). 47. Amirebrahimi, S.; Rajabifard, A.; Mendis, P.; Ngo, T. A data model for integrating GIS and BIM for assessment and 3D visualisation of flood damage to building. In Proceedings of the Locate, Brisbane, Australia, 10–12 March 2015; pp. 78–89. 48. Amirebrahimi, S.; Rajabifard, A.; Mendis, P.; Ngo, T. A BIM-GIS integration method in support of the assessment and 3D visualisation of flood damage to a building. J. Spat. Sci. 2016, 61, 317–350. [CrossRef] 49. Boyes, G.; Ellul, C.; Irwin, D. Exploring BIM for operational integrated asset management-a preliminary study utilising real-world infrastructure data. In Proceedings of the ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Melbourne, Australia, 26–27 October 2017; pp. 49–56. 50. Zhu, J.; Wang, P.; Wang, X. An assessment of paths for transforming IFC to shapefile for integration of BIM and GIS. In Proceedings of the 26th International Conference on Geoinformatics, Kunming, China, 28–30 June 2018; pp. 1–5. 51. Isikdag, U. Towards the Implementation of Building Information Models in Geospatial Context; University of Salford: Salford, UK, 2006. 52. Wikipedia. Tessellation (Computer Graphics). Available online: https://en.wikipedia.org/wiki/Tessellation_(computer_ graphics) (accessed on 14 February 2021). 53. Zhou, X.; Zhao, J.; Wang, J.; Guo, M.; Liu, J.; Shi, H. Towards product-level parallel computing of large-scale building information modeling data using graph theory. Build. Environ. 2020, 169, 106558. [CrossRef] 54. Open CASCADE. Be Free with Your 3D Modeling Kernel. Available online: https://www.opencascade.com/content/open- source-core-technology (accessed on 25 October 2020). 55. Bannat, A.; Bautze, T.; Beetz, M.; Blume, J.; Diepold, K.; Ertelt, C.; Geiger, F.; Gmeiner, T.; Gyger, T.; Knoll, A. Artificial cognition in production systems. IEEE Trans. Autom. Sci. Eng. 2010, 8, 148–174. [CrossRef] 56. Ziemer, S.; Stenz, G. The case for open source software in aeronautics. Aircr. Eng. Aerosp. Technol. 2012, 84, 133–139. [CrossRef] 57. Bedaka, A.K.; Lin, C.-Y. CAD-based robot path planning and simulation using OPEN CASCADE. Procedia Comput. Sci. 2018, 133, 779–785. [CrossRef] 58. Ma, L.; Sacks, R.; Zeibak-Shini, R.; Aryal, A.; Filin, S. Preparation of synthetic as-damaged models for post-earthquake BIM reconstruction research. J. Comput. Civ. Eng. 2015, 30, 04015032. [CrossRef] 59. Xu, Z.; Zhang, L.; Li, H.; Lin, Y.-H.; Yin, S. Combining IFC and 3D tiles to create 3D visualization for building information modeling. Autom. Constr. 2020, 109, 102995. [CrossRef] 60. GitHub. OpensourceBIM/IfcOpenShell-BIMserver-Plugin. Available online: https://github.com/opensourceBIM/IfcOpenShell- BIMserver-plugin (accessed on 17 February 2021). 61. Chen, Y.; Shooraj, E.; Rajabifard, A.; Sabri, S. From IFC to 3D tiles: An integrated open-source solution for visualising BIMs on cesium. ISPRS Int. J. Geo Inf. 2018, 7, 393. [CrossRef] 62. Open CASCADE. Open CASCADE Technology 7.2.0. Available online: https://old.opencascade.com/doc/occt-7.2.0/refman/ html/index.html (accessed on 16 February 2021). 63. Eck, D.J. Introduction to Computer Graphics. Available online: http://math.hws.edu/graphicsbook/ (accessed on 8 September 2020). 64. Zhang, S.; Hou, D.; Wang, C.; Pan, F.; Yan, L. Integrating and managing BIM in 3D web-based GIS for hydraulic and hydropower engineering projects. Autom. Constr. 2020, 112, 103114. [CrossRef] 65. Sacks, R.; Eastma, C.; Lee, G.; Teicholz, P. BIM Handbook: A Guide to Building Information Modeling for Owners, Managers, Designers, Engineers and Contractors, 3rd ed.; John Wiley & Sons: Hoboken, NJ, USA, 2018. 66. BuildingSMART. Available online: https://www.buildingsmart.org/ (accessed on 30 September 2020). 67. BuildingSMART. IFC Specifications Database. Available online: https://technical.buildingsmart.org/standards/ifc/ifc-schema- specifications/ (accessed on 1 May 2020). 68. ESRI. The Multipatch Geometry Type. Available online: https://support.esri.com/en/white-paper/1483 (accessed on 16 February 2021). 69. ESRI. ESRI Shapefile Technical Description. Available online: https://support.esri.com/en/white-paper/279 (accessed on 16 February 2021). Remote Sens. 2021, 13, 1889 26 of 26

70. Zhang, L.; El-Gohary, N.M. Automated IFC-based building information modelling and extraction for supporting value analysis of buildings. Int. J. Constr. Manag. 2018, 20, 269–288. [CrossRef] 71. Rasmussen, M.H.; Pauwels, P.; Lefrançois, M.; Schneider, G.F. Building Topology Ontology. Available online: https://w3c-lbd-cg. github.io/bot/ (accessed on 13 February 2021). 72. IfcWiki. KIT IFC Examples. Available online: http://www.ifcwiki.org/index.php?title=KIT_IFC_Examples (accessed on 25 January 2021). 73. KIO Technology. KIT: FJK-Project-Final. Available online: http://openifcmodel.cs.auckland.ac.nz/Model/Details/123 (accessed on 27 August 2020). 74. Kreveld, M.V.; Nievergelt, J.; Roos, T.; Widmayer, P. Algorithmic Foundations of Geographic Information Systems; Springer: Berlin/Heidelberg, Germany, 1997. 75. Schirra, S. Precision and robustness in geometric computations. In Algorithmic Foundations of Geographic Information Systems; Kreveld, M.V., Nievergelt, J., Roos, T., Widmayer, P., Eds.; Springer: Berlin/Heidelberg, Germany, 1997. 76. Safe Software. FME—The Simple Solution for Complex Integration. Available online: https://www.safe.com/ (accessed on 12 February 2021). 77. Xue, F.; Lu, W.; Chen, Z.; Webster, C.J. From LiDAR point cloud towards digital twin city: Clustering city objects based on Gestalt principles. ISPRS J. Photogramm. Remote Sens. 2020, 167, 418–431. [CrossRef] 78. Uchida, T.; Hasegawa, K.; Li, L.; Adachi, M.; Yamaguchi, H.; Thufail, F.I.; Riyanto, S.; Okamoto, A.; Tanaka, S. Noise-robust transparent visualization of large-scale point clouds acquired by laser scanning. ISPRS J. Photogramm. Remote Sens. 2020, 161, 124–134. [CrossRef] 79. Kim, J.-S.; Li, K.-J. Simpliﬁcation of geometric objects in an indoor space. ISPRS J. Photogramm. Remote Sens. 2019, 147, 146–162. [CrossRef]