Documentation of cultural heritage monuments with CityGML: an application for ancient theatres

The scope of this research is to identify the concepts that describe cultural heritage monuments and model them with CityGML. CityGML is the most popular data model for storing and sharing semantic 3D geographic data and there is an increasing interest in its use in the Cultural Heritage field. An Application Domain Extension that covers the most important concepts for describing monuments with special focus on the ancient theatres is developed. The INSPIRE data model is reviewed and its integration with CityGML is discussed. Following the proposed extension, a CityGML model is constructed for the ancient theatre of Hersonissos in Crete. To visualize the model, it is transformed using the Generics approach.


Introduction
In the past ten years, a large volume of 3D spatial datasets has been developed for cultural heritage monuments; these data are needed for different aspects of the monuments' management such as mapping, conservation or restoration, monitoring and protection [8]. Modeling these data with CityGML, a data model that can handle 3D information, is a necessity since it provides the interoperability framework in which data can be easily used and exploited by different applications that communicate with each other. In recent years, 3D data acquisition technology has been used extensively to create 3D spatial datasets for the representation of monuments and sites, their visualization and their virtual navigation. Using software that adopts the CityGML standard can support the storage and management of a wealth of semantically enriched information. The representation and documentation of a monument is a difficult task because it encompasses several aspects that cannot be easily documented. It is difficult to document the architecture of a monument and its different structural components, and also consider the 'life cycle' (degradation through time, impacts from natural or human induced disasters, protection, reconstructions, etc.) of the monument and its components. To successfully model all these characteristics a CityGML extension cannot be generic but must be specialized. Numerous CityGML extensions have been developed [5,15,20] for modelling the history, status and legal protection of cultural heritage sites.
The objective of this research is to define the basic classes for describing a monument with focus on ancient theatres (Greek and Roman theaters that have a relatively similar architecture). This is accomplished within an extended schema of CityGML implementing a methodology validated by OGC CityGML Working Group and the Special Interest Group 3D. In this research, the extension is developed using the level of detail 3 (LoD3) of CityGML rather than the level of detail 4 (LoD4). The reason for this is that the documentation of monuments includes information that require descriptions of openings (doors, windows, roofs) but not necessarily description of interior elements for which level LoD4 would be more appropriate. The focus of the research is on ancient monuments that may, or may not, be located inside an archaeological site. Since CityGML and INSPIRE 1 data models have common properties and CityGML "lends" the 3D geometry description to the INSPIRE data model, a monument is described using CityGML concepts with properties added from INSPIRE as needed.

2
Theoretical framework

Description of cultural heritage sites
In Greece, the Law 3028/2002 for the Protection of Antiquities and Cultural Heritage defines as areas of cultural heritage the archaeological sites (sites on land or sea with ancient monuments constructed from antiquity up to 1830), the historical places (places on land or sea where exceptional historical or mythical events have occurred or where monuments constructed beyond 1830 are located) and the monuments ("ancient monuments" constructed before 1830 or "newer monuments" constructed after 1830). This law specifies the designation of a cultural heritage site, its location and its protection status by a Presidential Degree, the documentation of its elements, its preservation and protection from various damages, the prevention of illegal excavations, accessibility to the site for education and public awareness etc. A protection zone is usually designated around a cultural site; the protection zone can be either of type A, construction is completely prohibited, or of type B, in which case there are restrictions on new construction, land use and activities permitted. The information on cultural sites is stored in the official database of the Ministry of Culture (Ongoing Catalog of Archaeological Sites and Monuments of Greece) and includes the official name, location, designation acts, type of site, ownership of the premises etc. This database will be supplemented by the integrated geo-database, core element of the Archaeological Cadaster, a project currently under development that will store spatial information on different thematic layers and therefore enable sophisticated spatial analysis.
In the INSPIRE framework, the most significant directive for managing spatial information, there is not a specific theme for cultural heritage monuments. The 1 Infrastructure for Spatial Information in Europe "cultural site" and "monument" concepts are represented respectively by the "Protected Sites" and "Buildings" themes. The focus of the first theme is on the legal issues of the protection of the site -the legislation that defines the protection status, its type and spatial extent-and on the environmental characteristics of the area surrounding the monument. The "Buildings" theme documents the geographical location and the monument's characteristics. Attributes assigned to the main classes of the theme ("Building", "AbstractBuilding" and "AbstractConstruction") may include conditionOfConstruction, dateOfConstruction, elevation, name etc. Classification of monuments is performed through the attributes: currentUse that describes the activity in the building (e.g. cultural) and buildingNature that represents the building type (physical characteristics or classification e.g. landmark). A complete discussion of the use of INSPIRE for documenting cultural heritages sites in Greece is available in [10]. The authors propose an extended application profile of the INSPIRE data model that covers the legal and area protection issues of cultural heritage sites in Greece.
Although cultural heritage protected areas can be described using these themes there are no guidelines for describing in detail the semantic information of cultural heritage characteristics such as architecture and style, historic and past events that had an impact on its lifetime and others. The focus of INSPIRE is on environmental data to support environmental policies and therefore does not address these issues. Semantic information for cultural heritage is discussed in the CIDOC Conceptual Reference Model [9] in up level semantics that provides definitions and a formal structure for the implicit and explicit concepts and relationships for documenting cultural heritage objects (e.g. class "E27 Site" or "E24 Physical Man-Made Thing").
As a result of advances in 3D data acquisition technology -3D laser scanners, active or passive sensors and computer vision-based technologies for capturing and modeling the real world using imagery -an exponentially increasing number of 3D datasets of cultural heritage sites have been developed in the past ten years [7]. The data are used in research (e.g. for reconstructing the historical landscape of a region) but they are also necessary for the day to day management of monuments (e.g. for preservation processes). To be useful, the data must be modeled using a logical framework that resolves interoperability issues among different databases (e.g. 3D data of different monuments in the same site, cadastral data etc.). CityGML is the appropriate data model for performing this. INSPIRE covers 3D spatial objects but does not cover fully the details of 3D modeling neither exploits some technology advances in 3D storage and visualization such as point clouds and others.

