ISSUE   HOME 

Joukowsky Institute for Archaeology and the Ancient World Brown University, RI, USA. Email: martin_uildriks@brown.edu

Cite this as: Uildriks, M. 2016 iDig - Recording Archaeology: a review, Internet Archaeology 42. https://doi.org/10.11141/ia.42.13

Summary

Archaeological data and practice are becoming increasingly digital, stimulating the manufacture of software and hardware solutions for in-field data-collection. A new stand-alone piece of software for the iPad, iDig - Recording Archaeology, introduces promising features for recording and visualising archaeological excavation data in the field.

Introduction

Digital data are becoming central to most archaeological projects. Indeed, many now aim to become exclusively paperless (e.g. Austin 2014; Roosevelt et al. 2015; Wallrodt 2016). In the light of this development, numerous web-based software solutions have become available to facilitate the collection of digital data in the field, like the Field Acquired Information Management Systems Project (FAIMS) and the Archaeological Recording Kit (cf. Dufton 2016). A recent and impressive addition is iDig - Recording Archaeology, a stand-alone piece of software for recording and visualising archaeological excavation data in the field. Marine archaeologist and programmer Bruce Hartzler, affiliated to the American School of Classical Studies at Athens and digital specialist for the excavations at the Athenian Agora, has been developing iDig since 2012.

Currently, the software is at version 5.0.2, freely available through Apple's App Store, and requires iOS 5.1 or higher, as well as 10.6 MB of free space for basic operations. The software comes with two example datasets, based on the 2013 fieldwork at the Athenian agora (trenches B Γ and BΘ). For this review, the software was tested on a third-generation iPad (model A1416) with 32 GB, running iOS 9.3.1, using these datasets. A more complete review would require the software to be thoroughly tested in the field and outside the scope of the Athenian Agora project. However, some potential of the software can be gleaned from an out-of-field testing.

Description

