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

By Donald L. Gautier

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


After more than ten years of application of digital systems to the compilation, editing, and publication of moderate to large-scale geologic maps, USGS geologists on the Western Geologic Mapping Team routinely produce, and many of our customers expect delivery of, both digital spatial databases and paper map plots instead of traditional printed maps. Efficiencies in publication are also urging us towards release in digital form. We are beginning to encounter problems, however, because of differences in geology, applications, customer expectations, and the lack of agreement on standards for large-scale geologic map data. The very energy and creativity of the digital geologic mappers themselves have led to a proliferation of approaches to the preparation and delivery of modern geologic maps.

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.


Two years ago, I began a campaign to expand digital work in the team to ensure that all newly released maps published by the Western Geologic Mapping Team were fully digital, including a graphics file (the cartographic map), a readme (first cousin to metadata), and a spatial database. Many team members were already working this way, but for some this required moving from digital graphics to GIS, and for others it required diving into the digital world for the first time.

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.

Table 1. Typical parts of a standard geologic map

Map graphic Spatial data, drawn in a projection in XY space
Description of map units DMU: map symbols and text descriptions of the units
Correlation of map units CMU: graphic depiction of the age relations of map units
Cross section(s) Spatial data, drawn along a vertical profile (in XYZ space)
Other illustrations  

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


The single geologic-map data model is being developed under three broadly defined objectives: (1) to continue to serve the needs of the map users, (2) to provide consistency and compatibility within the team, and (3) to be compatible with the single-map components available within the NGM data model.

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 SGM data model defines two fundamental geologic map layers: a units, contacts and faults (UCF or geology) layer, and a structural data (SD) layer. Other layers are permitted but not defined at this time. SGM uses the vector spatial data model, also known as the geo-relational or arc-node-topological model, in which points, lines and polygons (area boundaries) represent spatial features. Attributes are stored in relational database tables linked to the spatial features by common identification numbers. Standard vocabularies for attributes are not yet defined in the SGM model, but all attributes must be documented within the dataset's definition tables.

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

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.


The SGM data model has been developed specifically to address the practical problems encountered on a daily basis as we work to develop and deliver digital geologic maps. It is designed to serve our immediate needs for a common storage and exchange format and to be expanded as we develop consensus on how best to encode other parts of a geologic map. We expect this expansion to move the data model progressively toward the full NGM data model. The SGM model must be immediately practical, and as a first step in implementation we have prepared AML tools for use in Arc/Info to convert between the ALC and SGM models and to operate on the SGM definition tables in ALACARTE. Further tools, converters, and continuing support for the SGM data model will be developed and provided by the team as needed, with the ultimate goal of having tools with which to compile, edit, query, and publish directly in the SGM model.

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


I write from my vantage as team leader, but our progress toward digital consensus, and much of the detail herein, have depended on the constructive work of numerous participants, including David Bedford, Debra Block, Todd Fitzgibbon, Scott Graham, Russell Graymer, Ralph Haugerud, Steven Kennedy, Jon Matti, David Miller, Geoffrey Phelps, Carl Wentworth, and Karen Wheeler.


Brabb, E.E., Graymer, R.W., and Jones, D.L., 1998, Geology of the Palo Alto 30 X 60 minute quadrangle, California: a digital database: U.S. Geological Survey Open-File Report 98-348,

Fitzgibbon, T.T., 1991, ALACARTE installation and system manual (version 1.0): U.S. Geological Survey, Open-File Report 91-587B,

Fitzgibbon, T.T., and Wentworth, C.M., 1991, ALACARTE user interface - AML code and demonstration maps (version 1.0): U.S. Geological Survey, Open-File Report 91-587A,

Matti, J.C., Miller, F.K., Powell, R.E., Kennedy, S.A., Bunyapanasarn, T.P., Koukladas, Catherine, Hauser, R.M., and Cossette, P.M., 1997a, Geologic-point attributes for digital geologic-map data bases produced by the Southern California Areal Mapping Project (SCAMP) Version 1.0: U.S. Geological Survey, Open-File Report 97-859.

Matti, J.C., Miller, F.K., Powell, R.E., Kennedy, S.A., and Cossette, P.M., 1997b, Geologic-polygon attributes for digital geologic-map data bases produced by the Southern California Areal Mapping Project (SCAMP) Version 1.0: U.S. Geological Survey, Open-File Report 97-860.

Matti, J.C., Powell, R.E., Miller, F.K., Kennedy, S.A., Ruppert, K.R., Morton, G.L., and Cossette, P.M., 1997c, Geologic-line attributes for digital geologic-map data bases produced by the Southern California Areal Mapping Project (SCAMP) Version 1.0: U.S. Geological Survey, Open-File Report 97-861.

McKee, E.H, Wickham, T.A., and Wheeler, K.L., 1998, Evaluation of faults and their effect on ground-water flow southwest of Frenchman Flat, Nye and Clark Counties, Nevada: a digital database: U.S. Geological Survey Open-File Report 98-580,

Miller, F.K., Matti, J.C., Brown, H.J., and Powell, R.E., 1998, Digital geologic map of the Fawnskin 7.5' quadrangle, San Bernardino County, California: U.S. Geological Survey Open-File Report 98-579,

Johnson, Bruce R., Broderic, Boyan and Raines, Gary, 1998a, Digital Geologic Map Data Model (version 4.2): Unpublished American Association of State Geologists / U.S. Geological Survey draft document,

Johnson, Bruce R., Broderic, Boyan, Raines, Gary, Hastings, Jordan T., and Wahl, Ron, 1998b, Digital Geologic Map Data Model Addendum to Chapter 2 (version 4.3): Unpublished American Association of State Geologists / U.S. Geological Survey draft document,

Wentworth, C.M., and Fitzgibbon, T.T., 1991, ALACARTE user manual (version 1.0): U.S. Geological Survey, Open-File Report 91-587B,

Return to Table of Contents

This site is
Maintained by the Eastern Publications Group Web Team
Last revised 11-2-99