Keywords

1 Introduction

The planned maintenance of cultural heritage (CH), in recent years, has been strongly supported by innovations in the digital field and, in particular, by digital models. In fact, the 3D representations of the architectural asset inserted into its context allow to understand the environmental conditions in which it is located, analyse and understand its behaviour and record the data of interventions or restoration activities performed. In this framework, BIM-GIS integration is currently a hot topic, and it is increasingly applied with different methodologies and approaches.

Starting from some previous works [1, 2], in this contribution, we combine the BIM-GIS domains not only by verifying the correctness of the information when the BIM models are imported into the GIS environment but rather by investigating the possibility to simultaneously query a unique database (DB) including information with different levels of detail. This DB is structured according to European cartographic standards and it points to the data of both domains. Thus, the main objective is to view the geometries, query them and, most of all, once the new data have been entered (planned maintenance records, history of activities, etc.), convey them into the DB structured according to the INSPIRE Directive (2007/2/EC, Infrastructure for spatial information in Europe) [3] or CityGML [4] standard with its Level of Detail – LoDs) for the GIS representation and IFC [5] for the BIM one. The Italian National Unification (UNI) norms have also been considered for the DB design. To do this, we had to overcome incompatibilities due to data formats, geometries, standards, diverse LoDs and software, since BIM and GIS were born for different purposes and scale of representation. In this project, the data of the two domains meet in a core database capable of managing dynamic and continuously updated data both of the building and urban-territorial components.

1.1 Case Study

The case study considered for the research is the “Sacred Mounts” (Sacri Monti) system in northern Italy, dating back to the 15th century. In particular, the site of Varallo has been chosen thanks to its multi-dimension in terms of the scale of representation (45 chapels distributed with an urban spatial dislocation), heritage variety, historical relevance, involved stakeholders and operators, as well as the related maintenance complexity [6]. In addition to these peculiarities, it is included in the Main.10.ance project funded by ERDF (European Regional Development Fund) within the Interreg programme. This is a research project (Interreg Italy-Switzerland “MAIN.10.ANCE”, 2019–2021) [7] with the primary objective of creating a tool to support the planned maintenance of the Italian and Swiss Sacri Monti.

The chapels constituting the architectural complex are generally “semi-confined” environments, namely environments which, despite being closed, have a continuous and climatic exchange with the outdoor environment through wooden or metal grates. They are, in fact, spaces with sculptures, frescoes, stuccoes or local handicrafts (Fig. 1) freely opened to tourists.

Fig. 1.
figure 1

The indoor environment of two chapels at the Sacro Monte di Varallo.

Full size image

The most common pathology at the Sacro Monte di Varallo is the presence of humidity that acts, most of the time, both through infiltrations from the roofs and capillary rising from the ground. It affects the state of conservation of the frescoes, sculptures and architecture itself. To this condition, it must also be considered the wooded environmental context and the presence of unfavourable climatic conditions.

Since it is not possible to keep all the chapels and the artefacts contained therein in an optimal state of conservation, given the large number, it is advisable to avoid at least their deterioration. To reach this, various classes of intervention have been foreseen:

  • ordinary and extraordinary maintenance of the roof systems,

  • inspection and routine maintenance of the indoor environments of the chapels,

  • monitoring of the action of humidity.

Precisely for these reasons, many professional figures are involved in the maintenance plan of the Sacri Monti and their coordination with a unique and updated database would undoubtedly be beneficial.

1.2 Related Works

In this context, the integration of data with different levels of detail, which allow multi-scale analysis, becomes indispensable for managing the built heritage, such that of Sacri Monti, and the union of BIM and GIS domains can provide an adequate solution.

Their integration is not a novel idea [8,9,10,11], and it is subject of international benchmarks as GeoBIM [12, 13] where conversion procedures between IFC and CityGML have been investigated. The potentialities for smart cities [14], sustainable environment [15] or the construction industry [16] are just some of the manifold positive implications. However, relying on a unique standard-compliant database that combines the informative levels of both the environments constitutes a relatively new approach. Specifically, [17] proposed to merge BIM and GIS through ontologies in the ACTIVe3D project, but the use of a database constitutes, in this case, a drawback as it would limit the power of ontologies. A very similar project is Chimera [18], where GIS and BIM are organised and viewed in a single environment, with different scales of details and data query and updating is easily accessible.