After installation and startup, the screen is divided into two vertical panes. The left pane provides an index of archaeological collection units (CUs) within the currently selected trench, such as Sections, Features, Contexts, Objects, and Lots (described in more detail later). By tapping on the trench name above this pane, the user selects a different trench or adds a new one to the system. The second pane provides a graphic viewer where CUs from the selected trench can be visualised in different ways (Figure 1); tapping the title above the right pane allows the user to change the background graphic onto which to project the selected trench's CUs. Three icons above the second pane provide some general functionality; the first () opens up a configuration panel for detailing the selected trench and the third () provides a number of different visualisations, both described later in this review. The second () toggles tool-tips for a number of tools below and above both panes: three buttons below the left pane add (), sort (), and copy/delete () a CU from the currently active trench. Two buttons above the viewer ( and ) filter CUs by type and status (discussed later). Finally, holding down the pencil tool () provides a dropdown menu with three modes for selecting CUs in the viewer: the standard pencil, Camp's Pencil, and Talcott's Pencil. The standard pencil allows quick selection of entire CUs; the other two pencils will crop the selection to shape and find the deepest features (Camp's Pencil) or select all items in the shape (Talcott's Pencil).

Setting up the Data

The configuration panel (opened by tapping ) allows the setting up and storing of a configuration profile for each individual trench (duplicate trench names are not allowed). In this menu, the user can also select a base map on which to project the CUs in the viewer (e.g. an orthophoto). Plans of other trenches are also available here, and other images can be imported, through iTunes only. The software handles image files, up to 2048 x 2048 pixels, with and without an (external) georeference file (.wld- and .tfw-extensions). If geospatial data are available ungeoreferenced, images can be georeferenced on the spot (see the step-by-step online guide). If geospatial data are not available, the software offers the possibility to collect real-time data from a Leica Total Station equipped with a battery-powered WiSnap WiFi RS-232 Dongle (not tested). WiSnap WiFi Dongles operate on 802.11 b/g channels through a 2.4GHz radio with low power consumption. A grid can be overlaid on images with a spatial reference (at 0.1m, 1m, or 5m intervals) as can data from other users and previous seasons. Admittedly both untested, the former would be done through a specially designed feature called Trenchmates (an instant read-only feed between multiple devices to resolve synchronisation issues and data conflicts) and the latter by connecting to the American School of Classical Studies at Athens (ASCSA) online archive. At present, ASCSA is the only integrated repository, but the software author intends to integrate other archives as well.

Once the trench is configured, and fieldwork begins, new CUs are added to the current trench by tapping the icon below the left pane. In the next window, the user is asked to input some details of the new CU, such as the type of CU, a unique ID (UID) number, as well as a title/name (e.g. Southern Section). The type defaults to Untyped, but the list from which others can be selected include Section, Feature, Context, Object, Lot, and Other. Each type of CU comes with its own specific data fields. For example, Sections record four fields labelled chronology, elevations, looking and page, while Features contains five fields labelled category, deposit, chronology, range start and range end. For easy reference, and to keep track of when a CU was opened in the field, the system automatically adds a start timestamp that can be changed if needed.

As fieldwork continues, the user can add freshly collected Total Station data to the new CU, characterize its further details, and establish its relative temporal and spatial relations to other CUs. The latter is done by indicating its relative position (e.g. 'below') to another CU and essentially allows any kind of CU to be meaningfully associated with any other kind of CU. For example, 'Pit 293' is 'below' 'Floor 12', or 'Section 14' is 'above' 'Wall 9'. This procedure is surprisingly simple, though potentially quite tedious and laborious as new CUs are added to the system and the user will need to manually scroll through all of them. Although not perfect, in my opinion, this is one of the most promising, useful, and exciting features of the software as it can instantaneously generate temporal and spatial matrices (see below). As the fieldwork draws to an end, the user can indicate the CUs status, as Open, Closed, Will Lot, All Done, and Attention, as well as indicate whether the CU is Sidelined (yes/no), and the user can add a second timestamp to mark the end. Before addressing these last quite vague options, let us first look at the matrices (Figure 2).

Visualising the Data

New data can be visualised instantly in relation to other data logged in the system. Tapping provides a dropdown list with a number of options, including Plan, Relationships, Temporal Matrix, Spatial Matrix, Cross Section and Index. Plan provides a top-down view, while Relationships will show the relative spatial relationships between CUs. The Temporal Matrix will draw a relation diagram of all CUs as they relate in time (Figure 3) and though daunting at first, to distinguish easily between the types of CU, they are given their own colour and symbol: Sections (), Features (), Contexts (), Objects (), Lots (), Other (), and Untyped (). These symbols are selectable and tapping each symbol will bring up its metadata on the left. The Spatial Matrix shows stratigraphic relations and Cross Section provides a 'sectional' view of them.

A Few Considerations

The visual appearance of this piece of software engineering is certainly commendable; it runs smoothly and I have not encountered any problems on my slightly older iPad, nor had any issues with navigating the menus and accessing data. However, I have identified a number of areas that may require attention in future development starting with more detailed documentation and explanation of the many features and aspects used in the software. For example, there is no documentation on the fields associated with CUs, nor are there any explanations of status settings (e.g. Will Lot, Attention, and Sidelined), descriptions on the use of colours, symbols, and different types of line in the matrices. Projects that use lots in their recording methodology will undoubtedly find use for Will Lot, but as every site offers specific material culture, and every project uses its own specialized ph(r)asing, only few archaeological projects will be able to fully integrate iDig into their workflow. Further fine-tuning should perhaps consider that a CU is always 'Open'; from the moment it starts, until it is 'All done', making the status options 'Open' and 'Closed' superfluous.

Second, iDig depends on expensive Leica Total Stations, and Leica's Geo Serial Interface (GSI): a file-format first developed in 1996 (see this detailed manual on Leica's GSI) and unfortunately, not very accessible to non-Leica users. In fact, specifying other formats for extracting data from Leica machines can be difficult without resorting to its complicated Format manager or other proprietary tools. Thus, dependency on GSI poses two problems; first, GSI-files are only used within the context of Leica software, limiting the use of iDig to Leica programs and devices. This excludes the numerous projects that use other brands such as Topcon (Sokkia), Magnet, Nikon, and Trimble. These machines may encounter problems of properly interfacing with iDig. Second, many projects use a differential GPS system (possibly other than Leica), no Total Station at all, or perhaps even both. Normally, integration of dGPS data could be easily accomplished, as exported data from Total Stations and dGPS systems are quite similar and hence can be parsed similarly (e.g. from a .csv-format). However, this is not the case if such integration depends upon varying raw data file-formats, which iDig may or may not support.

