Received 28 July 2014; revised 30 August 2014; accepted 20 September 2014

ABSTRACT

The surveying, analysis and documentation of ancient infrastructures or settlement sites are often carried out by the additional use of geoinformatic software and tools, i.e. embedded in geoinformation systems (GIS). Since these GIS-methods are usually adjusted to the local use case, the spatial dimensions, coordinates, map projections and file formats differ significantly between individual survey sites and/or archaeological focus. Consequently, the interdisciplinary digital fusion and interactive analysis of such regional varying geodata by collaborating teams of archaeologists are often a quite cumbersome procedure. Alternatively, new web-based GIS online technologies offer a unique opportunity to quickly visualize thematic maps, location metadata and find details of archaeological objects in a standardized way, also allow the upload of individual geodata from any local client via the internet. Hence individual scientists can contribute information to the documentation and spatial relation of these objects not only by mail or data attachments (GeoArchaeology Web 1.0) but also by directly integrating their standardized geodata using an online webserver-portal (GeoArchaeology Web 2.0). The aim of this study is to assess the potential use of the open source GeoServer software and related web-applications to generate a new archaeological perspective on geospatial data with different scales, resolutions, thematic focus and information depths. Therefore, the two case studies range from a small scale, large regional scope ( Sudan ) to scales of local conventional excavations ( Turkey ). Both surveys provided various datasets (i.e. base maps, UAS aerial images, terrain models, photographs, attribute and GPS data, field observations, etc.) which were combined in an interactive web-based geoportal with global range and minimum scale limitations since the service was based on a WGS84 map projection. The embedded archaeological data follows accepted Open Geospatial Consortium (OGC) standards which are available in every GIS. This particular archaeological data infrastructure enables not only the publication and visualization of archaeological datasets in a web-based geoportal but also the interactive geospatial interpretation and data extension of the whole available data pool “by third party users” in order to enrich and promote further scientific discussion on archaeological issues of the respective sites.

Keywords:

Geospatial Information Services, Web-Based Data Visualisation Strategies, GIS, Doliche, Turkey, Wadi, Sudan

1. Introduction

During the last decade geoinformatic methods have had a strong impact on archaeological survey principles and data processing strategies (Wheatley & Gillings, 2002; Chapman, 2006; Prinz, Krüger, & Lasar, 2010; Hacigüzeller, 2012). Since archaeological data represents time related geospatial data, it meets all requirements to be managed in a geoinformation system (GIS). Consequently, analysis and visualisation can be carried out in such systems at various geospatial scales according to the geographical dimension of the specific survey. In contrast to computer aided-design software (CAD), a GIS (and related geoservices) is also capable to deal with temporal (stratigrafic) aspects of findings or related metadata. This is the essential motivation for many archaeological teams to log and record their survey data not only by use of traditional documentation methods (pen and paper strategy) but also by applying innovative geoinformatically processed geospatial data sampling techniques. Latter approach includes (D)GPS-supported mobile mapping (GPS field pads with customized GIS software), high resolution aerial images (acquired by unmanned aerial systems, so called UAS), geotagging and digital annotation of findings, laserscanning (LIDAR) and many more, to directly combine the data in a GIS for further analysis. Local data processing is often realised by the use of commercial desktop GIS software like ArcGIS (ESRI, 2013) or other comparable products. The usage and analysis is often restricted to a single desktop PC or can sometimes be expanded to a “client-server” relationship, where the server offers additional tools and services for authorized clients. Nowadays the digital sharing of such data within the global scientific community becomes more and more important and can only be ensured by standardized file formats (Iso/Tc211 19118, 2005). For instance, the German Landesamt für Archäologie Sachsen established a Documentation and Informations system in Archaeology (DIA) which allows the web-visualisation, recombination and request of all available archaeological geodata in Saxonia for internal purposes (Göldner, 2007, 2012), but its core functionality is based on commercial client/server applications. As a result, the interoperability of the system is limited since it depends on its special architecture, specific file formats, data availability and restricted client policies and licenses.

