Techniques employed for data collection and model generation during the 1995 excavations University of Victoria Jordanian Department of Antiquities
A report on the tools and techniques used to collect measurements in the
field and integrate them into an overall site information system
By linking the entities in these CAD drawings to these database tables (also an automatic function of the original drawing), a Site Information System would be created, providing a single interface to the entire data set.
The experiment was a qualified success (the patient died) but the approach has proved itself and our experiences may be of interest to others embarking on such a venture.
Al-Humeima (the ancient Hawar or Auara), was a major Nabataean, Roman, Byzantine, and early Islamic centre in Jordan's southern desert. The ruins of the settlement lie just east of the Wadi Araba about half way between Petra to the north and Aqaba (ancient Aila), on the Red Sea, to the south. Ancient sources credit its founding to the Nabataean king Aretas III (87-62 B.C.) and archaeological and literary evidence indicate that the city flourished in the Late Roman and Byzantine periods, and during the Umayyad and early Abbasid eras. Around 687 the town became a centre for the Abbasid family's revolt against the Umayyad dynasty and the fortified house (qasr) and adjoining mosque (masjid) built by that family are the source of most of the illustrations used in this article.
The recording of the 1995 season at Humeima represented a significant departure from most previous archaeological record keeping in that an attempt was made to modify field procedures to integrate the initial recording with the creation of a spatial database of the site. The intent was to create links between the copious database tables of pottery and finds already being maintained and the graphic information provided by the drawings which would be prepared during excavation. In this way the plans and sections generated by the CAD program become a graphic interface providing access to a Site Information System, as previously described by the author. The resulting model can respond to queries in SQL (standard query language) and, by using the Autocad Data Extension (ADE), display the requested CAD entities and through these the relevant images, text files and database entries are accessible with a mouse click.
For a number of reasons such a system is difficult to build after the fact. In even the most comprehensive field notes the data needed to reconstruct such a CAD model will be incomplete. Coordinates tend to be plotted rather than written down and, while it is possible to determine the X,Y values from the plotted plans these values are less precise and much slower to enter into a database than if the numerical values were available. As well, assumptions about things such as right angles often prevent the satisfactory coordination of adjacent squares.
This shortage of dimensional information, coupled with a tendency for descriptions and associations to be buried in field books and for other information to be scattered among the specialists studying it, means that any attempt to create a comprehensive database from pre-existing material will become an extremely large job and the product will inevitably contain numerous inaccuracies and omissions.
A compromise would seem to be the conversion of the manual drawings to a CAD format either by scanning and vectorization or using a digitizing tablet with the entities thus created linked to the data using conventional GIS software. However such a conversion would be slow and require large investments in hardware, software and expertise. Furthermore, the creation of the links between drawing and database can be awkward, time consuming and are prone to error.
The breakthrough that realised the possibility of actually keeping up with the excavation using CAD was the automation of the drafting. The software we have developed reads a database of the points collected on-site which is annotated with CAD functions and Object Names and from this creates a three dimensional model as accurate as the points collected. Thus our primary objective at Humeima was to get the geometric data first hand by capturing all the measurements digitally, before they became buried in the general notes or had their accuracy reduced by plotting.
There are various techniques used by archaeologists to establish the absolute position of objects. These include: distance and offset measurements, trilateration, surveying and even manual sketches. Each has its own inherent accuracy, limitations and resource requirements but added to these considerations was our need for easy input of the resulting coordinates into the database that would eventually create the drawing. Modern surveying tools such as the "total station" would have satisfied these requirements most efficiently, and it was for such input that the software was originally designed, but the high cost of these tools coupled with some problems encountered when using them in an archaeological context, dictated a different and more economical device.
Our solution was to design a device, best described as a digital plane table which we dubbed the "omphalos" (as it was to be the centre of each square's world for the duration of the dig). It consists of a compass rose on which is mounted a rotor supporting a tape measure. This provides an angle, distance and, when a line level is attached to the tape, a relatively level tape position. The tape is extended to a point directly over the spot to be measured and the angle and distance read at the centre of the device. The depth is read off of a calibrated rod or by plumb bob and a second tape. This system provides polar cylindrical coordinates which can easily be entered into the database and which have the added advantage of being almost impossible to "fudge".
To assure that all the pertinent information would be recorded in an easy to input format, data entry sheets were designed reflecting the fields of the database. Two such sheets were prepared, a general measurement sheet and a baulk specific version. The general measurement sheet was laid out with the three coordinates (angle, distance and depth), the point ID which tells the CAD program what to do with the data and the object name which groups the cad entities into the single symbol which will be linked to the database. To these fields, essential for the automatic drafting program, were added the project specific fields of locus number, object type (soil, architecture, installation, etc.), phase and date. We had also prepared Baulk Measurement Sheets which were designed as a matrix with the X values across the top and the Y values for each strata occupying the rows below. However these did not prove to be flexible enough for many situations and the General Measurement Sheets were modified to accommodate the X,Y measurement system used for the baulks and in other situations where detailed measurements were required.
As ours was the first use of this system for archaeological excavation many details had to be worked out in the field. Naming conventions, for instance, evolved as the project progressed. From the outset we knew that all names needed to be useable as filenames (for both Mac & DOS systems) but a consistent set of codes for square numbering, object names, find registration numbers, photographs and other associated documents took some time. This is the central issue behind all digital recording and the chances of success will be greatly enhanced if these questions are well thought out before going to the field.
Careful planning is also required on the question of what exactly you are going to try to capture for the model. This was not completely clear to us at the outset and as a result there was a wide variation in the data prepared by the different excavators. The most extensive databases provided what was essentially a stone by stone drawing of the entire square while others showed only wall outlines supplemented by manual sketches.
For efficient utilization of the system and to obtain a consistent model these questions must be resolved well in advance. A guide should be prepared and published which spells out the approved file naming formulas and minimum recording standards along with examples of how each recording sheet is to be filled out. The excavators are generally quite willing to follow a structured procedure especially if the reasoning behind these dictates are clearly explained but they quickly become frustrated if they have to invent something which must eventually be changed.
In our case the 1995 season was expected to be a test of the system so we were prepared for these variations, but in the future the requirement will be to provide a database capable of producing: wall and floor outlines, installation volumes, landmark stones, tumble outlines, locus tops, bottoms and elevations, registered finds and baulk drawings. To these, computer generated, entities will be added stone by stone sketches and baulk details drawn by hand over the computer generated base.
The procedure, as it evolved, was as follows:
When a square was opened it's location and orientation was established and staked out by survey in the conventional manner. The omphalos was then installed at some relatively high and stable point in or near the area to be excavated and its relationship to the square was calibrated based on distances and angles taken from its centre to the known corners of the square. This location was later confirmed by comparing the square outline as produced from measurements taken by omphalos and those from the original setting out. The discrepancy between these values was treated as the standard error for that square. In situations where multiple omphali were required, due to obstacles such as walls around which measurements could not be made, their location was also established by survey though this could also have been accomplished using the polar system relative to the benchmark.
At the computer a symbol reflecting the size, shape and orientation of the square was inserted into a master CAD model of the site and then exported to the square drawing where a symbol representing the compass rose was added and oriented as indicated by the measurements taken during setting out. From this symbol a coordinate system was established for the square drawing, based on the elevation and orientation of the omphalos. When we had drawings from previous seasons we also added these to the square drawing by adding raster files using TernOVLY a raster overlay product working within Autocad.
As excavation proceeded most of the measurements needed were taken by reading the angle, distance and depth based on these omphali and the values recorded on the data collection sheets for later entry into the database but as an alternate to the radial measurement system, the software allows the use of the more conventional X,Y coordinate system. This we found useful for detailed work such as floors and the stone by stone drawings of wall elevations as well as the baulk drawings. The switch is accomplished by placing a tape measure in any convenient location and establishing its position using the radial system. Point identification codes for the origin, X axis, Y axis and origin offset (if the 0 point can not be measured) will, when entered into the database, create a new coordinate system which will be in effect until another is established or a previous one recalled.
The data entry phase worked best when the numbers were read by one team member to another who keyed in the information but even at its most efficient this manual step caused computer congestion which in turn provided an excuse, for those so inclined, to fall behind in the process. Once the data is entered the drawing is automatically generated and errors and absurdities are obvious and can be weeded out or flagged for investigation on site. Because they lacked this immediate feedback, the groups that fell behind with their data entry never developed the measurement techniques needed for good results and this often resulted in an incomplete or inaccurate record.
In future seasons enough computers will have to be provided to allow about an hour a day per square for data entry and drawing manipulation. The need for more computers, the time spent recording and entering these numbers and the errors that arising from the process suggest that a total station or some other automated measurement system is a cost that may be well justified.
When printed top plans or baulk drawings were needed subsets of the data showing particular loci were printed with the different elements differentiated by varying linetypes. Loci were printed using solid lines with elevations inserted at points indicated by the recorders, tumbles and random stones were plotted with dashed lines and architectural elements were plotted using a faint dotted line which was later enhanced manually by the excavators. For the final top plan these manually rendered drawings were scanned, vectorized and added to the square template drawing.
Finds were treated as symbols by inserting AutoCad blocks designated as coin, ivory, metal etc. into the drawing at their measured locations and links were created, using ADE, to both the geometric database (to which all the objects are linked) and to the separate database tables specific to the object in question.
By far the greatest problem with the system, as implemented, was that the measuring devices were not up to the conditions. Tests in the classroom and some limited field trials in Canada, showed the radial measurement system to have accuracies comparable to the baseline and offset method and though they were slightly inferior to trilateration, overall accuracy was well within that needed for a model of this type. The radial method was chosen because it can generally be performed more quickly and with less manpower than the others while still providing relatively straight forward data entry. An added consideration was that the output from a total station is in a similar format so less customization of the software was required, though the program now accepts all common formats except trilateration.
The high winds prevalent at the site caused the tapes to flap or bend giving erroneous angle and depth measurements. One solution was to take measurements in the morning whenever possible (before the wind picked up) but the excavators were often forced to take angles and depths with a string line and a separate distance with a tape measure which slowed the procedure significantly. Other difficulties were caused by tape measures whose locking systems succumbed to the desert conditions and prevented tightening the tape enough to give reliable levels. However, despite these problems several groups achieved accuracies more than adequate for wall outlines and locus volumes though they often had to resort to an X,Y system or manual drawing for individual stones. This was in no way detrimental to the final model and, in fact, this manual enhancement after plotting was deemed to be a useful compromise between the requirements of the computer model and the desire for detailed top plans.
Clearly other solutions to the measurement question must be found. For the architectural recording of heritage buildings we use an electronic theodolite coupled with a visible laser distance measuring device. This provides excellent (and completely automatic) results for architecture but such an arrangement has trouble seeing into the holes which are the stock in trade of the archaeologist. We are working on a compromise that would combine the visible laser with a rotary encoder for angles and a data entry device for the other variables though this, like the very continuation of the experiment at Humeima, is likely to be delayed due to a lack of funding.
In spite of the problems in the field I feel that this experiment
was completely successful with one glaring exception. On the
positive side we demonstrated that archaeological data can easily
be captured in formats ready to enter into a computer and the
automation of this step is within sight. The CAD/data model of
the '95 season if not consistent, is complete, and with the
integration of the scanned, stone by stone, sketches from both
'95 and previous seasons the drawings would be as detailed as any
archaeological record I have seen. More important than these
graphic considerations though is the fact that all of the
elements we recorded, though they have been destroyed or at least
lost their context in the real world, have been given a second
life in cyberspace. They know what they are and where they came
from as well as how to locate further information about
themselves. That information can be in any electronic format
including pointers to non electronic data and will grow as more
is gleaned from the site. One would think that this would be the
answer to an archaeologists dreams but the fact is that even
after almost a year with this data on their computers none of the
project directors has learned how to deal with it. I have heard
several explanations for this - time, money, learning curve - but
the reason can only be that they are not really aware of the
extent of the resource they have at their disposal.
There are two phases to the adoption of any new technology. At first it is a new tool which is used to do the old task but eventually that task changes to take advantage of the new possibilities. It seems that second level of adaptation has not yet been reached in archaeology. The focus is still in putting things on paper and the paper, not the underlying data, is seen as being the final product. From my vantage as a technical support person, who has been doing almost everything by computer for several years, this is hard to understand, especially when I see the drawings being redrawn by hand while the digital equivalent sits, complete and unexplored, on floppy disks in the drawer but the bottom line is that if the data cannot be used by those who need it is of no more use than if it had not been collected at all. So the experiment has been cancelled, a classic case of the operation having been a success even though the patient has died.
The software used was as follows:
Autocad (release 12). . . . . . . . . . . . . . . . Autodesk graphic engine Autocad Data Extension (ADE 1.0) . . . . . . . . . Autodesk CAD - database connection CART - Computer Aided Recording Tool . . . . . . .Nickerson automatic model generator dBASE III . . . . . . . . . . . . . . . . . . . . . .Borland data entry and manipulation TERNOvly version V . . . . . . . . . . .Tern Solution Group raster viewing and manipulation within Autocad
Nickerson, S. 1996
CART - A Computer Aided Recording Tool
Automation in Construction Magazine
Elsevier Science Publishers
Nickerson, et al. 1995
Integration of Measurements and the Knowledge Base to Generate a CAD model on Site.
proceedings of ACADIA '95
University of Washington, Seattle
Nickerson, S. 1994
A Site Information System (SIS): CADD/Database Integration for Field Use.
APT Bulletin 24(1):56-62
Nickerson, S. 1994, 1996
Object Oriented Recording
Nickerson, S. 1995
A Comparison of Measurement Techniques in Archaeology and Heritage Recording
Oleson, et al. 1993
The Humeima Excavation Project, Jordan: Preliminary Report of the 1991-1992 Seasons
Annual of the Department of Antiquities of Jordan
37 (1993): 461-502
Oleson, et al. 1994
The Humeima Excavation Project, Jordan: Preliminary Report of the 1993 Season
Classical Views/Echos du monde classique
13 (1994): 141-79
Oleson, et al. 1995
Preliminary Report of the Humeima Excavation Project, 1993
Annual of the Department of Antiquities of Jordan 39 (1995).