Cultural heritage (CH) assets should take advantage of developments in the AEC (architecture, engineering, and construction) Industry [1
]. The needs of refurbishment, management, and conservation of large monumental buildings over time encourage the adoption of practices and tools that are appropriate for new construction as well as CH assets.
In this respect, the most suitable tool is Building Information Modeling (BIM), intended as “information modelling and information management […], a process for creating and managing information on a construction project across the project lifecycle” [2
]. Thanks to its capability of archiving and organizing all the information about the building, reference data on the 3D model, and integrate geometric and information models, BIM allows an in-depth knowledge of the building and helps to optimize renovation, management, maintenance, and conservation processes.
Planned conservation [3
] is nowadays considered the approach to CH management. It can be equated with preventive maintenance [4
], and focuses on a deep knowledge of the building and on the accurate evaluation of weaknesses, possible risks/damages, and environmental hazards. Documenting the asset’s health condition, keeping track of the interventions that occurred, and of the recovered/current/possible damages, makes it possible to prevent worse problems by scheduling future works. The translation of such approach in the BIM environment would be of great help to schedule activities and safeguard assets.
BIM adoption is expanding worldwide, due to normative requirements [5
] as well as to the improvements brought to the construction process. However, despite the undeniable pros it could provide to CH buildings [8
], such as support for documentation and management [11
], energy [14
], and structural analyses [15
] or virtual reconstruction [17
], BIM is seldom applied by agencies in charge of conservation and is basically still a research topic [19
The limited implementation of Historic BIMs (HBIMs) can be attributed, on the one hand, to the lack of clear, precise, and shared regulatory references and guidelines, associated with the lack of knowledge and training in information technology of most CH professionals; on the other hand, to problems in applying BIM to heritage assets. In fact, even buildings of the same type and epochs have peculiar features and singularities (historical, constructive, architectural, artistic) that make them unique. Currently no commercial software packages are capable of fulfilling all the requirements of 3D modeling and semantic data management [22
] for such buildings. Three-dimensional modeling is particularly binding due to the parametric nature of BIM software, which contrasts with the complexity and irregularity of historical buildings [23
]. Semantic data is generally managed by the integrated database provided by the main BIM commercial software, and the architectural elements are organized according to standard classifications [25
]. These standard classifications conflict with CH needs because historical assets are more heterogeneous and complex, have a different hierarchical organization, and require multi-temporal and multi-disciplinary analyses, which involve different professionals and comply with different standards and formats. Therefore HBIMs should ensure easy usability and flexibility, to meet the needs of all the practitioners involved, who belong to different disciplines, have different digital skills, and are used to different working processes [27
The research presented here investigates the management of non-geometrical information in HBIM, overcoming the limitations of the databases integrated in the software packages, and meeting the needs of flexibility, easy usability, and information sharing. The research implements a procedure tailored for CH information management, to support documentation, ordinary management, and planned conservation of historic buildings. The implemented HBIM was conceived as an information system at architectural scale and is based on a standalone specific-designed database linked to the 3D model of the asset, built with BIM software. The database is accessible both with a developed desktop application, which acts as a plug-in for the BIM software, and through a web interface, implemented to ensure data sharing and easy usability by skilled and unskilled users.
The system, thanks to the external database, allows the management of multi-temporal and multidisciplinary information in a coordinated and flexible way. On the other hand, the link with the 3D BIM model, allows users to visualize 3D information and benefit from the capabilities provided by BIM tools. The system is highly customizable for adaptation to different assets and, as far as its application to real cases is concerned, is compliant with the most adopted standard on planned conservation in Italy [3
The paper is organized as follow: Section 2
provides the background on HBIM adoption, with particular attention to semantic information management; Section 3
describes in detail the implemented system, passing by 3D modeling, semantic breaking down of the assets, database design, as well as system architecture and capabilities; and Section 4
illustrates the application of the system to two case studies in Italy: The Cathedral of Parma and the Ducal Palace of Mantua. Finally, the results and future developments are debated.
2. Background and Related Works
BIM on existing assets are generally based on the scan-to-BIM process (survey, 3D modeling, and BIM implementation). As far as survey is concerned, nowadays workflows and techniques are well established [11
], and guidelines such as the English Heritage Metric Survey Practice [30
] and Historic American Building Surveys (HABS) [31
] are progressively appearing. Open research topics are big survey datasets management [32
], multi-resolution surveys [34
], and automatic point cloud segmentation [35
]. Three-dimensional modeling research concentrates mainly on how to parameterize complex elements (such as ornaments and classical orders elements) [21
] and how to model geometric irregularities and structure deformations [24
On the contrary, even though BIMs are actually information systems where semantic data organization has a central role, studies about database design in BIM are still few and even fewer in the CH field. In fact, database design is generally a topic in information technology or in GIS (Geographic Information Systems), while in BIM particularly focuses on the object’s classification and ontologies.
Since, as anticipated, the focus of the research presented here is non-geometrical information management in HBIM and the translation of traditional CH conservation procedure in the BIM environment, the analysis of the state of the art will only focus on these topics.
2.1. Semantic Breakdown and Data Organization in the BIM Environment
The degree of reliability of geometric and/or non-geometric information is commonly described on the basis of several recognized international specifications, generally known as LOD (level of development, level of detail, and other different definitions) [41
]. Currently, the most exhaustive reference standards are the BIMForum Level of Development Specification (2019) [42
] and the UK PAS1192-2:2013 [5
]. However, the classification of the elements, based on standards such as CSI Uniformat 2010 or Omniclass, and the attributes of each element, which are suitable for the most common BIM uses, such as quantity take-off, 3D coordination and 3D control, and planning [42
] make these standards hardly applicable to CH assets.
Italy, with the UNI (Italian National Unification agency which represents Italian legislative activity at the International Standard Organization (ISO) and European Committee for Standardization (CEN)) 11337:2017, part 4 [43
], which extend at national level the ISO EN 19650, has been the first country to introduce levels of development for restoration of CH sites: LOD F, which is required to document the as-built including management and maintenance plans, and LOD G, which represents the evolution of the object during its lifetime and provides information about maintenance, restoration, replacement interventions, decays, and pathologies. Nevertheless, their theoretical definition has not yet been followed by specific guidelines indicating which descriptive fields are needed.
The English guidelines written by Historic England [8
] and COTAC [9
] try to adjust the generally used BIM methodology and normative to the cultural heritage objects. Nevertheless, they highlight the difficulties in defining specific and binding standards in the heritage context because of the differences between historic assets, their heritage significance, and the conservation activities required.
Vocabularies and shared libraries of classical architectural elements are addressed by Murphy et al. [44
], De Luca et al. [38
], and Apollonio et al. [39
]. Quattrini et al. [46
] focused on Romanesque buildings and developed ontologies and shared libraries starting from the surveyed elements. The use of coded ontologies provides a common and shared reference through which to model a domain of knowledge, defining objects (classes), properties, and relationships that constitute it. Ontology-based representations allow having a common language, and enable information exchange and integration between heterogeneous sources of information.
In the CH field, the reference ontology is the CIDOC-CRM (International Council of DOCumentation-Conceptual Reference Model) [47
]. It became the ISO standard in 2006, and provides definitions and formal structure for representing information used in CH documentation. While developed mainly to support cataloguing and museum documentation, in recent years it has also been applied in the BIM environment as described, for example, in Pauwels et al. [48
], Yang et al. [49
], and Acierno et al. [50
], who extend the CIDOC-CRM model to the entire field of architectural heritage and its conservation process.
Nevertheless, semantic classification is still an open research field: a rigid classification collides with the unicity of historical architecture and with the different methods of analysis used by multi-disciplinary figures involved in the CH conservation process, thus there is no absolute correct way of working. An interesting approach is proposed by De Luca et al. [38
], who introduced the “point of view” analysis of the building, distinguishing between construction techniques/materials and vocabulary. They distinguished between four different points of view starting from the same morphological cutting and superimposed the information according to the sculpture, the moldings, the order, and materials. In this way, it is possible to completely analyze the structure accessing all the available data.
With regard to information management, in a BIM model, the entire structure is governed by the underlying database. It contains object definitions, parametric constraints that handle the object’s behavior, and any attribute that can be attached to the model. These attributes can be configured by the user: new ones can be defined to link all the desired information to the elements (texts, number, files, images, and so on). Nevertheless, in commercial BIM software, it is hardly possible to manage the relational complexity of information breaking down and re-aggregating data into tables connected by complex relationships with different degrees of cardinality. Data are often redundant since their normalization (i.e., the separation of tables with duplicated data into related tables with unique values) in many cases is prevented. In addition, time dimension management (4D) concerning semantic data is complex. It is possible to account for changes (additions, demolitions, or reconstructions) at the 3D model level, but there is no way to tag the attribute’s value with a date when only the associated information changes over time. Moreover, queries regarding the model can be precluded by unstructured data or links to external data/folders.
As highlighted in [52
], to overcome such limitations, several tools to simplify data management in BIM are increasingly developing (Table 1
). Revit DB Link [53
] exports Revit project data to a Access or SQL Server database, makes changes to the data, and imports it back into the Revit project; Ideate–BIMLink [54
] synchronizes Revit and Excel data; WhiteFeet Tools [55
] for Revit allow the connection with Access, SQL Server, or MySQL database and the management of sheets and schedules in Excel; CodeBook [56
] interacts with the main BIM software and allows collection and management of room and asset data; Nosyko dRofus [57
] and the Onuma Planning System [58
] integrate with the main BIM software and provide useful tools for data input, management, report, and export. Nevertheless, these systems are not specifically tailored for CH requirements.
2.2. Cultural Heritage Information Systems and Data Sharing
Many information systems for CH documentation, cataloguing, management, and analysis have been proposed in the past years with different purposes and at different representation scales.
The Kist o Riches by the School of Scottish Studies developed by the University of Edinburgh in 2015 [59
] and the CultureSampo promoted by the Helsinki University of Technology in 2015 [60
] can be mentioned among European implementations. In Italy, a web information system, SICaRweb [61
], for documentation, design, and management of restoration sites has been promoted in 2002.
Historic Geographic Information Systems (HGIS) based on several layers of historical maps [62
] are being applied in studies at the territorial scale, interfaced with external databases by Relational Data Base Management Systems (RDBMS). In this context, database design should address three main problems: identification of information and documents required; data organization into a relational database; interoperability and easy usability.
De Luca et al. developed two interesting information systems for semantic-aware 3D representation at the architectural scale: the NUBES project [38
] and AÏOLI [64
]. NUBES allows for 3D buildings representation, taking into account shape, dimension, conservation state, and hypothetical transformations in time, and for collecting and associating heterogeneous information. It represents an integrated framework, based on web technologies, able to manage and connect data about cultural heritage buildings, in order to describe, analyze, and document the assets.
AIOLI is a collaborative platform for sharing and increasing knowledge of heritage objects, of different scale and kind. Starting from a photogrammetric model of the objects, users are able to directly annotate the object, add semantic information, link external resources, and make multi-temporal analysis.
In the last years, Fassi et al. [22
] implemented BIM3DSG, a web-based system for archiving and management of all the information about the Milan Cathedral and other historical monuments and archaeological sites, with the purpose of supporting documentation and maintenance activities. Their database hosts 3D models (in different format and level of detail), descriptions, restoration activities, and files (such as photo, video, documents, dwg, etc.) associated with the objects. BIM3DSG gives solution to problems of managing big, high resolution, and heterogeneous 3D models, ensuring data and information sharing.
In all these studies, the need to use web application to share information and models is emphasized. In fact, to date, although the progressive adoption of ‘Open Data’ standards (IFC, COBie, and gbXML) in view of the transition to the BIM Maturity Level 3, complete interoperability between software has not yet been achieved and often, by transferring the model from one platform to another, inconsistencies, such as loss of information or errors in data, occur [23
]. Web applications free the users from any particular software platform (at least in the visualization and data consultation) since the information can be accessed through the browser. In this way, there is no data exchange between software and interoperability issues are overcome. In addition, web applications simplify usability and portability of the system: to access the data it is sufficient to have a web browser and connect to the web server containing the data. Users do not need to use any specific commercial software, avoiding personnel training and licensing, which can limit the actual use of the system. The visualization of the model is possible just with the help of an Internet connection, anywhere, on a PC, tablet, or smartphone. This can be very useful for on-site maintenance operations where the worker can view the model directly on the tablet and enter data directly, reducing working time and transcription errors.
3. The Developed HBIM System
The implemented HBIM system has been designed in cooperation with conservators and institution in charge of CH protection, to meet their specific requirements, such as coordinated and simple use by multidisciplinary actors to manage documentation and planned conservation, archiving data concerning the building and its components, monitoring problems over time, highlighting areas with problems, etc.
The system links the 3D model of a heritage asset (realized with a commercial BIM software) with an external relational database properly structured to account the multidisciplinary data. The link between the 3D model and the database is ensured by the unique identification code (ID), which identifies univocally each object into every BIM model. Each element of the model finds a unique counterpart in the database to which any information contained in the relational model is linked (Figure 1
). From a methodological point of view, the use of a particular BIM software, or RDBMS (Relational Database Management System) or even the structure of data inside the database are absolutely non-binding, because the ID is the unique key for the connection.
Therefore, the potential offered by both BIM and RDBMS existing software was combined to create an easy-to-use tool, able to fulfill CH needs. In this work, Autodesk Revit™ and Microsoft SQL Server have been used. However, with the development of simple plug-ins, the system can be interfaced to other BIM and RDBMS packages, both commercial and open source. As shown in Figure 1
, the system consists of:
The 3D model of the asset;
The relational database containing the asset information: each element in the model has a corresponding database record, to which all the tables of the database are linked;
Desktop database manager tool: a desktop application with a dedicated graphical user interfaces (GUIs) that allows the connection between the 3D model and the database, and makes it possible to manage the database (add/edit/view) directly within the BIM authoring tool/software;
Web platform: web interface that allows remote access to the database (add/edit/view), in addition to viewing and querying the model.
This architecture ensures multi-platform access (workstations or portable devices) and user-friendliness. The easy usability of applications is the key requirement for their effective success, especially in the case of cultural assets, where HBIM oriented systems are used by non-AEC-experts. Thus, user-friendly GUIs have been developed, which can be opened directly within the BIM software, via plug-in, or accessed via the web.
The web application overcomes interoperability restrictions between commercial software and provides a unique data access point from remote and mobile devices. The 3D model can be visualized inside the web browser using Autodesk 3d Forge viewer [67
]. This package enables to upload and view the 3D model and its parameters directly via the web and implements GUIs for 3D navigation that makes it possible to easily handle the model.
The implemented HBIM system meets the needs of conservator and institution in charge of CH protection, allowing the users to:
Add/edit/view textual information and files in the database and link them to the objects of the model;
Query the model and the database by a graphic query builder;
Visualize the results of the queries graphically though false-color maps of the model;
View/navigate/query the 3D model from remote through the web interface;
View past conservation works;
Plan conservation activities;
Make 3D mapping of surface decays automatically starting from 2D orthophotos;
Document survey and modeling phases using metadata.
Given the great heterogeneity of data and goals of CH information systems, the application has been restricted to documentation and planned conservation purposes, with the database and the 3D model structured accordingly. Nevertheless, the database has been structured to be flexible, repeatable, and scalable in similar contexts to meet the specific needs.
The processing workflow integrated survey, semantic data acquisition, semantic classification of the elements that compose the building, 3D modeling, and database design. Information management, database design, and semantic enrichment of the 3D model will be dealt with in detail in the following, while referring to Reference [68
] for surveying and 3D modeling phase description. Surveying and modeling are instead addressed with regard to their documentation and their integration with the database in terms of metadata.
3.1. Information Management: Database Design, Surveying and Modeling Metadata
The system implements the conceptual model of representing building’s information, which has to be tailored to:
Enable information management at different scales, from the single architectonical element to the entire building;
Provide asset’s semantic breakdown and data logical structure useful for documentation and planned conservation activities;
Manage historical information and enable links to existing documents and multimedia of any format;
Manage multi-temporal information, in particular related to the conservation state of the elements and to the maintenance and restoration works made over time, keep track of past actions and plan the future ones;
Be scalable both in terms of time and information: data input over time and change/enrichment of the information typology linked;
Be sufficiently flexible to comply with the level of detail chosen to represent the building. The LOD varies according to the case study, but may also vary within the same case study to represent the building with different levels of detail.
The classification system applied in this research derives from the requirement-performance approach, typical of building technology. This method is described, as far as Italian regulations are concerned, in UNI 10838:1999 [69
] and UNI 8290:1981 [70
], and is the most widespread methodology to draft a maintenance plan [3
]. Rather than focus on the properties of the built object (physical, chemical, technological, morphological, dimensional, etc.) it examines its behavior in relation to a number of functions that the object has to fulfill. Thus, the object quality is not expressed descriptively but in relation to the compliance with a set of requirements. Accordingly, the building is divided into “classes-technological elements” (foundations, vertical structures, horizontal structures, etc.) and “subclasses-building components” (column, beam, wall, roof, etc.), and all the data concerning conservation are linked to the building components. This semantic classification is the same for 3D model and the database since each element of the building has a graphical representation in the 3D model and a corresponding description in the database.
In addition to buildings’ components, in order to allow for grouped information (e.g., historical data referring to multiple elements of the building) or more detailed 3D models, three additional levels have been introduced: Building, Zones, and Building Components level B. Therefore, the overall semantic classification is as follows (from general to particular):
Lvl. 1—Building: it concerns the whole building and addresses data referred to the building in its entirety.
Lvl. 2—Zones: an optional layer to characterize building portions that have peculiar features or are volumetrically recognizable (for instance: first floor, apartment A, perimeter loggia, central nave in a church, and so on).
Lvl. 3—Building Components level A: subclasses of technological elements, compatible with a representation scale of 1:100–1:50.
Lvl. 4—Building Components level B: parts of components that have a higher modeling detail (representation scale 1:20) and can be used to account for different materials, pathologies or substitutions, or to give more geometric information.
For each level, three main categories of data have been associated: metadata about the survey, metadata about the modeling, and descriptive data, with particular reference to planned conservation. A summary of the data linked to the constitutive entities of the database is provided in Figure 2
Although no regulation refers to metadata on surveying and modeling, information about methods, instruments, accuracy, and validation are important to make the user aware of the data’s quality. The creation of a model is anyway an abstraction and simplification of reality and, as such, entails differences between the representation and the real object. Survey, as well as any measurement, is affected by errors, which the geometric simplification introduced during the modeling phase is added to. The correspondence of the model to survey data can be variable depending on the adopted technique, from the mesh model (which represents the most faithful model to the collected data) to the parametric model (which represents the maximum degree of abstraction and simplification of data). In the current state of technological development, it is necessary to make compromises between model accuracy, files size, modeling time, and limits of software capabilities. The available solutions are many and change according to each case study and model purposes. Several studies account for increasing accuracy, complex shapes modeling, and process automation. In the authors’ opinion, a relevant research subject that should be investigated as well is the following: whatever the technique and the accuracy obtained, it is necessary to document both surveying and modeling processes and certify quality and reliability of the information. To this end, a specific part of the database hosts metadata and data related to surveying and modeling.
The other descriptive data have been organized according to in-force Italian normative references [4
], however the same model with the necessary adjustments can be adapted to regulations in other countries. Planned conservation, as well as preventive maintenance, establishes the drafting of a conservation plan which, on the base of the building’s state of health assessment, provides for a program of checks and actions to monitor and resolve any critical issues. Information about damages or problems that may arise, a check program to monitor their onset or development and actions to undertake can be entered for each element. On the basis of these data, the system allows recording over time the element’s health state and restoration activities, and planning future inspections and interventions.
Data associated with the 3D model can be textual, entered as a field in the database, or can be links to external files of any format, stored locally or on the web. To enable multi-temporal analyses, date-type attributes have been associated with information that may vary over time, both with respect to the entry date and to the epoch, which that data refers to. The 3D model can contain objects belonging to the same period or to different epochs to account for the different constructive phases of the asset or for replacements occurring over time. Multi-temporal 3D objects are managed using time management tools provided by the BIM software used, for instance, in Autodesk Revit™ through the “constructive/demolish phase” filter: each model belonging to a different phase is simply a new component to be added in the database and can be filtered thanks to the automatic updating of the database with reference to the phase of creation and demolition.
Despite the presence of four different semantic levels, it was decided to define them all as a unique entity in the database, called “BIM Elements”, which is the link between the database data and the 3D model. This choice sets the connection between the model and the database just on a single table and makes it more manageable. Nonetheless, the structure of data permits through filters to distinguish the information to be associated to each semantic level, in order to avoid redundancy or sparsely populated columns. All other data are grouped by categories of information and are stored in independent tables that can be linked to the main “BIM Elements’” table, according to the needs or the level of detail to which they refer. This structure guarantees high flexibility of the database as any table can be deleted and/or new tables (containing additional data not yet included) can be easily created and linked to the “BIM Elements” table, without altering the basic structure of the system. Figure 3
shows the conceptual diagram and the entities implemented so far.
The main entities related to planned conservation data are “General info”, “Problems”, “Damages”, “Conservation-Interventions”, and “Files”.
The “General info” table contains descriptive and morphological information about BIM elements. Since the data referring to an architectural element are different from those relating to the entire building, a discriminator has been introduced to automatically enable the specific information of each semantic level. “Problems” and “Damages” tables replace the maintenance Technical Manual
]. According to the Technical Manual
, each BIM Element may be associated with one or more Problems (if potential) or Damages (if actual). Each problem has associated data (such as risk areas, preventive actions, inspections, etc.) and may cause different damages. For example, a wall may be subject to mechanical stress and possible damages such as deformations or cracks have to be evaluated.
The “Conservation-Interventions” table has been created to keep track of all the actions that the asset was subject to. Conservation-Interventions are catalogued by date, allowing diachronic queries, and are linked to the specific Works performed, with relative unit prices, as in terms of the contract.
The “Files” table refers to all external files of any format that are linked to the database (raster images, vector files, text files, documents, etc.). Files can be associated with different object classes, architectural elements, functional areas, or the entire building and are also linked to restoration work and to Survey Data to keep track of the attached documentation.
Based on the structure described in this paragraph, a template database was created, which includes the tables and the seeding of pre-compiled data (such as Problems, Anomalies, etc.). This template can be applied to every new database related to BIM models for restoration and maintenance.
The database is installed on a local network or on a remote server to be accessed through Internet connection by different devices. The database stores the textual information about the objects and the path of the related files, while the 3D model is accessible from remote thanks to the work-sharing capabilities offered the BIM software.
3.2. Desktop Database Manager Tool
The desktop database manager tool acts as a plug-in to Revit, but can be used also stand-alone or can be extended to other BIM software. The stand-alone usage prevents only the 3D model visualization and forces to search information by ID instead of by selecting elements on the 3D model.
The plug-in is written in the C# language and uses. NET Framework. In particular, the Entity Framework technology was used to support the development of the whole application, enabling the easy interaction with the external relational database. For each entity defined in the database conceptual schema, the correspondent class was created, and relationships with the other classes were defined [77
The desktop application allows users to add/edit/view data about an item through the graphical interfaces: textual information, multimedia files (images, video, etc.) of any format, other files of any format (dwg, pfd, doc, etc.), past and future maintenance or restoration activities.
The GUI is quite simple and is organized as shown in Figure 4
. The top of the interface provides objects identification data. The central part is dedicated to a tab panel, which shows the information about the selected item. Information is grouped in tabs, each referring to the corresponding database table.
In addition to this information, the system prototypes a tool to insert metadata and data related to the survey. These data are linked to the entire building or to zones, since usually a survey does not involve just one element but the whole building or a portion of it. Each 3D element can, however, be associated to the survey data it has been modeled on.
A survey is represented by the union of data and processes: data may be either raw data or processed data; processes document the type of elaborations, with the associated input and output data. The structure of the database makes it possible to link data and processes in a sequential way, in order to reconstruct the sequence of raw data, processes and processed data, from the initial data produced by the instrument to the output data used for modeling, to certify the correctness and quality of the operations carried out.
Through properly designed GUIs, users can enter survey information such as description, date, authors, instruments, links to external files and folders, information about processing operations, obtained accuracy, etc. Once inserted, processes and data are listed and graphically represented in a node diagram. Graphical visualization helps to trace the chain of processes carried out when simply listing of processes and data, it would not be enough to understand the actual pipeline. By clicking either on the list of data/processes or on the corresponding graphical representation, the user can see all the associated information and any external files loaded and/or trace the chain of processes carried out up to that point.
The same applies to modeling: information about modeling techniques, tools, representation scale, and accuracy of each 3D element are entered in the database.
A graphical interface allows querying the database both through text queries and a query builder. Through drop-down menus, users can select the database tables to query and the related fields, then the condition of the query can be specified with the help of graphic tools and automatically populated fields. The results of the query can be exported in Excel format and are shown colorizing the 3D model. This function is particularly useful, for instance, to identify elements in the model needed of maintenance or objects that have a particular pathology.
The implemented system features also a tool to build thematic maps of the 3D asset’s surface in BIM environment on the basis of orthoimages [68
]. This function lets the users to draw material/decay/damage maps directly on the orthoimages, associate attributes, and project them on the 3D wall surface, with the ability to calculate areas, make queries and view the 3D damage development. These tools have been designed to facilitate the tasks of restorers, who usually work with two-dimensional mappings. Users can work on 2D orthoimages directly in the BIM environment, which is a novelty for the BIM software, and create 2D polygons that are not simple hatched areas but vector polygons with attributes. The working environment therefore does not differ much from CAD, enhanced with GIS capabilities and is totally integrated into a BIM system. At present, the function has been implemented only for vertical walls based on a line segment, an extension also to cylindrical walls is under way.
4. Case Studies
4.1. The Cathedral of Parma (Italy)
The Cathedral of Parma is a Romanesque building, built between the second half of the XI and the beginning of the XII century. During its lifetime, the church has been subject to changes, additions, damages, and repair works which last until today. The need for continuous restoration and maintenance, and its historical and architectural features make this building particularly suitable as a test case study. In particular, one of the most relevant problems is the material decay of the façades, which are made mainly of limestone or sandstone and, due to climate action, tend to delaminate and crumble. Therefore, the institution in charge of Cathedral’s conservation, the Fabbriceria del Duomo, set the following requirements as priority for the implemented system: (i) monitoring and planning conservation activities on the external façades; and (ii) archiving and managing existing documents, technical drawings, past surveys and restoration works.
The first phase of the work concerned the analysis of the regulatory requirements and specific needs of the building. The survey [68
] and the acquisition of both geometric and semantic data were then carried out with an integrated and multi-scale approach and archival analysis. The integrated survey overcomes the limitations of each technique, optimizing data acquisition, and object coverage [34
]. Multiresolution helps to manage the huge amount of data while ensuring an adequate level of detail where needed. Total station, GPS receivers, terrestrial laser scanners (TLS), and close range photogrammetry have been used. The most used technique was TLS both on the interior and exterior. Close-range photogrammetry was instead applied only to the external façades, with the main aim of obtain high-resolution orthophotos, while the use of Unmanned Aerial Vehicles has been foreseen for the roof and the building elements above the 18 m height.
From the 3D survey data, the 3D model of the building was then built using Autodesk RevitTM
]. The focus has been in particular on building components (semantic classification levels 3 and 4). At level 3, the adherence of the model to the semantic breakdown was preferred to the geometric precision. For planned conservation purposes, in fact, an accurate geometric reconstruction of the element is often not necessary, but it is sufficient that each element is recognizable and spatially referred within the building. Nevertheless, parametric modeling with the system objects already present in the software libraries was possible only in a few cases. Normally, it was necessary to create custom parametric objects (columns, window, decorative elements), with dimensions that can be edited on the model, or use in-place modeling through traditional modelling functions (extrudes, merge, merge on path, revolution).
With complex and irregular shapes, the form of the elements was simplified and represented by placeholder objects, using external links for proper documentation. In particular, the mesh models of elements such as capitals or decorative elements were associated to the model via external links. Wherever significant deformations and/or irregularities are present, difference maps (i.e., a false color 2D representation of discrepancies between modeled and surveyed object) have been linked to the elements to indicate their actual form and emphasize, if present, existing damages. In this way, the information requested for building knowledge is contained in the model and the user can have a faithful representation of reality, while keeping the model size manageable.
The integration with two-dimensional representation does not invalidate the information content of the model, on the contrary in many cases it was more effective and capable of modeling the phenomenon involved. In fact, a model of a building does not necessarily mean a 3D model, but the model is an abstraction and simplification of reality, regardless of the medium adopted.
At level 4, several workflows were tested to manage the modeling of irregularities in 3D, in order to reach the higher level of accuracy [68
]. Walls, floors, vaults, and semi-domes were modeled starting from the point cloud, both as 3D solids and parametric objects. In the former case, 3D modeling tools, and Boolean functions were used directly in BIM environment, in the latter case, reference surface following the point cloud were created on which parametric objects were adapted.
Level 2 (Zones) reflects the spatial organization of religious buildings: main façade, central nave, north aisle, south aisle, north side chapels, south side chapels, transept, choir, crypt, etc., since it was the most suitable for structuring the available descriptive data. As well as the building level, Zones were not modeled as independent objects, but are a group of building components, obtained through the “create group” function of Revit. In this case the level of detail of the representation is always equal to that of level 3 or 4 (scale 1:100–1:20), but depending on how the selection is done on the model, the user can access data from levels 1, 2, or 3.
The 3D model realized for the Parma Cathedral represents the current state of the asset (2018), previous transformations or construction phases have not yet been modeled, though this option, that obviously applies also to future changes, can be implemented at any time. Information to draft the conservation plan were added to the building components: problems, anomalies, risk areas, interactions between adjacent elements, methods of inspection, qualitative and quantitative analysis results (Figure 5
). In addition to these descriptive and textual data links to external files, we added:
Data from previous surveys: technical drawings (plans, elevations and sections), TLS point clouds, images for photogrammetric surveys, orthoimages, technical reports, decay/material analyses, geo-structural analyses;
Archival data, previously digitized or transcribed;
Photographic images, current and historical;
Data sheets about previous restoration activities.
We focused particular attention on documenting the survey and modeling through metadata (Figure 6
). In fact, the use of integrated techniques and the need to implement survey in time require consistent, comparable, and commonly referred datasets and metadata that are fundamental for achieving this aim. In addition, data from previous surveys were inserted into database tables, by recording files, general description, and start and end date.
The system has been implemented with the support of restorers in charge of the conservation interventions on the Cathedral. The first results of the system application to the Parma Cathedral are shown in Figure 5
, Figure 6
and Figure 7
4.2. The Ducal Palace of Mantua (Italy)
The Ducal Palace of Mantua has been built since the 13th century and has been expanded over time thanks to the work of architects such as Giulio Romano. From a spatial point of view, the complex is very articulate with the presence of heterogeneous elements, which make it particularly interesting to test HBIM capabilities.
The system’s test on the Ducal Palace was part of a research concerning the application of HBIM to CH assets, developed by the Politecnico of Milan within the project “Building Information Modelling for the planned conservation of Cultural Heritage: even a Geomatic question” (Italian Scientific Independence of young Researchers SIR 2014-RBSI144B5K). In this context, substantial work had already been carried out, both with regard to 3D modeling and the management of semantic information only using the tools offered by commercial BIM software [79
]. Therefore, surveying and 3D modeling were not addressed in this case study, and only the database structure and the system flexibility by adapting it to a case study not created for this purpose were evaluated.
The general structure of the database has proven to be suitable for the management of a complex of buildings as articulated as the Ducal Palace. In particular, we focused on the different levels of detail by which breakdown the asset and organize information:
Building: the entire building was modeled as a solid by extruding the perimeter of the building. The level of detail is very low and is suitable only to establish building location and associate data. Conversely from the case study of Parma, a lot of information had to be associated with this level. In particular, the database was required to include risk assessment data (in particular given the proximity to a lake) and current and historical cartography, both in vector or raster formats, with related descriptions and metadata. An additional section of the database was implemented to store cartographic data and linked to the “BIM Elements” table, without altering the other tables of the database. The GUIs already developed have been slightly adapted for the management of these new data (Figure 8
Zones: in this case the zone definition followed the division of the building into apartments and has been functional not only to the management of semantic aggregated information, but also to the survey and modeling that are still ongoing.
Building components level A: the investigated area was the Cavallerizza Courtyard. As in Parma case study, simplified elements compliant with the 1:100 representation scale were modeled starting from a TLS survey. For each element, the information concerning planned conservation activities were entered in the database and linked to the model.
Building components level B: this level has not yet been modeled due to the high complexity level of ornaments, material, constructive techniques and historical stratigraphy. This level will be developed in the future to meet the needs of a restoration project.
In contrast to Parma, in Ducal Palace every level has been modeled with a different level of detail LOD (from a conceptual solid representing the building to detail scale of representation). Thus, each level is an independent model, whose visualization can be managed filtering the LOD value. The link between objects belonging to different levels (for instance between components and zones) is managed only within the database.
Currently, further tests about the consistency of the classification schema, the optimization of the database structure, and the automation of some data entry processes are in progress, also on other historical buildings [80
The implemented system has been realized in cooperation with conservators and actors involved in conservation process, to meet their needs in documentation, ordinary management, and planned conservation activities. By integrating BIM and RDBMS capabilities, the system allows users to store, manage, query, and reference all data about the building during the whole lifecycle on the model, which for CH assets could be potentially endless. Information is digitized and can be retrieved from a single point of access and in a simple way through desktop GUIs and the web application.
Unlike the above mentioned tools for data management in BIM environment (Table 1
), which allow, through dedicated interfaces or external databases, easier management/updating of BIM model’s parameters, the implemented system can associate the 3D model with data stored only in the database, which does not have a corresponding parameter in the BIM model. In this way, the data can have any relational structure and it is possible to link the 3D model also with pre-existing databases, not specifically developed for the creation of the HBIM system.
With respect to other similar examples, such as NUBES [38
] and BIM3DSG [22
], this project followed a different approach because we chose to base the system on BIM software instead of 3D modeling software (e.g., Rhinoceros) and not to design a new software for the visualization and management of models and information, but to integrate existing BIM software with new features designed for CH.
This choice is disadvantageous in terms of 3D model accuracy, since parametric modeling is much less flexible in representing complex and irregular geometric shapes, but, on the other hand, object modeling allows setting the object’s behavior and establishing constraints and topological relationships useful in the 3D model management. In addition, all the potentialities offered by the BIM software can be used, taking advantages from the model not only for planned conservation and documentation, but also to carry out structural or energy analyses, plants design, refurbishment, or restoration projects.
Moreover, the regulatory requirements are pushing towards the progressive adoption of BIM standards, so the use of commercial or open-source BIM software is expected to become the reference standard to which many institutions and professionals have already migrated. For this reason, it was decided to adopt the plug-in logic that, regardless of the platform used, allows associating the 3D model with data organized in an external database. In this way the model must not be migrated to another platform or another software and the users can continue to use the software they are more skilled in, to modify and display the model. This allows a greater applicability of the system and its use with already existing models.
Another innovative function of the proposed system concerns survey metadata. It allows not only to describe the surveying process and to give its accuracy assessment, but also to document all the phases by attaching the original and the output data and by describing each process adopted. This function completely agrees with the BIM definition as a process for the management of building information throughout its life cycle. In a HBIM system, the initial phase is the survey and it must be documented and inserted into the BIM. The organization of survey data introduced in this paper is useful for all the subjects involved in the use/implementation of the HBIM:
Surveyors: they are able to well organize the data and, especially in complex and integrated surveys, can keep track of any data processing phase. In addition, they can have full awareness of the operation undertaken and references for survey implementation in time;
Modelers: they can check the original data if any inconsistency occurs;
Restorers: they are able to check information and extract precise geometric information directly from the point clouds, making up for the 3D model geometric simplifications;
Owners/institution in charge of asset management: they can benefit from the complete documentation about the asset with a unique point of access and can validate information at any time.
The implemented system has been tested on two case studies with different characteristics both in terms of typology (a cathedral and a palace), spatial complexity (a single isolated building and a complex), constructive techniques, and related information. Further tests on other buildings are in progress or planned.
On the basis of the experiments carried out thus far, the following considerations can be deduced:
The semantic classification adopted (building, zones, and components), although not standardized by in-force regulations, proved to be effective in both cases of study:
The Building level fulfills the function of archive for general information. In complex cases, composed of several buildings, many Building entities can be used to account for the associated data.
The Zone definition, instead, varies according to the asset, its features and available data. Problems may concern the association of border elements with one area or another (e.g., pillars between adjacent aisles) or the criteria used to identify zone (façades/surfaces or volumes). In the Parma Cathedral case study, the former issue was addressed by establishing a hierarchy between building parts: from the central nave to the side chapels. According to this hierarchy, the elements at the boundary between two areas have been assigned to the top-level area. Thus, for example, the lateral walls and pillars between the central nave and the aisles were attributed to the central nave.
The latter issue is very common especially when existing documents have to be associated to the building. In fact, it is not uncommon that restoration works and technical drawings are organized by façades while other information, such as constructive epoch, refer to volumetric portions of the building. In this case, the database has been structured to associate each element to more zones according to the need.
However, the zone detection inside the building is mainly a conceptual matter of building analysis, which does not affect the structure of the DB and the system.
The Building components A level meets well the requirements of planned conservation and ensures easy management of information in the database. Its geometric modeling, on the other hand, presents still many issues, addressed by several authors in the last decade: how far BIM elements modeling should/might simplify the geometry of the real object? The developed information system addresses all these issues providing an information level specifically designed to document all the modeling processes.
The Building components B level still presents many open questions, especially with regard to modeling and the association of information (see previous point). A conceptually open problem concerns the appropriate level of detail for modeling: compromise between model accuracy and software capabilities, which are not addressed in this paper. Additional tests are instead ongoing about how to structure information useful for the development of restoration projects in a BIM environment.
The four semantic levels have been modeled using two different approaches in the two case studies. In the case of the Ducal Palace, every level was modeled with a different level of detail LOD, while in the case of Parma, only the building components A and B were modeled. The procedure adopted in Mantua makes it easier to display the model when level 2 or 1 is selected, but it makes the relationship between components and zones more difficult. On the contrary, the procedure adopted in Parma makes the relationship between components and zones not only at the database level but also at the model level.
The different modeling strategies have been accurately documented in the project’s metadata. In this way, the user is aware of the quality and reliability of the model. While not providing a technical solution that requires software-side implementations or precise modeling guidelines (both of which fall outside the scope of this research), the metadata documents the level of accuracy achieved and thus, indirectly, indicates the possible uses of the model.
In this study, the implementation of a HBIM methodology aimed at supporting documentation, management, and planned conservation of cultural heritage assets is presented. Its main goal was to give a concrete answer to the lack of tools tailored for CH requirements: organized and coordinated storage and management of historical data, easy analysis and query, time management, flexibility, user-friendliness, etc.
A relational database storing all data about the historical building has been designed and linked to the asset 3D model. The structure of the system has proven to be sufficiently flexible for handling data from different case studies. The choice to structure the database with a central main entity (“Bim elements”), to which both the information in the database and the object of the model are associated, has ensured the flexibility of the database and of the system in general. In fact, it is possible to add/remove/modify database tables without altering the underlying structure (for instance a table with the data related to cartography was added in Mantua Case study, while was missing in Parma). Data organization flexibility is essential when approaching historical assets: CH is case sensitive and there is no standard remedy for every case. On the contrary the methodology of approaching should be flexible and adaptable to case-specific requirements and goals.
The system developed proved to be flexible also in terms of architecture, since the link with the 3D model is managed by the object ID and ensures not to be bound to specific software solutions. Regardless of the software used in these applications, the system can interface with other RDBMS and commercial and open-source BIM software, providing flexibility both in data consultation and authoring. The database is accessible both trough a local or a web connection and by workstation and mobile devices; GUIs allow easy data enter/edit directly in BIM environment (with a developed plug-in) or on a web platform, simplify usability also for non-AEC experts and make possible the collaboration between the many figures involved in the conservation process such as architects, historians, art historians, and restorers.
Future developments of the system will concern its large-scale applicability and interoperability, working on three main topics:
Integration with other BIM platforms than Revit and development of appropriate plug-ins. Test both with commercial and open-source software;
Automatic updating of graphical interfaces, based on the fields and tables in the database. Currently the interface structure is static, so any changes in the database fields requires a manually intervention in interface definition. The development of dynamic interfaces could extend the flexibility of the system and easy usability;
Integration of the information model with the CIDOC-CRM ontology. In the current state of research, in agreement with the stakeholders involved, a classification based on the requirement-performance approach, commonly used in planned conservation in Italy, has been adopted. However, to facilitate the exchange of heterogeneous cultural heritage information and the integration of the different actors involved, the integration between this classification model and the CIDOC-CRM scheme will be foreseen.
The presented work highlights the opportunities that BIM tools can provide in conservation activities. The aim is that their effective use by both professionals and public administrations or institution in charge of CH asset protection will progressively increase. Only in this way will it be possible to create a dialogue between all the figures involved, arriving at effective interdisciplinary collaboration, which is fundamental when approaching a complex heritage such as the historical one.