Smart and swift IT-infrastructures allow the implementation of new and completely web-based geoinformatic archaeological services which are located outside the common licensed desktop solutions. From the user perspective web applications are simple to maintain and to apply because the only required software on the client site is basically a free web browser. They also exhibit a high level interoperability and independence because the usage of the graphic user interface (GUI) is usually not restricted to a specific operational system. Such applications can literally address more users then desktop-based GIS solutions because their URL’s are bookmarked in search engines. In contrast to conventional Web 1.0 solutions (where one has to send ones own complimentary data by email or external file media to be uploaded to desktop/server systems) the exchange rate between all scientific users in a web-based application (Web 2.0) is generally higher. An example for this new generation of GI-services has recently been launched by the Deutsches Archäologisches Institute (DAI) in Berlin: The CISAR project, which represents a new web-based modular archaeological information service, offering all sorts of sophisticated archaeological data and recombination/visualisation tools (some based on a typical “client-server”- system but also web-based relations; DAI, 2013). Since this impressive system consists partly of commercial GIS server packages with client interfaces and web-functionalities it requires more than one GI-specialist to cope with the high level administrative efforts—consequently the maintenance level outweigh the archaeological activities (regarding time and financial matter) and are not applicable to traditional survey projects.

2. GeoArchaeology Web 2.0

In order to reduce the financial and administrative overhead our GeoArchaeology Web 2.0-approach (http://geo-archaeology.uni-muenster.de) includes an OGC-conform (Open Geospatial Consortium, 2013) open source web-based application (Herring, 2010; GeoServer, 2013) for displaying, uploading, modifying and also retrieving archaeological data which is acquired in the field in a standardized and GIS compatible way. The implementation strategies is basically described by Röttger (2011) and Warrlich (2012) but also considers general aspects of (geo-) spatial data infrastructures (SDI), which are described in the European INSPIRE philosophy (Infrastructure for Spatial Information in the European Community, 2013). The resulting simple framework brings about considerable benefits for the scientific users with reasonable expenditure. We also focus on the aspect of building an architecture which supports mechanisms of adding additional services and data formats to the application in order to widen the analysis opportunities in terms of geographical relations between investigation sites by including global base layers and coordinate systems (Figure 1). Furthermore, the whole architecture has the aim not only to be fast and stable but also to be configurable and maintainable by archaeologists themselves (toolbox strategy). Within this toolbox standards provide and guarantee a high interoperability and exchangeability of the components: The used technology on the client-side is OpenLayers (2012) which supports a huge set of functionalities to build up geo-based web applications. The server-side architecture provides GeoServer (2013) including PostgreSQL/GIS (2012) database technologies for publishing and storing geospatial data and GeoExt (2012) to customize the web mapping user interface. Another important aspect of our system is that it can be easily adjusted to the field mapping methodology of individual survey teams, as long as they apply standards to their digital archaeological field data in terms of GIS-compatibility.

2.1. Specification of the Application

Spatial data varies and can be used in several ways within the GeoArchaeological Web 2.0 application. Therefore, our GI-services support essential standard data formats and OGC-based web services. As a result, all published data is accessible by OGC conform http-requests. Other functionalities allow individual uploading of local data formats like *.kml, *.gpx and *.shp files to combined own archaeological findings with those offered by the server (for instance generated or contributed by other colleagues within the scientific community). Important components are as follows (see also Figure 2):

2.1.1. GeoServer

GeoServer (2013) is a Java-based free server software, facilitating the storage, modification and web-publishing of geospatial data by Java scripting API’s (application programming interface). The most frequently used open standard web services (OGC, 2013) are called web map services (WMS), web feature service (WFS) and web coverage service (WCS): The WMS produces maps with spatial knowledge in well-known output formats like *.png, *.gif, *.jpg or vector-based graphical elements. The three standard operations of this service return service-level metadata, maps or feature information, where a WFS allows web applications to update (in transaction mode) or to retrieve geographical features by using a geography markup language (GML). GML expresses geographical features in a XML-like way (extensible markup language, a commonly used internet exchange format), which is per se system and operational independent. It can also be applied to geographic transactions as well as spatial modelling. The WCS is similar to the WFS, except that the service retrieves, updates or queries a whole thematic coverage instead of single geographical features. This service has some enhancements like the protocol, format, range subsetting, transaction, processing etc., but requires a greater administrative attention. The hereby applied service is a WMS in most cases, since it is the less complex service to be administrated in a GeoServer environment.

2.1.2. PostgreSQL/PostGIS

In our approach all spatially defined archaeological data is stored in a PostgreSQL (2012) database and published as “layers” to a URL-addressed web service generated by the Geoserver. Typical data formats in the database are standard formats like *.tif, *.jpg, *.png (all raster image formats) and also *.kml, or *.shp. The KML (keyhole markup language) format is based on the XML notation in order to visualize maps and images in spatial web applications or browsers (like Google Maps, Open Street Map, Google Earth or NASA World Wind).

The other popular vector storage format is the shapefile (*.shp) from ESRI (2013) which describes geometries like points, polylines and polygons. There are also some other formats which could be used, like for instance the *.gpx format, which is required to add standard GPS-data to the services. The PostGIS extension to the database allows the geospatial analysis, selection and geometric modification of the data. It also offers some common GIS functionality.

2.1.3. Client OpenLayers

Our application is based on the OpenLayers (2012) APIs, which contain free JavaScript libraries for displaying map data in nearly any web browser and can be modified by use of a free Java Software Development Kit (SDK). It contains all basic functionalities like visualisation, zooming, panning, scaling or layer selection, map composition, integration of external WMS, etc. The resulting map is finally published as a web-content which can be accessed by http-requests using a normal web browser on the client side.

2.1.4. Client GeoExt

In order to administrate the offered GeoServices more user-friendly we also used the GeoExt extension (GeoExt, 2012) on the client side. GeoExt enables tree-structured browsing through the layer content and an individual selection of thematic layers or offered functionalities within OpenLayers. It also facilitates web-based uploading, temporal visualisation and (if necessary) storage of individual *.kml, *.gpx and *.shp files (where the *.shp format is converted and stored as *.kml in the database) to the interface and the server itself. It also enables the integration of “outside” geodata-services. Consequently a resulting map composition can not only include a wide range of customization functions like thematic layers, controls, events, etc. but also other related geo-spatial information data if offered by other servers outside our system as base-layer services (GoogleEarth, bingMaps, other WMS provided by Geoserver, MapServer or ArcGISServer; see also Hazzard, 2011).

3. Archaeological Use Cases

In order to proof our concept regarding to a wide range of possible archaeological, spatial, methodological and regional aspects we concentrated on two archaeological use cases/survey sites (Figure 3) which are different in geographic dimension, cultural meaning, field/survey situation and exhibit also significant variations in data acquisition strategies:

1) The Wadi Abu Dom Itinerary (WADI) project in the Sudan (Lohwasser, 2012, 2013).

