Digital Mapping Techniques '99 -- Workshop Proceedings
U.S. Geological Survey Open-File Report 99-386

Data Model for Single Geologic Maps: An Application of the National Geologic Map Data Model

U.S. Geological Survey
345 Middlefield Road, MS 975
Menlo Park, CA 94025
Telephone: (650) 329-4909
Fax: (650) 329-4936
E-mail: gautier@usgs.gov

INTRODUCTION

Within the Western Geologic Mapping Team, several funded projects have developed different approaches to digital geologic-map development. In our Las Vegas project, maps have been produced using a CAD program and then converted into Arc/Info format for release (for example, McKee and others, 1998). In the San Francisco Bay project, scientists ordinarily use ALACARTE (Fitzgibbon, 1991; Fitzgibbon, and Wentworth, 1991; Wentworth, and Fitzgibbon, 1991), a menu and standards system for Arc/Info developed ten years ago as one of the first successful systems for rendering geologic map information digital (used, for example, in Brabb and others, 1998). In southern California, the Southern California Areal Mapping Project has developed a more complex data model (Matti and others, 1997a,b,c) to produce numerous maps for publication and for fulfillment of various contracts (for example, Miller and others, 1998), while in the Pacific Northwest, geologic mappers hope for better weather and input their data in their own fashion.

If such variation exists within just one team, consider the diversity of approaches across the whole spectrum of producers and users of geologic maps. And yet the need for effective communication with customers and internal efficiency should be driving us towards common practice and standards. We have an urgent need to present a common face to the outside world and to be able to move data sets from one place or project to another. This paper describes my effort to move a group of creative and productive geologists towards agreement in the form of their digital products without interrupting the flow of work or denying needed flexibility in content and procedures.

GOING ENTIRELY DIGITAL

In implementing this digital-only policy, it soon became clear that, as is often said, the devil is in the details. The serious practical issues surrounding database design, content of layers, needed attributes and the codes to describe them, the role of relates and lookup tables, and a myriad of other details presented themselves to the geologists immediately. Work simply couldn't proceed without practical means of addressing these seemingly mundane issues. At the same time, demanding users expected, by turns, traditional printed materials, preliminary plots, Postscript and PDF files, or full-blown ARC coverages to be downloaded in their own computers, all with rapid delivery. The various projects, with their resourceful scientists, seemed to find almost innumerable ways to solve these problems and deliver the required materials. This creative diversity came, however, at the price of consistency, compatibility, and efficiency.

Fundamental to a digital geologic map is the organization of its spatial data into topical layers and database tables, as well as the encoding of its other parts (table 1). It became clear that we all needed to agree on a standard model for encoding the spatial data before we could proceed to address the other details. Within the team we had the data model inherent in ALACARTE (the ALC data model), the new and rapidly evolving SCAMP data model, as well as other developing and ad hoc data models not yet formally documented.

It was also clear that, regardless of any future migration to other applications, we now needed to work within the practical constraints of Arc/Info: the Geologic Division requires that map datasets be released in Arc/Info as well as SDTS format (GD Policy 6.1.3.2), Arc/Info has become virtually the lingua franca of geologic mapmakers, and ARC export format is the single most useful exchange format for our customers.

At the national level, the draft National Geologic Map data model (Johnson and others, 1998a, b) provides a structure for a national data library that is designed to accept data from, and track the differences between, many disparate geologic maps. Accommodating these differences leads to complexity that is not needed for individual geologic maps, and the model cannot be implemented in Arc/Info. It does, however, provide us with a useful framework to help guide our development of team standards for the release of new, medium- to large-scale maps produced within the context of a team mapping project.

We call this partial implementation of the NGM data model the Single Geologic Map (SGM) data model. By single we mean that the model addresses the encoding of individual geologic maps. The SGM data model must be able to encode all the information represented on each map in such a way that the digital version of the map (including both the spatial and attribute data) can be released as a self-contained USGS publication. Adjacent maps with compatible stratigraphies, line categorizations, etc., can be mosaicked to create a regional data library or the maps can be uploaded into the national database.

GOALS AND CONSENSUS

The SGM data model must have certain properties. It needs to address the encoding of the information found within a standard paper geologic map (table 1), and it needs to define an agreed-upon model within which the data can be stored and exchanged. The data model must be backward compatible to the extent that all our previous creative and labor-intensive development work is not wasted. It must be as simple as possible and it must be able to be implemented in Arc/Info.

