QUERYARCH3D: QUERYING AND VISUALISING 3D MODELS OF A MAYA ARCHAEOLOGICAL SITE IN A WEB-BASED INTERFACE

: Constant improvements in the field of surveying, computing and distribution of digital-content are reshaping the way Cultural Heritage can be digitised and virtually accessed, even remotely via web. A traditional 2D approach for data access, exploration, retrieval and exploration may generally suffice, however more complex analyses concerning spatial and temporal features require 3D tools, which, in some cases, have not yet been implemented or are not yet generally commercially available. Efficient organisation and integration strategies applicable to the wide array of heterogeneous data in the field of Cultural Heritage represent a hot research topic nowadays. This article presents a visualisation and query tool (QueryArch3D) conceived to deal with multi-resolution 3D models. Geometric data are organised in successive levels of detail (LoD), provided with geometric and semantic hierarchies and enriched with attributes coming from external data sources. The visualisation and query front-end enables the 3D navigation of the models in a virtual environment, as well as the interaction with the objects by means of queries based on attributes or on geometries. The tool can be used as a standalone application, or served through the web. The characteristics of the research work, along with some implementation issues and the developed QueryArch3D tool will be discussed and presented.


INTRODUCTION and related works
Steady advances in the field of surveying, computing and digital-content delivery are changing the approach Cultural Heritage can be virtually explored: thanks to such new methodologies, not only researchers, but also new potential users like students and tourists, are having the chance to use a wide array of new tools to obtain (3D) information and perform analyses with regards to art history, architecture and archaeology.One useful possibility is offered by computersimulated 3D models, representing for example both the present and the hypothetical status of a structure.Such digital models are sometimes linked to heterogeneous information and queried by means of (sometimes web-enabled) GIS tools.In such a way, relationships between structures, objects and/or artefacts can be explored and the changes over space and time can be analysed.For some research purposes, a traditional 2D approach generally suffices, however more complex analyses concerning spatial and temporal features of architectures or archaeological sites require 3D tools, which, in some cases, have not yet been implemented or are not yet generally available.Nowadays reality-based 3D models of large and complex heritage sites are generated using methodologies based on image data [1], range data [2], classical surveying or existing maps [3].The choice depends on the required accuracy, object dimensions and location, surface characteristics, working team experience, project"s budget, final goal, etc.However, more and more often the different methodologies are combined to derive multi-resolution data at different levels of detail (LoD), both in geometry and texture, and exploit the intrinsic advantages of each technique [4,5,6].

