INVESTIGATING INTEGRATION CAPABILITIES BETWEEN IFC AND CITYGML LOD 3 FOR 3 D CITY MODELLING

Smart cities are applied to an increasing number of application fields. This evolution though urges data collection and integration, hence major issues arise that need to be tackled. One of the most important challenges is the heterogeneity of collected data, especially if those data derive from different standards and vary in terms of geometry, topology and semantics. Another key challenge is the efficient analysis and visualization of spatial data, which due to the complexity of the physical reality in modern world, 2D GIS struggles to cope with. So, in order to facilitate data analysis and enhance the role of smart cities, the 3 dimension needs to be implemented. Standards such as CityGML and IFC fulfill that necessity but they present major differences in their schemas that render their integration a challenging task. This paper focuses on addressing those differences, examining the up to date research work and investigates an alternative methodology in order to bridge the gap between those Standards. Within this framework, a generic IFC model is generated and converted to a CityGML Model, which is validated and evaluated on its geometrical correctness and semantical coherence. General results as well as future research considerations are presented.


INTRODUCTION 1.1 Why 3D City Models?
The generation of complex 3D City Models allows for a more sophisticated understanding of the objects and their spatial interactions with their surrounding environment.The type and amount of information that can be implemented rises drastically, a condition that promotes the necessity of generating semantically enriched 3D Models and highlights the demand for collecting massively huge data.This demand is handled either by (i) the collection of big data, namely a considerable amount of data collected by various sources (Hashem and Anuar, 2016) or (ii) by the knowledge via Internet of Things (IoT), specifically the connectivity of a number of objects to the Internet at an extraordinary rate (Paul et al., 2016).That collected amount of data needs to be properly stored, edited and visualized, issues that GIS science is able to deal with.The massive amount of free data that are available globally, has enhanced the capabilities of addressing critical issues in an integrated and functional way.Hence, GIS is vital for addressing spatial issues and their surrounding context, analyze the proposed solutions and highlight the optimal solution for each scenario in a dynamic environment (Tao, W., et al., 2013).That way, a prominent utilization of a 3D City Model seems mandatory.Semantic 3D city models (Chaturvedi, 2016) join the spatial information with the physical entities in cities and allow an interaction via spatiosemantic queries.They also provide a description of the physical and built environment (Kolbe, 2009).More specifically, 3D models are capable of representing entities such as Buildings, Transportation Networks, elements of a real city such as Bridges, Tunnels and City furniture (Traffic signs, Lights), Vegetation and Water Bodies.Those entities can be semantically enriched with a variety of attributes that vivify a virtual 3D City Model.Furthermore, 3D City Models can be created, edited and visualized in different scales, from basic shapes up to fully detailed both internally and externally real-looking objects.Another significant advantage is the tracking of their life-cycle * Corresponding author and the constant monitoring of the project.Within that context, the role of an object is enhanced by adding specific equipment that depends on the project's purpose.Furthermore, a 3D City Model can be implemented to the environment of a 3D Smart City aiming to integrate descriptive and geographic information in order to enhance its efficiency and sustainability (Batty, et al., 2012) and more specifically in application fields such as transportation, mobility, energy demand, security, urban planning, healthcare and environmental protection.

