The recording of the 1995 Excavations at Humeima represent a significant departure from most previous archaeological record keeping in that an attempt was made to modify field procedures to facilitate the creation of a spacial database of the site. The intent was to create links between the copious databases of pottery and finds already being maintained and the graphic information provided by the drawings prepared during excavation, so that those plans and sections could become a graphic interface providing access both to the geometric data and to the individual databases of the artifacts. This combination would provide a site-wide model capable of responding to queries in SQL (standard query language) by displaying the associated CAD entities through which the relevant images, text files and database entries would be accessible.
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 coordinates 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 processing 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 and the entities thus created linked to the data using conventional GIS software. However CAD drafting can be slow and requires large investments in hardware, software and expertise and the creation of the links between drawing and database can be awkward and time consuming.
The breakthrough that created the possibility of actually keeping up with the excavation using CAD was the automation of the drafting. Newly developed software will take a database of points, annotated with point function and object names, and create 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 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 including trilateration, distance and offset measurements and surveying. 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 we were using was originally designed, but the high cost of these tools dictated a more economical solution so a device best described as a digital plane table was developed which would provide polar cylindrical coordinates that could easily be entered into the database. It consisted of a silk screened compass rose with a rotor supporting a tape measure on the end of which is attached a line level. This provides an angle, distance and relatively level tape position, the depth is read off of a calibrated rod or by plumb bob and a second tape.
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 consisted of 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.
The Baulk Measurement Sheets were designed as a matrix with the X values across the top and the Y values for each strata occupying the rows below. 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 and are still far from being resolved. We knew that they all names needed to be useable as filenames (both Mac & DOS) but a consistent set of codes for square numbering, object names, find registration numbers, photographs and other associated documents still needs to be worked out.
As well it was not clear at the outset exactly what it was we would try to capture for the CAD model and there was a wide variation in the data presented by the different squares. 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.
The 1995 season was expected to be a test of the system so we were prepared for these variations, or even the total abandonment of the idea, but in the future the requirement will be to provide a database capable of producing wall, floor & installation outlines, landmark stones, tumble outlines, locus tops, bottoms & elevations, registered finds and where necessary baulk drawings To these computer generated entities will be added stone by stone sketches and baulk details drawn 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 a conventional manner. A compass rose was then installed at some relatively high and stable point in or near it 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 a comparison of measurements taken, using the rose, of the staked out square and the discrepancy between these values and the surveyed points can be considered as the standard deviation of the measurements. As well the elevation of the rosette was established by survey, based on established bench marks.
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 at the site. From this symbol a coordinate system was established for the square drawing, based on the elevation and orientation of the rosette, from which all future measurements would originate.
As excavation proceeded the measurements needed were taken by reading the angle, distance and depth based on this compass rose and these values were then recorded on the data collection sheets for later entry into the database.
As an alternate to the radial measurement system, provision was made to switch to a more conventional X,Y coordinate system for detailed work and the baulk drawings. This is accomplished by placing a tape measure in any convenient location and establishing its position using the radial system. Point ID codes for the origin, X axis, Y axis and origin offset (if the 0 point could 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 and provided an excuse for those so inclined to fall behind in the process. Presumably because of a lack of immediate feedback, these groups never developed the measurement techniques needed for good results and this often resulted in an incomplete or inaccurate record. Once the data was entered the drawing was automatically generated and errors and absurdities weeded out or flagged for investigation on site.
In future seasons computers will have to be provided that will allow about an hour a day per square for data entry and drawing manipulation. The need for more computers for data entry, the time spent recording and entering these numbers and the errors that arose from the process suggest that a total station is a cost that may well be justifiable for future seasons.
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 automatically 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 recorder. 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 linking them to both the geometric database (to which all the objects are linked) and to separate databases specific to the object in question.
By far the greatest problem with the system, as conceived, 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 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 the tightening of 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 need for detailed top plans.
Clearly other solutions to the measurement question must be found before the next season, probably a combination of a total station operated by the site architect or surveyor for the final top plans and a modified manual device for each trench's daily measurements.
Current Status of the Model
All data and control files for the project are stored in a single directory structure (HUM95) the contents of which are described in more detail in an accompanying document.
By the end of the season thirty four squares had provided databases totalling about 1.4 megabytes of data which is stored in the \DBF sub-directory. Template drawings for each square, totalling 2.5 megabytes, reside in the HUM95 directory though the size of most of these will increase substantially when the stone by stone linework is added from the scanned files (these are currently stored as PCX image files in the directory of the same name and occupy about 4 megabytes of disk space.
When generated these databases create about 4 megabytes of drawing files which are stored in the QUERY sub-directory. It is these drawing files that are consulted by the predefined ADE and SQL queries available under the "ade/query/run" menu item or the query building screens of "ade/query/define". Such queries will produce drawings of the particular elements requested and the elements presented bring with them their links to the database that created them, and in the case of finds, to a database for that class of object if such is present in the \DBF sub- directory.
To complete the model as envisioned there are a number of steps still to be undertaken.
To complete the drafting of final top plans:
The scanned stone by stone drawings must be brought into Autocad, using TernOvly or a similar product, scaled to fit the data and then vectorized, a process that will take one to two hours for each of the thirty seven areas for which such data exists.
To provide access to the databases of finds:
The databases currently stored as Macintosh Fox Base files must be modified to adhere to AutoCad naming conventions. Specifically this means removing the "." from the bucket and registration numbers though there may be other details that need to be addressed. Copies of these revised files would then be stored in the \DBF sub-directory along with the geometric data of the measurements.
To provide access to manual drawings and photographs:
To be accessible from within the model the images must be scanned and stored in an appropriate format (to be determined) using a file name consistent with the conventions used in the model. Photographs of loci, for instance, would be named for the square and locus and images of artifacts, either photographic or drawn, would bear their registration number.
To provide access to the written material:
Word processing documents describing different elements such as square summaries, locus and artifact descriptions, conservators reports or any other pertinent material should be saved as ASCII text files named for the object they describe with an extension designating the author.
Once these tasks have been accomplished the AutoCad drawing via the queries will be able to provide a front end to all the data from the site.
A comprehensive file and object naming standard must be developed as a first step in the implementation of any overall GIS type of application for the site and the existing databases converted to the new standard.
Area, Structure and Square names should be standardized and a conversion table linking the old and new names published.
The 1995 Data
The scans of the stone by stone drawings must be processed as must the photogrammetric material collected for the squares that did not provide adequate top plans in order to provide the documents that will be needed for publication.
Data collected prior to 1995
The scans of the stone by stone drawings of previous seasons should be separated into individual squares, scaled and vectorized. These would form the basis of square drawings similar to those created in '95 and would complete the geometric database.
Registered finds can be inserted manually into the square drawings, preferably in consultation with the excavators involved though the information provided in the field notes and find sheets should be adequate if the participants are unavailable.
Drawings and photographs of registered finds and significant square photographs can be processed as described above.
Square reports already in electronic formats should be converted to ASCII and named for the year, square & author.
Locus sizes and volumes can be left for processing on an "as required" basis though it is not anticipated that this data will ever need to be incorporated into the model.
The 1996 Season
If this experiment is to be successfully continued into the 1996 season a number of changes will have to be made:
The most urgent requirement would seem to be a detailed manual. This would be distributed to all prospective participants and would include an explanation of the benefits accruing from the model thus created. It would detail what is expected of the excavator in terms of the collection and processing of data and stress the need for the daily maintenance of the database. Detailed descriptions of the different point taking techniques and the naming conventions to be used should also be included.
To support these, well prepared, participants the project should procure, enough in advance to allow for configuration and testing, the following hardware and software most of which will be needed anyway to do the work described above.
At least two CAD machines, one for drawing generation and the other(s) for the excavators to tune their drawings to their muhdeers specifications.
At least two CAD knowledgeable participants to help train the others.
Several smaller machines capable of data entry and/or manipulation as well as word processing.
A total station &/or theodolite mounted visible laser for automating the measurement procedure.
Humeima Digital Data 28 February, 1999 I. Directory Structure A. E:\HUM 1. Autocad .DWG files a. Query Drawings HUM-F102.DWG, HUM-SITE.DWG, F103-MOS.DWG F103-SE.DWG, etc. b. blank template drawings for each square SH42.DWG, RM02.DWG etc. c. the symbol library HUM-SYMS.DWG 2. predefined ADE queries -FINDS.QRY, -WALLS.QRY -FLOORS.QRY etc. 3. D2L program files a. a D2L settings sheet for each square SH42.D2L, RM02.D2L etc. b. a global D2L settings sheet HUMLISTS.D2L c. Template Recording sheet HUM.RSH d. Batch files (1) HUM2M.BAT - starts Autocad & D2L (2) HUMDISK.BAT - prepares a data entry diskette (3) _BHUM.BAT - back-up instructions (a) HUM and HUM-DBF diskettes are needed to run this 4. Instructions and Comments in Wordperfect 5.0 a. MEASURE.HUM - Measurement techniques and Naming Conventions b. SCANS.HUM - Descriptions of Scanned files c. SQUARES.HUM - Information by Square (1) omphalos orientation and elevation (2) benchmark elevations d. SURVEY.HUM - Survey and Layout Information e. AUTOCAD.HUM - descriptions of useful Autocad commands f. HUM95_SN.WP5 - 1995 status report and recommendations g. HUM.WP - this list 5. Spread Sheets in Excel 3.1 a. SURVEY.XLS - a sumary of the survey information on which the 1995 benchmarks and the bearings reflected in HUM-SITE.DWG b. SURVEY-B.XLS - a blank spread sheet containing the equations for calculating new benchmarks and square elevations B. E:\HUM\DBF 1. the databases for all squares 2. each has the same name as the .DWG and .D2L files in E:\HUM C. E:\HUM\QUERY 1. the latest generated drawing from each the database of each square 2. used by the queries to create composites of all squares in an area and eventually across the site. 3. these files are created by using the Save_As option under files and chosing the QUERY directory - the filename stays the same as the blank one in E:\HUM D. E:\HUM\MIL - raster files from scanned drawings in CALS-4 format with a .MIL extension E. E:\HUM\PCX - raster files from scanned drawings in PCX format F. E:\HUM\SYM 1. individual symbol drawings 2. part of the ACAD system variable, this directory may contain other reference material needed by autocad G. E:\HUM\DISK - most of what is needed to create a data entry diskette H. E:\HUM\ARCH - miscelanious backup and reference files I. E:\HUM\PLOT - temporary storage for files prepared for plotting II. To Do A. Standardize procedures for new square layout 1. size, baulks, orientation B. Explore and develop procedures for the exchange of data across computer platforms C. Develop Naming conventions consistent with both Mac and Dos file naming conventions 1. Area, Building and Square 2. Files 3. CAD / D2L a. Symbology, Layer Use, Point ID, Object Names D. Develop Strategies and tools for producing final drawings 1. what needs to be measured in the field 2. points for rectification 3. scans of daily top plan tracings E. Convert scanned drawings to vectors on square by square basis for reference and final prints F. Full survey of site to orient the different structures and provide ample benchmarks and cross references for non professional maintenence