________________________________________________________________________________
Geoinformatics CTU FCE 2011 11 One interesting opportunity offered by reality-based 3D models is to use them as visualisation "containers" for different kinds of information.Given the possibility to link their geometry to external data, 3D models can be analysed, split in their sub-components and organised following proper rules.This is, for example, the case of (modern) buildings, where their geometry, topology and semantic information is organised in Building Information Models (BIMs).By extending the concept of BIMs to the framework of Cultural Heritage, it is easy to understand that these properties/capabilities could facilitate data organisation, storage, use and communication.Powerful 3D visualisation tools already exist, but often they implement no or only limited query functionalities for data retrieval, possibly web-based.Queries are actually typical functions of current GIS packages, which very often fall short when dealing with detailed and complex 3D data ( Figure 1).Probably, one of the most well-known examples is Google Earth: the user can browse through the geospatial data and get, when necessary, external information by clicking on the selected object, or by activating a selectable layer.However, more complex, interactive queries are not implemented: it is not possible, for instance, to select all structures in a city/site built between a certain interval of time (i.e.350-400 AD), or planned by a certain architect (provided this information is given and linked to the geometric models).Different authors have proposed solutions for 3D data management and visualisation, possibly on-line [7,8,9,10,11,12] but, no unique, reliable and flexible package/implementation is commercially available nowadays.When it comes to data modelling and storage, CityGML [13] represents a common information model for the representation of 3D urban objects, where the most relevant topographic objects in cities and their relations are defined, with respect to their geometrical, topological, semantic and appearance properties.Unfortunately, even CityGML"s LoD4, the highest level of detail, is not meant to handle highresolution, reality-based models, which are characterised by complex geometry and detailed textures.Moreover, CityGML is conceived for modern buildings, andunderstandinglynot for archaeological models/sites, which generally differ in terms of scale and scope.Regarding visualisation, some development tools exist in the videogames domain and can be adapted to support 3D geodata (e.g.Unity3D, OSG, OGRE3D, OpenSG, 3DVIA Virtools, etc.) but with limited capabilities when it comes to displaying large and complex reality-based 3D models.When it comes to (3D) web services, some initial experiences were carried out [13], but, again, a standard and widely accepted solution does not exist as of today.Keeping in mind the mentioned approaches and the existing limitations, an ideal tool able to perform analyses in the framework of architectural and archaeological Cultural Heritage should be able to perform (at least) the following four tasks: a) Handle fully 3D multi-resolution datasets, b) Allow queries based both on geometries and on attributes, c) Support 3D visualisation/navigation of the models, d) Permit both local and on-line access to the contents.This article introduces and describes the QueryArch3D tool, which is the result of a project aiming at creating a tool chain for a web-based visualisation and interaction with a reality-based multi-resolution 3D model, i.e. aiming at the above-mentioned four characteristics.As test field, the archaeological Maya site in Copan (Honduras) was chosen.
Copan is an UNESCO World Heritage site and one of the most thoroughly investigated Maya cities, located on the southern periphery of the ancient Maya world, in today"s Honduras.The site contains over 3700 structures.Thanks to excavation studies, a dynasty of sixteen kings ruling between the 5 th and the 9 th cent.A.D. could be identified.Temple 22 is one of the most representative structures.It was once three storeys high and covered with plaster, paint and sculpture [15].However, today only the first storey remains, the upper facades and sculptures have collapsed making it ________________________________________________________________________________ Geoinformatics CTU FCE 2011 12 is difficult for visitors to imagine this temple without the aid of 3D reconstructions.Different types of data exist and have been created during the course of time: the first recorded surveying of the archaeological site dates back to the 19 th cent.[ 16,17] as schematic maps of the Principal Group were drawn.More detailed maps were successively published in 1896) [18] and 1947 [19].From the 1980s are maps and drawings of the Principal Group at scales of 1:100 and 1:200 [1ř], while archaeologists on the Proyecto Arqueológico Copán (PAC I) published maps of the valley"s residential sites at a scale of 1:2000 [21].GIS data of Copan has been created only recently by Maca [22] and Richards-Rissetto [23]: PAC I maps (covering 24 km 2 ) were digitised, georeferenced and integrated with more recently available large-scale maps to create a GIS for the entire Copan Valley, containing data of archaeological buildings, hydrology, contour lines and a Digital Elevation Model (DEM) of the valley.In 2009, high-resolution 3D data were acquired using terrestrial photogrammetry, UAV platforms and terrestrial laser scanning [24].Using and combining all these data, the 3D contents for the web-based visualisation and interaction QueryArch3D tool were created.

THE QUERYARCH3D TOOL
As mentioned in the previous section, no tool currently exists which is able to guarantee the four identified properties.
Thus the goal of this research work is to implement a prototype, called QueryArch3D, which can fulfil all aforementioned tasks.QueryArch3D is tailored to the needs of researchers working at the Copan archaeological site, but basic concepts can be extended and generalised to similar contexts.Before proceeding with the development of the QueryArch3D tool, a general check was performed on all available data (spatial and non-spatial) for potential incompatibilities (different formats, different modelling paradigms, etc.), geometric and/or semantic inconsistencies.The development of QueryArch3D was then split into four successive steps: I. Definition of a conceptual schema for LoD, adoption of geometric and semantic hierarchies, II.
Check and structure existing data accordingly, III.
Data integration and homogenisation, IV.
Development of the visualisation and query front-end.

Step I -Levels of detail and hierarchies
In order to cope with the complexity of multiple geometric models, a conceptual scheme was defined to handle multiple levels of detail, which are required to reflect independent data collection processes, levels of detail facilitate in fact efficient visualisation and data analysis.For the Copan site, four levels of detail were identified for the structures: the higher the LoD rank is, the more detailed and accurate the model is.The used levels of detail are (Figure 2): LoD1 contains simplified 3D prismatic entities with flat roofs.All LoD1 models were obtained starting from the GIS data [23], i.e. a 2D shapefile with attribute data containing also the structures" height.Polygon features were first triangulated and then extruded.
LoD2 contains 3D structures for some exteriors of the buildings.The sub-structures (e.g.walls, roofs or external stairs) can be identified.For the LoD2, hypothetical reconstructions models obtained in 3D Studio Max were used.
LoD3 adds the interior elements (rooms, corridors, etc.) to the structures.Some simplified, reality-based models can be optionally added, both to the interior and to the exterior of the structures.For the Copan dataset, the interior rooms of the hypothetical reconstruction models of LoD2 were used, plus some reality-based simplified models of two stelae, the corner mask and the interior doorway of Temple 22.These reality-based models were obtained from the more detailed ones (acquired in 2009 [24] and used in LoD4) by applying mesh simplification algorithm.The geometric simplification was in the order of 30% of the original models.LoD4 contains structures (or parts of them) like high-resolution geometrical 3D models.These models were further segmented into sub-parts.Currently, LoD4 contains the segmented models of Stela A and Stela B, as well as the corner mask and the interior doorframe of Temple 22.The adoption of a LoD-dependent hierarchical schema required the contextual definition of geometric and semantic hierarchical schemas.This was achieved by an accurate identification and description of the so-called "part-ofrelations", in order to guarantee a spatio-semantic coherence [25].At the semantic level, once every structure is defined (e.g.: What is a temple or a palace?How is it characterised?What are its components?), its entities are represented by features (stairs, rooms etc.) and they are described by attributes, relations and aggregation hierarchies (part-of-relations) between features.If a query on an attribute table is carried out for a certain roof, the user should retrieve information not only about the roof itself, but also about which structure contains that roof.This is exemplified in the hierarchy shown in Figure 4 (left), which is based on a Copan temple.However, the semantic hierarchy needs to be linked to the corresponding geometries, too: if a query on an attribute table is carried out for a certain roof, not only the linked attributes should be retrieved, butif neededalso the corresponding geometric object.This operation requires however to structure the geometric models in compliance with the hierarchy.________________________________________________________________________________ Geoinformatics CTU FCE 2011 13