2) The Doliche/Dülük Baba Tepesi (DBT) Project in Turkey (Winter, 2011, 2014).

Both use cases provide different data, ranging from remote sensing images (i.e. small scale perspective) to single ground sites or specific local findings like building remnants or scattered artefacts (i.e. large scale perspective) with related explanatory notes. The data represent either rasterdata (i.e. aerial, UAS and satellite images; geotiff), vectordata (i.e. geometries; polygone, polylines), point (single site) or metadata (related database attributes). In terms of the Wadi Abu Dom Itinerary project all field data is directly acquired in the field by a GIS-compatible and customized ArcPad software (Esri, 2013), running on Trimble (2013) GPS-handheld devices (Juno SC) whereas the Doliche survey data is typically stored in a CAD-System (Autodesk, 2013) after the analogue graphical data has been digitized at the end of an excavation day. This accumulated datasets are exported into ArcGIS-formats (shapes, geotiffs) later on, typically by the end of the current survey campaign. In both cases the remote sensing images are incorporated to the project at different analysis stages, depending on regional survey aspects, time slots and scale levels. Photographs and all other metadata are added to the individual databases by geotagging (i.e. GPS or tachymeter coordinates). Both use cases facilitate a proof of concept regarding our GeoArchaeological Web 2.0 reading.

3.1. Wadi Abu Dom Itinerary

The Wadi Abu Dom Itinerary (WADI) project explores the cultural landscape of the Wadi Abu Dom in northern Sudan. This particular dry valley runs from the center of the Bayuda desert to the area of Napata, the ancient capital of the Kingdom of Kush (approx. 800-300 B.C.). Since the lower Wadi Abu Dom forms an integral part of the “cities” immediate hinterland, the investigation of the historical traffic infrastructure of that area is a major focus of the research activities (Lohwasser, 2012, 2013). Nevertheless, the project’s general aim is a documentation of all historical anthropogenous records within that region. This will lead to the development of a complete archaeological map of the Wadi Abu Dom. In the years from 2009 to 2014 an area of roughly 230 km² was covered by an intensive survey on foot and by 4WD. Teams of 2 or 3 archaelogists are exploring terrain sections in order to document all pre-islamic human activities visible on the ground. Until now, a total of more than 7600 sites were recorded, ranging from the Palaeolithic period to the Sudanese antiquity and even Mediaeval Times. These sites are usually very small in dimension and sometimes only consist of a single feature class, like burials, shelters or isolated fireplaces. Others are significantly larger, like entire cemeteries with up to 200 graves. Besides graves, other categories of archaeological structures found in the Wadi Abu Dom are settlement remains, some rock art and—most important for the investigation of the Wadi’s ancient mobility infrastructure—campsites of different periods. In two “micro-oases” (small ecologically favored areas) within the Wadi Abu Dom, some larger stone buildings were found: The most remarkable are the medieval monastery of Ghazali and the still enigmatic building structure of Umm Ruweim. The lower Wadi Abu Dom, where these structures are situated, was the main focus of archaeological work until today.