The CityGML data model
CityGML is an open XML data model for storing and sharing information of 3D city models and is based on the GML3 language published by O.G.C. 2  Appearance, Bridge, Building, CityFurniture, CityObjectGroup, Generics, LandUse, Relief, Transportation, Tunnel, Vegetation, WaterBody, and TexturedSurface (no longer used). The CityGML "Core" defines the most significant, components and a CityGML "profile" is a combination of themes with the CityGML core. CityGML includes a geometric-topological model and a thematic data model. The geometric model permits a consistent and homogeneous specification of the geometric and topological properties of spatial objects in a 3D city model and its main class is the _CityObject GML sub-class of _ GML class _Feature. The thematic model determines the thematic properties of the geometric model [16]. The Building model is the most significant component of CityGML; it is used to document the buildings and their components in terms of their geometry and their semantics at the five levels of detail. Main classes are the "Building" and "BuildingPart" that inherit features such as, function, use, year of construction, year of demolition, roof type, measured height, number and height of floors above and below ground from the super class _AbstractBuilding.
There is a close connection between INSPIRE and CityGML since: ▪ Both standards use Building, BuildingPart, and AbstractBuilding (features) as concepts (and with the same semantic classification) ▪ Many CityGML concepts have been adopted by the INSPIRE Building theme: Building -BuildingPart aggregation, extended2D profile and many properties such as roofType, measuredHeight, yearOfConstruction, numberOfStoreys, terrainIntersection etc. ▪ CityGML introduces concepts in Profile core3D (at LoD1 level) and Profile extended3D (at LoD1 -LoD4 levels) and 3D object-geometry (geometry3DoD1-2-3-4) of INSPIRE. CityGML is designed as a standalone data model independent of applications or systems. However, often, there is a need to create custom model profiles (extensions) that follow the conceptual requirements of different applications (e.g. modelling information on energy infrastructures that require a more systematic and customized description). This is possible using generic objects / attributes or the development of extensions following the Application Domain Extension (ADE) mechanism. Generic objects and attributes provide new features and/or additional attributes to the CityGML extension, without changing the default XML schema. The CityGML ADE mechanism supports the extension of the model since it permits the introduction of new concepts that describe in detail the characteristics of different application domains. These new concepts refer either to new properties of existing classes, e.g. number of occupants in a building or entirely new classes e.g. Byzantine monument. Each ADE must be created in a separate XML schema with its own namespace [16].