Step II -Data check and structuration
In case of the LoD1 models, a data aggregation was necessary in order to reduce the ca.19000 polygons to the current ca.3700 structures.Data aggregation was performed on the basis of the existing attributes, after some manual editing was carried out to check geometries for topology errors (overlaps and gaps) and to correct and normalise the attached attributes table.An example is given in Figure 3.For LoD2, LoD3, LoD4 the segmentation of the models into sub-parts was carried out according to the hierarchical schemes in order to perform a proper classification and the subsequent assignment of attributes to each segment.An example is given in

Step III -Data homogenisation and integration
Once all data were checked and structured, data homogenisation and integration could be performed: all geometric models were aligned in order to spatially "fit" together (e.g. the reality-based corner mask with the Temple 22 models) and georeferenced, in order to share the same coordinate system.A TIN-based digital terrain model for landscape contextualisation was created using GIS data [23].To all structures objects were finally given an elevation value, taken from the DTM.With respect to all available non-spatial tabular data (mainly coming from MS Access databases, text files, FileMaker Pro databases), non-spatial tabular data (mainly coming from MS Access databases, text files, FileMaker Pro databases), they were checked, restructured and integrated.In order to reduce data-formats heterogeneity, PostgreSQL was chosen as DBMS where to store all data.Moreover, thanks to its PostGIS extension, spatial data also could be stored in the same database, providing a valuable (and unique) data management system.

Step IV -Front-end development
For data administration purposes, a simple front-end, based on Microsoft Access 2010 and relying on Access Runtime 2010, was developed and distributed to the project members.The front-end connects directly to the PostgreSQL server and allows update operations on the data currently stored.For the interactive 3D visualisation and query front-end, the game engine Unity3D, an integrated authoring tool for creation of 3D interactive content, was adopted.Applications can be developed for all major platforms as well as for web sites requiring in the latter case a free plugin to access embedded contents ( Figure 5).Moreover, Unity can communicate with external databases and retrieve data when needed, e.g. by means of a PHP interface between Unity and PostgreSQL.As soon as the application is run, all the remotely stored information like structure types, structure names, year of construction etc. is retrieved and assigned to the respective geometric objects.For the navigation in the 3D environment, three modes were implemented ( Inside the 3D environment front-end, the user can perform attribute queries over the whole dataset (e.g."highlight all structures built by a ruler X"; "highlight all altars"; "highlight only stelae belonging to group Y and built in year Z").
The user can also perform standard queries with a mouse click: once a geometric object is selected, the related attribute values are retrieved from the external database and shown in a text box (Figure 7).The amount of retrieved information depends on the LoD: for LoD1 structures, only global attributes are shown, while for higher LoD also the detailed information is shown, according to the selected segment.Finally, distances between two objects in the 3D world can be measured, and line-of-sight tests between two selectable objects can be performed.

CONCLUSIONS AND OUTLOOK
This article presented the development of the QueryArch3D tool.The goal of the QueryArch3D is to address some open issues regarding multi-resolution data integration, access and visualisation in the framework of Cultural Heritage.Four requirements, considered of crucial importance when dealing with archaeological and architectonical reality-based 3D models, were set and inserted in the QueryArch3D tool: a) the capability to handle multi-resolution models, b) the capability to query geometries and attributes in the same virtual environment, c) the capability to allow 3D data ________________________________________________________________________________ Geoinformatics CTU FCE 2011 16 exploration, d) the capability to offer on-line access to the data.The Maya archaeological site of Copan in Honduras was chosen as a test field, due to its extent (ca.24 km 2 ), its considerable number of mapped structures (over 3700) and the availability of several heterogeneous datasets.In order to integrate the existing data in a coherent way, different levels of detail (LoD) were defined while the 3D models were manually segmented paying attention to both semantics and geometry.Finally all geometric models were integrated with attribute data gathered from several external sources.The integrated data are stored in PostgreSQL, while the interactive 3D visualisation is achieved using the game engine Unity3D, which is connected to the database by means of a PHP script.The front-end visualisation allows the user to navigate interactively in a virtual environment, where the existing archaeological structures can be visualised and queried in a LoD-dependent way.According to the observer"s distance from the object, the visualised geometry varies from low-resolution prismatic geometries to high-resolution meshes.At the same time, the amount of data retrieved from the database is dependent on the LoD: just global information is shown at a coarse LoD, while more detailed attributes are shown at higher LoD.Some spatial functions (like distance measurements and visibility analysis) have been also implemented.The 3D multi-resolution model is now accessible to the project members via web for visualisation, studies, interaction, queries, educational purposes as well as further tests and evaluation.Future developments and improvements for the QueryArch3D tool will add more spatial functions (beside the already existing distance measurements and visibility analysis) and more models at LoD2 to LoD4, consistently enriching the attributes related to the entities.Moreover, most of the structures are neither textured nor chromatically characterised.The very first improvement of the buildings will take this into account.It should be possible also to distinguish real structures from virtually reconstructed ones.Regarding the database storage system, some functions should be added and/or improved.Just to name an example, PostGIS itself offers support to store 3D features, but all GIS functions are still substantially 2D, i.e. 3D "out-of-the-box" spatial analysis tools are still to come.Besides the building structures, only a coarse TIN is used and objects are simply placed on top of it leading to some geometric inconsistencies in some places.A better integration of high-resolution models into a coarser DTM should be therefore taken into account, as proposed for instance in [26].Adding more high-resolution models into an on-line virtual environment requires good hardware and internet connections.Proper strategies will have to be tested and adopted to keep the user experience acceptable as the number of models (and polygons) grows.

