Vol. XV, No. 3

Winter, 2003

How many times do we need to invent the wheel? An old and trite question, but one that is too often appropriate when new archaeological projects start up and computer programs are to be used. Time and again it seems that personnel assigned to do computer work have little or no serious experience to guide them in the particular tasks assigned; so that proverbial wheel must, in essence, be invented again and again and again.

People who have experience with one computer technology -- database development, CAD, or GIS -- are too often asked to work with another, regardless of their background and training. Similarly, a project's most experienced computer person is too often asked to take on a new computer task for which he or she has neither training nor experience. The lack of experience often shows most quickly when software choices are made. Inexperienced users very often want to use software that experienced users have rejected for specific reasons. The choices are obviously not made with ill intent, but they are generally made out of an innocent ignorance borne of the absence of experience.

Project directors obviously do not choose people to do computer work with the expectation of ineptitude. The assumption, usually implicit, is that he/she who knows one computer technology can easily pick up another without instruction or time lost to training. After all, how many academics have received training in the computer technologies they use every day -- email, word processing, Web browsing? The assumption -- again implicit -- is that none of the computer applications is so difficult that formal training is required. A similar assumption might result in expecting a Latin scholar to become proficient in ancient Greek both quickly and on his/her own because, after all, he/she has demonstrated proficiency in one ancient language and another must not be much different.

It is rare that a month passes without an example of this kind of confidence in a staff member who seems to be competent in one area and is consequently pressed into service in an area where he/she has neither expertise nor training nor experience. For that reason, Susan Jones and Nick Eiteljorg have joined forces to explain why experience and training with each specific computer technology to be used in an archaeological project -- not with computers in general or with some other computer technology -- should be prerequisites for anyone who may be given responsibilities with that technology on a project. We will treat separately the three crucial data-recording technologies most commonly used in excavations and surveys -- database management, CAD, and GIS. The discussions are not meant to be complete -- a book would then be required -- but simply to offer some compelling reasons to insist that, as project director, your database manager have training in database technology and archaeology, that your CAD specialist have both CAD and archaeological experience, and that your GIS supervisor does not have to learn either archaeology or GIS technology on the job. At the same time, it is important for those who may be pressed into service to realize that, absent training and experience, they risk reducing a project's ultimate success and being responsible for errors of omission or commission they could not have prevented.

Databases

Why does one need training with databases in archaeological settings before putting them to use in such a setting? This is really a two-part question. First, why does someone working on an archaeological database need training with database design and development? Second, why does a computer specialist working on an archaeological project need archaeological experience?

1. Protecting Data from Accidental Change or Erasure

Let us start with the first question, why does someone working on an archaeological database need specific database training? Many archaeologists, after all, have learned to use computers, including complex database management software, on their own. Here is one rather simple example from a project I visited several years ago. A database for the project had been prepared by someone with some computer experience; so the problem that was apparent to me was unexpected. In this case the data items, when presented for casual on-screen viewing, were not protected from accidental erasure or change, despite the fact that the program used had an excellent feature for doing so. Any time the data items could be seen on the computer monitor, any item could be changed by accident, and there was not even a warning or an instruction for reversing an unintended change. Presenting the data in such a way is such poor practice that any modern database management system provides at least one way to present data while preventing change, but the person who prepared that database was either unaware of the problem or chose to ignore it.

2. Making Data Entry Smoother, Easier, and Less Error-Prone

A more complex example from an excavation database also illustrates the need for training. The excavation was of a multi-period site with different paper data sheets for excavation units of different periods. Each paper data sheet presented to the excavator a list of the most common pottery styles appropriate for the period and some blanks for styles not listed. For each style a number could be provided for handles, rims, body sherds, etc. In addition, any of the listed styles could be edited to change the description; for instance, a listed description such as "red-slip cream ware" might be changed to "brown-slip cream ware" on the paper sheet.

The data entry form on the computer had to match the paper form used by the field personnel so that errors could be kept to a minimum. Thus, the computer form presented for data entry listed the pottery styles from the data sheets in the same order; the content of each list depended on the period of the excavation unit. The entry process also had to permit each item on the list to be edited (changing that "red-slip cream ware" to "brown-slip cream ware" on the computer screen to match the paper change), permit new styles to be entered (matching new entries on the paper form), and then allow the numbers of sherds of each kind to be entered. For the next data entry process, however, the original listed styles had to be presented again, without the changes made in any previous entry process so that the starting computer form would again mimic the paper form. Those unfamiliar with database design may have only a glimmer of the problems presented in this example, but the key difficulty lies in presenting a list that the user can modify for data entry while not permitting that user to corrupt the original list; the original list must be presented exactly the same for each data entry session. This is not the now-proverbial rocket science, but neither is it something that can easily be done by an inexperienced database designer.

3. Keeping Track of the Finds