3D City Models: Interoperability options
However, it is mandatory to label the interoperability issues that derive from different 3D Models in order to be rendered valid for 3D City Modelling.To be more precise, the data that are applied for generating the models could vary in terms of how they handle the stored information, not only on global but also on domestic or even local level.In fact, not only the data, but also the modelling processes could differ from time to time, concluding that different modelling approaches produce different results (Dimopoulou, et al., 2014).The environment of "Smart Cities" should be able to overcome such issues, in order not only to achieve the maximum interoperability between different systems, but also speed up and broaden the techniques of generating 3D Models.The Open Geospatial Consortium (OGC) provides standards that are freely available and intend to tackle interoperability issues among others.A couple of potential standards are CityGML (Kolbe et al., 2012) and Building Information Models (Eastman, 1999).Following the direction of enhancing the interoperability between 3D Models, OGC has initiated the project "Future City Pilot Phase 1".This project aims to demonstrate how the combined use of CityGML and Industry Foundation Classes (IFC) data can provide information that enhances the quality of life of citizens living in the cities (OGC, 2016).The aforementioned Standards present significant dissimilarities in geometry, topology and semantics rendering their integration capabilities quite challenging.
The objective of this paper is to investigate the conversion of a generic IFC Model to a LoD 3 CityGML Model and propose a methodology that generates a model compliant with the prerequisites of the CityGML Standard in terms of geometry validation, topology accuracy and semantic coherence.Section 2 presents a brief overview of the two Standards, as well as the related research work in the field of integration and interoperability.Section 3 describes the methodology and the conversion process in detail, followed by the validation and evaluation of the generated CityGML model.Lastly, Section 4 presents the key findings of the paper and proposes topics of interest for future research work.

Overview of CityGML
CityGML is an open standard that allows the storage and exchange of virtual 3D city models.It does not focus solely on the geometric representation of the objects, but delves into their semantic and thematic properties (OGC, 2012, pp. 9-11).CityGML defines the geometries of the objects, as well as the interactions of each object with the surrounding environment in terms of topology.It represents a variety of thematic city objects such as Buildings, Bridges, Tunnels, Transportation Networks, City Furniture, Vegetation, Land Uses and Water Bodies (Gröger and Plümer, 2012).Each of those objects can be semantically enriched with attributes such as class, function and usage with an input that is supported by the CityGML Standard.Also, CityGML supports 5 Levels of Detail (LoD 0-4), where objects are represented in more detail accordingly to the increasing LoD.Finally, as an open standard it provides the capability of adding extensions (ADEs) based on the requirements and the goals of the 3D Model (OGC, 2012).

Overview of IFC
IFC is a data format that is used to describe, exchange, share and define how information should be stored throughout the building industry's life-cycle (El-Mekawy et. al., 2012).It is the international standard for Building Information Modelling (BIM) and is used to create a model of a facility that contains all its information and relationships among its parts and facilitates their sharing among the project members.It can hold data for geometry, quantities, facility management and equipment for various professions.IFC is comprised of a set of schemas and each schema belong to one IFC layer.The content of the schema represents a specific concept of the facility (equipment, geometry, costs).IFC has a full range of geometry classes (solids, surfaces, curves, etc.) and a full range of topology classes (shell, point, path, etc.).Finally, IFC supports the Level of Development (LoD) from 100 up to 500.For the purposes of this paper, the entities investigated were: IFC Building, IFC WallStandardCase, IFC Slab, IFC Window and IFC Door (buildingSMART, 2013).

Correlation of the two Standards
The interoperability between IFC and CityGML is considered essential since it could address issues such as cost reduction that is also translated in a time-efficient management of projects, advanced data analysis and a unified view of the details of an area (El-Mekawy, 2010).Nagel and Kolbe (2007) and El-Mekawy et al. (2012) highlighted the most relevant relationships in IFC Models that can be applied in geospatial analysis (Fig. 1)

State of the art in 3D data integration
Based on the premise that a well-structured 3D City Model leads to more effective smart cities, contributing to understanding and managing the real-world objects more efficiently and the fact that interoperability of the 3D Models is essential, data integration is elemental for a desegregated solution towards a specific issue.Nagel (2007) pinpoints the differences in the geometrical approach of each Standard and generates CityGML Model up to LoD 2. Simultaneously, addresses the limitations and highlights the need for conversion of IFC Models to semantically, geometrically and topologically concrete CityGML Models for higher LoDs.Isikdag and Zlatanova (2009) investigate a framework for automatic transformations between CityGML and BIM.More specifically, the proposed framework the framework produces CityGML models up to LoD 4 and encapsulates three critical steps: firstly the semantic mapping between IFC and CityGML then the conversion of geometry and finally preserve the suitable information for each LoD.Another methodological approach that supports semantic mapping prior to geometric conversion and generates a valid CityGML LoD 3 model from IFC, while highlighting the necessity for an extension to LoD 4 has been documented by Donkers (2013;Donkers et al., 2015).A 3D Conversion Framework is presented by the Technical University of Berlin (Nagel et al., 2009b), in which certain limitations such as formal grammar and the combination of

