Planning a digitally integrated future: GIS and BIM for roman architecture, the case of Pompeii Archaeological Park
Full text
Planning a digitally integrated future: 1 GIS and BIM for roman architecture, 2 the case of Pompeii Archaeological 3 Park 4 Angrisani Giovanni1, Borriello Giovanni2, Bosco Angela*2, 5 Cera Valeria1 Forte Francesca2, Fregonese Luigi3, 6 Rosignoli Olga3, Scandurra Simona1 7 8 1 Università degli Studi di Napoli Federico II – Naples, Italy 9 2 Università di Napoli L’Orientale – Naples, Italy 10 3 Politecnico di Milano – Milan, Italy 11 12 13 *Angela Bosco 14 Correspondence: [email protected] 15 16 ABSTRACT 17 The ongoing wave of digitization across scientific domains is reshaping the fields of cultural 18 heritage and archaeology. Nevertheless, as demonstrated by previous research, the 19 exceptional nature of heritage historic assets often conflicts with software architectures, such 20 as data schemas and communication protocols, that are not conceived with those specific 21 requirements in mind. The archaeological remains preserved within the Pompeii Archaeological 22 Park constitute an extraordinary case study, where architectural features have been preserved 23 almost in their entirety. Given this configuration, any digital management tool designed to 24 support the site’s conservation must integrate the functionalities of both Building Information 25 Modelling (BIM) and Geographic Information Systems (GIS), ensuring their seamless 26 interoperability. 27 This study offers a quantitative evaluation of this interoperability challenge-frequently mentioned 28 in articles but not demonstrated yet-by identifying the precise information loss that occurs during 29 the digitization process and the following alignment with established data standards. 30 Specifically, a semantic mapping between the entities involved in the process is presented: the 31 open-format standards IFC (for BIM) and CityGML (for GIS) are compared with a purpose-built 32 taxonomy developed for Vesuvian Roman architecture. 33 The resulting correspondence matrix indicates the conceptual relationships across schemas, 34 assessing their instrumental relevance for archaeologists, conservators, and site managers. 35 To further enrich the semantic representation of archaeological data, the research explored the 36 possibilities given by ontologies and thesauri. This approach allowed for the definition of 37 domain-specific concepts and relationships that are not adequately captured by existing BIM 38 and GIS standards, thereby aligning the data more closely with archaeological practices. 39 All this constitutes a foundational step toward the development of an integrated digital system 40 that bridges the BIM, GIS and ontological domains, while remaining responsive to the 41 methodological principles and operational needs articulated by archaeological experts. 42 Keywords: BIG_SMAART, BIM, GIS, semantics, Pompeian architecture 43
Introduction 44 This contribution is part of the broader context of the digital framework for the digitisation of 45 archaeological assets. Nowadays, there are many studies that highlight the exceptional nature 46 of historical heritage and how it clashes with software, schemas, or data protocols that have not 47 been specifically constructed with archaeology's needs in mind (Bosco et al., 2021; Bosco et 48 al., 2019; Garagnani et al., 2020). 49 During the last decades -as well as in the pastarchaeology has looked tirelessly for creative 50 and satisfying solutions to represent both the complex status quo and the development of 51 archaeological sites. Its complicated long relationship with digital representation tools is part of 52 this on-going research, one that started several years ago, mainly with GIS (Geographic 53 Information Systems) representation. Then, with the popularity of BIM increasing in the sector, 54 the demand for its integrations to GIS drastically grew, and the first experiments in this regard 55 started almost simultaneously (Delpozzo & Balletti, 2023) 56 Within this context, the aim of this investigation is to define a theoretical structure necessary 57 for the organisation of the heterogeneous data that contribute to the study of archaeological 58 evidence, identifying in the relevant available schemas the points of connection between 59 representation systems such as BIM, GIS and the archaeological domain. 60 The BIG_SMAART project, funded by the Italian Ministry of Universities and Research, 61 involves the co-operation of three universities: the University of Naples L'Orientale, the 62 University Federico II of Naples and the Politecnico di Milano. 63 64 Figure 1 - Project workflow with division of the various phases 65 The aim of this project is to provide a quantitative assessment of the interoperability between 66 these systems. Although the topic is widely known in the literature, it is still rare to find research 67 demonstrating what information is lost during digitisation processes and the compliance 68 between the most widely used data schemas in BIM and GIS. 69 Considering these assumptions, to define the specific workflow (Fig. 1), it was decided to 70 define three main research questions: 71
(a) do current GIS and BIM data schemas or existing ontologies dedicated to archaeology 72 meet the requirements for the representation of ancient architecture and especially Vesuvian 73 architecture? 74 (b) does a data schema support these requirements better than its equivalent? 75 (c) how can BIM and GIS methods be integrated in an archaeological context? 76 The research aims to address these questions through the analysis of a concrete case study 77 in which data formats have been applied and evaluated. 78 To this purpose, the project's methodology is based on the analysis of how the semantic 79 data provided by these systems overlap with the archaeological needs. Since the 80 archaeological world is so wide-ranging, the experimentation focuses on the Vesuvian area, 81 which is unique because it was crystallised in 79 AD. Thanks to this condition, the context 82 reveals extensive information about life and technology in the Roman world of the Republican 83 and early Imperial periods. 84 More specifically, we propose a semantic mapping between the entities that are part of the 85 process, starting from an analysis of the most widely used open format standards for BIM and 86 GIS, namely IFC and CityGML. We then proceeded to compare the semantic possibilities 87 offered by these formats with the semantic tree created specifically for Roman architecture in 88 the Vesuvius area. 89 Digital Data Management in the Pompeian context 90 The archaeological analysis of evidence and construction techniques was extended to allow 91 the creation of a semantic tree (a schematic hierarchical model) useful for breaking down the 92 single elements of the complex archaeological reality of Pompeii. The choice of the site is linked 93 to various reasons, which can be summarised in the following points: 94 • Extensive, well-preserved archaeological evidence, on which to test as many 95 cases as possible; 96 • Evidence for which there is a good level of previous documentation, even when 97 it concerns excavations carried out in past centuries; 98 • A complex reality to manage, characterised by modern infrastructure that adapts 99 to ancient evidence; 100 • The volume of evidence requires an informatic system capable of providing 101 effective management support. 102 Over time, the Park has implemented, through the Great Pompeii Project, research actions 103 focused on the collection and systematisation of data with a precise view to preventive 104 maintenance. In particular, the so-called “Knowledge Plan” 1 has led to the creation of SiPompei, 105 a georeferenced and relational platform that describes and catalogues the entire ancient city, 106 joined by Open Pompeii (https://open.pompeiisites.org/index.html), a digital archive with free 107 access aimed at facilitating the dissemination of data that is integrated with SIAV (information 108 system of the Vesuvian area) and Tolomeo for archival materials and historical documentation. 109 1 The data from the GPP_Knowledge Plan has been kindly provided by the Archaeological Park of Pompeii.
The Knowledge Plan has also produced new 3D survey documentation with laser-scanning 110 and photogrammetric methodologies covering the entire surface of the Park as of 2015. This 111 three-dimensional documentation, however, is unrelated to the systems mentioned above. 112 It therefore follows that the conservation and management requirements for such a complex 113 site would necessitate the combined use of BIM and GIS functionalities. 114 Based on these assumptions, the initial phase of the research involved an in-depth review 115 of the state of the art regarding the integration of BIM and GIS applied to archaeology. The 116 analysis of the literature made it possible to identify the data formats most frequently attested 117 in previous studies, the software most adopted in this field of investigation, as well as to define 118 the main problems met by other research groups with the aim of setting up an efficient mapping 119 between the entities belonging to these knowledge structures we are aiming to communicate. 120 The choice of the case study 121 To verify the theoretical model defined at the outset of the project, an application case was 122 identified and selected. 123 The choice of the House - Bakery VIII, 6, 1-9/11 (Fig. 2), is linked to several factors: the 124 location of the complex between two public areas, the Civil forum and the Triangular forum; a 125 complex stratigraphic sequence with various modifications and restorations, including modern 126 ones; the type of building structure that was transformed from a private house into a productive 127 activity with the addition of peculiar installations such as the oven and millstones. 128 The archaeological complex was already discovered at the end of the 19th century, but it is 129 still almost unstudied 2 . Therefore, a census and cataloguing of the architectural and functional 130 elements of the complex, as well as the building techniques and materials used for their 131 construction, was carried out (Borriello et al., 2025). 132 Although not widely known to the general public, the Domus — in addition to occupying a 133 strategic position within the topographical framework of the ancient city — is perfectly suited to 134 the experimental needs of the project due to its structural complexity and its multi-layered 135 chronological and functional stratification. 136 2 The first excavations took place between 1881 and 1882.
137 Figure 2 - Photo of the oven installed in place of the cubiculum east in the 138 atrium of the House - Bakery VIII, 6, 1-9/11 (Courtesy of the Archaeological 139 Park of Pompeii) 140 The semantic breakdown of Vesuvian constructions 141 To make the management of the evidence as suitable as possible for its use with BIM and 142 GIS platforms, a semantic breakdown of private construction elements in Pompeii was carried 143 out (Fig. 3). The semantic scheme was based on the HBIM model, where entities are described 144 as: Class, Category, Type and Instance, attempting to adapt it within the limits of archaeological 145 requirements. The main components of the Roman building were divided into three disciplines 146 (structural, architectural and plant engineering), based on the function of the object in the 147 Roman building complex. Each discipline was then divided into classes or sets, i.e. elements 148 that share the same formal and functional characteristics (wall, coin, pillar), which can be divided 149 into subclasses or subsets, based on the variation of certain characteristics (e.g. rectangular 150 pillar, square pillar, oval pillar). This is followed by categories, which allow the class to be broken 151 down into constituent elements (e.g. column, which is subdivided into capital, shaft and base). 152 Likewise, the subcategory allows the order or building technique used to be defined (e.g. opus 153 incertum shaft). Finally, the type indicates the material used (e.g. limestone); the instance, on 154 the other hand, constitutes the individual object created (Borriello et al., 2025). 155
156 Figure 3 - Semantic structure of Pompeian architecture 157 In addition to being assigned an ID during modelling, each instance was accompanied by a 158 set of data that allows for the management of archaeological information in various ways. The 159 modelling phase and subsequent implementation of BIM objects were structured to combine, 160 on the one hand, a broad pattern of archaeological requirements and, on the other hand, to 161 avoid overloading the BIM system. All this required operational choices to be made (Carpentiero 162 - D’Auria 2023): the addition of numerous families available locally would make it possible to 163 compensate for the lack of archaeological elements within the BIM platform; however, this could 164 lead to the possible loss of essential data during export. 165 Among other necessary choices, it was useful to refer to the data management system of 166 the Archaeological Park of Pompeii for the nomenclature of the walls. This system involves 167 dividing a single wall into two different sides, so in the information set for each instance, it was 168 necessary to add a field that would allow the two separate sides to be joined into a single wall 169 entity. 170 Another choice involved the introduction of a code to identify elements other than walls, such 171 as floors, ceilings and cladding. 172 Lastly, necessary choices concerned the reconstruction of the quoins, identified as sections 173 of masonry, and the doorways, which were modelled as empty spaces. These examples are 174 just a few of the difficulties that are evident in the modelling phase. For this reason, it was clear 175 that there was a need to compare the semantics of Roman architecture with IFC formats and 176 the main ontologies of the archaeological domain. 177 The semantic comparison between data schemas 178 IFC 3 is both the schema and exchange format more widely used in the BIM domain. The 179 hierarchical structure that arranges classes in descending order and connects them through 180 specific relationships is actually very complex and at the same time descriptive: at the point of 181 development it reached nowadays (with the version 4x3 of the standard) it can be argued that 182 IFC, of the available and approved-on data schema is the more advanced in the semantic 183 3 BuildingSMART Alliance 2024, Industry Foundation Classes Release 4.3 ADD2 (IFC 4.3 ADD2) (https://standards.buildingsmart.org).
description of built assets; it was put to the comparison with the created “pompeian” classes 184 and a mapping (connection) was performed to the more semantically correspondent. The 185 correspondence was registered both in a spreadsheet and graphically. 186 As an example, in Fig. 4, we position the class ifcWall, its declination in “Opera Vittata” and 187 the materials that make it up and determine the type. The various wall “instances” (entities in 188 the project) will inherit these characteristics. 189 In a comparison work of complete mapping of entities, a missing percentage relationship 190 was estimated for several elements such as quoin, arch or threshold, for which there are no IFC 191 classes. 192 Going into the specifics of the class “Wall”, the declination in the typology standard was also 193 analysed. As can be seen graphically from the mapping connections in Fig. 5, the “Archaeo194 Wall” class (on the left) corresponds to the ifcWall class of the 4x3 standard (on the right), the 195 latest official version. The typologies, on the other hand, flow into an ifcWallType unique class 196 where the various specifications due to building works and materials can subsequently be 197 created inside the project. Optionally, the various instances can take on an additional 198 Enumerative Type which, however, does not help to better specify the semantics at the level 199 required by the archaeological needs. 200 The same mapping process was carried out with CityGML , the de-facto semantic standard 201 in the geospatial sciences. Designed for representations at the urban scale, which includes 202 morphological data for built and natural environments, similarly to IFC has a dually structured 203 nature (with geometry and information combined) but it is operates in the Geography Markup 204 Language (GML). 205 Due to the number of classes (named “features”) available, CityGML is subdivided in 206 interconnected modules, that connect through the same hierarchy. This standard is flatter and 207 less descriptive than IFC, and customisation mechanisms have to be employed that deviate 208 from the predefined classes to reach good. The definition of types is less complete than the IFC 209 because it must be reproduced with a customised mechanism called “CodeList”. Using the 210 example illustrated before, specifically for the class “WALL”, this flows into the “Building 211 Constructive Element”, a very generic concept, while the types of flow into the “CodeList”, which 212 is not globally approved (Rosignoli et al., 2025). 213
214 Figure 4 - the complete archaeological classes “tree” on the left and a zoom-in on the entity 215 wall in “opera incerta” 216
217 Figure 5 - in the image, an extract from the visual mapping performed between 218 the classes of the ex-novo hierarchical “tree” constructed for the archaeological 219 entities and the partial hierarchical schema of IFC 4X3. The extract focuses on 220 wall entities. It is clear from the number of arrows that often converge in the same 221 direction towards IFC classes that there is a loss of semantic granularity.The 222 complete archaeological classes “tree” on the left and a zoom-in on the entity 223 wall in “opera incerta” 224 The possibilities provided by ontologies: an overview 225 The need to align this semantic decomposition with the most popular standard formats 226 required the integration of data with additional systems capable of supporting this type of 227 description. This led to a reflection on conceptual representation tools and semantic 228 interoperability closer to the archaeological domain, directing an analysis of what is already 229 available in the current landscape and what alternatives they presented for the description of 230 the entities of the archaeological semantic tree. Evidence of this can be found in ontologies, i.e. 231 conceptual models that provide a formal structure to describe information in a systematic and 232 interoperable way. The system of ontologies has found wide application in cultural heritage as 233 it provides a common language for the description of the asset, allows a standardization of 234 terms and concepts to ensure a uniform description, favours interoperability between systems 235 and supports more advanced and precise research, since it enables data to be queried based 236 on concepts and their relationships, not only on textual terms. In addition, these systems allow 237 for providing adequate support in the identification of classes and properties to be included in 238 the semantic tree of the archaeological building, where the conceptual structure offered by the 239 BIM and GIS systems does not sufficiently meet the needs of archaeological documentation. 240 In particular, the research involved the analysis of international and national ontologies and 241 thesauri: 242