HBIM IN A SEMANTIC 3D GIS DATABASE

This work describes the different attempts and the consequent results derived from the integration of an HBIM model into an already structured spatial database (DB) and its 3D visualisation in a GIS project. This study is connected to the European ResCult (Increasing Res ilience of Cult ural Heritage) project where a DB for multiscale analyses was defined. To test the methodology proposed, the case study of Santa Maria dei Miracoli church in Venice was chosen since it represents a complex architectural heritage piece in a risk zone, it has been subject to a vast restoration intervention in the recent past but a digital documentation and model concerning it was missing. The 3D model of the church was structured in Revit as a HBIM, with the association of different kind of information and data related to the architectural elements by means of ‘shared parameters’ and ‘system families’. This procedure allows to reach an even higher Level of Detail (LOD4), but lead to some issues related to the semantic and software interoperability. To solve these problems the existing DB for the resilience of cultural heritage was extended adding a new entity representing the architectural elements designed in the BIM project. The aim of the test is to understand how the data and attributes inserted in the HBIM are converted and handled when dealing with a GIS DB, stepping from the IFC to the CityGML standard, through the FME software.


INTRODUCTION
According to the latest technological developments in the AEC (Architecture, Engineering, Construction) and Facility Management (FM) sectors, but also thanks to the recent emanation of the italian legislation on public works (UNI 11337 "Gestione digitale dei processi informativi delle costruzioni" 2017) it has been possible to update heritage documentation techniques and concepts and knowledge of information concerning heritage documentation techniques are now available in the standard.In fact, especially in recent years, the BIM (Building Information Modeling) methodology is increasingly being used to manage and digitize also the cultural heritage (CH) assets using the HBIM models (Historical BIM) (Brumana et al., 2013;Oreni et al., 2014;Barazzetti et al., 2015;Inzerillo et al., 2016;Fregonese et al., 2017;Banfi et al., 2018).This emerging widespread practice, also documented by an interesting article that analyses the recent publications on BIM (Volk et al., 2014), showing how the tendency to use the BIM models for the documentation of existing buildings is a constant growth, was also encouraged by the development of new survey techniques (laser scanners, UAVs, ecc.).These technologies provide, in fact, a consistent support for the digital reconstruction of these parametric models (Dore and Murphy, 2012;Quattrini et al. 2015;Chiabrando et al, 2016).The HBIM, therefore, allows the structuring of historical and technical-constructive information in a single virtual 3D model, making it easier to catalogue and consult data for multiple purposes (Oreni et al. 2017;Bruno and Roncella, 2018).Hence, since the BIM was defined by the National BIM Standard-United State Project Committee (NBIMS-US), as a digital representation of the physical and functional characteristics of a building, in addition to being a semantically enriched model for knowledge sharing that can be used to support the decisional process during its entire life cycle (Tang et al., 2010;Eastman et al., 2011), underlining its role in the building management (Sabol, 2008), it is clear as this methodology can be effectively applied also to CH where, the management and maintenance aspect certainly plays a key role.Thanks to these considerations, the HBIM can actually be considered an adequate solution for cataloguing the information of the assets on the architectural/building scale.Now it is therefore necessary to understand how these HBIM models can be properly integrated with those produced in a GIS environment and then, how the two different data structures can be harmonized and be interoperable with each other, in order to create a single complex database involving multi-scale data and details allowing real multi-scale analyses, thanks to the completeness of the data itself.In this framework, an attempt was made to integrate a HBIM model of a XV century venetian church into a semantic geospatial database within the model structure proposed by the European ResCult project.