State of the art
The use of CityGML in cultural heritage applications has been adopted relatively recently and is getting increased interest since it has the potential to fulfil the need of interoperability among 3D cultural heritage databases. In [20], the authors point out that CityGML is a useful tool for the Built Cultural Heritage (BCH) domain because it supports different levels of detail and scale of the data. However, the standard has several limitations when used for a thorough documentation of cultural heritage sites (for example lack of more specialized concepts and the representation of relevant thematic information). They extend, therefore, the standard with an ontology through the ADE mechanism that addresses issues related to the conservation of BCH monuments. In a similar line of thought, the authors in [5] propose a CityGML extension for architectural heritage. They selected some key entities that refer to the whole building and some properties that characterize it as an architectural heritage building and those attributes necessary for documenting its protection. Their efforts were partially successful since the documentation of the various building specific characteristics is not an easy task. In [20], it is pointed out that huge volumes of 3D data of cultural heritage buildings can be developed easily nowadays, highlight the need for a semantic framework for documenting this information and propose a methodology that integrates different data for the historic port of Nantes. In [21], the authors participated in a research project in the Netherlands in which many stakeholders were involved; topics that were extensively discussed included 3D data collection, information building standards, 3D data maintenance, and their use in various applications. The aim of the research was to investigate the possibility of creating a 3D National Data Infrastructure and propose a pilot project for that purpose.
In recent years, 3D information technology has been used extensively to create 3D spatial datasets for the representation of ancient monuments and sites, their visualization and/or their virtual navigation [13]. The author in [13] created a 3D model of the San Giorgio fortress on Capraia Island in Livorno that was imported in the open source SGJ-3D software with the information structured following the CityGML standard. In [19], the authors created a prototype application for visualizing CityGML geometric information and applied it to architectural heritage objects.
In the CityGML official website there is a list of cities, most of them in Germany, the Netherlands and in USA, for which 3D data sets have been developed at various levels of detail. Some of the datasets are freely available to the public. In the website there are also presentations and discussions of 3D modeling software and programming applications (APIs) that are useful for validating CityGML datasets. Other software with 3D modeling capabilities include ESRI's 3D Cities Project (3DCity Information Model geodatabase) and the SketchUp (CityGML plug-in) and others. A detailed list of software that can handle 3D data is available in [1].
The Building Information Modelling (BIM) covers the digital representation of the natural and operational characteristics of buildings. Further capabilities for documenting and managing cultural heritage buildings are provided by the extension of BIM to BHIMM or HBIM (Built Heritage Information Modeling / Management) [4], a library for documenting buildings from point cloud data and image survey data [6]. The authors in [6] investigated the HBIM and 3D GIS software synergy using the logic framework provided by the CityGML data model.
The matching of 3D models to CityGML refers to the conversion of their geometry and their semantic information to the classes specified by the standard. The authors in [6] used SketchUp (and the CityGML plug-in) software to convert automatically the geometry of a 3D model (BIM model) to CityGML concepts and then expanded the CityGML model by matching manually the semantic information of the BIM model to CityGML classes. The standard then allows for additional information (e.g. properties) to be added by editing the resulting file. As a case study they modeled a street in Dublin with 18th century buildings (Georgian Street).
Finally, the authors in [8] developed the GIRAPIM software as a collaborative platform for interactive 3D cultural heritage documentation using the CityGML and an ontology that provides the vocabulary for key features of a cultural heritage site (e.g. pathology and intervention).

Guidelines for the development of a CityGML ADE
Two different approaches can be followed for integrating CityGML data and application specific data [16]: ▪ Integration of CityGML objects into a broader application and designation of their in-between connection. For example, CityGML data are embedded in the application's XML files or stored as attributes in the application's objects following the data model. ▪ Integration of application data into a CityGML instance document. This methodology is preferable when the application has the same structure as CityGML. Then, the application data can be visualized with additional properties from the CityGML objects and only a few additional new object types must be specified. The guidelines provided by CityGML, for the second approach specify two alternative methodologies: ▪ Define new feature types within the ADE new namespace that are based on CityGML abstract or concrete classes. In this way, the new objects automatically inherit all properties and associations from the respective CityGML super classes. ▪ Extend existing CityGML feature types with new concepts to document either their geometry of properties. This is implemented using a "hook" in the xml schema of CityGML that allows to attach additional properties in the form of "GenericApplicationPropertyOf<Featuretypename>" where <Featuretypename> is the name of the feature type in which it is included. For implementing the first method, the authors in [3] developed a process that was eventually validated by the OGC CityGML Working Group and the Special Interest Group 3D. With this approach the new ADE is modeled using UML class diagrams. After investigating the advantages and disadvantages of various alternatives and the associated technical difficulties, they selected the alternative which suggests that properties must be added as subclasses in the ADE. The subclasses are suppressed from the generated XML schema and in this way the rules of UML, ISO 19100 and OGC are not disturbed. In the UML schema, a subclass is marked as an ADE extension using a stereotype which defines that the ADE subclass is not mapped to an XML schema component.
The first step of the process is to regenerate the UML model of CityGML from its XML schema. The next step is to model the new concepts as subclasses of the existing CityGML ones marked with the stereotype <<ADEElement>> which permits only the addition of properties to the CityGML class [3]. The third step is to generate the XML Schema (a GML application schema) from the ADE constructed in UML.
Alternatively, the CityGML extension can be developed using GenericCityObject and _genericAttribute methodology; this is the official way for extending the model without changing its template; however, it provides a limited number of data types. Nevertheless, the advantages of using ADE instead of Generics are very significant since in this way: a) a specialized namespace that introduces and describes the new concepts is created, b) the extended schema can be validated and established as a separate formal schema, c) several different ADEs can be used in one application [2].