Another feature of great importance for the regional reconstruction of historical traffic patterns is the infrastructure like trails, tracks or pathways, associated with findings of antiquity (mostly pottery sherds). Many of these linear structures are still visible—and some of them in use until today. Some of those tracks are accompanied with fireplaces or shelters. The scientific cataloguing of such sites of different dimension, sizes and categories becomes quite complex and a systematic workflow is crucial for its success. Every object category must be well defined in terms of classes, appropriate attributes or feature relations: For instance graves (geometry/form of superstructure, dimensions, associated findings etc.) or rock-art (motive, technique of picking, orientation of panel, 2D/3D etc.). This broad variance in addressing the sites and features for standardization reasons is therefore an important issue and also a great challenge to both, the archaeologists and the geoinformatics.

3.2. Dülük Baba Tepesi

Since 2001 the summit of the Dülük Baba Tepesi (DBT), a 1211 m high landmark in the area of the modern city of Gaziantep, south-eastern Turkey, is under investigation by an international team of archaeologists and historians under the direction of the Asia Minor Research Center (University of Münster). On top of the hill the sanctuary of Iuppiter Dolichenus is located. From this place, the cult of this ancient storm-god (usually depicted standing on the back of a bull) spread throughout the entire Roman Empire during the 2^nd century AD. The Belgian scholar Franz Cumont identified the location of the sanctuary as early as 1907, but his discovery went largely unnoticed. Only a few scientists subsequently paid visit to the site. In the late 1970s Wagner made some important contributions as he identified various remains of the sanctuary (Wagner, 1982, 2012; Blömer, 2012). Later the so-called “priests” necropolis, a group of rock tombs located in close proximity to the sanctuary, was explored by Ergeç (2003). Regular archaeological investigations on the peak of the Dülük Baba Tepesi started in 2001, when a small team of students and researchers started to explore this site. Today the excavation team comprises up to 60 people who work on the Dülük Baba Tepesi every year. From the onset of the excavation an interdisciplinary approach has been adhered to.

The main aim of the project is to explore one of the most important religious sites of the ancient Near East and its origin, which can now—due to recent archaeological findings—be securely dated back to the Iron Age. The excavations on the plateau of about 28.500 sq. m have thus far already supplied important new evidence. Most notable is a fragment of a 9^th century BC stele showing a goddess on the front and a hieroglyphic-Luwian inscription on the back. Considerable architectural remains dating back to the Iron Age are visible in a large area at the centre of the plateau. Surprisingly rich finds from the 6/5^th century BC—thousands of beads, cylinder and stamp seals—and also from Hellenistic and Roman times greatly contribute to our understanding of the cult of Iuppiter Dolichenus and offer insights into the history and architectural design of the sanctuary. The Dülük Baba Tepesi is one of the few sites in the Southeast Anatolia where there is evidence of continuous religious activity from the early 1^st millennium BC to late antiquity and medieval times, when the monastery of Mar Salomon—known from literary sources—was founded on the Dülük Baba Tepesi. These circumstances allow us to draw conclusions regarding the cult continuity and religious history of the entire ancient Near East.

3.3. Typical Data Acquisition Workflow

To illustrate the two different (but in terms of GeoArchaeology Web 2.0 also corresponding) methodologies one can focus on representative vector-, meta- and raster-datasets from both survey areas. Although they differ significantly in spatial dimension, reference system, geographic scale and scientific focus, each local finding represents basically an object with a defined geometry, topology and related features. These objects are either directly mapped in an analogue or in a digital way, attributed and later on converted to/stored as geocoded vector-data (with related meta-information) in a GIS or CAD system. Once integrated in those systems they can easily be exported as OCG-conform shape-files. Additionally, those shape-files are combined with supplement remote sensing information (raster-data), acquired by satellites or customized UAS-based close range photography.

3.3.1. Methodology at Wadi Abu Dom

The working methods within the Wadi Abu Dom (WADI) Project developed step by step from mainly pen-and- paper-based documentation to a mobile digital data management system. From the very beginning of the acti- vities at Wadi Abu Dom, the research methods then were quite traditional (despite the fact that remote sensing played an important role within the preparation of the work). Sites found discovered during the ground survey or by satellite images were documented by hand and geo-referenced using off-the-shelf outdoor GPS. The integration of the raw data recorded in the field and by remote sensing into a GIS was done completely by post-pro- cessing not even during the field campaign until 2009.