Despite these various efforts above-mentioned, a lack of a complete workflow for HBIM-GIS integration based on a unique standard-compliant spatial database that store, edit and query information about historical built heritage at different scales for maintenance plans and analysis emerged.

Moreover, the adoption and the reuse of SDIs (Spatial Data Infrastructures), national and regional geoportals, WebGIS solution, spatial ontologies and standards, allow the fruition of information and knowledge in different domain through a user-friendly solution and thanks to standard structure and semantics. In this context, geographic information standards play a crucial role in the scenario of data models’ integration. International standards to represent built heritage have been therefore investigated and applied.

The efforts made ten years ago by the Open Geospatial Web Services (OGC) for CAD-GIS-BIM integration are essential to mention among the BIM-GIS data format integration. It defined the requirements for linking the AEC world’s data models and workflows with those of the geospatial community to make BIM objects available in both the IFC (Industry Foundation Classes) and CityGML (Geography Markup Language) standards. CityGML was developed in 2002, and it became ISO standard in 2008. It is an open data model for the storage and exchange of virtual 3D city models. The development of CityGML aims to reach a standard definition of the basic entities, attributes, and relations of a 3D city model. Several geometries can be associated with the same object to obtain a multi-representation based on time, different reconstruction hypotheses, or different detail levels. This last case is foreseen by the standard, which implements 5 levels of detail (LoD) for a multi-scale representation of cartographic objects. On the other side, the IFC data schema architecture, in the BIM domain, relies on a higher level of detail and defines different conceptual layers, where each schema is assigned to precisely one conceptual layer.

2 Methodology

The methodology described in this paper focuses on the structuring of the DB according to the different LoDs and geographic standards. This spatial databased (DB) has been designed with the free and open-source relational database management system PostgreSQL (with the spatial extension PostGIS) and it is connected to the data derived from the BIM models. In particular, the users involved need to analyse data at different levels: tourists should query only general data and information; the managing body must inspect all the specific entities and files, while the professionals and artisans only their relative parts and details. This multi-level structure is reflected in the database, organised according to the users’ needs and specificities, where LoDs 0–2 are rather contextual data and represents a urban scale, Lod 2–3 define the outdoor environment and architectural component, LoD 4 the indoor elements and LoD 5 the alphanumerical data about maintenance plans and the state of conservation (Fig. 2).

Fig. 2.
figure 2

Methodological workflow.

Full size image

2.1 The Data Model and the Spatial Database Design

After the standards and data model analysis in geographic information, the spatial database has been designed with the free and open-source relational database management system PostgreSQL (version 13, with the graphical interface PgAdmin 4).

Hence, the database structure integrates standards’ entities and properties, follows the CityGML LoDs subdivision and assimilates knowledge useful for restoration, preservation and conservation activities. Cartographic 2D data of the case study selected from the regional geoportal (BDTRE, Territorial Database) [19, 20] have been selected and stored in the DB platform. Subsequently, the BIM model database has been connected. Before the DB implementation, the preliminary phase of the database modelling aimed to choose an appropriate data model to manage the specific application domain data. Different information from many actors, stakeholders, and technicians have been collected to represent the historical building domain correctly and to structure the DB upon the users’ necessities. The successive modelling phases followed the standard workflow with the definition of [21]:

  • the external model;

  • the conceptual model (identification of concepts and relations);

  • the logical model for the implementation of the conceptual model;

  • the internal model (or physical model) for system implementation.

In the conceptual model, the entities to be managed in the database, their attributes, and their associations are formal. For this step, our research considered the INSPIRE and the OGC CityGML data models. The Level of Details have been adopted to design the conceptual model for the spatial database creation.

These LoDs have been related to the macro-categories Outdoor Environment, Building, Immovable and Movable assets and are linked to LoD 5 containing alphanumeric data over maintenance activities of the Sacred Mounts (Fig. 3).

Fig. 3.
figure 3