Concepts for modelling cultural heritage monuments in CityGML
The monuments can be described as a sub-class of "Building" (Fig. 1), therefore the ADE for cultural heritage monuments must follow the specifications of the CityGML -Building thematic module. Fig. 1. The UML package diagram illustrating the separate modules of CityGML [16] and the suggested ADE for monuments.
"Monument" is the most significant new concept introduced; it is a subclass of "Building" that refers to the general CityGML category "CityObject" and therefore inherits their properties and relationships. The geometry of "Monument" is constructed according the model's geometry and depending the level of data detail the geometry can be a point, a line, a polygon or a composite object (e.g. MultiSurface). The "Monument" as a "Building" may have individual parts ("BuildingPart") and may be within a cultural heritage site ("CHSite"). The "CHSite" is a "Protected Site" around which there may be a "Protection Zone". Both the "CHSite" and the "Monument" are managed by a "Responsible Agency". The integration of these new concepts in the Building model for LoD 3 is illustrated in Fig. 2. New relationships are added between the new concepts (e.g. fallsWithin). These concepts and their generic attributes are discussed extensively in [10]. Since INSPIRE and CityGML models have common properties and the 3D geometry is "borrowed" from CityGML to INSPIRE, the description of monuments is based on CityGML while concepts and properties from INSPIRE are added as needed.
These concepts (classes, properties, and relationships) provide a general description of a monument. Since each monument type may have different architectural characteristics, a more detailed set of descriptive attributes is necessary. To elaborate the concepts discussed above in a case study, a CityGML model was developed for describing ancient theatres which are monuments of unique architecture.

4
Development of a CityGML ADE for documenting ancient theatres

Conceptual design
Ancient theatres are usually semi-circular, open air and consist of three main parts [17]: ▪ The main theatre or "cavea" or "koilon" (Fig. 3), the area where the audience was seated. It has a large capacity and is formed as a cone that extends beyond the semi-circle of the theatre. Usually, it is divided into tiers ("kerkides") and horizontal corridors between the tiers ("diazoma"). The corridors and the sideways ("parodoi") provide access to the cavea. Seats in the first rows are throne like reserved for the officials ("proedria"). ▪ The "orchestra", the circular or semi-circular area, located slightly below the stage, where the chorus stood and acted. In the orchestra, there was an altar for sacrifices (usually in Dionysus) called "thymeli". In some theatres, at the periphery of the orchestra, there was a pipeline for water runoffs ("evripos"). ▪ The "scaenae" (stage), an independent, low, rectangular building behind the orchestra, the area where the actors performed. Next to the stage, are the backstage ("paraskenia"), rooms for storage. Along the wall of the stage, there was often an elevated floor, the "logeion", on which the actors acted. In front of the stage, there is a gallery with columns, the "proskinion". In some theatres, there was a gallery that led to the entrance of the theatre, the "portico".