Figure 1 :
Figure 1: Examples of access to 3D geometric data linked to external information: [left] Google Earth allows retrieval of information by clicking on selected objects, but no multi-criteria queries; [right] a GIS environment (Esri ArcScene ř.3) allows more elaborate queries, but lacks in visualising "heavy" realitybased models.

Figure 2 :
Figure 2: Different levels of detail (LoD) in the QueryArch3D tool for the Temple 22 structure.Clockwise from top-left: LoD1 with prismatic geometries, LoD2 with more geometric details (only exterior walls), LoD3 with interior walls/rooms and some simplified reality-based elements, LoD4 with high-resolution reality-based 3D models.

Figure 4 :
Figure 4: Semantic and geometric hierarchies: [left] Example of semantic segmentation for a typical Copan temple.[Right] Example of geometric segmentation of the interior doorway of Temple 22 for a LoD4 model.

Figure 6 )
Figure 6): a) an aerial view over the whole archaeological site, where only LoD1 models are shown; b) a ground-based walkthrough mode, where the user can approach and enter any structure up to LoD3 (provided such a model exists, otherwise a lower-ranked model at LoD2 or LoD1 is visualised); c) a detail view, where LoD4 models are presented.Inside the 3D environment front-end, the user can perform attribute queries over the whole dataset (e.g."highlight all structures built by a ruler X"; "highlight all altars"; "highlight only stelae belonging to group Y and built in year Z").The user can also perform standard queries with a mouse click: once a geometric object is selected, the related attribute values are retrieved from the external database and shown in a text box (Figure7).The amount of retrieved information depends on the LoD: for LoD1 structures, only global attributes are shown, while for higher LoD also the detailed information is shown, according to the selected segment.Finally, distances between two objects in the 3D world can be measured, and line-of-sight tests between two selectable objects can be performed.

Figure 5 :
Figure 5: Front-ends for the QueryArch3D tool: [left] data administration GUI (edit/update) via Microsoft Access 2010 Runtime platform.[Right] The web-based interactive visualisation and query front-end for data exploration.

Figure 6 :
Figure 6: Navigation modes in QueryArch3D: [left] aerial view with LoD1 models only, [right] walkthrough mode, with mixed LoD1-to-LoD3 models.An example of the detail view for LoD4 models is given in Figure 2 (bottom-right).

Figure 7 :
Figure 7: Different data interrogation modes in QueryArch3D.[Top-left] Query by attributes with results displayed in terms of geometries.[Top-right and bottom] LoD-dependent queries on geometric models: at LoD1, only global attributes are shown, for LoD2 to LoD4 models also sub-parts can be selected and more detailed information is retrieved and visualised.