LoDs subdivision.

Full size image

The IfcBuildingElement connects, through the mass/volumetric unit, the urban data to the architectural ones, namely the CityGML with the IFC. Most of the GIS entities recall the BDTRE, which is INSPIRE compliant, while the data related to the status of conservation refers to UNI 11182:2006 and to a specific glossary elaborated by the partners and taking into account different Italian, Swiss and international terminologies (Fig. 4).

Fig. 4.
figure 4

Simplified schema of entities for each LoD and their relations. A specification of the standard they are derived from is also included.

Full size image

The conceptual model is graphically represented with a diagram (usually a UML) illustrating the entity’s name and the series of attributes associated. To better visualise the entities and their features, we reported a schematic view (Fig. 5) of the model. The logical model is adopted to express the conceptual model in a data structure readable by the machine. In this phase, we defined the connection among data and their values typologies. Depending on the type of data, storage takes place according to integers (Integer), floating-point numbers (Float), character strings (Character Varying) and a set of values to select from a list (Enumeration).

Fig. 5.
figure 5

An example table of part of LoD 1 from the logical model.

Full size image

Finally, the database structure has been developed in PostgreSQL and classes have been populated with spatial and alphanumeric data deriving from different sources (such as building, building elements, roads and vegetation from the regional geoportal) (Fig. 6). Moreover, raster data such as digital surface and terrain models (DSM, DTM) and orthophotos have been added thanks to the “raster2psql” command in PostgreSQL.

Fig. 6.
figure 6

Database tables and raws in PgAdmin.

Full size image

2.2 The BIM Model and Its Relational Database

The realisation of a BIM model involves the automatic creation of a relational database structured according to the IFC standard, useful for the organisation, management and interoperability of AEC (Architecture Engineering Construction) data. The database can be exported and consulted in RDBMS (Relational Database Management System) by connecting to an external data source that uses ODBC (Open DataBase Connectivity) drivers. During ODBC export, through Autodesk Revit [22] it was possible to create tables and adds relations between them using primary keys and reference values. This can be done using the “Export” command or using Revit-DB-Link, a plugin whose advantage is the ability to maintain the correlation between three-dimensional objects and information by allowing bidirectionality of the data through the “Edit and Import” command. In both cases, any changes to the database structure will be overwritten at the next export. The BIM modelling of the Sacro Monte of Varallo has been carried out, in several phases, by different people who have collaborated in this project over time. Each building or portion of the building has been modelled separately, starting from groups of point clouds obtained from the surveys [6, 23]. However, since the objective was to create a database of the entire religious complex, one of the problems that emerged was that of reuniting in a single place, the scattered information regarding the various chapels. In concrete terms, this meant finding a solution to the fragmentation of data and models concerning the Sacro Monte. A possible solution was to resort to a federated model (Fig. 7), in which the entire complex would be recomposed through the combination of all the models, taking advantage of the fact that all of them had always been created from georeferenced point clouds and therefore their relative position in space was correct.

Fig. 7.
figure 7

Federated model into Revit.

Full size image

This strategy turned out to be inadequate because the federation does not imply the possibility of accessing the informative part of the single models, nor therefore to its overall export. On the other hand, the export of individual databases can lead to inconsistencies arising from the potential for ID duplication of elements.

For all these reasons, we opted for an alternative way of BIM data management, given the need to record information within a database with a structure already set, useful to achieve the project objectives.

2.3 Working with VPL (Visual Programming Language)

In order to facilitate the automation of the process of data exchange between the BIM model and its database built in PostgreSQL, it was decided to use the Revit plugin called Dynamo. This tool’s operative logic is that of VPL (Visual Programming Language), which allows, even without any knowledge of traditional programming, to create algorithms that perform specific operations not otherwise provided for in the standard commands of the software in use. This is concretely possible through a step-by-step procedure in which a series of “pre-programmed” elements are placed in sequence to perform a specific function and provided with particular inputs and outputs. Joining together these different elements through logical and operational links, it is possible to create an entirely new sequence of operations, made up of a combination of simple instructions concatenated between them, which has the ultimate goal of carrying out a specific task otherwise not achievable.