Fig. 3.
The main parts of an ancient theatre [11].
The main class "Monument", sub-class of the class "Building" is further specified by the "AncientTheatre", a sub-class that describes the ancient theatre. The main components of the theatre are described by the classes "Cavea" (and its sub-classes "SummaCavea" (the upper cavea), "MediaCavea" (the middle cavea), and "ImaCave" (the lower cavea), "Orchestra", "Scaenae", and "Portico". All are sub-classes of "BuildingPart". These classes and sub-classes are described by a series of special characteristics (attributes) that are documented in Fig. 4.

Development of the UML diagram and the XML schema
The CityGML UML model was generated from the XML schema using the Enterprise Architect modeling tool. The CityGML model (version 2.0) was first imported as XML in Enterprise Architecture and then converted to UML. A new ADE package, the "Archaeo", was developed with its corresponding new namespace. The concepts for describing a monument/theatre were created as sub-classes of existing CityGML classes (generalization) following the conceptual design described above and as feature types marked by "stereotype". The proposed new class can be the same as a CityGML class and therefore the stereotype <<ADE>> is used to characterize the relationship between the two classes, or the proposed class can be a subclass of a CityGML class and therefore their relationship is not characterized by a stereotype and the class is modeled as <<FeatureType>>. The properties of each class were created as attributes and their datatype defined according to the ISO standard for model consistency. Part of the UML diagram is illustrated in Fig.4. The Java tool ShapeChange was used to generate the XML schema of the extension from the UML. This tool implements the UML to GML encoding rules as defined in ISO 19136, ISO 10118, and ISO 19109 [18] and generates the ADE XML. ShapeChange was customized using the validated approach of Kutzner [12]. Thus, the UML classes correspond to GML elements and the schema is generated. The schema was validated in Altova XMLSpy 2020 software. The final version of the schema was prepared after correcting various errors.

The theatre of Hersonissos in Crete
The ancient theatre of Hersonissos in Crete (Fig. 5) was built in the 1st century AD and is located 2 km outside the modern settlement, on the northwest of the island, at an elevation of 11 m. Its cavea consists of 11-seats rows of 45.5m diameter and is located at 12.7 meters from the columns of the stage. The width of the seats is 84.5cm. The diameter of the orchestra is 27.2m, the column length of the stage 45.75m and the width of the proskinion 19.3m. There is an actors' entrance and sideways (parodoi). Additional information is available at: https://romantheatres.ims.forth.gr/architecture/view?id=18. The 3D model is based on a hypothetical reconstruction of the theatre that was created in 3D Studio Max in the research program "Roman Theaters" [14]. As part of this project, an online database of ancient Cretan theaters and their 3D representation was developed. As discussed earlier and also by Biljecki et al. [2], most CityGML software do not support new ADEs, therefore new datasets cannot be visualized. To address this issue, either an existing software must be customized or a new one must be developed. The second option was beyond the scope of this research; therefore, to visualize the theatre's dataset, the new classes and properties were incorporated using the "_GenericApplicationPropertyOf" approach. For this purpose, the CityEditor plugin of Sketchup was used.
Sketchup is a free software that supports 3D visualization and editing of CityGML data via the CityEditor plugin with the use of «GenericApplicationPropertyOf». The 3D model was imported in the software and georeferenced. The three main parts (cavea, orchestra and scaenae) were extracted from the model as different building parts and documented with the new attributes and the geometry model provided by CityGML. Each of these was then described with the key properties inherited from the CityGML "Building" class and with new properties imported as GenericApplicationPropertyOf (Fig. 6). The 3D model can be exported as a GML 3 (XML document) and then imported in applications that support this data modelling.
An example of the documentation using Generics is provided below.

Concluding remarks
CityGML is the most popular data model for storing and sharing semantic 3D geographic data and is used worldwide in a variety of applications. However, there 3 Geography Markup Language are usually application specific requirements for modelling and managing the 3D information. The application specific profiles can be developed either using Generic objects / attributes or implementing Application Domain Extensions. CityGML is quite complex in its composition and both methods must be validated before they can be used. The first approach is relatively straight-forward, however, there are several disadvantages; usually, the second approach is adopted although ready-to-use tools for the visualization of the extended model's data are not available and must be developed.
The documentation of a monument must provide a description of its architecture (different types of buildings with different features) and also the lifecycle (excavation, restoration, protection, conservation, vulnerability to hazards, etc.) characteristics of the building as a whole and its components. This cannot be accomplished by generic extensions to the CityGML standard and therefore specialized extension must be developed. However, although several software tools can produce and visualize CityGML data, few support ADE extensions and most often they do that partially (3DcityDB, FZK Viewer, citygml4j, FME). Therefore, using a new ADE requires either customization of an existing software or development of a new one which is something that limits the use and easy integration of ADEs into applications.
Future steps of this research include: ▪ Customize existing CityGML software to support existing 3D datasets as GML datasets for different ADEs. ▪ Use the 3D CityGML monument datasets in applications related to the lifecycle of the monuments such as routine maintenance, protection from extreme events, disaster management etc. and for research purposes e.g. spatial analysis and spatial relations of different monuments. ▪ Develop appropriate 3D CityGML monument datasets queries for extracting semantic information such as architectural details and styles (ionic, doric etc.). ▪ Explore the integration of an ADE for monuments in the geo-database under development as part of the Archaeological Cadaster of Greece. ▪ Explore the linkage of 3D monuments datasets to other related spatial datasets to articulate an integrated spatial identity of a monument.