IFC TO CITYGML CONVERSION ALGORITHM BASED ON GEOMETRY AND SEMANTIC MAPPING

Geographic information system (GIS) is known traditionally for the modelling of two-dimensional (2D) geospatial analysis and therefore present information about the extensive spatial framework. On the other hand, building information modelling (BIM) is digital representation of building life cycle. The increasing use of both BIM and GIS simultaneously because of their mutual relationship, as well as their similarities, has resulted in more relationships between both worlds, therefore the need for their integration. A significant purpose of these similarities is importing BIM data into GIS to significantly assist in different designrelated issues. However, currently this is challenging due to the diversity between the two worlds which includes diversity in coordinate systems, three-dimensional (3D) geometry representation, and semantic mismatch. This paper describes an algorithm for the conversion of IFC data to CityGML in order to achieve the set goal of sharing information between BIM and GIS domains. The implementation of the programme developed using python was validated using an IFC model (block HO2) of a student’s hostel, Kolej Tun Fatima (KTF). The conversion is based on geometric and semantic information mapping and the use of 3D affine transformation of IFC data from local coordinate system (LCS) to CityGML world coordinate system (WCS) (EPSG:4236). In order to bridge the gap between the two data exchange formats of BIM and GIS, we conducted geometry and semantic mapping. In this paper, we limited the conversion of the IFC model on level of details 2 (LOD2). The conversion will serve as a bridge toward the development of a software that will perform the conversion to create a strong synergy between the two domains for purpose of sharing information.


INTRODUCTION
Geographic information system (GIS) is known for the modelling of the environment and conduct two-dimensional (2D) analysis of a small and larger areas. GIS models have become more detailed and have commenced to include detailed models of individual buildings in the form of building information modelling (BIM) which is basically referred to as the digital representation of building life cycle. There is an absolute similarity between the two domains in respect 3D modelling that motivated researchers across the world that developed significant interest to integrate the domains.
Based on that, it is only natural that the BIM field is currently intensifying its standards and software to enhance environmental information like infrastructure. The use of BIM is rapidly going to existing in GIS datasets that contains the environmental information. Moreover, the architecture, engineering, and construction (AEC) industry developed interest to incorporate the features surrounding the building or another structure into the framework. As a result, the two domains are rapidly merging, modelling the same things, even though the data is expressed and stored in quite different ways.
While there is significant similarity between the GIS and BIM domains when it comes to city modelling, each domain has its own focus and features. The BIM domain focused on information on the design and construction of building sites, and as a result, it contains an extremely comprehensive and semantically rich information about all the physical parts that make up a single structure as it is created or constructed.
Meanwhile, GIS depicts information on the environment as built at various moments in time, resulting in less detailed but often updated datasets traversing large areas. The integration of data from both domains is widely regarded as advantageous and a critical step forward for future 3D city modelling due to the similarity in the characteristics that are represented in both domains, as well as their distinct strengths and limitations (Atazadeh et al.,2017). This connection can save time and money by eliminating the need for duplicate modelling and allowing fresh data flows in both ways. More specific BIM data may feed more general GIS data in this way, and GIS data can give context that BIM data often lacks. Many concepts can be realised by exploring the integration of BIM and GIS data, for example, by utilizing BIM data, more detailed and comprehensive 3D city models may be created, smart city principles can reason about geography, buildings, and municipal infrastructure and diverse level of detail (LOD) and object's life cycles can be taking care of by spatial analysis (Arroyo Ohori et al.,2018).
Regardless of the strong interest of integrating the two domains, the modelling frameworks, software tools, and open standards used by BIM and GIS, like IFC and CityGML respectively, keep the two domains distinct (Amirebrahimi et al.,2016). As a result, BIM and GIS datasets significantly vary in view of geometry, semantics, reference systems, and LOD. There is no single optimum or consistent conversion method (Sani & Rahman, 2018), technique, or tool between the two models due to the various modelling techniques used by each. Even though researchers and practitioners have explored how to share information effectively and efficiently between BIM and GIS and how to address all the differences from different perspectives. Sharing 3D information among different users throughout the life cycle of urban and environmental procedures, namely, plan, design, and construction to maintenance, remains difficult (if not impracticable), particularly when trying to address all the differences from different viewpoints. Moreover, the purpose of the integration determines the approach, for example in this paper our aim is to harness the rich information in BIM into GIS for spatial analysis, therefore the need for unidirectional approach i.e., from BIM to GIS through their data exchange formats (IFC and CityGML). As stated in the previous section there is no standard method or specification to conduct the conversion and the few conversions were carried out using some existing tools like feature manipulation engine (FME) etc. The objective of this paper is to describe an algorithm for the conversion of IFC and CityGML for effective sharing of information between BIM and GIS. The remainder part of the paper is structured as follows; section 2 an overview on the open standards for BIM and GIS, Section 3 The conversion experiment, Section 4 Discussion and Conclusion, Section 5 Recommendations.