Available conversion software tools
There are numerous conversion tools available that convert IFC to CityGML such as BIMserver, KIT IFCExplorer and Feature Manipulation Engine (FME) by Safe Software (Donkers, 2012).BIMserver and IFCExplorer convert successfully the IFC Geometry but lack in semantic mapping (Donkers, 2013).Feature Manipulation Engine (FME) applies Extract Transform Load (ETL) as a two-ways conversion tool (Liu, 2017)

METHODOLOGY
In order to implement the aforementioned conversion, the IFC generic model was imported in FME Workbench in order to generate the conversion algorithm.The methodology proposed is categorized as follows: Firstly, the geometrical adjustment of the model takes place, in order to be compatible with the CityGML specification for LoD 3 Buildings.Secondly, semantic information based on the CityGML Standard is added and then descriptive information defined by the CityGML Standard is implemented.Afterwards, the generated model is validated in Val3Dity and finally, it is evaluated in terms of complexity.The workflow of the methodology is presented in fig. 3.

Geometrical Adjustment of the model
A key characteristic of an IFC Model is that each surface appears as a solid in contrast with CityGML LoD 3 specification.So, in order to achieve the geometrical adjustment of the model the following process was implemented.The first step of the procedure was to render the IFC geometries compatible with CityGML LoD 3 geometries.More specifically, the interior shell of the building had to be removed.As soon as the exterior shell of the building is extracted, the geometry of the model had to be adjusted, in order to fit the b-rep specification of GML.Therefore, the produced geometries fit the gml: MultiSurface geometry specification of CityGML.

Extraction of geometry:
It should be mentioned that each IFC Entity had to be manipulated separately due to the complexity of the schema.The algorithm created for the extraction of the geometry for IFC slab is presented in fig. 5. Firstly, with the implementation of the GeometryPartExtractor transformer, the IFC Slabs are extracted (Fig. 6).Then, the GeometryCoercer transformer converts the solid surface to a composite surface in order to be de-aggregated in its structural elements.
The International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Volume XLII-4/W7, 2017 12th 3D Geoinfo Conference 2017, 26-27 October 2017, Melbourne, Australia The algorithm to the IFC WallStandardCase (fig.7) follows the same principles with the IFC Slab at this stage of the process.
Figure 7: IFC WallStandardCase For the IFC Door, the GeometryExtraction is less complicated, since the model is consisted of only one door.A challenging task is the extraction of the IFC Windows that has to be filtered by attribute characteristics in order to be handled separately on latter stages.Afterwards, the GeometryPart extractor is implemented and the extracted geometry is de-aggregated in order to be converted in a MultiSurface geometry type.

Geometry Refinement:
After the phase of the extraction, the geometry should be refined to fit the requirements of CityGML.The part of the algorithm responsible for the refinement of the IFC Slab is presented in fig.8. GroundSurface and RoofSurface respectively.The same algorithm is applied to the IFC WallStandardCase, IFC Window and IFC Door in order to convert the geometries to MultiSurfaces.

