## 5 Conclusions and Future Perspectives  
Through the methodology proposed, a good level of interoperability is ensured, accomplishing the two levels of conceptual interoperability investigated. In fact, it is possible to convert an object-oriented model into the standard.GML format, through the IFC, keeping all the information related to geometry  
Figure 21: QGIS 3D visualisation of the.GML file of the church and its context. Figure 20: The 3D model CityGML file of the church visualised in the FZK Viewer. and semantics, even those typical of the HBIM models inserted, most of the time, as _shared/project parameters_. Furthermore, the geo-referencing of the model is maintained in both the standards analysed and within both the solutions proposed, the commercial and the open source ones. The first methodological phase (HBIM-GIS integration using a recent function in a GIS commercial solution) was aimed on importing a BIM model into the GIS environment. This test considered the native data format and represented the technical interoperability issue. The second test (HBIM-GIS integration considering standard formats and models solutions) considered a standard data model for exchange purposes. These solutions were chosen in order to allow a representation of the church and the city with a multi-scale approach (using CityGML Level of Detail). This method could allow the connection of the entire 3D model with other geographic information systems, SDIs, databases and linguistic and domain ontologies; in this way, interoperability (lexical, data, knowledge model and object) and sharing of information are ensured. In the GIS environment, moreover, the BIM model and its data information could be related to other parameters performing risk analyses, comparing entities with raster data as well as risk maps (such as the Italian seismic earthquake zoning map). The potentiality of importing such a detailed 3D model into GIS regards the possibility to create a spatial/geo-database connecting all the entities included in the project (such as buildings, roads, services and other cartographic elements, vulnerability parameters and hazard maps). A bottleneck of this methodology, using the standard data format, is the lack of a workflow where the attributes of the HBIM model are automatically maintained or managed after the conversion, without the need for manual insertion of transformers in FME (e.g., \"AttributeExposer\", \"Attribute Manager\", \"AttributeRemover\"). If we solely consider the visualization of the output file, it has been highlighted that on the one hand the commercial software ArcGIS Pro does not support the.GML format yet, on the other, the open source solution allows the model to be viewed, but a further theming is manually required. Finally, once the compliance test for the.GML format has been performed in the CityGML schema validator, the FME output file is not validated, therefore further studies should be needed. Future developments of this research could be: the test of the further conversion of the.GML format of a historic building into INSPIRE via FME, based on the latest research in the state-of-art; a validation of the XML schema through various tests and validator, as the one developed by the TU Delft GeoBIM research group and recently tested in the framework of the GeoBIM benchmark 2019 [40]; insertion of data related to seismic vulnerability or risk/hazard parameters directly into the HBIM model to allow more specific analyses in the GIS environment; validate semantic interoperability with a consolidated structure such as ontologies for cultural heritage [41], ultimately it could be useful to deepen and investigate the other levels of interoperability that, in this study, have not been taken into account (syntactic and pragmatic). Conceptualization, E.C. and F.M; methodology, E.C., V.D.R., F.M. and G.R. ; software, V.D.R. and G.R. ; validation, E.C. ; formal analysis, F.M. ; investigation, V.D.R. and G.R. ; resources, A.L. ; data curation, E.C. and F.M.