OVERVIEW ON OPEN STANDARDS FOR BIM AND GIS
Research on the sharing of BIM and GIS data frequently focus on the two most prominent open standards in the two domains due to a larger availability of information, simplicity of analysis, and practical considerations, such as CityGML which is an OGC standard for 3D GIS, on another hand IFC which is an open standard and data exchange format developed by the buildingSMART for BIM used in the AEC industry. IFC models represent the physical features of structures in detail, but CityGML models reflect the whole city in a simpler format that may be used for exchange, sharing of information, and geographic studies such as estimating solar potential and energy usage. The two modelling patterns expressed by IFC and CityGML are both widely utilised in their respective fields and are indicative of BIM and GIS data in general.

Industry Foundation Classes (IFC)
Standardization is a critical component of data interoperability. The current main BIM standard in the AEC sector is IFC, which was created by buildingSMART. It is an object-based format; therefore, buildings and their components are represented as objects. Building relationships and hierarchies are defined, resulting in a semantically rich definition. In order to define the relationships and the building hierarchy, as previously mentioned, IFC, adopt the EXPRESS data modelling language. IFC is used by the AEC sector to model fundamental building processes (such as design, construction, and maintenance) allowing information to be shared among many players across the building industry. The IFC standard comprises of the following components: semantic, encoding, topology, appearance, and the geometry the 3D model representation for the two standards solely rely on these components (Salheb et al., 2020). These components are significant for the conversion from IFC to CityGML.

City Geography Markup Language (CityGML)
CityGML is developed by the special interest group (SIG) of open geospatial consortium (OGC) , it is an open standard data model designed to exchange and store 3D data models of 3D cities and landscapes based on geography markup language (GML) in an XML format (Gröger et al., 2012). CityGML is an application schema for GML3 which is a standard for the exchange and sharing of 2D and 3D geospatial information over the internet (Yao et al., 2018). Also, the CityGML identifies the relevant attributes and unique relations of a 3D city. Yao et al presented that the CityGML is of great important for the simplification and maintenance of 3D city model (sustainable 3D city models) (Yao et al., 2018). Unlike IFC, CityGML represent 3D objects using only B-Rep.
Like IFC, CityGML model identifies building model in 5 Levels of Detail (LoDs) ranging from LoD0 being the lowest to LoD4 being the highest (i.e., LoD0, LoD1, LoD2, LoD3, and LoD4). The LoDs are define as follows LoD0 is a footprint on 2D of the building model, LoD1 is an extrusion of the building footprint in form of a block in 3D with flat roof, while LoD2 is block model which has differentiated and CityGML building models represents building in 5 LODs but still, CityGML is less complete and mature as in BIM, even in LoD4 being the highest LODs for both models.

3D Geometry representation
This paper concentrates on the representation of location and shape ifcLocalPlacement and ifcProductDefinitionShape respectively of IFC building Model elements. As mentioned in the previous section, three standards for representing geometry objects in 3D model were identified in IFC2x3 and IFC4 which is the most recent version of IFC, these includes constructive solid geometry (CSG), swept solid (SS), and boundary representation (B-Rep). IFC uses one or the combination of the three to represents 3D objects. Unlike IFC, CityGML represents 3D objects using only B-Rep. SS uses a 2D profile to describe a 3D geometry coupled with its sweeping direction. CSG utilizes the outcome of a series of Boolean operations such as: union, difference, and intersection of primitive objects to represent 3D model (object). These primitive objects could be cones, cylinder, pyramids etc. are important information for the creation of a model and stored in a GCS tree. Finally, B-rep represents a 3D object using its bounding surfaces and is mainly used for the representation of complex objects such as doors and windows.

Related work on IFC to CityGML conversion
Investigations into the significance of integrating BIM (rich and details building model) with GIS particularly at the data level (IFC and CityGML) is what attract some research towards automating conversion process from IFC to CityGML. The automation of the conversion from IFC to CityGML efficiently enhanced the manual process by minimising human intervention and the use of some existing software packages that have some limitations towards converting both geometry semantic information. Deng et al., (2016) were among the few that researched and presented their work on the conversion process, basically their research focused more on realizing a mapping structure (both exterior and interior structures) at LOD 4 with semantics information, their work mainly targeted a particular used case. However, in this paper we presented an algorithm that can convert any IFC file to the destination CityGML file (both geometry and semantics information). In future, the enhancement of this algorithm will lead to the development of a software that can be used for sharing of information between BIM and GIS (using IFC to CityGML) with little or no human intervention.