Semantic Mapping of the Model and Descriptive information
In order to achieve the semantic mapping of the CityGML, the IFC Building is utilized as input and isconverted to CityGML Building.The GeometryRemover transformer is used and then by implementing the AttributeCreator and CityGMLGeometrySetter, the Building is assigned a specific gml_id in order to render its connection with the Boundarysurfaces feasible.For the conversion to a CityGML RoofSurface, the part of the algorithm in fig. 9 is applied.The CityGMLGeometrySetter set the Geometry type to LoD3MultiSurface and the feature role to boundedby.It should be noted at this point, that the aforementioned transformer does not accept as valid input geometries that do not meet the b-rep specifications.The AttributeCreator is used to connect the surfaces with the CityGML Building by matching the gml_parent_id of RoofSurface and GroundSurface with the gml_id of the Building.

Validation of the produced CityGML Model
The generated CityGML Model is inserted in the Val3dity software, a validation tool of 3D GML primitives, created by TU Delft in Netherlands.A double inspection is executed with regard to the geometrical accuracy of the model and more specifically to the MultiSurfaces and CompositeSurfaces.
The model is inspected in terms semantics and also in FZK Viewer.The output is considered satisfactory, since the semantic hierarchy that is structured by CityGML in LoD 3 is preserved (Fig. 12).
Figure 12: Semantic validation of the generated CityGML Model Lastly, the final CityGML Model is visualized in FME Data Inspector, as well as in FZK Viewer (Fig. 13).
Figure 13: Visualisation of the CityGML Model in FME Data Inspector and in FZK Viewer, with and without RoofSurface

Evaluation of the process
The aforementioned conversion algorithm transforms an IFC generic Model to a LoD3 CityGML Model that is consisted of BoundarySurfaces and Openings (Windows, Doors).However, the following features of CityGML that can be included in a LoD 3 Model were not investigated: Firstly, the model did not include OuterBuildingInstallations.Secondly, there are topological issues that arise during the conversion of a model that shares common boundaries with another model.Furthermore, there are cases of converted building models that are composed of different structural elements that differ in terms of floors or type of roofs and should be implemented as BuildingParts in CityGML.Additionally, the conversion in FME Workbench is a manual process that must be altered based on the needs of the project.Finally, it should be noted that CityGML Standard follows a specific topological structure.More specifically, each object of the physical space should be represented by one geometrical object.This object should be used as reference from other objects or complicated geometries that are defined and shaped based on that object.In order to implement topology, CityGML utilizes XML Xlinks.However, within the context of the specific paper it is not investigated during the conversion.For example, the generated LoD 3 MultiSurfaces could be utilized for the modelling of the building as LoD3Solid.

CONCLUSIONS & FUTURE RESEARCH
In terms of results and conclusions it can be stated that the conversion of a generic IFC 2x3 Model to a LoD 3 CityGML Model consisted of Boundary Surfaces and Openings was successful.This paper aims to present a methodology that tackles firstly the geometrical compliance of the Model with CityGML, followed by the semantic mapping and the extension of the model with descriptive information.The generated CityGML Model is validated on the accuracy of the geometry and the concreteness of the semantic hierarchy with positive results.The overall procedure can be characterized as time-efficient and aims to improve the existing converting tools.However, it should be noted that the methodology did not investigate a fully complex LoD 3 CityGML Model and presents certain limitations compared to other methodologies.Nevertheless, this paper constitutes a basis for further research by implementing specific modelling and conversion tools in order to produce valid CityGML models and a holistically methodological approach towards data integration and management that generates, converts and manages a CityGML model in a 3D spatial database.
As for future research, an IFC Model does not only consist of structural elements such as Walls, Doors, Columns, etc., but also includes information about the activity during the construction of the model, the financial cost of construction etc. (Hijazi, Ehlers, Zlatanova, & Isikdag, 2009).It is essential that that information can be preserved during the conversion of an IFC Model to CityGML.Hence, a future plan intends to investigate the most efficient way of preserving that information, either utilizing the Generic feature or implementing an ADE.As soon as the aforementioned issues are addressed, the conversion of an IFC Model to a LoD 4 CityGML Model will be explored based on the presented tools.Additionally, a semi-automatic conversion procedure should be investigated, in order to tackle the challenges that arise in more complicated models.Since IFC does not support the multiscale modelling of CityGML, but contains a high level of information in one level of detail, the generation of CityGML models with different LoDs from one IFC Model will be examined.A required part of that procedure is the implementation of generic algorithms, potential via software API for more IFC Instances.It is also of paramount importance to investigate the conversion of CityGML to IFC in order to fully understand the integration capabilities of the two Standards, a task that constitutes a future goal of this research project.Finally, the integration of IFC and CityGML can be further examined via the utilization of 3D Modelling softwares, such as CityEngine and Trimble SketchUp in order to investigate alternative conversion methodologies in terms of efficiency.