A somewhat related, but separate issue is how raw data are integrated into the software, and how users can interact with it. The software does not seem to provide any quality control of measurements and allows users to manually adjust individual coordinates (including elevations). Correcting and recalculating geospatial data is a precarious matter and preferably done with the raw data in the geodetic equipment itself or in specialized geodetic software, rather than with already processed data. All geodetic data are a calculated approximation of reality, based on a complicated range of variables (e.g. prism constant, target height, instrument height, temperature, humidity etc.), and when one variable needs adjusting, the entire calculation will need to be redone. I am uncertain whether iDig allows the user to change any or all variables in the raw data, whether it then uses the raw data to recalculate measurements, and if it does, whether it does the calculations correctly. This freedom adds a layer of uncertainty to the reliability of data in iDig and perhaps should be more limited.

Aside from potential mechanical or calculation errors, the software also has no built-in tools to counter human error. As mentioned above, some of the supplied field codes and descriptions are ambiguous, like the page field when adding a new Section CU, or the deposits field when adding a new Feature CU. In the case of the latter, the user is given a selection list that only contains K 3:2. This vocabulary is probably specific to the Athenian Agora Excavations project but owing to their ambiguity, misunderstandings and typos can easily creep in if no clear boundaries are provided. A word of warning: my iPad's built-in spellchecker autocorrected some of my input to incorrect values, and in other cases did not pick up those that it should have corrected. New users will also need time to get acquainted with the vocabulary, while experienced users will need to spend hours of laborious scrutiny afterwards ensuring that no errors creep in. Also, the huge amounts and variety of data that the software intends to manage, could easily confuse users, and although the software deals very well with visualisations of complex relations, they are themselves not always easy to understand or manage through the textual interface of the software (e.g. when defining or reviewing relations between different CUs).

Despite a great attempt at making the massive amount of data manageable, a major weakness is the sometimes awkward and unintuitive control. Some of these problems certainly derive from the architecture of tablets and touch-screen devices in general, but some also relate to iDig's design. For instance, during the step-by-step process of adding a relation to a CU, the instructions guiding the first step list all possible temporal and spatial relations, while the final step effectively lists all CUs, making it a cumbersome process to establish one relation, let alone multiple relations for each CU. Although temporal and spatial relations are deeply and intrinsically inter-related in archaeological practice, disentangling them for the purposes of recording data may be a more pragmatic and sensible approach. A final critical note is that apparently no part of the software's configuration can be customised and it is tailored only to recording a few types of excavation data in the context of the Athenian Agora project. In fact, the software comes with predefined lists of diggers, deposits, and chronological phases to which the user can add new values by typing, but not remove or change old ones.

Conclusion and Discussion

iDig presents innovative features such as the real-time integration of data from previous seasons, the next trench over, and a properly equipped Leica Total Station standing by. The options for visualisation and drawing relation diagrams on the fly are also impressive and the software looks slick. Certainly, these are exciting aspects that many archaeologists undoubtedly will find useful in the field and that without doubt could save precious time. In addition, the pencil tools, filters, and organisation of data are exceptionally well executed and usable, within the scope of the Athenian Agora Excavations project. Whereas other data management modules, like FAIMS and ARK, as well as database systems developed in FileMaker are usually text-based, iDig provides a stronger visual interface and workflow.