In 2010 a cooperation with the University of Muenster’s Institute for Geoinformatics (IfGI) opened new opportunities for applying innovative geoinformatic methods to current field campaigns: Two major tasks while integrating computerized methods into the archaeological workflow were to standardize the data record, and to improve the work speed in order to use the limited time in the field as effectively as possible. It became clear that the traditional raw data record was highly time consuming, and tended to generate non-standardized data which made later geospatial and statistical analysis difficult. All parties discussing those topics—archaeologists as well as geographers and GI scientists—agreed that those two major tasks would be solved best by collecting the raw data in a digital mobile mapping approach, thereby enabling the integration of the resulting object-data in a GIS application directly in the field. Today at WADI most geometry objects are directly documented in the field by using a customized ArcPad 10 version with project specific tools, running on Juno Trimble SD Hand- held (Trimble, 2013) (Figure 4). The handheld device offers an internal GPS SIRF III positioning, which under ideal circumstances delivers a position accuracy of +/−3 m, which is completely sufficient in the context of such a large area archaeological survey. Furthermore photos and sketches (raster-data) can be integrated into the geo- database via an ArcPad-protocoll, since the Juno Handheld has got an internal digital camera (with is usually

sufficient in quality for pure inventory purposes) or offers a bluetooth interface to more sophisticated GPS-dig- ital cameras for detailed documentation needs.

Beside these aspects, the Trimble Juno-ArcPad solution can also be used as a navigation device, especially the possibility to upload every kind of OGC-conformed geo-referenced map—vector data as well as raster data. This independence from commercial proprietarily adapted GPS-maps is of great advantage in remote and desert areas of Africa where useful maps are rarely to be found. In Sudan, the Soviet military map 1:200,000 from the 1970’s is still the most accurate topographic map and not offered as map packages by outdoor GPS-device companies. Due to the fact that ArcPad is open for almost all formats of geo-referenced raster and vector data, these old soviet maps (and even old ones from the colonial Anglo-Egyptian Sudan Survey Office, which are also still of some use) can be integrated into the base layer functionality of the customized ArcPad GUI.

This special technical setup enables the user to document and map relevant objects in terms of their detailed geographic position, dimension and specific features (latter ones are predefined and selectable in a drop-down attribute table to avoid meta-database inconsistencies) with a high efficiency. Thus, the traditional two-fold archaeological survey documentation pattern (using larger scale entities—here sites) were filled with secondary, smaller scale entities (here objects/features). That concept made it necessary to define every site geometrically as a polygon, and every object/feature (in the archaeological sense of the term) as a point. A second opportunity to define archaeological objects/features as polygons was not implemented, because it turned out that a point- shaped feature in 99% of the cases was completely sufficient to define analyzable distribution patterns. This aspect is very important because WADI focuses on regional archaeological finding patterns and correlations in an area of interest which is several hundred square kilometres in dimensions. In many cases the resulting shapefiles are later combined with digital GPS-camera photographs and geocoded multispectral Landsat ETM 7 satellite images to offer the required widened regional perspective. Hence the entire data is stored and analysed in ArcGis desktop, since it is geocoded according to the local reference system.

Figure 5 illustrates the typical data acquisition workflow: After having discovered an ancient structure, first an archaeological site covering the whole area of all the find spots has to be defined as a polygon. This record class archaeological site gives some possibilities of defining further specifications, like category, dimension and topographical data by a drop-down menu. Every value chosen from those drop-down menus effects the next steps, for instance if the site category settlement is chosen, the program offers different patterns of hut clusters and other settlement structures to chose from for the secondary categorization level and so on. By this progressive data acquisition strategy almost every archaeological object in the field can be mapped according to GIS database standards.

After having used the Trimble Juno devices and the modified ArcPad package for three years (and having improved it from year to year), it turned out that this concept of applying mobile mapping GIS field-techniques for data acquisition led to a significant increase in mapping efficiency as well as in data clarity. Also the fact that all data was collected and processed by only one highly integrated system showed that the probability of mistakes was reduced significantly compared to traditional recording methods using a vast amount of different types of paper from sheets and list, as site and feature cards, GPS list, photo list, etc. Furthermore even a relatively untrained survey team is able to document up to five times as much archaeological records in a representative time frame using the mobile GIS as mapped by conventional methods. But the major advantage is the archived high degree of data standardization which makes subsequent spatial analysis much easier and allows a direct import into the Archeaological Web 2.0 application.

3.3.2. Methodology at Dülük Baba Tepesi