Figure 1 :
Figure 1: UML Diagram of the most relevant IFC Entities forCityGML(Nagel & Kolbe, 2007) However, the different schemas as well as the handle of geometries and semantics in each Standard renders the integration quite complex.Concretely, IFC focuses on the building environment and provides great detail in terms of structural elements such as Tiles and Walls and equipment such as MEP.On the contrary, CityGML describes the Buildings as observed and used.The differences regarding the semantical objects of a building are pinpointed byNagel et al. (2009)  and highlighted in fig 2.Moreover, IFC focuses solely on the building, while CityGML represents a more complex City Model that is compiled of LandUse, Transportation Objects, Vegetation, Water Bodies, etc. Finally, unlike CityGML, IFC does not support the multi-scale modelling, since its objects are represented in one Level of Detail(Gröger & Plümer, 2012).

Figure 2 :
Figure 2: Semantics of IFC and CityGML(Nagel, Stadler &  Kolbe, 2009) geometry and semantics among different objects are highlighted.De Laat and van Berlo (2010) propose a conversion of an IFC model to a LoD 4 CityGML Model via the open-source Building Information Modelserver and address the need of generating lower LoDs by implementing the aforementioned tool.

Figure 3 :
Figure 3: Workflow of the methodology

Figure 4 :
Figure 4: IFC Model in FME Data Inspector

Figure 8 :
Figure 8: Geometry refinement of IFC Slab The extracted geometries are inserted in the GeometryCoercer Transformer, which allows the conversion of the geometries in features.The surfaces are converted from Solids to MultiSurfaces.Then, by implementing the AttributeFilter Transformer, the surfaces are categorized based on their attributes to Floor and Roof, which represent the CityGML

Figure 8 :
Figure 8: Algorithm of semantic mapping of RoofSurface The result produced by CityGML RoofSurface and GroundSurface is demonstrated in fig.10.

Figure 10 :
Figure 10: Generated CityGML GroundSurface and RoofSurface.The semantic mapping in the BoundarySurfaces is more complicated because the WallSurfaces should be matched with the corresponding Openings.In figure 11, the semantic mapping of Windows is presented.The FeatureMerger transformer ensures that each opening is placed on the appropriate WallSurface.The previously geometrically adjusted surfaces of the Windows serve the role of the Requestor, while the corresponding WallSufaces serve the role of the Supplier.The same algorithm was created for the successful conversion of the Door.The CityGMLGeometrySetter transformers ensure the geometry type of the openings which is LoD3MultiSurface and the feature role Opening.
and supports the reading of IFC as well as writing in CityGML.The converters from FME that are available up to today, are not capable of converting IFC Models to valid CityGML, even though there is an output in gml format.Various errors such as the geometrical inaccuracy and semantical incoherence of boundary surfaces as structured by CityGML are addressed in the generation of a LoD 2 CityGML model.Additionally, the CityGML output of the conversion in LoD 3 contains thickness in the WallSurfaces, while in LoD 4 both geometries and semantics do not follow the CityGML Standard.However, FME constitutes a fairly flexible and user-friendly tool that handles successfully numerous data formats.This paper aims to properly utilize FME and present a methodology that firstly adjusts the geometry of the model and then regulates the semantics refinement in order to produce a valid LoD 3 CityGML model from a generic IFC model.