However, the software cannot be customised and/or include other aspects of archaeological field recording. Currently, it is not possible to record other types of archaeological data (e.g. survey, archaeobotany, archaeozoology, geophysics etc.), and although the software is not explicitly presented as an encompassing package, its present form does not seem prepared to include this in the future. However, over the last century, the integration of different disciplines has turned archaeology into a much more complicated field of study, and we can expect new fields (like computer science) to complicate archaeological recording even more, necessitating the integration of these fields in different ways. Developing iDig to facilitate such broader use and have a bigger impact on archaeological recording might prove challenging, but nonetheless deserves attention if the software is intended to be useful outside the Athenian Agora project. Such development could only be done collaboratively, in the field, with source codes, different types of equipment, and specialists at the programmer's fingertips.

In addition, some users might hope that iDig's developers will explore integrating already existing technology of tablets, such as digital photography, voice-recording, and connection to other BlueTooth-peripherals (the website mentions it intends to develop BlueTooth-enabled Total Station connections). Others would perhaps wish the software was available for different operating systems and devices, or maybe suited to other archaeological practices such as survey at scales requiring grid-sizes larger than five metres. A final avenue of exploration is exporting the data from the system; iDig currently only exports to a UTF-8 Tab-delimited text-file, which at times may not be the most convenient format, as such files often require some sort of post-processing.

Aside from these suggestions, other points of consideration include the stability of the software. During the course of my testing, the software crashed twice. Admittedly, this could have been caused by the (older generation) iPad with a recent version of the iOS operating system, but iDig definitely pushed the boundaries of my iPad's capabilities; others may have different experiences on newer machines. Recent versions tend to put more strain on older hardware (e.g. selecting a different map does not immediately update the name of the currently viewed map). This seems unlikely to relate to an imbalance between hardware/software and rather suggests the possibility of small (insignificant yet destabilising) bugs. Also, sophisticated calculations and a continuous use of Wi-Fi and other hardware components will undoubtedly have an impact on energy consumption, draining the battery and making the software expensive to run.

In conclusion, iDig supplements the developing in-field digital recording toolkit of field archaeologists, and on the one hand exemplifies some of the possibilities that modern technologies have to offer archaeological data recording. On the other, the use of one or more iPads and Leica Total Stations will not be affordable and/or used by many projects. iDig was developed to assist recording during digging and does not facilitate other aspects of archaeological recording (e.g. survey or archaeobotanics). However, in modern practice, different specialists are part of the collection and interpretation processes of data. To secure its place in the future of archaeological recording, and play a viable role in interpretation, I hope iDig will develop to become a more comprehensive and integrated tool to support other aspects and types of data in different archaeological projects as well.

Bibliography

Austin, A. 2014 'Mobilizing archaeologists. Increasing the quantity and quality of data collected in the field with mobile technology', Advances in Archaeological Practice 1, 13-23. https://doi.org/10.7183/2326-3768.2.1.13

Dufton, A. 2016 'CSS for Success? Some Thoughts on Adapting the Browser-Based Archaeological Recording Kit (ARK) for Mobile Recording' in E.W. Averett, J.M. Gordon and D.B. Counts (eds) Mobilizing the Past for a Digital Future: The Potential of Digital Archaeology, Digital Press at The University of North Dakota. https://thedigitalpress.org/mobilizing-the-past-for-a-digital-future/

Roosevelt, C.H., Cobb, P., Moss, E., Olson, B.R. and Ünlüsoy. S. 2015 'Excavation is destruction digitization: advances in archaeology practice', Journal of Field Archaeology 40(3), 325-46. https://doi.org/10.1179/2042458215Y.0000000004

Wallrodt, J. 2016 'Why Paperless: Technology and Changes in Archaeological Practice, 1996–2016' in E.W. Averett, J.M. Gordon and D.B. Counts (eds) Mobilizing the Past for a Digital Future: The Potential of Digital Archaeology, Digital Press at The University of North Dakota. https://thedigitalpress.org/mobilizing-the-past-for-a-digital-future/

 ISSUE   HOME   FOR AUTHORS 

Internet Archaeology content is preserved for the long term with the Archaeology Data Service. Help sustain and support open access publication by donating to our Open Access Archaeology Fund.