The excavation site on the Dülük Baba Tepesi (DBT) requires a refined and precise documentation system to ensure the meticulous recording of all data. An important prerequisite is the accurate mapping of artifacts, contexts and survey trenches. Since 2004 the excavation area is divided into a relative, local-referenced grid system. All trenches are adapted to this 5 m × 5 m grid by means of tachymetric measuring. The excavation is conducted following a traditional stratigraphic methodology. It is imperative to document the superimposed layers and all single contexts as precisely as possible. Consequently, any archaeological context (e.g. a wall, a pit, the filling of a pit, a layer) is documented in a detailed written description, in photographs and in drawings and their exact position. The X-, Y- and Z-coordinates of objects facilitates their attribution to specific archaeological features and thus their contexts. Sections and contexts are photographed and subsequently drawn by hand in a scale of 1:20. Architectural remains and the final sections are measured using a tachymeter and subsequently drawn. Ultimately, these drawings are then digitalized using AUTOCAD-software (Autodesk, 2013) and relatively rectified. The mapping tool applied to the excavation-databse also offers the option to visualize individual finds within the digital map. Thus a digital plan of the excavation site with some limited meta-data is created that visualizes and documents the already excavated areas. These map data are also useful for the planning of future survey campaigns. The CAD-plan is based on vectorlayers, which are formatted to shapefiles for the mapping tool inside the database. Those shapefiles can also be imported into the GeoServer and then used for the web-GIS.

In 2012 and 2013 an Unmanned Aerial System (UAS), a customized quadrocopter, equipped with a calibrated digital Fuji W3D camera, was used at DBT for the very first time. This device provided valuable true-colour, close range stereo aerial photographs which significantly facilitate the archaeological documentation (Figure 6). Once the remote sensing information is gathered, processed and georectified it can be used to create maps, blueprints, or 3D-models.

Furthermore Structure from Motion Technology was employed for the first time on related raster-data. This method benefits not solely from the UAS-images but also from terrestrial digital overlapping orthorectified photographs in order to create 3D-models. In combination with tachymetric data, the rectified pictures created from the models were also integrated into the CAD system. The documentation of finds and features in the form of a digital 3D-model offers the advantage of enabling a retro-perspective processing of excavation results even if one is at home, more than 2500 km away from the actual architectural element. This strategy was also applied to sections and walls which thus far have only also been recorded in conventional photographs and drawings in the past, thereby substituting the process of drawing these features in a significant measure.

Selected CAD-excavation plan objects and remote sensing data are finally geographically transformed and converted into ArcGIS-compatible feature data sets (Figure 7). The use of a GIS visually aids our understanding of the geographic and topological interdependence between the DBT sanctuary and other archaeological sites in the region (e.g. like the ancient city of Doliche which is situated in the north of excavation area) and facilitate the interpretation of the site in its geocultural, geographic and historical context.

4. Data Characteristics and Management

All internal shapefiles are stored and managed in the GeoServer PostGIS database, whereas rasterlayers are selectable as separated ImagePyramid layers applying the gt imagepyramid plugin. Layout and styling of the offered geospatial information can be defined in the WMS-services tool of GeoServer or the styled layer descripter (SLD) which basically represents an OGC-conform XML-scheme.

Regarding the Wadi Abu Dom Itinerary (WADI) project all generic data which was integrated into the new service belong either to the shape files Wadi_sites or Wadi_features, where each site (spatial geometry, polygon or polyline, for instance a settlement) contains one or more features (polygon or polyline but also point geometry, single finding, for instance a box grave). Both shapes classes also contain additional geo-object attributes which are editable in the field or automatically generated by ArcPad (Table 1). This is also the case with the sub-WADI survey site Umm Ruweim.

Since the data from Doliche is exported from a CAD-system the Doliche_feature shape does not contain as much detailed object-related information (attributes) as if mapped in a direct GIS application. Therefore, the information is limited to some fundamental geometry and additional metadata (Table 2).

Apart from the already mentioned vectordata (shapes) both regional surveys depend on remote sensing data (rasterdata, geotiffs), in case of Doliche represented by geocoded high resolution panchromatic Quickbird satellite and UAS images (larger scales), whereas the Wadi project focuses on medium to small scale Landsat ETM 7 satellite and aerial images. Both use cases also incorporate GoogleEarth (GoogleEarth, 2013) image information for regional geospatial considerations. Consequently GoogleEarth is one out of three selectable base layers besides OpenStreetMap (OpenStreetMap, 2013) and NASA Global Imagery (NASA, 2013) in the GeoArchaeology Web 2.0 Application. Furthermore the *.gpx, *.kml and *.shp formats are also accepted to allow relations between external GPS- or additional shape data and the current survey map composition on a temporary level. Navigation between the survey sites can be conducted by the use of a drop-down selector menue of the service.