Geometry
In order to extract the geometric information of a building elements, two categories of information are significant, and should be considered, these include: the placement of the element (IfcLocalPlacement) and its representation (IfcProductDefinitionShape). The placement defines the location of an element, and the representation defines the shape Figure1: IFC attribute structure of that element. Figure 1 shows the attribute structure of an IFC geometry. The process comprises of the following.
First, as earlier stated in this section, the framework basically relies on the ifcPlacement and the ifcProductDefinationshape of the building elements (ifcWindow, ifcDoor etc). The following were adopted for the geometric transformation process (as summarized): The geometric data of the building objects in question was extracted from the IFC file.
Secondly, the local coordinates of the objects' vertices were computed using the following equation (1).

…………… (1)
Where: (Wx,Wy,Wz):-represent the direction Vector of sweeping A: -represent the sweeping distance. Thirdly, is the computation and the transformation of the LCS to WCS using a transformation matrix equation as presented by (Wu & Hsieh, 2007) in the final step, CityGML object model is generated. The model was generated after the local coordinate was successfully transformed to the world coordinate.
The IFC geometry was represented basically in one or combination of the following methods of 3D geometry representation, these includes swept solid (SS), boundary representation (Brep) and constructive solid geometry (CSG) (Arroyo Ohori et al., 2018). In order to achieve our set goal, the geometry harmonization was initialised to convert an element from IFC to the destination CityGML. This harmonisation could be from SS to Brep, CSG to Brep and or Brep to Brep (depending on the method used to create the IFC model) that is when converting IFC to CityGML. The conversion process from IFC to CityGML is shown in figure 1 where the geometric IFC entity types were transformed into suitable geometry representations. Conventional and geometrical curves, surfaces, and volumes were translated into specific boundary representations. IFC converts all placements and transformations into 3D affine transformations specified by a matrix, which may subsequently be applied iteratively to each object as needed as shown in the equation 2. with respect to (x-axis, y-axis and z-axis) A script was created to export a series of files including all necessary objects included in the IFC files using the standard version of IfcOpenShell (with its Open CASCADE kernel) in this approach. The subclasses of IfcBuildingElement, according to the IFC standard constitute some basic functional building elements, were examined for this purpose: such as IfcDoor, IfcWindow, IfcRoof, IfcWallStandardCase, IfcColumn, IfcBeam, IfcSlab. This is summarised in an algorithm shown in figure 3.
As a result, every geometry in each IFC file automatically extracted to an efficiently parsable format, although the most important semantic information in the original input file was preserved, only the mapping of the semantic information was considered.

Coordinates Positioning for 3D models
IFC files are 3D models in a planar surface, therefore do not contain geographic information. The files are often placed using the LCS, mostly used in the computer 3D design tools, in this case the origin of the file is at (0,0,0). WCS, the WCS is to define the location of object on the earth, considering the 3D spherical surface. The datum base on the spheroid, the angular unit of measure and the prime meridian were all included. However, the longitude and latitude used in the WCS can locate any point on the earth's surface, the points are not uniform measure of distances, therefore it is only along the equator you find the distance represented by one degree of latitude equals to that one degree of longitude. Thus, different WCS are strictly developed for different regions to stand for the representation of distance for the latitude and longitude.
The transformation of the 3D LCS model to a 3D WCS model in the host CityGML, is significant to carefully think and choose the right coordinate systems, so also the process for the translation of the coordinates to WCS. At this point the absolute select projected coordinates system was selected, where the location of points on a curve surface was converted to the locations of the points on a flat plane which is absolutely needed in the 3D coordinate projection. The coordinate projection supports the transformation tool to move the 3D models into the correct location on the map for various tools (i.e., IFC in LCS to CityGML in WCS) which can be verified easily using Google Earth based on world geodetic coordinate system (EPSG:4236). The process for the coordinate transformation from LCS to WCS is for georeferencing the IFC data model created from the source IFC file. The model reference point was produced by iterating through all the points in the model and picking the least value for all of them.