(H)BIM/GIS integration
BIM and GIS integration has become a common topic, however, until few years ago there were still several incompatibilities between BIM and GIS systems in various aspects.In fact, these two formats hold different kinds of information at different level of detailswhich leads to most of the interoperability issues when it comes the data conversion between them.During these years, numerous attempts have been made trying to accomplish the BIM/GIS integration in a variety of ways (Fosu et al., 2015;Ma and Ren, 2017).Many studies and researches have been carried out with various solutions, and even if most of them focus on the BIM integration (not HBIM), the resulting methods can also be applied to the HBIM.One of the first approaches proposed by the researchers, in order to overcome the single weaknesses of BIM and GIS, dates back to ten years ago with the work of the Open Geospatial Web Services on CAD-GIS-BIM integration, which defined requirements for bridging the data models and workflows of the AEC world with those of the geospatial community (Lapierre and Cote, 2008), to make available the BIM objects in both the IFC (Industry Foundation Classes) and CityGML (Geography Markup Language) standards.CityGML is the dominant standard for 3D GIS, while the IFC is more commonly related with BIM: a GIS and BIM datasets differ fundamentally with respect to their semantics, geometry and level of detail (Ohori et al., 2017).CityGML structure is shaped for cities and contextual features and its Level of Detail (LOD) is not enough accurate for building, as it includes LOD0 for regional and landscape level, LOD1 for regional level, LOD2 for urban context, LOD3 for city district, exterior architectural model and landmark and finally the LOD4 for interior architectural model (Tolmer et al., 2013), even if it is not as specific as the same LOD level for BIM models.On the other side, in the AEC sector, the IFC open standard data, used for information exchange is based on the concept of LOD (Level of Development), different from the one of CityGML.In this case, in fact, the LOD is used to monitor the design process, the reliability of the information associated to the drawing and the different phases of the building construction, namely it is not referred to the level of detail of the representation, which is related to the scale of visualization.Starting from these standards, some researchers tried to develop an extension of CityGML to get semantic IFC data into a GIS context (Van Berlo and De Laat, 2011) or to use the IFC standard to convert both GIS and BIM data (Shen and Yuan, 2010).Anyway, even if there are a lot of studies on the BIM/GIS integration, still few researches on the data management in the integration of HBIM models and GIS can be found (Dore and Murphy, 2012;Tobiàs, 2016;Vacca et al., 2018) and very few studies have been conducted on the use of ontologies for HBIM models (Quattrini et al., 2017).It has also to be considered that, as in this case we are facing with existing building, it is fundamental not only to think about the integration between the standards, but also the georeferencing accuracy of the existing building in a 3D GIS environment Even if the matter of the integration of the HBIM georeferenced model in the GIS environment seems to be solved, the problem of how to create an effective dialogue between the two standards (IFC and CityGML) and the structuring of models has not been fully developed yet.In fact, the integration of a large amount of data describing a complex system such as a city or territory with an adequate Level of Detail that goes up to the architectural scale for CH is an indispensable prerogative.On the basis of the aforementioned reasons, the ResCult database was used to test a new methodology for the integration of HBIM models into a GIS project, maintaining all the related data.This procedure would help different kind of analyses, both for the cultural heritage itself and the urban context in which it is located, enabling, for example, risk and vulnerability assessments, in addition to provide an effective supporting decision tool for emergency operations.A particular focus was placed to understand how all the different kind of information, associated to the single element in the HBIM, are managed when bridging this model in the GIS environment.Some previous researches (Vacca et al., 2018) demonstrated that the issue is not about transferring the geometries, but the data related to them.Therefore, the data were associated to the instances in several ways (shared and family parameters, georeferencing coordinates), in order to set up a methodology that could be applied indifferently and widely, regardless of how the model is built.