5. Graphic User Interface and Functionality

The graphic user interface (GUI) of the GeoArchaeology Web 2.0 Mapping Service can be separated into the following functional sets of toolboxes (see also Figure 8):

Main map viewer (center) allows the visualisation of selected feature data sets (including one’s own uploaded data) on different global base layers (GoogleEarth, NASA Global Imagery, OpenStreetMap or none). Panning, zooming, coordinates, scale bar are being offered. Selected features display their meta-data also in the viewer. Maximum zoom level with “no base layer”.

Go to project (mid right) redirects the viewer to the geographical center of the archaeological survey sites WADI (including Umm Ruweim) and Doliche (DBT). This function is editable as an administrative user.

Legend content graphic list (lower right) indicates the symbology of active and/or visualized feature data sets currently loaded in the main map viewer.

Layers (upper left) is structured in thematic blocks and offers access to all objects and feature data sets (layers) in a folder substructure by check-boxes. It ranges from Landsat TM infrared satellite images of the WADI area or UAS-mosaics from DBT to specific sets of findings, maps, photos, metadata, etc. of all surveyed sites. The offered data represents permanent vector and rasterdata (geodata) within the database—some of those layers also offer WMS functionalities (by right click: URL capabilities); only the folder Uploads represents the content of individual, temporary uploaded user-data. The position of the layers (layer stack) can be modified within the folder structure by drag and drop functionality. The content of the toolbox layer can easily be adjusted to the users needs by the database administrator.

Measure and print (mid left) offers the traditional tools for measuring purposes in the map or to print the map layout as a *.pdf document.

Upload (lower left) allows the uploading of vector data sets on a temporary level only as *.gpx, *.kml files or *.shp corresponding ZIP-archives.

Opacity of layer (upper right) offers the possibility to change the transparency of the selected layer.

Figure 8 illustrates the typical application of the GeoArchaeology Web 2.0 in terms of visualisation and archaeological data interoperability, here related to the DBT project: After selecting the appropriate baselayer from the content table (here: Google Satellite) one chooses the direct rooting to the DBT location (Go to project). Now the user selects the desired thematic layers from the content table by checking the corresponding boxes and, if necessary, re-arranges the layer order within the stack by dragging them into the wanted vertical position within the list. The related metadata/attribute tables of all selected thematic layer/feature data sets can be examined by a “left-click” on the geo-object in the main map viewer. This data can additionally be extended by photographs, drafts, comments or PDF-documents. If there is also interest in UAS images covering that particular survey site, one can add the UAS mosaic DTB layer to the current selection.

The user is also capable to change the colours of a corresponding layer on a temporary level by “right-click/ properties”. Furthermore one can easily zoom to a desired layer by “right-click/zoom to layer”. Another functionality provided to the user is the possibility to swipe a layer. This can be done by “right-click/activate swipe”. Now, with the active swipe function, the user can cut the layer on the current mouse position. This functionality comes with a small help animation to explain how to use this function. Additional to this visualisation manipulation, the user can change the opacity of each layer. By “left-click” on a layer, it gets highlighted by a blue background. Now the user can drag the “opacity of layer” slider in the upper right corner of the interface. Since Google Satellite allows only a limited zoom level one has to deselect this base layer by selecting no baselayer in order to view the full ground resolution of the UAS ortho-images. In case the user wants to combine the benefits of this UAS photo mosaic with his own findings/data he can either upload this local data (Shape Upload) directly to the online service, or copy the WMS URL address of the active mosaic by “right-click/info” on that particular UAS raster data layer (within the content table of the service) in order to paste this address into the WMS interface of his own local GIS hereafter. In case one has to share archaeological data with other co-workers the user needs to have administrative rights on the system (user management of the GeoServer) to add layers to the content list.

6. Conclusions and Discussion

Our study clearly underlines the high potential of open source technologies to establish new web-based geodata visualisation services for archaeological purposes in order to increase the global interoperability of field data. The GeoArchaeology Web 2.0 mapping service and hereof implemented necessary technologies offer a promising platform that will facilitate the interactive and data-based cooperation between involved scientists in a contemporary way. The capability of the system to process data by accepted geo-standards will also encourage archaeologists to make more use of these geoinformatic standards during the digital documentation process of regional findings and throughout the survey. In addition, this approach allows a flexible extension of toolsets since it follows a modular architecture.

