A Sample Geodatabase Design for Archaeology

The actual manner in which you organize your data within a geodatabase does not have to be defined by anyone else. When I began researching a way to structure data so that it could be useful for the future, drawing upon mine and other's backgrounds in archaeology, the following design emerged as a useful one. The model offered below is not meant as universal, no data model for archaeology can be universal, there is just too much diversity in the arcaheological process.

However, a model is certainly a nice place to start, and there were none published in the archaeological or GIS literature that I could draw upon when I began to create mine.

There are two aspects of geodatabase creation that have to be carefully addressed by the designer. First, how will the geodatabase, its feature classes and feature datasets, be organized. Second, what kind of attribute data will be included in the attribute tables of each feature class.

I have organized my past geodatabases based on both past experience and the type of data typically available to archaeologists. Six datasets were created, each containing a number of feature classes.

(Feature Datasets and Feature Classes created for my Master's Thesis in Svalbard, Norway)

The six datasets were Arch_Tools, Artifacts, Boundaries, Environment, Structures, and Transportation.

“Arc_Tools” contained feature classes that represented data specifically related to the archaeological organization of the work, such as base datum points, dimensions of the sites (polygons), and feature number annotations (labels).

The “Boundaries” dataset held polygons that represent survey and site boundaries as established by the field work.

“Structures” held point, multipoint, line, and polygon files used to represent all objects associated with buildings (standing or ruined).

The “Artifacts” dataset held point, line, and polygon files which represent objects associated with individual artifacts (i.e. pipes, brick scatters, etc.).

“Environment” held only one feature class that recorded contour data for Longyear Valley used to create the DTM (digital terrain model).

The “Transportation” dataset included point, line, and polygon files representing any type of transportation facility, such as roads and railways. Historic and modern features are both contained in these feature classes dated by a field in their attribute tables.

In my opinion, each of these datasets could be used for any archaeological project. To summarize:

• Arch-Tools – information about archaeological organization of the work
• Boundaries – simple polygons labeled to outline work areas in the study
• Structures – information about standing or ruined structures, past or present
• Artifacts – information about individual artifacts or scatters of artifacts
• Environment – records characteristics of the physical environment
• Transportation – information about transportation facilities, past or present

Approaching archaeological work (especially if it will produce electronic data) with these classifications in mind will help ensure valuable information is not lost. Of course, differentiating structures from artifacts and so forth is different for each project. However, I believe that turning an eye to these considerations will greatly improve data collection, ease data handling, and create documentation strategies that include consideration of future research.

The selection of attribute data for any geodatabase is case-by-case. Only the project leader and those involved in the investigations know what they are looking for. Of course, there are certainly some common types of information that should be attached to each feature class. These include: site name, identifying number, occupation data, method of collection, historic context, basic dimensional measurements, photograph information, and so forth.

If you are creating a geodatabase, without a model of any sort, sit down with the project leader or a more experienced archaeologist and ask them what type of information they would like to have attached to features. Remember, ArcGIS and the Geodatabase design function like a traditional Database Management System (DBMS) in that you can search and select features by attributes, find features by searching for specific attributes, and even generate reports using any of the attribute data. Therefore, don't worry about including 'too much' information, there is no such thing, only needlessly redundant information (e.g. multiple features instead of one single, site wide feature).

Finally, like so much in GIS, creating a Geodatabase that fits your project and its future is an experimental process. That's why it has to remain updatable, in other words, expandable. Ultimately, the life of your GIS, whether you used a Geodatabase or not, is extended if you properly document its construction.

IMPORTANT

If you are using ArcGIS 9.2, there is a new geodatabase format that need to be aware of, the file geodatabase. The file geodatabase offers many advantages over shapefiles and personal geodatabases, such as:

• The file geodatabase uses an efficient data structure that is optimized for performance and storage. File geodatabases use about one-third of the feature geometry storage required by shapefiles and personal geodatabases for Access. File geodatabases also allow you to compress vector data to a read-only format to reduce storage requirements even further.


• File geodatabases have no storage size limit. Individual datasets within a file geodatabase, such as a feature class or table, do have a size limit of 1 terabyte (TB).


• The file geodatabase offers improved performance. For example, it can easily support individual datasets containing over 300 million features and datasets that can scale beyond 500 GB per file, while maintaining very fast performance.


• The file geodatabase offers less restrictive editing locks. Locking can be done per table instead of on the entire database.


• Lastly, the file geodatabase is supported by many platforms, including Windows and UNIX (Solaris and Linux).

One important thing to remember is that file geodatabases are stored as a directory on your hard drive, so you will need to zip the entire directory in order to transport it.

It is reccommended that you consider migrating or utilizing a File Geodatabase if you have ArcGIS 9.2 or later.

To download sample files, click on this link.