The GeMS database design is an outcome of years of research and collaboration by many scientists and GIS specialists, under the auspices of numerous projects and initiatives. The preparers of this document, Ralph A. Haugerud and David R. Soller (both USGS), especially thank Peter Lyttle (former Program Coordinator, National Cooperative Geologic Mapping Program) for his recommendation in 2008 that we undertake this work. We also thank our many colleagues who have given thoughtful comments and critiques of this design.
This report1 describes and defines GeMS, a new standardized database schema—that is, a database design—for the digital publication of geologic maps. It originally was intended for geologic mapping funded by the National Cooperative Geologic Mapping Program (NCGMP) of the U.S. Geological Survey (USGS), but its use can be extended to other programs and agencies as well. It is intended to bridge the gap between traditional geologic mapping and GIS communities at an operational level.
This schema was introduced at the Digital Mapping Techniques ’09 meeting (May 2009) for evaluation as version 0.8.2, in order to solicit preliminary comments and testing; at that time, it was named “NCGMP09” to reflect its target audience and the date of its initial release. Subsequently, version 1.0 was released October 14, 2009, for presentation at the Geological Society of America’s 2009 Annual Meeting. In the months that followed, more extensive evaluations were received, and the design evolved in response: version 1.12 was published at the end of 2011 as an article in USGS Open-File Report 2010–1335 (U.S. Geological Survey National Cooperative Geologic Mapping Program [USGS NCGMP], 2010). Several more years of experience, evaluation, and discussion have led to this current version3, renamed as “GeMS,” for Geologic Map Schema.4, 5
GeMS provides for the encoding in digital form of the content contained in geologic maps published by the USGS and by state geological surveys. It stipulates that an Esri database format be used, not only to adhere to USGS policy6 but also because Esri’s ArcGIS is the most commonly used GIS in the USGS, in state geological surveys, and in the larger geologic mapping community. Nevertheless, migration to a nonproprietary format is a worthy goal, and GeMS has been designed with this in mind.
Although GeMS is designed for a single-map database, it also is intended to provide a stepping stone toward the development of multiple-map databases, in particular the National Geologic Map Database (NGMDB). The Geologic Mapping Act of 1992, and its subsequent reauthorizations, mandate the creation of a national archive of standardized geologic map content. The NGMDB Project functions on behalf of the NCGMP as coordinator of database design and maintenance, in cooperation with the Association of American State Geologists. The database design contained herein will significantly promote that goal. All questions or comments about GeMS should be directed via email to gems@usgs.gov.
In our years of work prior to developing NCGMP09 and GeMS, we recognized that one single database design cannot suit all purposes, and this realization has been underscored by our colleagues’ evaluations of this design. In addition, we acknowledge that a database most suited to the needs of a field geologist likely will not address the content and cartographic requirements of a single-map database that would be published for use by geologists and nongeologists alike, nor will it meet the requirements of a multiple-map database that would be maintained in perpetuity by a mapping agency. We further recognize that, for any of these purposes, settling on one single database design may be contentious, in part owing to the varying requirements of other endeavors (for example, for field systems, for requirements imposed by local geology, or for particular hardware). Nevertheless, we have developed a design that ought to be generally useful for most implementations, while recognizing that many will not find it their first or best choice or that they may need to extend it to suit their purposes. Compromise in design, without sacrificing the flexibility necessary for science-driven data and information management, is the path we sought during development of the GeMS standard.
Geologic mappers, geologic mapping agencies, and geologic map users will all benefit from a standard database design for the digital representation of geologic maps. This document describes such a design for the representation of a single geologic map. The design is focused on the publication, transfer, and archiving of map data and less on the creation of map data, the visual representation of map data, or the compilation of data from many different map sources. With increased use of this design, we anticipate reductions in the cost of map preparation, production, and publication (including data compilation and synthesis, review, editing, cartography, prepress work, training, and tool development).
For the purposes of this design, a single-map database means a package of data (bearing in mind that many geologic map data are inherently interpretive) that pertains to a particular portrayal of the geology of a certain area (that is, the map extent), which is directly analogous to a traditional paper geologic map. The database is attributed to an author or authors who either have collected original data and developed the database and portrayal or have compiled data from existing sources and developed the portrayal.
We focus on the design of a single-map database for two reasons: (1) it is the issue that the geologic community understands best, and (2) it is the problem that we perceive is most in need of a solution. The construction and maintenance of an enterprise, multiple-map database raises several issues that we do not address here, including versioning, multiple-scale representations, vocabulary management, maintenance of the stratigraphic lexicon, and access control.
Geologic map producers have been developing and using GIS representations of geologic maps for more than three decades. In the course of this effort, we have all learned valuable lessons, some of which are listed below.
Map data are most usefully stored, shared, and analyzed in a GIS.—Although paper maps can be represented digitally by scanning them and storing the resulting image files, this is only a very small step towards making the map and its constituent data more easily accessible. Similarly, maps that are simply vector-graphic files (for example, those produced in desktop publishing software such as Adobe Illustrator) generally do not contain real-world, spatially explicit locations, nor do they explicitly state their thematic content and, thus, are not easily shared nor used for subsequent analysis. The most useful digital map data have feature attributes that are stored explicitly in database tables and feature locations that are provided in a real-world spatial reference framework (for example, UTM10, NAD83).
The distinction between map data and their symbolization is important.—Geologic map data primarily consist of feature attributes in database tables (for example, line #27 is an accurately located thrust fault; line #28 is an approximately located contact; line #29 is the shoreline of Lake Erie on August 27, 1978). Symbolization of these data via line symbols, point symbols, colored areas, and patterns results in a map portrayal on screen or on paper. Storing map data in a GIS—as opposed to its symbolization in a drawing program—facilitates machine-assisted analyses of the data, gives greater flexibility for alternate symbolization, and eases reuse of the data at different scales.
Maps in a GIS need to be accompanied by metadata for both the overall database and its individual features.—Early GIS practitioners, largely limited by both storage space and database architecture, created a substantial number of map databases in which key data fields were populated only by map-specific symbols that were not defined within the database (for example, a map unit was identified as “Ks” without specifying that “Ks” is shorthand for “Cretaceous sandstone”); however, this approach is inadequate to effectively communicate the geology of an area. Mappers and map users benefit from feature-level metadata that describe both data source and quality. Reasons for such metadata include (1) most geologic maps contain data from mixed sources and of variable quality, (2) map data need to be closely linked to their authorship because such data mostly are interpretations made by authors, and (3) mapping commonly requires significant support from a governmental agency, an academic institution, a professional society, or private industry, and such support needs to be recognized.
Real-world database designs reflect compromises between the intrinsic complexity of geologic map data, the needs of geologists and GIS practitioners who work with the design, the capabilities of GIS and database software, and the limitations of the underlying computer systems.—Database designs that do not make such compromises are not likely to be widely used. Even the names of various database elements (spatial featuresets, tables, and fields) must be carefully crafted to be understood by users who have different backgrounds, to facilitate the adaptation and reuse of software tools, and to promote the distribution, translation, and compilation of data.
Obtaining widespread community acceptance for a particular database schema and its associated vocabularies, which may extend beyond the precedents set by traditional mapping methods, is difficult.—Although this conservatism may be a good thing because our mapping traditions embody a great deal of hard-won wisdom, it is also unfortunate because these traditions incorporate prior compromises, necessitated by the limitations of nondigital formats, that are unnecessary in a digital world.
And finally, a perception persists among some geologists that the comprehension of their maps may be beyond the capabilities of the uninitiated and that, therefore, these maps cannot—and should not—be expected to be readily useable by members of the public.—This is unfortunate because it is the public who needs the maps (and who have paid for them). As noted by then–USGS Director John Wesley Powell, “maps [need to be] designed not so much for the specialist as for the people, who justly look to the official geologist for a classification, nomenclature, and system of convention so simple and expressive as to render his work immediately [understandable]” (Powell, 1888).
We have endeavored to honor these lessons when designing the GeMS database schema, and we hope that the schema will contribute to a better understanding, and the wider use, of geologic map data.
Within GeMS, we have attempted to do the following:
U.S. Geological Survey National Cooperative Geologic Mapping Program, 2020, GeMS (Geologic Map Schema)—A standard format for the digital publication of geologic maps: U.S. Geological Survey Techniques and Methods, book 11, chap. B10, 74 p., https://doi.org/10.3133/tm11B10.