## 3 Interoperability Issues
### HBIM and GIS Integration: Semantic and Technical Interoperability
#### 3.3.2. HBIM-GIS Integration Considering Standard Formats and Model Solutions  
As mentioned before, for the second interoperability validation, the conversion between IFC and CityGML standards was considered. Referring to these two international standards, a methodology based on the use of conversion data format software was chosen, thus FME (Feature Manipulation Engine by Safe Software, version 2019.1) was selected. It allows to create various workspaces, in which it is possible to specify the format of the input and output data and to use a special combination of transformers that let the data structure to be edited according to different needs. In the FME project created for the present research, the input file (\"Reader\") is the.IFC, the LoD 3 model exported from Revit. As output file, the.GML data format, compliant with the CityGML standard is set. The JFC file was set following the IFC hierarchical structure (explained in Section 3.1). In this regard, it was necessary to insert two \"Readers\": the first as \"Single Merged Feature Type\" and the second as \"Individual Feature Type\". The first one is required to read all the IFC features and to populate the table containing the \"id\", \"parent_id\" and \"feature_type\" field. The \"BinaryEncoder\" and \"VariableSetter\" transformers were used to code and to associate the values with the corresponding variable (Figure 13). Since the second \"Reader\" is composed by both geometric and non-geometric data, the \"GeometryRemover\" transformer was used in order to remove geometries to non-geometric data (as \"IfcBuilding\"). Then the \"AttributeRenamer\", which allows the manual association of the \"Id\" attributes of.IFC to those of.GML, was applied (Figure 14). After that, for each geometric data (\"IfcWindow\", \"IfcBuildingElementProxy\", \"IfcDoor\", \"IfcRoof\", \"IfcSlab\", \"IfcWallStandardCase\" and \"IfcWall\") the same combination of transformers has been adopted. For example, the workspace created for the \"IfcWindow\" feature is shown (Figure 15). Figure 14. Conversion to remove geometry from \"IfcBuilding\". Figure 15. Example of workflow applied for windows, from “IfcWindow” to CityGML. Since in the IFC standard geometries are composed of \"solids\", while they are represented as \"multisurfaces\" in CityGML, it was necessary to create an ad hoc transformer, called \"ConvertGeometry\" (Figure 16). This tranformer has allowed the correct conversion of the geometries. Each custom transformer requires the creation of an additional workspace, containing a combination of transformers. In this case, \"GeometryPartExtractor\" to extract the geometries from the features, \"GeometryCoercer\" to make them \"composite_surface\" and \"Deaggregator\" to disaggregate them on several levels were used. Subsequently, the \"Aggregator\" was employed to combine geometries into \"multisurfaces\" and the \"GeometryRefiner\" to perform \"refinements\" on features' geometry. After the conversion of the geometries, the \"BinaryEncoder\" and \"VariableRetriever\" were added in order to read the pre-set \"_parent_id\" variable and to attribute the corresponding \"_parent_type\". With \"AttributeRenamer\" the \"ifc_unique_id\" field was renamed in \"gml_id\". This step is useful to create a correspondence between the IFC and CityGML standards. Successively, the hierarchy of each feature was tested using the \"Tester\" transformer. Then, a new ad hoc transformer named \"GetGrandParentID\" (Figure 17) was created, \"_parent_id\" field has been codified and the corresponding value has been assigned in the \"_gparent_id\" one, in turn decoded through the \"BinaryDecoder\". In this way, it is possible to establish the correspondence between the two standards.