Article Index Project Index Print Version

Measuring Humeima '95 - Excavations at Humeima in Southern Jordan

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 Author: Steve Nickerson :


During the summer of 1995 an experiment in archaeological recording was carried out at Humeima in Jordan's southern desert. It was based on the premise that carefully collected measurements could be used to automatically generate CAD drawings of the trenches and, at the same time, build a database where all the hard information collected at the site could be stored. This information would then be supplemented by other tables where the interpretive information supplied by specialists, conservationists and historians could be added over time without affecting the primary record.

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.

Recording Humeima '95

Building a Spatial Database for Archaeology in the field

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.

Problems encountered

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.

Current Status of the Model

By the end of the season thirty four squares had provided databases containing about 1.4 megabytes of point information. Template Autocad drawings for each square, blank except for the square outline and the omphalos symbol, total about 2.5 megabytes and the scans of the manual sketches, currently stored as PCX image files, consume another 4 megabytes of disk space. When the drawings are generated these databases create about 4 megabytes of drawing files which are stored in a "query" directory and it is these drawing files that are consulted by the predefined ADE and SQL queries available from the custom menu. Such queries produce Autocad drawings of the elements requested and these elements bring with them links to the database that created them, and in the case of finds, to a database for that class of object if one is present. As well, the photographs, sketches and text files use the same object name as that used in the model and as a result these files can be located, viewed and edited using the same interface.


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 Humeima excavation is directed by J.P. Oleson, University of Victoria with co-directors: K. 'Amr, Department of Antiquities of Jordan, R. Schick, Albright Institute and R. Foote, Harvard University. It is funded by the Social Sciences and Humanities Research Council of Canada, the Taggart Foundation, the Van Berchem Foundation, and the American Schools of Oriental Research. The authors participation was supported by Designed Building Systems (Canada) ltd.

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

Humeima'95 - Bibliography

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).

Up Index Cover

Inquiries to:
Generated Fri Jul 30 08:33:53 1999 by: CART Computer Aided Recording Tools