In developing this model, it has been important to follow a process that could develop consensus among the map producers of the team. The model has to build upon the current state of knowledge and application, thus taking advantage of our existing experience and capability and avoiding the need for complete retooling. It has to draw in the existing practitioners by providing them clearly recognizable advantages, and it has to be able to accommodate new requirements while retaining maximum flexibility (future expansions of the model shouldn't break earlier datasets). Finally, we have had to create a model that is not too great a departure from the products with which our users are already familiar and able to use.

THE SINGLE GEOLOGIC MAP (SGM) DATA MODEL

Each of the two map layers consists of a spatial layer and its associated attribute tables (figure 1). Two types of spatial features are grouped in each layer: arcs (faults and contacts) and polygons (geologic units) in the UCF layer, and arcs (structural lines) and points (structural measurements) in the SD layer. This natural grouping facilitates queries and avoids the problems of duplicate storage. It can be implemented simply in Arc/Info and is routinely used in ArcView and other GIS packages. Each spatial layer also includes digital registration tics.

Figure 1. Single Geologic Map (SGM) Data Model.

Associated with each of these feature types are three database tables containing attributes. The first is the feature attribute table, which contains one record for each spatial feature (such as a fault). This table contains identification numbers for each feature, topology fields (if any), area, perimeter and(or) length as appropriate, a unique primary key field (ITEMID), and a single characteristic descriptive attribute (see below). The feature attribute table for polygons is termed a Polygon Attribute Table (PAT), for arcs an Arc Attribute Table (AAT), and for points a Point Attribute Table (PAT).

The second table is a definition table, also known as a lookup table or domain table. This table contains expanded definitions for each unique attribute in the corresponding feature attribute table. Therefore the relationship is many-to-one, the "many" being the set of records in the feature attribute table that share a common attribute (e.g. all polygons with ULABEL of Kgr), and the "one" being the single record in the definition table that describes that attribute (e.g., Cretaceous granite of Hidden Wells). Each definition table can contain additional items, including cartographic symbol assignments.

The third table is an ID Table, which can contain additional attributes, such as strike and dip for a structural measurement, for each individual spatial feature. The relationship is one-to-one with the corresponding feature attribute table. These attributes are placed in the ID Table rather than in the feature attribute table to keep that table as small as possible. This enhances the speed of many GIS operations, and makes the equivalent feature attribute tables of every map database identical in structure, which permits easy mosaicking. Any additional attributes are placed in the ID Table, whose structure can vary between adjacent maps as required.

The units, contacts and faults (UCF or geology) layer is required for all geologic maps, and contains arcs and polygons. Polygon and arc topology must be present. Arcs represent contacts and faults (as well as water boundaries and the map boundary); arcs that are not part of a polygon boundary (dangling arcs, e.g. some faults) are permitted. Arcs with polarity (e.g. low-angle faults) must be encoded with right-hand rule. The characteristic attribute in the UCF.AAT is LTYPE (for line-type, e.g. thrust fault or contact); the definition table, UCF.LN, adds the LDEF, the line-type definition. Polygons represent geologic units and consist of bounding arcs and a single label point internal to each closed polygon. The characteristic attribute in the UCF.PAT is ULABEL (for unit-label, e.g. Kgr, Qal). The definition table, UCF.UN adds UNAME, the formal or informal name of the map unit.

The structural data layer (SD) is optional and contains points and lines; no topology is present (no intersections where structural lines cross). Points represent structural measurements such as attitudes. The characteristic attribute in the SD.PAT is STYPE (for structure type, e.g. bedding or lineation). The definition table SD.ST adds SDEF, the full definition of each STYPE, and SMODE, the convention used to record orientations (e.g. strike and dip, trend and plunge). A separate table, the SD.SMDEF (for structure mode definition), defines each of these modes or conventions. The point ID Table (SD.PID) contains the structural measurements, AZIMUTH and INCLIN (inclination), for each point. Arcs in the structural data layer represent structural lines such as fold axes. The characteristic attribute in the SD.AAT is LTYPE (e.g. anticline). The SD.LN definition table adds LDEF, the definition of each unique LTYPE.

The relationship of the SGM data model to the National Geologic Map data model is straightforward. The spatial layers and their associated feature attribute tables correspond to the Spatial Object Archive in the NGM data model. The SGM Definition Table is a simplified subset of the tables in the NGM Compound Object Archive. The SGM ID Tables correspond to the tables in the NGM Singular Object Archive, with the difference that the SGM data model currently allows a single record in the ID Table for each spatial feature. In a later SGM version, we expect to provide for multiple records referring to single map elements in order to accommodate coincident features such as multiple observations at a locality.

CONCLUSIONS

We view the SGM model as a means to present a standard face to each other and our users, but also as a mechanism by which to draw our GIS practitioners together and to stimulate the joint development of tools and procedures of common value. We invite participation by others in this development process and welcome active participation in devising, testing, and adopting expansions to the model and to the tools and procedures with which to use it. The descriptions, code, proposed expansions, and discussions are available at our GIS web site http://geology.wr.usgs.gov/techniques/.

ACKNOWLEDGMENTS

REFERENCES

Wentworth, C.M., and Fitzgibbon, T.T., 1991, ALACARTE user manual (version 1.0): U.S. Geological Survey, Open-File Report 91-587B, http://wrgis.wr.usgs.gov/docs/software/software.html.

Return to Table of Contents This site is https://pubs.usgs.gov/openfile/of99-386/gautier.html Maintained by the Eastern Publications Group Web Team Last revised 11-2-99