If the foregoing explains why database training is required, the second question, "Why does a computer specialist working on an archaeological project need archaeological experience?" remains to be answered. That is a harder question, because archaeologists may not easily recognize the uniqueness of their needs. Perhaps this example will suffice. In the same excavation referred to above the sherds from any given excavation unit were brought to the dig house in a bag labeled with the context information (excavation unit). The bags did not need unique identifiers, since the need for context information was entirely satisfied by the label. However, the need to re-examine the contents of any given bag to confirm the analysis (data were recorded for each bag, not each excavation unit) or to do more detailed analysis required a bag number as well as the context information. It was the database designer who realized that and added a computer-generated bag number to the database -- but the database designer was also an archaeologist who was concerned that later re-examinations would be possible only with an identifier for each bag.

CAD

Why does one need training with CAD for use in archaeological settings? In this case, most readers will acknowledge that training in CAD is necessary. This is not software one can easily learn on one's own. A few people will try to learn CAD alone, no doubt, but it is hard to believe that anyone would hire an inexperienced archaeologist to work with CAD on an excavation. Or is it? Actually, such a plan was just suggested for a project; so let us have two examples here as well.

1. Using CAD Layers

Some years ago an architect was brought to a site to inaugurate the use of AutoCAD^® there. Despite his training as an architect, he launched into the work without considering the use of CAD drawing segments (called layers) to separate the materials drawn in an individual trench as it went deeper and deeper into the earth. Instead, he used different colors to distinguish the materials from one phase from those of any other. In a fairly short period of time he had an indistinguishable mass of lines, none of which could be made out because he had drawn everything on the default layer. The complexity of the whole overwhelmed the color distinctions. A system of layers was eventually introduced to assist, and work could then continue, with layers removed from view when appropriate so that the resulting drawings could be useful. In the meantime, though, time and effort had been wasted, and only the chance appearance of a CAD expert at the site provided the solution.

2. Drawing a Rectangle

A more basic problem with CAD may be seen here, in the five different versions of the same simple rectangle. What are the differences? The first rectangle is actually four lines; each is unrelated to the others. If one is moved, the others stay where they are.

The second rectangle is treated as one line broken into segments. The entire rectangle will move along with any part thereof, with the shape remaining constant. To change its shape, one must specifically change the location of one of the corners.

The third rectangle was produced by a specific command that could only generate a rectangle, with specified length and width; each of the preceding commands could have been used to generate an irregular quadrilateral figure. The resulting figure, however, is identical to rectangle number two. It is a single unit that can only be moved as a whole, with internal relationships remaining constant. The shape can be changed by editing any one corner, bur all corners must have the same elevation. (It could, after completion, be rotated to lie on an inclined plane, as could rectangle number two.)

The fourth rectangle is the same as the second with one important distinction. It was made with a process that permits any individual corner to have an elevation different from any other. In the case of the second rectangle, each corner had to have the same elevation because of the command used.

The fifth rectangle is understood by the CAD system to be more than a rectangle; it has been created explicitly as a surface. Therefore, it is capable of interrupting a line of sight, of obstructing a view of anything positioned behind it. None of the previous figures can obstruct a view of any other item. None of them is a surface.

The distinctions between and among the various "rectangles" are not trivial. Each is produced by a different command and different data sequences. Some of the rectangles are appropriate for certain uses, others for different uses. Trying to use any of these except the last, however, would not permit a useful 3D model to be built. It is the only rectangle that can function as a real-world object to obstruct views of other objects. Is that something an inexperienced CAD user would understand without instruction? Would someone who does not understand archaeology know when to use each? Experience with beginning CAD users suggests a negative answer to both those questions.

GIS

The power of Geographic Information Systems (GIS) in archaeology is greatly enhanced by scholars' ability to use maps that were created for another use or user in another time and place. At the same time, however, that ability to use maps created by others for other purposes places an enormous burden on the scholar who needs the maps because, like all maps, GIS maps of geographic areas abstract and simplify the real world in some aspects. Those abstractions and simplifications can create serious problems for anyone wishing to use maps of any kind, but especially maps made for other purposes. Two of the traps waiting for the inexperienced user of GIS are discussed here.

1. Map Projections¹:

Even were the earth truly spherical, which it is not, mathematical transformations known as projections would be required to plot geographic points on the earth's surface onto a two-dimensional surface such as a piece of paper. Indeed, there is a long and distinguished series of cartographic work on this topic, with different projections systems defined to meet specific problems confronted by map makers over the centuries. As a result, there are many different mathematical transformations used to generate projected maps, each different from the other in subtle but important ways. A map made with one projection differs significantly from a map made with any other. As a natural consequence, a GIS user must know what projection was used for any given map, whether it is the appropriate projection for the task at hand, and how to fit it to other maps that may have been generated by a different projection technique. This seems arcane but can be very important, as illustrated in the following. Figures 3 and 4 are simple maps of the US. The reader will recognize each and may not even notice any significant differences between them, but they have been made using different projection systems.