But at this stage there are still some obstacles to be overcome. Concerning the data acquisition workflow in the field, it turned out that even using a standardized software and data-formats it still caused some difficulties to create data consistent enough for a smooth post-processing. Consequently this problem will be a subject to the further improvement of the workflow. Furthermore there are the still subjective classifications of some found archaeological objects in terms of different meanings and record densities, for instance, when dealing with a graveyard or an agglomeration of huts, it is quite obvious where to delimit it. But some other site categories, especially the remains of camp-sites of non-sedentarians along the banks of the contributory Khors are make things not that easy. Confronted with large areas with scattered remains of inhomogeneous camp and habitation structures, some survey teams tended to few, but large sites, others defined more, but smaller sites with less features. This example shows that even sophisticated software cannot guide the users so strictly through a data recording process that completely standardized and consistent data will be created automatically. The human factor remains still in charge, and the software can not replace the permanent discussion between the survey teams and clarification of their different modes of operation.

Concerning the processing of the data into the web-GIS, the continuously increasing complexity and user demands of web applications will make it impossible to use only plain JavaScript functions without new features like HTML5 (W3C, 2012) or prevailed standards like Ajax (Asynchronous JavaScript and XML) in the future. The latter one is a combination of several technologies like HTML, DOM, JavaScript and the XMLHttpRequest object (Koch, 2011). Unlike the classic web applications Ajax sends asynchronous HTTP requests to a server without refreshing the entire web application, which significantly speeds up the entire visualization process. Consequently, the GeoArchaeology Web 2.0 application has to integrate these technologies in order to provide a stable and fast web application which is still modular and connectable with other technologies.

A further need for improvement can be observed in the field of rasterdata management and visualisation, since remote sensing imaginary (in contrast to geometry vectordata) usually represents huge amounts of data volumes which have to be processed in both directions. At the moment the uploading size of own image data is restricted to 100 Mb maximum in the application but should be extended in the future by integrating smart compression strategies and pyramid-layer technologies into the GeoServer/OpenLayer architecture.

Another important issue is the implementation of basic web processing services (WPS, see OGC, 2013) which enables the user to select and analyse different geo-objects and features according to their geospatial relation (like buffers, intersections etc.) by accessing the geoportal instead of a local desktop GIS. Online editing of feature classes and their related attributes would also be useful, not only for participants of the excavation campaigns in the field but also for invited, cooperating scientists later on. Consequently those resulting layers should be stored in the system permanently and not only temporarily, in order to be published by the GeoArchaeology Web 2.0 application itself. This would facilitate a further exploitation of the data by the scientific community, even by use of mobile “smart field clients” like tablets or smart phones (iOS, Android) because the data is easily accessible applying a simple http:// request to the GeoArchaeology Web 2.0 service. Some of those functions and services are already available in commercial web-GIS like ArcGIS Online (Esri, 2014) but are limited in usability since its functionality focuses mainly on ESRI standards, workflows and depends on licences policies. In general, it is necessary to implement the approaches of the GeoArchaeology Web 2.0 project from the very beginning into the ongoing discussion about the permanent storage and the open acces to raw data within archaeology. Especially for Sudan’s archaeology, standardizations enabling different international projects to merge their data could prove crucial, since a general database of archaeological sites is still a desideration in this country. Thus—besides other ongoing approaches—this Web 2.0 application could form a simple and is easy to handle preliminary platform for a wider collection of archaeological geo-data.

Summarizing the GeoArchaeology Web 2.0 allows us to communicate our deliverables in an easy and fast way. In the case of the Doliche-project, the later uploaded data is recorded anyway for the internal database. The web application offers the possibility to visualize the results and makes this data accessible from anywhere around the world—not only for the project-members, but also for the interested public.

The platform has the potential to form a useful tool for cooperation with other regionally and/or thematically related archaeological projects (i.e. Paner & Pudlo, 2010). Beside the data-upload of current and future projects, the structure enables also the implanting of data from older projects, which can be converted to the mentioned standards. For example historic survey-data from the early and middle 20^th century, like the photos and finding records made by F. K. Dörner in south-east Anatolia (Nieswandt & Salzmann, 2014).

Acknowledgements

We thank the ifgicopter group of the Institute for Geoinformatics (http://ifgicopter.uni-muenster.de/) for providing the UAS platforms and the corresponding technical support. Both, Angelika Lohwasser and Engelbert Winter provided not only helpful comments to a former version of the manuscript but also for their support in the field—we are grateful for their cooperation. Sebastian Whybrew has to be acknowledged for polishing our English. We also like to thank all our colleagues and partners who support our ongoing work in Turkey and Sudan.

References

NOTES

^*Corresponding author.