THE 3D GIS DATABASE
The database chosen to test the methodology is the one proposed for the European ResCult project (https://www.rescultproject.eu/).Since it is semantically structured and standardised, already organized by different Level of Detail (LOD, which allows multiscale analyses including both territorial and architectural data, and planned for a GIS visualization, it provides a proper starting point to rehearse the various steps.

The ResCult project
The aim of the ResCult (Increasing Resilience of Cultural Heritage) project is to provide a supporting decision tool for the Civil Protection or other emergency bodies during the disaster management phases with the purpose of reducing the CH losses, aside from lessen and prevent the disaster impacts.To reach this objective, an interoperable database named EID (European Interoperable Database) was designed with a LOD subdivision (Fig. 1) (Chiabrando et al., 2018).(Colucci et al., 2018).According to these standards, a designing process has been used for EID modelling from real word to DB implementation: starting from the external world, the model was formalized in the conceptual and logical model.Afterwards, the DB structure was developed with the objectrelational database management system (ORDBMS) PostgreSQL and the spatial extension tool PostGIS was used to populate the EID with geometries and spatial data.For the project, three case studies were selected to test the DB and to provide a comprehensive framework to represent, with different LOD and representation scales, different conditions both for the CH itself (movable or immovable) and the documentation availability (historical cartography, drawings, georeferenced maps, point clouds…).These case studies have been chosen also on the basis of the related hazard (flood, earthquake or fire) and they are, respectively, Santa Maria dei Miracoli Church in Venice, San Nicola Church in Tolentino and the contemporary architectural building hosting the museum of Prehistory in Quinson.For the case studies of Quinson and Tolentino, a survey campaign was first carried out using geomatics techniques (TLS, UAVs ...), allowing the creation of point clouds for both the Museum and the Basilica, in order to support the following 3D modeling activities.The 3D models generated reached respectively a Level of Detail 2 for the Basilica of Tolentino and 3 for the Museum of Prehistory, with reference to the CityGML classification.

THE CASE STUDY
Since most of the cultural heritage is characterized by a substantial presence of historical, archival, iconographical and, above all, graphical documentation (plans, elevations and sections) not digitized or in any case not three-dimensional, it was decided to choose also a case study that falls into this category.Santa Maria dei Miracoli Church in Venice represents a typical example for which digital documentation is missing; it has been selected to develop and test a method that could be applied to entire architectural heritage in these conditions.Furthermore, since this procedure relies on already existing documentation, it can be considered a challenging test.Hence, the LOD2, 3 and 4 of Santa Maria model have been based on some restoration project drawings.Whereas, for the construction of LOD0 and 1 the geospatial datasets available on the Geoportal of the Veneto Region, relating to the Municipality of Venice, were used.

Santa Maria dei Miracoli church
As mentioned, the case study is located in the Municipality of Venice.Its peculiarity consists in having one of the side façade directly overlooking the water of a canal and in being totally covered with polychrome marbles, both externally and internally (Fig. 2).This church was built around the end of the fifteenth century and it represents an example of a historical-ecclesiastical building, whose vulnerability to the flood risk affecting this lagoon city can be assessed.Modeling this cultural asset, associating it with a series of information and subsequently inserting it into a geospatial database can therefore provide a project to be consulted by the Civil Protection or other bodies, which will be able to query the geometries and choose the best operating procedures to adopt in case of risk.

From LOD 0 to 2
Once all the data had been collected, a project was created, viewable in QGIS (GIS open source software) and structured in different LODs (each containing different information depending on the scale of detail) with the consequent insertion of such data into the DB.The LOD0 (Fig. 3) consists of the DTM (Digital Terrain Model), the road network, the hydrography and the buildings from the Regional Technical Map (1:10k) in 2D.
The LOD1 shows the church and its context with the 'elevation' data (2,5D) so they can be visualised in 3D thanks to this attribute of the geometries.Finally, the LOD2 (Fig. 4) represents the 3D model of the church with roofs, designed in a CAD environment and then imported.Since this project is based on a spatial DB, the Reference System set up is the UTM WGS84 33N.
In particular, this project can be downloaded from the ResCult website, where it is possible to login in the EID Cultural Heritage interface (an open source GIS-based interface connected to the EID to visualise the Cultural Heritage related data with the different layers and geometries) and view the three case studies.

LOD 3 and 4: the HBIM model
For 3D modeling plans, elevations and sections published by the architects Mario Piana and Wolfgang Wolters in the book Santa Maria dei Miracoli a Venezia.La storia, la fabbrica, i restauri were used.These drawings were scanned, imported and scaled in a CAD environment.At first, in fact, we proceeded with their digitalization, using only closed polylines, as they are easily recognizable as multipatches in a GIS environment.Following the same logic, we then proceeded with modeling in three dimensions using 3D polylines and solids.Although the compatibility and interoperability with the GIS environment was satisfied, this operating procedure was immediately discarded as it was noticeably slow and not interoperable with BIM environment.It was therefore decided to use an object-oriented software, in which the construction of the geometries is more expeditious and there is also the possibility of associating to the architectural objects a good number of additional information and specifications.For this purpose, Revit by Autodesk was used.
Although it is a proprietary software, it allows to export in the IFC standard format, compatible with several other programs.The LOD3 was therefore created starting from LOD2 and adding all the openings, both windows and doors.Subsequently, in the LOD4 the external architectural details (such as pilasters, friezes, moldings and decorative elements) were added, as well as all the internal structures (altar, crypt, choir...) (Fig. 5).
Before the integration into the GIS environment, a further step was carried out for the LOD4: additional information were associated to the single architectural objects, directly in the Revit software, in order to evaluate whether and how these were maintained, once the model is imported into the aforesaid GIS environment.
Hence, three types of information were added to each element, using three different data recording methods: -geographical position; -materials within the 'system families'; -year of restoration with 'shared parameters' and 'project parameters'.Firstly, the LOD4 was assigned with the information of its geographical position which, unfortunately, could not be inherited from the cloud itself, unlike what happens for HBIM models produced starting from a georeferenced point cloud.
Then the position has been set by defining it based on the "Internet location service" (latitude and longitude).At this point the icon was moved manually to the position occupied by the Church of Santa Maria dei Miracoli (Fig. 6).In this way, the Revit software automatically assigns the information relating to the geographical position, expressing it in terms of geographical coordinates.
Secondly, for each element previously modelled, the information relating to its material has been added by compiling the parameters of the "system families".Therefore, based on the descriptions of historical documents, various ad hoc materials were created such as "Pavonazzetto toscano marble", "Pietra d'Istria", to reddish "Porfido antico antico", a greenish stone named "Serpentino" and associated to the elements.Finally, information on the various restoration activities carried out over the years was also found out, a fundamental data for any asset maintenance plan.Therefore, it was decided to associate to each single component also this data, using "shared parameters", subsequently made as "project parameters" (Fig. 7).
Figure 7. Restoration dating as a 'project parameter'.
Since all the related information were added in the HBIM, it was possible to proceed to exporting the file for the GIS integration.

THE METHODOLOGY: FROM HBIM TO GIS
In the nowadays scenario of 3D built heritage models, the generation and the visualization (specially with Open Source GIS solutions) of 3D geometries, connected to a database, implicate still some interoperability problems among the tools available today.
In this case study, after the creation of the HBIM, in order to populate the ResCult 3D GIS DB, it was necessary to convert the IFC geometries and their related parameters in different interoperable formats.

From IFC to shapefile
Two different methodologies were used in order test the integration and visualization of the BIM models in the GIS environment, according to the different two LOD and to the attributes information necessary in the database for each geometry.
On one side, starting from the LOD3, since the IFC model had to be converted in a Multipatch geometry (composed by points, polygons and polylines), the following steps have been implemented: the model was converted in .dxf to be readable into the CAD environment in which it was exported as .igsfile (IGES).This file was afterwards converted in polygonal mesh and exported again in .dxfusing 3DReshaper (by Technodigit); finally, the model was imported in ArcScene by ESRI, where the software recognises it as Multipatch geometry.
After these steps, it was possible to visualise the geometries into the structured DB.The main problem of this method consists in the impossibility to maintain and to copy in the GIS environment the attributes and the parameters (as well as materials, dimensions, name …) set in the BIM project.In fact, querying the database attributes table in GIS it appears empty.On the other side, for the LOD4 importation in the 3D DB, a different conversion methodology was applied.
In order to populate the spatial DB both with geometries and attributes information of the church, the direct conversion of the Revit (IFC) file into the ESRI shapefile (.shp) was chosen.To make possible this conversion the FME (Feature Manipulation Engine) software (by Safe Software), a platform that streamlines the translation of spatial data between geometric and digital formats, was used (Fig. 8).
In addition, FME has a free plug-in (FME Exporter for Revit) for Autodesk Revit, which allows to export BIM models into a ".rvz" format, essentially a compressed .ifcfile.
The .rvz format is compliant with the FME Workbench, the software used to achieve the aims above mentioned.Before beginning the conversion process in the FME Workbench, the FME Data Inspector was used in order to evaluate how the data deriving from the Revit conversion in .rvzwere read.
In the Data Inspector (Fig. 9) was possible to visualise all the attributes of the different families' elements in which the church was segmented in the BIM project.Due to the known issues to represent cultural heritage in BIM environment (HBIM), it was necessary to schematise the geometries of the church using seven families.The Data Inspector recognized windows, walls, generic object, slabs, doors, roofs, pillars and a category named "Building" which identifies the coordinate system of the model.Despite the multitude of elements and architectural parts that compose cultural building such as churches, for the present research the focus was testing interoperable issues knowing that structured ontologies featured by semantic approach have been proposed (Acierno et al, 2017).
Figure 9. .rvzfile in the FME Data Inspector and its elements subdivision and information.
The proposed method required the creation of three FME Workspace for each step necessary to integrate the HBIM model into the 3D GIS database.These are: the conversion in a GIS readable format, the merging of the above-mentioned elements in a unique geometry (composed by macro-elements) and its incorporation in the existing DB structure.
In the first step, using FME Workbench, the .rvzfile with its elements were set as "Reader" (input file) of the process model, and the shapefile format was set as "Writer" (output file).
In order to maintain the features information of the model, it was necessary to insert between the .rvzand the .shpfile a series of Trasformers.After many attempts three main functions were added: the "AttributeExposer", to force the feature information in the new table of the shapefile; the "AttributeManager", to modify, to copy and to rename attributes and the "AttributeRemover", to select which information has to be visualised in the output file.Finally, running the Workspace process it was possible to export the GIS files, one for each elements type (BIM categories).
Figure 10 shows the first workflow.
The second Workspace was created in order to merge the eightdifferent shapefile in a unique GIS file containing all the spatial elements with their features' information.The output of the process is a Multipatch file representing the "Reader" of the third Workspace.

From shapefile to PostGIS
The third FME Workspace was used in order to bridge the shapefile with the spatial DB and populate it with the 3D model converted.
After having set the PostGIS (Obe and Hsu, 2011) data format as "Writer", it was necessary to enable the connection with the PostgreSQL ResCult DB, setting the database name, the port, the IP, the schema and an entity, as it will be showed in the next paragraph.
To complete the workflow, two Transformers were used, both able to act on the geometries.Specifically: "GeometryFilter" and "GeometryCoercer".The first one made possible to know all the typologies of the shapefile and to copy completely and unaltered the corresponding attributes.
The second one allowed to change the geometries type.In this case, all the geometries were converted into the "fme_composite_surface" type, that is compliant with the Multipatch geometry and with the MultipolygonZ geometry of PostGIS.The 3D model is composed of 936 geometries, but three of these were not converted.Querying the shapefiles in FME Data Inspector, was clarified that they were the features containing the geographic information without geometries, which in the first workspace were named "Building".

HBIM INTEGRATION IN THE 3D GIS DB
Since we are dealing with an existing DB not set for a the IFC standard, after the conversion processes and the geometries definition, it was necessary to revise the DB structure.In fact, starting from the DB conceptual model, in order to properly implement the spatial DB and to guarantee the increased Level Of Detail achieved, a new object with its relations and attributes was added.

THE EID extension
Starting from the ResCult EID CM a new extension was developed (Fig. 11).In order to link the LOD4 elements, designed in BIM as families, whit the entity Building from the UML schema of the CityGML Building module (OGC, 2012), a new object was added.Thus, the table buelements was created importing the 3D model with the FME software in PostGIS ( § 4.2).In this way was defined a specific entity for the 3D geometries designed in HBIM project and converted in GIS.
The spatial entity buelements inherits the Revit parameters as part of its attributes (Fig. 12).They are name, object_type, tag (the identifier "ID" in the BIM project), category, dimension, years and IFC material.Moreover, to verify that the geometry type was imported correctly in FME the column wkt_geometry (wellknown text) was added, this attribute describes the geometry as text and coordinates.
Figure 12.Attributes of the new buelement entity.

HBIM families to Getty ATT Vocabulary standard
As in the BIM models there is no provision for semantics related to cultural heritage and no appropriate vocabularies to define historical architectural elements, it was decided to consider a standard for semantics.This choice could allow effective standard compliant attributes for the The attribute elementstype represents the identification of the Architectural Element type according to the Art and Architecture Thesaurus (AAT) from the Getty Vocabularies standard, in order to represent the elements of the buildings.The use of the Getty thesaurus, compliant with the CIDOC-CRM standard, makes possible the identification of the elements connected with different families' subdivision in BIM.
The part of the AAT considered to obtain a shared definition of the architectural parts in which the church was segmented includes the sub-terms: Object Facet -Components -Components by specific context -Architectural Elements.
After that, Structural Elements, Opening and Opening Components and Surface Elements sub-classes were considered.
In particular, for the Opening And Opening Components subclass Openings By Forms was selected for Windows and Doors families; Surface Elements (ArchitecturalElements) were used to identify the Slabs Family and, finally, Enclosing Structural Elements were referred to Dome, Walls, Roofs and Pillars (Fig. 13).
The Dome class was associated to the BIM family named "Generic Model".This is due to the designing process of a HBIM model, where some elements (as well as dome) cannot be represented in a BIM software as "pre-set" families.The "Generic Model" entities correspond to a new BIM family which identifies the geometries not belonging to the "System Families".The attribute type to define these vocabularies was created in PostgreSQL as a code-list "enumeration" named rescult.elements_type,a list of every typology of elements according to the AAT (Fig. 14).Thanks to this list, in the database project, querying the geometries it is possible to know for each BIM family element the corresponding typology according to the Getty standard.Finally, the table BuildingPart was linked to the new Buelements adding the attribute "relatedtobuildingpart", creating in PostgreSQL a Costraint-Foreign Key able to connect the ID of the existing table to the attribute of the new one.

GIS 3D VISUALISATION OF LOD3 AND LOD4 MODEL AND RELEATED ISSUES
The visualisation of the 3D geometries into an Open Source GIS software was another important aim of the present research.As well as for the ResCult project, the QGIS software was considered.Thanks to the new tool named "3Dmap", developed for the lasts released of the software (3.0 and followings), was possible to visualise, query and categorize the models.
After the successfull population of the DB, the LOD3 model was added to the map and was categorized in the seven different elements (roofs, slabs, windows, walls, columns, dome and other architectural elements).Thanks to the relations of the EID and to the new links between the entities Building, BuildingPart and Buelements querying the geometries and the related attribute table is possible to know all the useful parameters of the church (at every Level Of Detail) which derived both from the BIM project and from the EID structure.
As regard the visualisation of the LOD4, some other interoperability problems were spotted due both to the complexity of the model and for the use of Open Source solution.
At the firsts attempts, after filling the DB and setting the 3D visualisation mode at the buelement geometry, using the "3Dmap" tool of QGIS 3.6, the Open Source software crashed.However, thanks to the use of an Open Source software, was possible to find a solution among the QGIS developers community.
For the present research, to finally visualise and query the LOD4, the QGIS Master version was installed through OSGeo4W (a binary distribution of a broad set of open source geospatial software for Windows environments).
Adding the buelement shapefile it was possible to see the higher level of detail reached for the Venice case study (both for the inside and outside geometries) in its content.Moreover, thanks to the other relations present in the ResCult EID it is possible to connect the building and its feature to the different Risk analysis parameters (Fig. 15).

CONCLUSIONS
Thanks to the test work presented in this paper, focusing on a method for the integration of a HBIM model into a semantic 3D DB an interaction between these two domains has been made possible, avoiding data loss, regardless of their typology.In fact, whether they are inserted in the HBIM as parameters of a "system family" or as "shared" and "project parameters", they are maintained in the workflow and enabled to be queried in the GIS environment.is also shown that with the use of some open source software good results can be achieved anyway, even if there is still a bottleneck when bridging the data, as FME is a proprietary software.The use of open source software besides gives the possibility to solve relatively quickly bugs or other issues, as the one of the 3D visualization, thanks to the QGIS developers team.Moreover, the most used softwares for the BIM projects are still commercial ones and the open source offer is not fully developed yet (BIMx, Digital project, BIM 360), though the spread of the IFC standard allows the user to choose different software solutions.Furthermore, the methodology here proposed permits to exploit the great potential of these two domains, letting real and effective multiscale analyses with an adequate level of detail useful for several purposes.
Finally, for future developments it would be interesting to investigate the relation and the compatibility between the LODevelopment of the BIM domain and the LODetail of the CityGML standard.This element could allow a further integration between these two fields and help an even better semantic approach.

Figure 1 .
Figure 1.Level of Detail for CityGML standard.The designing of the DB considered the will to set up a new methodology able to link and connect the CH with the Risk and Hazard analysis, as well as create a DB interoperable as much as possible.The EID Conceptual Model (CM) is structured considering the CityGML standard and three INSPIRE themes (Protected site, Buildings and Natural Risk Zone from the Annex I and III)(Colucci et al., 2018).According to these standards, a designing process has been used for EID modelling from real word to DB implementation: starting from the external world, the model was formalized in the conceptual and logical model.Afterwards, the DB structure was developed with the objectrelational database management system (ORDBMS) PostgreSQL and the spatial extension tool PostGIS was used to populate the EID with geometries and spatial data.For the project, three case studies were selected to test the DB and to provide a comprehensive framework to represent, with different LOD and representation scales, different conditions both for the CH itself (movable or immovable) and the documentation availability (historical cartography, drawings, georeferenced maps, point clouds…).These case studies have been chosen also on the basis of the related hazard (flood, earthquake or fire) and they are, respectively, Santa Maria dei Miracoli Church in Venice, San Nicola Church in Tolentino and the contemporary architectural building hosting the museum of Prehistory in Quinson.For the case studies of Quinson and Tolentino, a survey campaign was first carried out using geomatics techniques (TLS, UAVs ...), allowing the creation of point clouds for both the Museum and the Basilica, in order to support the following 3D modeling activities.The 3D models generated reached respectively a Level of Detail 2 for the Basilica of Tolentino and 3 for the Museum of Prehistory, with reference to the CityGML classification.

Figure 2 .
Figure 2. Santa Maria dei Miracoli church with the marble covering both outside and inside.

Figure 11 .
Figure 11.Simplified schema of proposed EID CM extension.After having structured the new internal and logical model for the DB extension, the implementation was designed using PgAdmin, the Open Source administration and development platform for PostgreSQL.Since the different BIM elements are parts of the building, an extension of the BuildingPart of INSPIRE Consolidated UML Model was considered to represent them.The BuildingPart INSPIRE "featureType" Class is part of the Annex III Theme in the Building3D schema; it is identified as a "sub-division of a Building that might be considered itself as a