Note what happens when they are superimposed on one another, with a third map based only on latitude and longitude, in Figure 5. The apparent similarity has suddenly disappeared; instead one is struck by the differences. At this scale, all three maps appear to align for Missouri and Illinois, but the versions of Florida and Maine appear to be in different locations. If you were to draw a road from St. Louis, Missouri, to Bangor, Maine, on the Mercator projection map the road would end up in the North Atlantic on the Lambert Conformal Conic projection map! On this combined map Augusta, Maine, seeming to be hundreds of miles from Augusta, Maine.

To use data from any one of these maps with any other of them requires that the user know the map projection system used (including the center of the map, in latitude and longitude) for each map. Otherwise, the data will be mismatched. CSA's first foray into GIS some years ago, in fact, was based on maps for which no information about the projection system could be found, which is one of the reasons that work foundered.

2. Generalizations²:

Maps require different kinds of simplifications to show coasts, rivers and roads. The paths of such features are too complex to be shown accurately at scale; so they must be generalized; the paths must be made simpler. Similarly, a map may generalize by aggregating many river channels around small islands into a single channel, possibly eliminating the islands altogether if the map is small. The generalization may be a deliberate decision to omit some entities, e.g., road details on a map of a river or river details on a road map. Once the generalization has occurred, the map lacks the data omitted. There is no way to recover the information without re-creating part of the map.

Now consider what happens when the location of a specific point such as a burial -- perhaps a location from a GPS used in a survey -- is added to a map by entering the latitude and longitude coordinates. That point suffers no loss of precision; latitude and longitude fix its position. But other parts of the map will have some lack of precision because of the necessary generalization. That generalization may be sufficient to cause considerable confusion. The map below; Figure 9 A, B, and C; illustrates the potential problem.

If the person who gathered the data and the person who entered it have done their jobs well, the problem with relating the stream to the burial location will be apparent in scenarios B and C, but there is no "fix" for that problem. The map generalizations made it impossible to show the the true course of the stream, and the exact placement of the burial is correct. This shows how important it is to match GIS data sources to one another and to the needs of the project at hand. This is a problem for which inexperienced personnel cannot be prepared.

In both these examples the need to use data gathered in different ways and for different purposes is critical. Being able to do that, as noted already, is the great strength of GIS programs. Knowing how to do it, however, requires training and experience.

Conclusion

Using database systems, CAD software, and GIS programs requires specialized training. The issue has been discussed in the CSA Newsletter before and doubtless will be again. It is crucial and remains under-appreciated.

While there are programs specifically for such training in the UK, students in the US still have difficulty obtaining useful and effective computer training. In part, of course, that reflects the absence of training among older scholars, but it also reflects a job market where such skills are not valued and a climate that too often deprecates formal training for fieldwork, implicitly assuming that on-the-job training is best. Finally, the absence of training also reflects the prevalent view that computer skills can be learned by anyone when needed. That may be true for word processing or email, but it certainly is not for database development, CAD, or GIS.

-- Harrison Eiteljorg, II
    Susan C. Jones

To send comments or questions to the author, please see our email contacts page.

1. For a wider discussion of map projections see: http://www.colorado.edu/geography/gcraft/notes/mapproj/mapproj.html, written by Peter H. Dana, The Geographer's Craft Project, Department of Geography, The University of Colorado at Boulder, copyright 1999. Accessed 1/17/03.
and the web site from the Department of Geology, University of British Columbia, compiled with assistance from Vicki Chmill, University of California, Santa Barbara: http://www.geog.ubc.ca/courses/klink/gis.notes/ncgia/u27.html#SEC27.1. Accessed 1/17/03.
Return to body of text.

2. The mapping standards employed by the United States Geological Survey specify that: "requirements for meeting horizontal accuracy as 90 per cent of all measurable points must be within 1/30th of an inch for maps at a scale of 1:20,000 or larger, and 1/50th of an inch for maps at scales smaller than 1:20,000." This translates into +/-10 meters at a scale of 1:12000, and +/-50 meters at 1:100000. http://www.colorado.edu/geography/gcraft/notes/error/error_f.html, written by Kenneth E. Foote and Donald J. Huebner, The Geographer's Craft Project, Department of Geography, The University of Colorado at Boulder.copyright 2000. Accessed 1/17/03.
Return to body of text.

For other Newsletter articles concerning the applications of CAD modeling in archaeology and architectural history, the applications of GIS, issues surrounding the use and design of databases or the use of electronic media in the humanities, consult the Subject index.

Next Article: Comprehensiveness for All: The OASIS Project and Research Values in the Digital Age

Table of Contents for the Winter, 2003 issue of the CSA Newsletter (Vol. XV, no. 3)

Table of Contents for all CSA Newsletter issues on the Web