Semantic mapping between IFC and CityGML
One of the challenges of BIM and GIS integration at the level is semantic mismatch. In order to solve this issue, the semantic mapping between the two data formats that is IFC and CityGML generated, different principles were used to generate the semantics mapping between the IFC and CityGML. It was also assessed based on the existing classes that belongs to IFC, and the prospect of matching same in CityGML class, involving geometry and semantics such as the work of Saran et al., (2018) where the notations and classes of the two data models (IFC and CityGML) were match together to generate the mapping between them. Furthermore, several applications in software that deals with this kind of problems, most particularly in FZK Viewer (Salheb et al., 2020) remarkably assist in matching the semantic object's terminologies and the classes employed in the data models as shown table 1. Number of elements on different LODs in IFC model were converted to CityGML without their semantics being changed (El-Mekawy et al., 2012). Furthermore, the same table was used to depict the semantic mapping between IFC and CityGML as shown in figure 2. Even though, semantic mismatch is inevitable in the process of converting from IFC to CityGML, but the semantic mapping presented in this paper minimises the semantic information mismatch. Based on what we have in figure 2, we can see the direction of flow from the source IFC to the destination CityGML after being mapped.

The algorithm
The main implementation parts consist of a programme which is a scrip file written in python. After the compilation, the programme will convert a source file in IFC to the destination file in CityGML. The basic module used in the programme; are "numpy" to perform mathematical operation like find the minimum value or subtracting arrays, "GUID" to automatically generate unique IDs etc.

The steps for the IFC to CityGML conversion
Step 1: Load IFC model (.ifc).
Step 2: Initialize IfcOpenShell library to convert the implicit. geometry (Open CASCADE) in IFC into explicit geometry.
Step 5: Recreate the 3D model based on CityGML data schema.
Step 6: Georeferenced the model using 3D affine transformation.
Other software packages adapted in order to achieve our set goal includes the following: i. Autodesk Revit: -is a BIM software used to develop the BIM model and later converted to IFC. ii. Solibri and usBIM.viewer+: -is software to view, check and carried out analysis on the IFC model based on geometry and semantics. iii. FZK viewer: -to view the converted CityGML model.
The developed algorithm was tested with a real-world dataset, that is an IFC dataset of a model in one of the students' hostels within Universiti Teknologi Malaysia (UTM) Johor that is Kolej Tun Fatima (KTF) HO2 was used for the validation. Even though, the data is in LOD4, but we were abled to convert only Figure 3. Workflow for the conversion of IFC to CityGML The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLVI-4/W3-2021 Joint International Conference Geospatial Asia-Europe 2021 and GeoAdvances 2021, 5-6 October 2021, online in LOD2. We tested the conversion from IFC to CityGML using different models starting with the simple IFC building model to complex IFC models.

Filtering
Regards to building model, IFC models are practically richer, details and comprehensive than CityGML Therefore, it is not all the rich information in IFC that need to be converted at once, the purpose for the conversion determines the required contents to be converted. In this paper we considered the basic elements and ignored others. The filtering process is automatically done by considering the implementation process. The programme converts features that have a certain tag (for example, building). If a feature tag is not included in the programme, it will be automatically excluded from the conversion process.

DISCUSSION, CONCLUSION, AND RECOMMENDATIONS
We have presented an algorithm created to convert IFC data to CityGML geometrically and semantically. The approach was developed through an investigation into the two most prominent data models (IFC and CityGML) and importance of information sharing toward the current trends of the development of smart cities and digital twin across the globe. Based on our findings, the approach transformed a controlled IFC dataset into a semantically correct CityGML format that can be read by all GIS applications. Furthermore, the GIS (CityGML) models which is the outcome of conversion spatially referenced using a WCS. IFC dataset comprises of some attributes, when converted to CityGML these attributes were equally converted and maintained, even though some were missing but limited in number. The result of the conversion is shown in figure 4.
Based on the few experiments we have conducted on different IFC models on both geometry and semantics data, in some complex IFC models that contents several elements, therefore it takes time to convert (conversion process). This required some modifications to speed up the process and to reduce the file size in CityGML (XML file).
Therefore, the findings in this research includes, some IFC elements like IfcBeam, IfcColumn, IfcRailing, IfcStair are all referred to as BuildingInstallation in CityGML there is need for more clear definition of this rule in order to maintain easy and clear rules for the conversion.
Even though, there are clear rules for modelling beam (IfcBeam) and column (IfcColumn) in IFC, but there is need for more definition of the elements on "stand-alone" (beam and column) and beam and column that form part of the wall thus, there is need for clear definition. Finally, by making some adjustments and refinements on both IFC and CityGML standards, the conversion of IFC and CityGML would be improved.
In this research certain limitations need to be addressed in the near future work to perfect the conversion algorithm. For example, is the need to check and repair the input geometry quality before the conversion. On the semantic parts, in order minimises the sematic miss match in the conversion process, there is need to improve the semantic mapping which will result in better geometric conversion. In CityGML other city object like vegetation, city furniture, water bodies etc. need to be taking into consideration in future in order to improve our conversion algorithm.