This approach has been used for the realisation of an algorithm as a bidirectional information bridge between the modelling software and PostgreSQL.

3 First Results

3.1 GIS Database Connection and Entities Visualisation and Querying

After the database population of objects and their attributes harmonisation, it was possible to connect the data structure in GIS.

Fig. 8.
figure 8

QGIS visualisation of entities attributes and relations of the spatial database.

Full size image

Thanks to the open-source platform QGIS (version 3.16.1) and the spatial extension PotsGIS, the users can visualise, query and edit (with different level of permission) the data related to the Sacred Mount of Varallo.

Figure 8 shows examples of Chapels 14 and 26 queried; in this case, attributes of different tables connected to the “building” could be integrated and updated.

3.2 BIM Data Integration Through Dynamo

The bidirectional data bridge with the VPL methodology previously described is made of a series of Dynamo script, each with a specific function. A script allows the export, extracting from the BIM model a series of parameters related to information necessary for maintenance, such as dimensional data, materials, textual parameters containing information on the last maintenance operations carried out, notes on the peculiar characteristics of certain elements. This information is then used to populate the respective attributes within the database in PostgreSQL in tables previously created and related to the GIS ones. This data transfer is possible by using the “Get Parameter” and Python nodes which, given a series of variable Revit inputs, generates a matrix of commands in SQL (Structured Query Language) and sends it to the database via a connection string. This operation can be repeated to update the BIM data by running an additional script to overwrite the previous content. Finally, a script allows the data import, i.e. reading potential changes from the PostgresSQL database, directly into Dynamo through specific queries and transferring them to Revit parameters based on the proper correspondences, using the “Set Parameter” node (Fig. 9).

Fig. 9.
figure 9

PostgresSQL database connection of one of the BIM models through Dynamo.

Full size image

The final result is a one-click action that the end user will start through Dynamo Player, then depending on the operation performed the output will just be a notice of operation occurred correctly. Through this application and the graphical client PgAdmin, the database administrator will be able to manage in a simplified way the PostgreSQL database and the integration of GIS-BIM data. This methodology allows the continuous updating of the data but, above all, it allows the bidirectionality of the information as Revit-DB-Link keeps unchanged the structure of the database, which is an essential requirement to achieve the project goals. Through the viewer, it is possible to edit the data of the models that will be automatically updated in the DB with time versioning. In fact, a specific field permits to store the date of data insertion and, depending on the kind of data, it will be replaced or simply stored. In particular, the data that must maintain a registration frequency for maintenance purposes would not be overwritten, otherwise the data substitution allows an easiest storage, lowering memory capacity, exploiting also the SQL option to make database backups, restoring a data history.

4 Conclusions and Future Developments

The present paper illustrates the first results of a three-year research project for planned cultural heritage maintenance (both movable and immovable). The project’s first developments are essential to structure an integrated database, following geographic standards such as INSPIRE, CityGML and IFC and containing Sacred Mounts’ data represented in different levels of detail. Hence, thanks to the LoDs subdivision, it is possible to describe and visualise both the architectural assets and the urban-territorial contexts. Moreover, the HBIM models and cartographic data visualised and queried in GIS derived from post-processed data of 3D metric survey performed.

The main innovation consists of creating a unique platform in which it is possible to visualise and query the HBIM model, GIS and acquired data and maintenance parameters. In this way, interoperability problems between DBs are avoided, and data management and updating are simplified. The GIS-BIM database integration has been achieved by using Dynamo, a visual programming language, which made it possible to create a script to connect the DB of the object-oriented software (Revit in this case) with the Developed DB (in PostgreSQL). The existing data from the parametric model are converted and inserted directly into the DB’s table; moreover, BIM parameters could be updated from PostgreSQL.

Ongoing development of this project involves creating a viewer platform in which it could be possible to visualise, query and update all the data stored in the DB. This demonstrator should include a user-friendly dashboard to immediately understand complex and multi-scale data through graphs or charts and the option to modify only specific parameters according to the login type (with different level of permission of access according to different types of users, such as tourists, maintenance technicians, architects, restorers and artisans).