The Seamless Integrated Geologic Mapping (SIGMa) Extension to the Geologic Map Schema (GeMS)

Scientific Investigations Report 2022-5115
By: , and 

Links

Acknowledgments

The authors would like to thank Ralph Haugerud, Evan Thoms, and Andrew Cyr of the U.S. Geological Survey (USGS) for helpful reviews and comments that improved the design of this extension and the quality of this document. We benefited from discussions and review of an earlier version of the extension and this document by these reviewers and Dave Soller (USGS). Discussions with Sky Bristol (USGS) were helpful in developing the feature-level contributor and versioning attributes. This work was funded by USGS’ National Cooperative Geologic Mapping Program.

Abstract

Geologic maps are the fundamental building blocks of surface and subsurface three-dimensional geologic framework models of the Earth’s crust. However, as the production and availability of geologic map databases continues to increase, inconsistent data models and the lack of synthesized, national geologic map data at scales appropriate for informed decision making negatively affect the functional integration of geologic map data with other national datasets. The Geologic Map Schema (GeMS) is the publication and archive database standard for geologic map data funded by the U.S. Geological Survey National Cooperative Geologic Mapping Program, and standardizes the organization and content of a single map database. However, synthesizing multiple databases into a seamless geologic map database creates a different set of challenges and database needs than GeMS was designed to accommodate. The Seamless Integrated Geologic Mapping (SIGMa) extension is designed to expand the capabilities of GeMS by enabling integration of map-based geoscience data. In particular, the SIGMa extension enables capturing a diverse and ever-changing set of map units, produced by many contributors operating independently, and by incremental and noncontiguous assembly and publication. Feature-level metadata fields allow data sources and digital compilation methods to be attributed separately and a relational structure is designed to support the link between data sources and features attributed with multiple data sources. Instead of paragraph-style map-unit descriptions that can be highly inconsistent, SIGMa parses fundamental map-unit attributes, including material, genetic process, and age, into thematically specific fields. The SIGMa extension uses a hierarchical map-unit organization to facilitate a dynamic and evolving, formation-level stratigraphic framework. The hierarchy is developed around geologic provinces that represent temporally restricted geologic events, processes, and settings. Geologic provinces can include magmatic events, depositional settings associated with tectonic processes or stable continental margins, and processes that are actively shaping the modern landscape. A geologic province hierarchy places map units into a geologic context at subregional to continental scales and provides the flexibility to support incremental assembly of the stratigraphy.

Introduction

Geologic maps are a combination of descriptive and interpreted geospatial data that document the distribution of lithologic deposits, geologic structures (including active faults and fault zones), areas of hydrothermal alteration and secondary mineralization, and anthropogenic ground disturbance. Geologic maps, integrated with topographic base materials, depict three-dimensional relations on the Earth’s surface. Using field and remotely sensed orientation data for map units and structures, mapped surface features can be projected to shallow and moderate crustal depths. As such, geologic maps are the fundamental building blocks of surface and subsurface three-dimensional geologic framework models of the Earth’s crust. Framework models are essential to our understanding of geologic processes responsible for distribution of hydrocarbons, mineral deposits, groundwater aquifers, landslides, and faults. More emphasis is now placed on the availability of the underlying databases of geospatial data for use in geographic information systems (GIS) than a static geologic map representation (paper or digital file), although the traditional cartographic representation of a geologic map is, and will continue to be, an important medium for the release of geologic mapping. Predictive modeling of geologic processes applied to resource management, land use, and environmental decisions of high-societal impact benefit considerably from the availability of standardized representations of geologic map or geologic framework model databases.

The U.S. Geological Survey (USGS) Science Strategy for 2020–30 (USGS, 2021) sets a goal of predictive science capability, which is dependent upon integrating multidisciplinary and geospatial information. However, even as the production and availability of geologic map databases increase, the functional integration of geologic map data into larger, national data ecosystems is negatively affected by inconsistent data models and the lack of synthesized, national geologic map data at scales appropriate for informed decision making (National Research Council, 2012). Downstream use of geologic map data can require a great investment in time and resources because of inconsistences in map scale, thematic emphasis, database schema, and stratigraphic framework. The standardization of geologic map databases represents a significant step forward toward the functional integration of geologic map data and enhances the useability of these datasets consistent with Findable, Accessible, Interoperable, and Reusable, or FAIR, data principles (Wilkinson and others, 2016).

The Geologic Map Schema (GeMS) is the publication and archive database standard for geologic map data funded by the USGS National Cooperative Geologic Mapping Program (NCGMP). Details on GeMS can be found in NCGMP (2020). A primary objective of GeMS is encoding of geologic data consistent with a single map. Even though a consistent data structure is achieved through implementation of GeMS, a single-map database is typically only internally consistent and not inherently integrated with surrounding geologic mapping. The NCGMP has recently established the goal of developing a two- and three-dimensional geologic framework model for the Nation (Brock and others, 2021). Integrated national geologic mapping facilitates a wide range of analytical applications from basin (subregional) to continental scales, but successful integration requires the many geologic map sources to contribute to a coherent geologic framework. Although the national geologic map database is ultimately a single-map database, assembling and publishing a national database incrementally will be significantly more complex than is typical for a single-map database that has a fixed extent.

Merging multiple internally consistent databases into a seamless geologic map database creates a different set of challenges and database needs than GeMS was designed to accommodate (NCGMP, 2020). Seamless databases are characterized by map-unit polygon boundaries defined by geologic features only, with no overlaps, gaps, or arbitrary boundaries such as administrative or topographic quadrangle map boundaries (commonly known as seams). Stratigraphically, map units in a seamless map database participate in a single stratigraphic framework and properties are consistently characterized. The Seamless Integrated Geologic Mapping (SIGMa) extension to GeMS is designed to expand the capabilities of GeMS by enabling integration of map-based geoscience data. In particular, the SIGMa extension enables capturing a diverse and ever-changing set of units, produced by many contributors operating independently and by incremental and noncontiguous assembly and publication. The SIGMa extension builds on feature-level and table-record-level metadata capabilities of GeMS, parses map-unit attributes into thematically specific and readily searchable fields, and uses a hierarchical map-unit organizational structure to facilitate a dynamic and evolving stratigraphic framework necessary to incorporate less traditional geologic mapping workflows.

The Intermountain West (IMW) project was launched in 2018 with the intent of developing the workflows and evaluating the database requirements necessary to produce seamless and stratigraphically integrated geologic map databases in a series of east-west transects across the geologically diverse western United States. Within the initial transect is a mosaic of more than 1,000 geologic maps that typically range in scale from 1:24,000 to 1:500,000. Most maps in the IMW project’s initial area of interest are in the form of georegistered raster data because relatively few vector-based geologic map databases are available. Synthesizing these map data sources into a seamless database requires new geologic interpretations during compilation that are based on field observations, mapping from remotely sensed base-map data, and published updates to stratigraphic or structural models. Some areas of limited spatial extent, by contrast, may require less interpretive compilation methods because map data sources are available as databases, making digital assembly and organization of modern map data possible (for example, Colman-Sadd and others 1996, 1997; Wells and others, 2020). With the SIGMa extension we aim to create a platform that can accommodate a continuum between the endmember compilation methods (digital assembly versus new interpretive compilation), with a possible skew towards interpretive compilation. A more traditional, interpretive approach is likely the most efficient approach where geologic maps are not digital databases, are not at appropriate scales, or are out of date. In the following sections, we describe the challenges encountered during construction of a seamless geologic map database and how the SIGMa extension to GeMS addresses these challenges.

Challenges of an Evolving, Integrated Geologic Map Database

A traditional approach to producing a geologic map is focused on a map area of fixed extent. Mapping is conducted by one or more geologists, including a lead geologist who integrates maps from all the contributors and ensures consistency in descriptive attributes and the cartographic representation of map features prior to publication. Subsequent mapping of new areas is published as separate geologic maps. Although the geologic content and interpretations may be applicable across many maps, in general, each map is internally consistent and can be used largely independent of other maps. The process of mapping and publication is usually a single cycle for each map.

Brock and others (2021) called for the NCGMP to collaboratively develop and regularly update a seamless geologic map of the Nation. Producing and continually updating a seamless geologic map creates a suite of unique challenges related to integrating geologic interpretations and database functionality. Typical processes associated with integrating interpretations, technical review, and publication of geologic map data are well suited for a single geologic map, because, traditionally, geologic maps and geologic map databases are single, fixed-extent geologic maps. However, review and publication of updates and development of an internally consistent geologic model in a continuously updated and seamless geologic map database is a more recent and complex challenge requiring a high degree of cooperation and coordination between many possible contributors. It is not the intent of this document to explore the intricacies of developing a consistent geologic model; rather, we intend to address database functionality. The process of compiling a continuously growing, regional-scale, and seamless geologic map database has given the IMW project insight that shaped the development of the SIGMa extension to GeMS. The design of this extension addresses three principal challenges related to the map-integration process: (1) a growing stratigraphic framework; (2) attribution of map-unit properties; and (3) managing data source metadata at the feature level.

A Growing, Formation-Level Stratigraphic Framework

The stratigraphic framework of a geologic map defines the map units and their spatial (areal) and temporal (stacking, crosscutting, or inset) relations. A traditional geologic mapping workflow involves building this framework during the mapping process, on the basis of new observations and published source information within the map area and surrounding region. The preliminary stratigraphic framework developed at the start of a mapping project is continuously assessed and updated until the map is finalized and published. Upon publication, the framework becomes a unique product of that specific geologic map.

Small-scale geologic maps (which have large extents; for example, scales from 1:500,000 to 1:5,000,000) generally use a specialized but simplified stratigraphic framework that largely abandons formational stratigraphic detail (Reed and others, 2005). Fewer map units are used through systematic lumping of multiple formations across both temporal and spatial dimensions. As a result, the map contains less stratigraphic detail and shows less geologic complexity. Additionally, the criteria by which map units are lumped on individual geologic maps can vary substantially. These factors can dramatically limit the utility of small-scale maps that have a simplified stratigraphy for local to regional natural resource management, geologic hazard assessment, and scientific investigations.

A geologic formation is a fundamental, mappable stratigraphic unit consisting of a body of rock that has characteristic lithologic, genetic, or other measurable or observable features (Neuendorf and others, 2011). Although formations can be combined into groups or subdivided into members, formation-level classification of map units is fundamental to the stratigraphic framework of most geologic maps. To maintain the detail and utility of map data within seamless, integrated compilations, formation-level classification of stratigraphy cannot be discarded even as map areas grow to State or national scales. However, the stratigraphic framework can be in a constant state of flux owing to changing project boundaries, mapping updates, geologic timescale revisions, or new mapping contributions, all of which pose a significant challenge. A flexible approach to map-unit organization should convey relative stratigraphic relations and must accommodate a frequently changing, formation-level stratigraphic framework resulting from incremental assembly and periodic updates.

Standardizing Map-Unit Attribution

Map-unit descriptions often follow a paragraph-style format, which can be highly informative, communicating the author’s interpretations and observations on a geologic map. Paragraph-style descriptions can vary significantly from map to map, even for the same package of rocks. For example, the descriptions in table 1 are for the same map unit from two overlapping maps at the same map scale (1:100,000). Weir and others (1989) were significantly more detailed than DeWitt and others (2008) in describing the physical characteristics of the basaltic rocks; however, DeWitt and others (2008) presented compositional information, which is not part of the descriptions from Weir and others (1989). The variability in detail and content can result from the purpose of the mapping, time constraints, expertise of project geologists, and map area extent. Map-unit descriptions typically characterize the unit properties within a specific map area, which may not capture the full range of properties for a regionally distributed unit.

Table 1.    

Examples of variations in unit descriptions from Weir and others (1989) and DeWitt and others (2008).

[Map-unit descriptions taken from Weir and others (1989) and DeWitt and others (2008). mm, millimeter; cm, centimeter; m, meter; ft, foot; Ma, mega-annum; K, potassium; Na, sodium; Mg, magnesium; Fe, iron]

Geologic map reference Map-unit name Map-unit description
Weir and others (1989) Basaltic volcanic rocks, undifferentiated Mainly medium gray to dark gray, weathering dark grayish brown, aphanitic to coarse grained, commonly porphyritic; locally vesicular; outcrop yields irregular blocks. Groundmass is generally micrograined to very fine grained, composed of acicular plagioclase, clinopyroxene, olivine, and opaque oxides. Olivine phenocrysts average 1-2 mm in diameter in finer grained rock and 3-4 mm in coarser grained rock and are as much as 4 cm across; clinopyroxene phenocrysts average 1-2 mm and are as much as 1 cm across; plagioclase phenocrysts average 1-2 mm and are as much as 1 cm across; less common quartz xenocrysts average 1-2 mm and are as much as 8 mm across. Mafic and ultramafic xenoliths occur in several cinder cones and their associated lava flows; mafic xenoliths are gabbroic and are as much as 5 cm in diameter; ultramafic xenoliths are olivine pyroxenite and dunite and are as much as 8 cm in diameter.
The basaltic rocks are commonly vesicular and in flow units 6-12 m (20-40 ft) thick; also include basaltic tuffs, dikes, cinder cones, and vent deposits too small to show separately. Map unit includes sparse thin but conspicuous, light-colored silicic ash deposits (mainly dacite) and some andesite in thin flows and small intrusions.
For the most part, the volcanic rocks unconformably overlie the Permian Kaibab Formation (Pk); in the eastern part of the quadrangle they overlie the truncated Triassic Moenkopi Formation ( ^m); locally, as on Blue Ridge in the southeastern part of the quadrangle, they overlie Tertiary sedimentary rocks; a few flows are intercalated in the Verde Formation (Tv).
Basaltic rocks on and near Casner Mountain in the northwestern part of the quadrangle and in the Black Hills in the southwestern part of the quadrangle have been assigned to the Hickey Formation of Miocene age (Levings, 1980; Wolfe, 1983). Isotopically dated basalt flows in the quadrangle range in age from 15.4 to 5.5 Ma (Peirce and others, 1979, p. 7-9: McKee and Anderson. 1971. p. 2770).
Thickness of volcanic rocks differs markedly from place to place because of original variations in deposition and subsequent erosion. Aggregate flows commonly range from about 15 to 90 m (50-300 ft) in thickness on uplands but generally thicken to more than 300 m (1,000 ft) along the margin of Verde Valley
DeWitt and others (2008) Basalt Basalt flows, cinder cones, and minor dikes. Includes all compositions of basalt not proven to be alkali basalt. As such, percentage of outcrop defined as basalt, versus alkali basalt, is probably overestimated.
Basalt in lower part of Thirteenmile volcanic rocks has an average K/Na ratio and is very Mg rich to Mg rich.
Undated flows west of Kirkland and west of Martin Mountain range in composition from basalt to andesitic basalt, are sodic to average in K/Na ratio, and are very Mg rich to very Fe rich.
Basal part of Thirteenmile volcanic rocks may include some basalt that is equivalent to that in Hickey Formation
Table 1.    Examples of variations in unit descriptions from Weir and others (1989) and DeWitt and others (2008).

The useability of a geologic map database is improved when map units are attributed consistently so that users know what attributes to expect and where the attributes are located; the variable nature of paragraph-style descriptions is inconsistent with these expectations. A standardized, structured, paragraph-style description presents data in a predictable way to an end user and can improve consistency in attribution, but many data types are still combined within a single field. Parsing data from a paragraph description into thematically specific fields greatly simplifies the review and query processes. Furthermore, construction and maintenance of paragraph-style map-unit descriptions in a continuously growing geologic map database constructed by a large, decentralized workforce would be challenging over the life of a long-lived project.

A schema can impose a standard approach toward the types of information that describe features and map units while also giving data compilers the flexibility to accurately capture geologic information. For example, in a GeMS database, multiple line attributes are parsed into specific fields that include Type, LocationConfidenceMeters, IdentityConfidence, and ExistenceConfidence (NCGMP, 2020). Map units can be approached similarly. Wilson and others (2015) and Horton and others (2017) incorporated fields to describe map units that specify lithology, age, and genetic information. Although some flexibility and nuance allowed by narrative descriptions is lost, implementation of thematically specific fields expedites and standardizes unit attribution and simplifies database queries.

Recording Data Sources

Within the scope of a single static published map, the number of data sources is limited, and feature-level documentation of sources can be relatively straightforward. However, the number of sources and complexity of referencing will grow in a continually updated geologic map database, both to fill in gaps where no previous mapping exists and to update existing databases with new observations and information. A record of how information from original sources is synthesized into new interpretations is also important metadata. In some cases, geologic features in the database require little to no modification from the original mapping, whereas areas that have outdated or no mapping require new geologic mapping or significant reinterpretation. These methods of compilation can include scale-appropriate simplification (for example, combining units), spatial adjustments (for example, adjusting contacts to match the topographic expression of map units seen in modern topographic datasets), or reinterpretation of the geology if the mapping is outdated with respect to modern geologic concepts (for example, reassigning polygons to modern stratigraphic units). These data-collection processes and decisions can be documented at the feature level to record how sources of information were used during mapping.

Core Concepts of SIGMa

The SIGMa extension expands the capabilities of a GeMS database to facilitate the process of generating, publishing, and updating a seamless, integrated geologic map database. The SIGMa extension is dependent upon the schema and relationships described by GeMS and, therefore, this document and the GeMS document (NCGMP, 2020) should be used together. For example, feature-class topology rules and all fields are inherited from GeMS and are not restated here in their entirety (NCGMP, 2020). Names of tables, feature classes, and fields described as part of the SIGMa extension are intended to follow naming conventions described by GeMS (fig. 1). Aspects of the SIGMa extension are relational, but the design does not adhere to database-normalization principles. This approach is partly due to inheritance from GeMS (NCGMP, 2020), but it is also done to improve the human-readable aspects of the database, which, in our view, results in greater accessibility and comprehension by a larger portion of the geologic and GIS community. The SIGMa structure expands upon concepts from GeMS (such as feature-level metadata), incorporates parsed map-unit attributes into thematically specific fields, and creates an organizational structure for map units that allows expandability of the database stratigraphic framework.

Entity-relationship diagram for selected features and tables with full implementation
                        of the SIGMa extension. Relationships that join map-unit features and attributes are
                        shown with a connecting line. Primary- and foreign-key fields that support other feature
                        classes are indicated by colored backgrounds. Field names that are standard to the
                        Geologic Map Schema, or GeMS (National Cooperative Geologic Mapping Program, 2020) are shown in
                        regular type; Seamless Integrated Geologic Mapping (SIGMa) extension fields are shown
                        in bold type. Asterisk (*) next to the MapUnit field in the ContactsAndFaults feature
                        class indicates that field is not included in this feature class in a standard GeMS
                        database but is included as part of the SIGMa extension.
Figure 1.

Entity-relationship diagram for selected features and tables with full implementation of the SIGMa extension. Relationships that join map-unit features and attributes are shown with a connecting line. Primary- and foreign-key fields that support other feature classes are indicated by colored backgrounds. Field names that are standard to the Geologic Map Schema, or GeMS (National Cooperative Geologic Mapping Program, 2020) are shown in regular type; Seamless Integrated Geologic Mapping (SIGMa) extension fields are shown in bold type. Asterisk (*) next to the MapUnit field in the ContactsAndFaults feature class indicates that field is not included in this feature class in a standard GeMS database but is included as part of the SIGMa extension.

An important distinction needs to be made between a database, or compilation, map unit and an original-source map unit, as both are referred to frequently in the following discussion. A database map unit represents one record in the DescriptionOfMapUnits table and is part of the stratigraphic framework applicable to the entire database. An original-source map unit is represented on a previously published geologic map and may or may not directly relate to the database stratigraphic framework. For example, if source maps are detailed, multiple original-source map units may be combined to form a single, undivided database map unit. The database map unit may also resolve variations in nomenclature from multiple original-source map units.

Feature-Level and Table-Record-Level Metadata

The SIGMa extension expands upon concepts of feature- and table-record-level metadata used by GeMS (NCGMP, 2020). Feature- or table-record-level metadata fields as defined by GeMS include quantitative spatial and measurement confidence (LocationConfidenceMeters, OrientationConfidenceDegrees), qualitative scientific confidence (ExistenceConfidence, IdentityConfidence), and data-source tracking (DataSourceID, DescriptionSourceID, among others) (NCGMP, 2020). The SIGMa extension augments the data-source tracking established by GeMS through an alternative relational structure and the addition of a new feature-level compilation method attribute. Local map-unit identifiers (original-source map units) are included at the feature level for feature classes that have map-unit information. New approaches to recording contributors and database versioning are also recorded in new feature-level attributes and tables.

Data Sources and Methods

A regional geologic map database can use hundreds or thousands of data sources. Complementing the data source is a record of how original-source information is incorporated into the database, referred to hereafter as a compilation method. Examples of compilation methods may include original mapping and previously published mapping, with minor spatial adjustment or significant reinterpretation. In a GeMS database, two important types of information (sources of data and compilation methods) can be combined in the DataSources nonspatial table, and each record is associated with a primary key1 in the DataSources_ID field (NCGMP, 2020). Foreign-key2 field names in other feature classes or tables include the suffix “SourceID” (for example, data-source foreign-key fields include DataSourceID and DescriptionSourceID, among others; hereafter, these fields are collectively referred to as “xxxSourceID” fields). Unique records in the DataSources nonspatial table can rapidly increase in number because of the various combinations of feature-level data sources and compilation methods and may result in repetition of information (table 2). Concatenating key values of unique records in the xxxSourceID fields would limit the number of unique DataSources records; however, this multiattribute approach disrupts the functionality of the relationship in a GeMS database and requires users to locate sources in the DataSources table.

2

A foreign key is a key used to link two tables together in a relational database. It is a field (or collection of fields) in one table that refers to the primary key in another table.

1

A primary key is a unique identifier for each record in a table within a relational database. It may be used to join (or relate) two tables. A table can have only one primary key, and the key field should not contain null values.

Table 2.    

Example of a DataSources nonspatial table, showing how data sources and compilation methods could be depicted in a GeMS database.

[GeMS, Geologic Map Schema; I, U.S. Geological Survey (USGS) Miscellaneous Investigations Map; SIM, USGS Scientific Investigations Map]

DataSources (nonspatial table)
Source Notes DataSources_ID
This report Field mapping conducted by A. Smith and J. Doe 2019–21 DAS1
SIM 2996 DeWitt, E., Langenheim, V., Force, E., Vance, R.K., Lindberg, P.A., and Driscoll, R.L., 2008, Geologic map of Prescott National Forest and the headwaters of the Verde River, Yavapai and Coconino Counties, Arizona: U.S. Geological Survey Scientific Investigations Map 2996, scale 1:100,000. DAS2
Modified from SIM 2996 Spatial adjustments to geologic features to fit modern topographic information or unit names are updated from DeWitt, E., Langenheim, V., Force, E., Vance, R.K., Lindberg, P.A., and Driscoll, R.L., 2008, Geologic map of Prescott National Forest and the headwaters of the Verde River, Yavapai and Coconino Counties, Arizona: U.S. Geological Survey Scientific Investigations Map 2996, scale 1:100,000. DAS3
I 1896 Weir, G.W., Ulrich, G.E., and Nealey, L.D., 1989, Geologic map of the Sedona 30’ x 60’ quadrangle, Yavapai and Coconino counties, Arizona: U.S. Geological Survey Miscellaneous Investigations Series Map I-1896, scale 1:100,000. DAS4
SIM 2996; I 1896 Geologic features based on mapping by DeWitt, E., Langenheim, V., Force, E., Vance, R.K., Lindberg, P.A., and Driscoll, R.L., 2008, Geologic map of Prescott National Forest and the headwaters of the Verde River, Yavapai and Coconino Counties, Arizona: U.S. Geological Survey Scientific Investigations Map 2996, scale 1:100,000; and Weir, G.W., Ulrich, G.E., and Nealey, L.D., 1989, Geologic map of the Sedona 30’ x 60’ quadrangle, Yavapai and Coconino counties, Arizona: U.S. Geological Survey Miscellaneous Investigations Series Map I-1896, scale 1:100,000. DAS5
This report; SIM 2996; I 1896 Map-unit description based on new observations; DeWitt, E., Langenheim, V., Force, E., Vance, R.K., Lindberg, P.A., and Driscoll, R.L., 2008, Geologic map of Prescott National Forest and the headwaters of the Verde River, Yavapai and Coconino Counties, Arizona: U.S. Geological Survey Scientific Investigations Map 2996, scale 1:100,000; and Weir, G.W., Ulrich, G.E., and Nealey, L.D., 1989, Geologic map of the Sedona 30’ x 60’ quadrangle, Yavapai and Coconino counties, Arizona: U.S. Geological Survey Miscellaneous Investigations Series Map I-1896, scale 1:100,000. DAS6
Table 2.    Example of a DataSources nonspatial table, showing how data sources and compilation methods could be depicted in a GeMS database.

The Digital Geologic Map Data Model (Johnson and others, 1999)—later referred to as the North American Geologic Map Data Model (NADM) version 4.3 (NADM Steering Committee Data Model Design Team, 2004)—divided bibliographic information into discrete fields to improve searchability. GeMS and SIGMa follow a similar approach toward capturing bibliographic information in the DataSources nonspatial table; however, SIGMa introduces a new table and feature-level field to document compilation methods. SIGMa also introduces an optional relational structure to augment the relationship between features and table records and the DataSources table. This approach minimizes the number of unique records, allows multiple source combinations in the xxxSourceID fields, and maintains a functional relationship between features and their source attribution.

Data Sources

The SIGMa extension limits the content of the DataSources table to information sources; one record in the table represents a single, unique information source. SIGMa extends the DataSources table defined by GeMS (NCGMP, 2020) so that elements of the data-source citation are parsed into separate fields (table 3). This approach is schematically similar to NADM version 4.3 (Johnson and others, 1999); however, field names and the content of fields included as part of the SIGMa extension are consistent with “Source Citation” data elements that are part of the Federal Geographic Data Committee (FGDC) metadata standard (FGDC, 1998). Parsing reference information serves multiple purposes:

  • Information is stored more consistently over the life of a longer lived project by eliminating inconsistencies in citation style.

  • By limiting the amount and types of information in each field, data-entry errors should be more easily detected.

  • As a result of the direct correlation between fields in the DataSources table and the FGDC metadata standard, scripting processes could be used to populate the “Source Citation” information in metadata for the published dataset (section 2.5.1.1; FGDC, 1998).

An optional field is recommended specifically for the product description URL from the National Geologic Map Database (NGMDB). The NGMDBProdURL field provides a resolvable link to this national registry for geologic maps in the United States and can facilitate integration of data resources in the future. The URL field is an optional field for a standard GeMS database (NCGMP, 2020) and is populated with a resolvable link to online data resources or a Digital Object Identifier (DOI; https://www.doi.org), for example. Although a direct link to the data source is useful, maintaining a dedicated link to the NGMDB is advantageous because of the spatial association with other geologic maps.

Table 3.    

Fields in the SIGMa extension and descriptions of their content in the DataSources nonspatial table.

[Fields included in GeMS (NGCMP, 2020) are omitted. SIGMa, Seamless Integrated Geologic Mapping; FGDC, Federal Geographic Data Committee; URL, uniform resource locator; DOI, Digital Object Identifier; GeMS, Geologic Map Schema; NCGMP, National Cooperative Geologic Mapping Program; NGMDB, National Geologic Map Database]

Field name (data type) Description
Originator (text) Author(s) or authoring agency or group. It is recommended to include “this report” to indicate new work. Multiple authors concatenated using a pipe character (|); for example, “Smith, P.D. | Doe, J.J. | John, G.G.” Such a delimited list would allow for scripted processes to populate unique “Originator” data elements in the “Source Citation” field (section 2.5.1.1, FGDC metadata standard; FGDC, 1998). Required field. Null values not permitted
PublicationDate (text) Year of publication or year website was accessed. Required field. Null values only permitted for new mapping
Title (text) Title of publication or web resource. If part of a larger edited volume, include editors and larger work title within the Title field. Required field. Null values permitted for new mapping
SeriesName (text) Name of the publication series. May include periodical name, book series, or website name. Required field. Null values permitted for new mapping and books not part of a series
IssueIdentification (text) Identifies the issue of the series publication. May include volume or number within a volume, for example. Required field. Null values permitted for new mapping, publications not part of a series, and books
PublicationPlace (text) The city and State (or country) where the data source was published. Generally used for books and academic theses or dissertation contributions. Required field. Null values permitted
Publisher (text) Name of publisher. Generally used for books and academic theses or dissertations. Required field. Null values permitted
SourceScaleDenominator (text) Scale of map if map data is part of data source. Multiple scales can be concatenated using the pipe (|) character, in cases where data sources include map data at multiple scales. Required field. Null values permitted for new mapping or sources without map data
OtherCitationDetails (text) Free-text field to include additional information identifying the data source; for example, pages within a periodical or number of plates. Required field. Null values permitted
NGMDBProdURL (text) URL to the NGMDB product description page. Field intended for geologic map data sources. Optional field, but use is highly encouraged. Field correlates with “Online Linkage” in the “Source Citation” (section 2.5.1.1, FGDC metadata standard; FGDC, 1998). Null values permitted
Table 3.    Fields in the SIGMa extension and descriptions of their content in the DataSources nonspatial table.

SIGMa introduces a new structure to support a functional relationship between features or table records and the DataSources nonspatial table when multiple data sources are required. Individual many-to-many relationships between a feature class (or table) and the DataSources table could be used to relate multiple data sources, but in our experience, application of multiple many-to-many relationships in the ArcGIS environment can be complex and confusing. Our goal is to minimize the number of many-to-many relationships in the database. The SIGMa relational structure incorporates a single many-to-many relationship between the DataSources and the DataSourcesList nonspatial tables (fig. 2). The DataSourcesList table is populated with an aggregate of all unique combinations of data sources in all database xxxSourceID fields. Key values in the DataSourcesList table can include individual source keys and composite keys that consist of concatenated lists of data source key values. For example, in the ContactsAndFaults feature class in figure 3, the foreign-key value DAS3 is used as a single value and as part of two composite key values. Key values that are repeated in multiple feature classes are not repeated in the DataSourcesList table, as is seen in figure 3. The composite key of “DAS1 | DAS2 | DAS3” is used in both GeologicLines and ContactsAndFaults but is used only once in the DataSourcesList table. The DataSourcesList table is a summary of all unique combinations of source foreign-key values (keys and composite keys) used throughout the database; multiple one-to-many relationships are maintained between feature classes (and tables) and the DataSourcesList table based on the xxxSourceID fields.

Relational structure between feature classes and tables and the DataSourcesList and
                                 DataSources nonspatial tables. Dashed line indicates relationship between feature
                                 classes or tables and the DataSources table in a Geologic Map Schema (GeMS) database. Solid lines indicate relationships using the Seamless Integrated
                                 Geologic Mapping (SIGMa) extension. One-to-many relationships are symbolized with
                                 “1” (one) and “M” (many). Field names that are standard to GeMS (National Cooperative
                                 Geologic Mapping Program, 2020) are shown in regular type; SIGMa extension fields
                                 are shown in bold type.
Figure 2.

Relational structure between feature classes and tables and the DataSourcesList and DataSources nonspatial tables. Dashed line indicates relationship between feature classes or tables and the DataSources table in a Geologic Map Schema (GeMS) database. Solid lines indicate relationships using the Seamless Integrated Geologic Mapping (SIGMa) extension. One-to-many relationships are symbolized with “1” (one) and “M” (many). Field names that are standard to GeMS (National Cooperative Geologic Mapping Program, 2020) are shown in regular type; SIGMa extension fields are shown in bold type.

Example of features or table records that have multiple data sources related to the
                                 DataSources table. Multiple data source keys are concatenated using the pipe (|) character.
                                 One-to-many relationships are symbolized with “1” (one) and “M” (many). Green lines
                                 indicate table relationships.
Figure 3.

Example of features or table records that have multiple data sources related to the DataSources table. Multiple data source keys are concatenated using the pipe (|) character. One-to-many relationships are symbolized with “1” (one) and “M” (many). Green lines indicate table relationships.

The many-to-many relationship maintained between the DataSourcesList and DataSources tables resolves into two one-to-many relationships using the DataSources_DataSourcesList intermediate table (also referred to as a junction table or an attributed relationship table; fig. 2). In the junction table, unique composite key values in the DataSourcesList table are associated with each component data source (fig. 3).

The relational structure outlined here minimizes the number of many-to-many relationships and results in a relationship between features that have many data sources and the DataSources table that functions within the capabilities of many GIS applications. However, additional workflows are needed to build the DataSourcesList table and the DataSources_DataSourcesList attributed relationship table. These tables will require frequent updates with each addition of a newly mapped area or when subareas of map data are extracted for publication. Maintaining these tables through manual editing may be possible, although not desirable, for map data derived from limited sources; manual editing would be costly when applied to a map database derived from an extensive list of sources. By contrast, scripted processes are more efficient at generating tables, evaluating for proper key values, and ordering data sources.

Methods

Compilation methods are recorded in the Methods nonspatial table. The Methods table may contain as little as one or two records. If, for example, all features are based on new mapping, only a single record may be in the Methods table. A controlled list of methods is not established as part of the SIGMa extension. Rather, these methods should be defined by a given project. As a best practice, projects should consider developing a fixed list of methods at the beginning of a project. If new methods are added at a later stage of a project, method attributes in earlier work may need reevaluation to assess their validity. Table 4 lists fields in the Methods table, and table 5 lists some examples of methods that may be used during creation of a geologic map database. The Methods table is related to all other feature classes by the Methods_ID primary-key field and the MethodID foreign-key field.

Feature-level MethodID attribution informs the user about the detailed lineage of geologic information incorporated into the geologic map database, which can be nuanced. Even within small map areas, contacts and faults that define polygon boundaries can be a mix of features included from a data source that has no modification, features that have some modification to adjust to topography or new field observations, and features that represent completely new interpretations incorporating new structural models or stratigraphic understanding. The user is provided the information necessary to make an informed decision when evaluating geologic information in the database.

Recording the compilation method in the MethodID field separate from the data source may result in some ambiguity when multiple data sources are recorded for a feature. However, we suggest that this problem is less pervasive when considered in detail and that a single compilation method is appropriate in most cases, despite the possibility that multiple data sources might be identified. The shape and extent of map-unit polygons are defined by line features that can be split to isolate segments to a single compilation method and data source, with the caveat that the resulting pseudonodes3 between line segments that only differ in their DataSourceID field are acceptable to a project. Isolating parts of a polygon is not possible, however, because polygons cannot be split without the addition of internal line features, which is contrary to the goal of a seamless geologic map database. Projects may choose to assign a single, most appropriate method that applies to all data sources or to concatenate multiple values into the MethodID field. Concatenated values in the MethodID field could be accommodated by an explanation in the Notes field to correlate the relationships between the methods and the data sources.

3

A pseudonode is a pair of nodes, or endpoints, of connected arcs (line feature) that may unnecessarily separate line segments that share the same attributes.

Table 4.    

Fields in the SIGMa extension and descriptions of their content in the Methods nonspatial table.

[SIGMa, Seamless Integrated Geologic Mapping]

Field name (data type) Description
Method (text) Short, easily understood statement of method used during compilation. Required field. Null values not permitted
Notes (text) Free-text field for additional information describing the method. Optional field. Null values permitted
Methods_ID (text) Primary key. Example values may be “MET1,” “MET2,” but a format is not prescribed. Required field. Null values not permitted
Table 4.    Fields in the SIGMa extension and descriptions of their content in the Methods nonspatial table.

Table 5.    

Example of mapping and compilation methods that may be documented in the Methods nonspatial table.
Method Notes Methods_ID
Compiled from sources referenced in DataSourceID field. Features are modified from source map Feature is modified from source map by spatial adjustments or minor revisions to map-unit nomenclature MET1
Compiled unmodified from sources cited in the DataSourceID field Feature is imported from GIS datasets directly into the database with no modification MET2
New field mapping Feature is based on new field mapping MET3
Table 5.    Example of mapping and compilation methods that may be documented in the Methods nonspatial table.

Local Map-Unit Identifiers

Local map-unit identifiers such as names and labels may vary across a region or multiple map sources and may differ from the database map unit. This can result from differences in scale between the original map sources and the database compilation scale or from updated unit nomenclature. The stratigraphic framework assembled for large-scale maps (for example, 1:24,000 scale) is generally too detailed for use in its entirety on a smaller scale map (for example, 1:250,000 scale). Individual members of a formation may be mappable on a large-scale map, whereas a smaller scale map of the same area may necessitate combining the members and only mapping the formation. One approach to retaining information from original sources is to catalog all map units in a nonspatial table. Unit names, labels, and descriptive properties can be recorded in the table and a relationship would be established between the database feature class and the nonspatial table (for example, Wells and others, 2020). This approach retains the most information and establishes an active link within the database between features and source map-unit information. However, this method may require a large investment in time and personnel if tasked with cataloging potentially hundreds to thousands of maps in a State to multi-State map database.

SIGMa uses LocalStratName and OrigMapUnit fields to capture feature-level map-unit identifiers (table 6). Map-unit names used by original mapping sources that are inconsistent with the compilation map unit should populate the LocalStratName field. The LocalStratName and Name fields may be redundant in some cases when the original-source map unit and compilation map unit are the same. Although retaining the name in both fields may seem repetitive, the unit name in LocalStratName field should be retained because compilation map-unit names could change over the life of a long-lived mapping project.

Table 6.    

Feature-level fields in the SIGMa extension used to record local map-unit identifiers.

[SIGMa, Seamless Integrated Geologic Mapping]

Field name (data type) Description
LocalStratName (text) Map-unit name(s) used on source map. Field is reserved for recognized formal or informal unit names, not generic unit names referring only to lithology or other physical characteristics of the map unit. Multiple values can be concatenated using a character delimiter. Optional field. Null values permitted
OrigMapUnit (text) Plain-text, ASCII-character identifier for map-unit label(s) used on the source geologic map(s). Multiple values can be concatenated using a character delimiter. Field is heavily used in map compilations but may be of little use for new mapping. Optional field. Null values permitted
Table 6.    Feature-level fields in the SIGMa extension used to record local map-unit identifiers.

The OrigMapUnit field captures the plain-text, ASCII-character identifier that represents a map-unit label as used on original sources cited in the DataSourceID field. Values may be concatenated when a database map-unit feature combines multiple map units from a source map (see unit Ttf in table 7). The OrigMapUnit field functions as a passive link to original-source maps (passive meaning the user will need to refer to the data source referenced in the DataSourceID fields for original map-unit information). Source maps may use these OrigMapUnit labels in correlation charts, cross sections, and other figures beyond the map data itself. These labels help maintain a connection between the SIGMa data and these extended local source elements that the user may be accessing.

Table 7.    

Examples of attributes in the LocalStratName and OrigMapUnit fields.

[|, pipe character]

MapUnit LocalStratName OrigMapUnit DataSourceID
Ttf Tschicoma Formation Tt | Tt1 | Tt2 | Ttp DAS1 | DAS2
Ttf2 Tschicoma Formation [DAS1: Tt | Tt1] | [DAS2: Tt2 | Ttp] DAS1 | DAS2
Table 7.    Examples of attributes in the LocalStratName and OrigMapUnit fields.

The passive link to original source maps provided by the LocalStratName and OrigMapUnit fields does not offer the same direct access to original map-unit information that would be available if all source maps and unit information were catalogued in a nonspatial table. The goal of this passive link is to maintain transparency in the attribution of map-unit features. Inclusion of the local stratigraphic nomenclature and labels expands user query and analysis capabilities beyond the scope of the database stratigraphic framework, reaching further into the source stratigraphy. Users can search for altered or abandoned local stratigraphic names from the mapping sources and assess how they were incorporated into the current framework. We assume that most users of integrated databases will be primarily concerned with the database map units and that queries will be performed on map-unit attributes in the DescriptionOfMapUnits table. However, feature-level metadata that enhances interoperability with source stratigraphy is also useful. A limitation with this schema is that ambiguous internal cross references within a feature can result from concatenated lists in the DataSourceID, LocalStratName, and OrigMapUnit fields. For example, when original map-unit labels and local stratigraphic names are different between multiple map sources recorded in the DataSourceID field (see unit Ttf in table 7). Certain attribution formats can overcome this limitation as shown for unit Ttf2 in table 7.

Contributors

Individual authorship and institutional association are important attributes of a geologic map. Geologic maps that have multiple authors often combine subject matter experts to focus on specific areas of the map. A traditional graphic representation of a geologic map may include a few descriptive sentences or an index map to indicate individual contributions. Institutional associations are indicated as part of the author affiliations and publishing institution. A digital database is also associated with authorship, but data may be separated from the traditional list of authors once the database is downloaded or if data are ingested as web-based feature services. Feature- or table-record authorship ensures that authorship and institutional association are not decoupled from the map data.

GIS applications and relational database management systems generally include editor-tracking capabilities. These attributes may include the creating and editing user(s), as well as time stamps, for these actions. Application- or database-managed editor tracking is an efficient approach to managing feature or record contributors but does have several limitations, including the following:

  • In institutional settings, system usernames will populate creating- or editing-user attributes, and public release of usernames may violate institutional privacy guidelines.

  • Individual features or table records can represent a collaboration of multiple contributors, but application- or database-managed editor tracking is generally limited to a single user and doesn’t maintain an organizational affiliation.

  • Built-in editor tracking can be overwritten during some database operations or may be lost if transferring to a different application.

Using the SIGMa extension, individuals and organizations can be associated with features and table records by using the Contributors table (table 8) combined with foreign-key fields, including ContributorID (for individuals) and ContributorOrgID (for organizations) (table 9; fig. 4), which are added to feature classes and tables. This approach is useful for workflows that lack a traditional lead compiler role, which can exist in a multiuser GIS environment or when mapping is contributed by many individuals or groups. However, it does not unambiguously associate an individual with an organization for a feature when multiple values are concatenated within one or both foreign-key fields. Persistent registry identifiers in the Contributors table (for example, RegistryURL; table 8) resolve to information about individuals and their institutional affiliations.

Table 8.    

Fields in the SIGMa extension and descriptions of their content in the Contributors nonspatial table.

[SIGMa, Seamless Integrated Geologic Mapping; URL, uniform resource locator]

Field name (data type) Description
Name (text) Name of individual or organization. Required field. Null values not permitted
RegistryIdentifier (text) Registry identifier for the individual or organization. Required field. Null values permitted, but values are recommended
RegistryType (text) Indicates type of registry that identifier is associated with. Common registry types include Open Researcher and Contributor ID (ORCID; https://orcid.org) and Research Organization Registry (ROR; https://ror.org). Required field. Null values not permitted if value is included in RegistryIdentifier field
RegistryURL (text) URL to the registry page; for example, https://ror.org/035a68863 (U.S. Geological Survey Research Organization URL). Required field. Null values not permitted if value is included in RegistryIdentifier field
Contributors_ID (text) Primary key for the Contributors table. Required field. Null values not permitted
Table 8.    Fields in the SIGMa extension and descriptions of their content in the Contributors nonspatial table.

Table 9.    

Feature and table foreign-key fields in the SIGMa extension and descriptions of their content for contributor tracking.

[SIGMa, Seamless Integrated Geologic Mapping]

Field name (data type) Description
ContributorID (text) Identifies individual contributors to the map database. Foreign key to the Contributors table. Multiple values can be concatenated. Optional field. Null values permitted
ContributorOrgID (text) Identifies organizational contributors to the map database. Foreign key to the Contributors table. Multiple values can be concatenated. Optional field. Null values permitted
Table 9.    Feature and table foreign-key fields in the SIGMa extension and descriptions of their content for contributor tracking.
Example of contributor and database-version tracking using the Seamless Integrated
                              Geologic Mapping (SIGMa) extension. Note that in version 2.0 (right panel), a fault
                              was extended, and the lower right contacts of the light green polygons were moved.
                              Other line features are unmodified from version 1.0 (left panel).
Figure 4.

Example of contributor and database-version tracking using the Seamless Integrated Geologic Mapping (SIGMa) extension. Note that in version 2.0 (right panel), a fault was extended, and the lower right contacts of the light green polygons were moved. Other line features are unmodified from version 1.0 (left panel).

Database Version

Tracking versions and version changes as feature- and table-record-level metadata are important in a database that is assembled and published incrementally and frequently updated. Successive releases of a database may include the addition of new map areas, revisions to previously released areas of the map database, or both. Stratigraphic revisions (for example, additions, deletions, and revisions to ages or nomenclature) and feature-level changes can affect the results of analysis of a given map area as subsequent versions are released. Communication of this information to users is essential to support use and assembly of the database over time. To accommodate the release of map data as GIS-only files without an associated formatted cartographic product, maintaining release information within the database is essential. Therefore, database-version tracking is a required field in the SIGMa extension.

SIGMa employs a method for tracking database changes that uses the DatabaseReleaseVersions nonspatial table (table 10) and the DatabaseVersionID and LastUpdateVersionID foreign-key fields (table 11). The DatabaseVersionID field indicates the most current release version of the database and will be a globally calculated value for every feature and table record in the database (fig. 4). The LastUpdateVersionID field indicates the database version when the feature or record was last modified. Unmodified features or records released as part of earlier versions will have different values for DatabaseVersionID and LastUpdateVersionID fields (see upper contact in fig. 4). However, if an earlier released feature or record is modified, the LastUpdateVersionID will be updated to reflect the version in which the feature or record was modified (fig. 4).

Table 10.    

Fields in the SIGMa extension and descriptions of their content in the DatabaseReleaseVersions nonspatial table.

[URL, uniform resource locator; FGDC, Federal Geographic Data Committee]

Field name (data type) Description
VersionNumber (text) Version number of database release. Required field. Null values not permitted
ReleaseDescription (text) Description of changes to the database from previous version. May indicate new areas that were included in the database and may highlight areas of previously released mapping that have been changed. Required field. Null values not permitted
ReleaseDate (text) Version release date. Format should follow FGDC (1998) metadata convention for a calendar date: YYYY, for years; YYYYMM, for years and months (months expressed as an integer); YYYYMMDD, for years, months and day. Required field. Null values not permitted
ReviewDate (text) Date technical review of database was completed. Format should follow FGDC (1998) metadata convention for a calendar date: YYYY, for years; YYYYMM, for years and months (month expressed as an integer); YYYYMMDD, for years, months and day. Required field. Null values not permitted
ReviewerID (text) Identifies reviewer or reviewers that conducted the technical review of the database. May consist of individuals or agencies. Foreign key to the Contributors table. Required field. Null values permitted
VersionURL (text) URL where database can be downloaded. Required field. Null values permitted
DatabaseReleaseVersions_ID (text) Primary key for the DatabaseReleaseVersions table. Required field. Null values not permitted
Table 10.    Fields in the SIGMa extension and descriptions of their content in the DatabaseReleaseVersions nonspatial table.

Table 11.    

Feature and table foreign-key fields and descriptions of their content for database version tracking.
Field name (data type) Description
DatabaseVersionID Foreign key to the DatabaseReleaseVersions table. Foreign key in this field is applied to the entire database to reflect the most current release of the database. Required field. Null values not permitted
LastUpdateVersionID Foreign key to the DatabaseReleaseVersions table. Foreign key in this field refers to the database version in which feature or table record was last modified. Required field. Null values not permitted
Table 11.    Feature and table foreign-key fields and descriptions of their content for database version tracking.

Map Units

Management of map-unit information in a continuously growing geologic map database can be complex because of the number of map units, the potential for prolonged project timelines, transient and sometimes noncontiguous project boundaries, and different contributors mapping different areas, potentially at different times. Even though the tabular format of a database imposes some limitations, the organization of map units should be expandable and editable, and it must also represent and communicate relative stratigraphic information. A hierarchical organizational structure has the benefit of reflecting relative stratigraphic position information and allows for expansion and updating of the stratigraphic framework while minimizing the effects on the database. The potential for prolonged project timelines and a decentralized workforce can lead to inconsistent map-unit attribution over time or across multiple contributors and may require a significant cumulative time investment to rewrite paragraph-style descriptions. The use of thematically specific fields to record map-unit attributes ensures that essential information types are consistently recorded for all map units and is less time intensive to modify than paragraph-style descriptions. Other additions as part of the SIGMa extension are included to allow more flexibility in how map-unit features are represented while remaining compliant with GeMS (NCGMP, 2020).

Parsed Map-Unit Attributes

Map-unit information is commonly contained in a Description of Map Units (DMU)—an organized collection of formal or informal unit names that has paragraph-style descriptions of unit lithology, age, internal variations, lateral correlations, and other relevant properties across the map area. The amount and type of detail in a map-unit description is dependent upon available time and resources, author expertise, how much is known about a unit, and the purpose of the geologic map. Highly detailed map-unit descriptions are obviously desirable, and exceptional detail is possible given sufficient time and resources. Time is a limiting factor, however, in developing a national geologic framework model by 2030 (Brock and others, 2021). Existing map-unit descriptions from published geologic mapping are foundational to a national geologic synthesis. However, they are often inconsistent because they generally reflect the limited spatial extent of a single map area, and the variability in thematic emphasis of the geologic map and geologic expertise of the authors. Furthermore, inconsistency is introduced by the large and decentralized workforce required to accomplish intermediate-scale mapping across the Nation. Maintaining consistency in map-unit attributes throughout the life of a long-lived project is equally important. A more structured approach to attributing map units, rather than a traditional paragraph-style description, may balance the need for accelerated map compilation and consistent unit attribution with the amount of detail needed to facilitate a wide range of uses.

The SIGMa extension records a limited set of fundamental map unit attributes into thematically specific fields in the DescriptionOfMapUnits table that describe genesis, composition or lithology, and age (table 12). Parsing attributes into discrete fields reduces data entry to a list of values rather than a complex mix of attributes, structured sentences, formatting, and grammar. Modifying map-unit descriptive information to account for new variations in map-unit characteristics when map areas are added to the growing database only requires appending attributes rather than reconstructing descriptive sentences. Quality control is simplified because only single terms or lists of terms are evaluated in each field, rather than full sentences. Similarly, users can focus queries and symbolize features on the basis of fields of a single data type, rather than extracting information from a paragraph that has a mix of attribute types.

Table 12.    

Fields in the SIGMa extension and descriptions of their content in the DescriptionOfMapUnits nonspatial table.

[Fields are discussed in detail in text. Fields included in GeMS (NGCMP, 2020) are omitted. Description column uses ASCII characters to match database requirements. Ma, mega-annum (or million years ago); SIGMa, Seamless Integrated Geologic Mapping; GeMS, Geologic Map Schema; NCGMP, National Cooperative Geologic Mapping Program; K-Ar, potassium-argon; 40Ar-39Ar, argon-argon; U-Th-Pb, uranium-thorium-lead]

Field name (data type) Description
UnitCode (text) Easily readable, meaningful plain-text identifier (no special characters) for the map-unit label. Required field. Null values permitted for map units that do not correspond to mapped features. For example, a group that is only mapped as its constituent formations
DepositGeneral (text) General characterization of dominant rock lithology or predominant process-oriented type of surficial deposit. Users may choose to establish a controlled list relevant to their purposes, but none is prescribed here. Example values may include, but are not limited to, “igneous,” “sedimentary,” “metamorphic,” “igneous and sedimentary,” “igneous and metamorphic,” “alluvial,” “eolian,” and “mass wasting.” Concatenated lists not allowed. Required field. Null values not permitted
Material (text) Rock, materials, or composition of materials that compose the map unit. Character-delimited concatenated lists allowed. Required field. Null values permitted
GeneticType (text) The process, environment, or protolith associated with deposition or emplacement of the map unit. Can explicitly state a depositional environment or can be a term that has implied process or protolith. Character-delimited concatenated lists allowed. Required field. Null values permitted
AgeMin (text) Minimum age of the map unit. Can include chronostratigraphic (for example, Upper Cretaceous), geochronologic (for example, Late Cretaceous), or stage terms. It is recommended to include the TimeScale table (see table 14) to document the numeric age ranges of these terms. Concatenated lists not allowed. Required field. Null values not permitted
AgeMax (text) Maximum age of the map unit. Can include chronostratigraphic, geochronologic, or stage terms. It is recommended to include the TimeScale table (see table 14) to document the numeric ages of these terms. Concatenated lists not allowed. Required field. Null values not permitted
NumAgeSummary (text) Narrative summary of the age or age range of a map unit based on geochronologic analysis or other quantifiable means such as paleomagnetism or fossil assemblage. Mean age should be accompanied by age units, analytical error and standard deviation (sigma). For example, 29.241 +/- 0.055 Ma (2 sigma). Field should not be confused with NumericAge and associated fields in GeochronPoints as described by GeMS (NCGMP, 2020), which is used to represent analyses for single samples. Optional field. Null values permitted
NumAgeMethod (text) Analytical method(s) by which age(s) are determined. For example, K-Ar, 40Ar-39Ar, and detrital zircon U-Th-Pb. Character-delimited concatenated lists allowed. Optional field. Null values only permitted if NumAgeSummary field is null
NumAgeComment (text) Free-text field for additional information about the reported age. Could include information about the sample, material analyzed, or other qualifying information. Optional field. Null values permitted
NumAgeSourceID (text) Identifies the source of the age data referred to in NumAgeSummary. Foreign key to the DataSources_ID field in the DataSources table. Character-delimited concatenated lists allowed. Optional field. Null values only permitted if NumAgeSummary field is null
GeologicProvincesID (text) Primary key for geologic province table. Required field. Null values not permitted
Table 12.    Fields in the SIGMa extension and descriptions of their content in the DescriptionOfMapUnits nonspatial table.

Limiting map-unit attributes to a few fundamental properties standardizes the process of map-unit attribution when compared to paragraph-style descriptions, but it omits important details frequently included in a map-unit description. Attributes such as thickness, porosity, color, weathering profile, phenocryst or clast content, proportions of rock types that compose the map unit, and grain-size variations are important, but they can be challenging to characterize for regionally distributed units while remaining specific enough to be valuable. Recording a thickness of, for example, 0–350 meters (m) for a unit distributed across multiple States has limited utility on its own because any polygon of that unit can be as much as 350 m thick even though the maximum thickness may be restricted to a small area. Similarly, a published map-unit description indicating a map unit is, for example, 70 percent sandstone and 30 percent shale, may be locally accurate but may not properly characterize the variation seen in a regionally distributed map unit that may be 100 percent limestone in some areas. Feature-level attributes may be a better solution to capture locally applicable variations in map-unit characteristics.

Use of the SIGMa extension does not preclude incorporating a paragraph-style description in the Description field or adding to the list of fields in the DescriptionOfMapUnits table to better characterize units. Additionally, because of feature-level source information in the DataSourceID field (and other xxxSourceID fields), users can access the original, possibly more detailed information on original materials.

Processes and Materials

The DepositGeneral, GeneticType, and Material fields document map-unit genetic processes and compositions or lithologies. In combination, the DepositGeneral, GeneticType, and Material fields contain information that is similar to the GeoMaterial attribute in a GeMS database (NCGMP, 2020), but they allow more variations in map-unit attributes. The GeoMaterial property is a controlled list and, therefore, does not fully capture the more diverse range of attributes often associated with a map unit. The SIGMa fields are intended to capture a keyword, or multiple keywords, as opposed to a structured sentence or paragraph. Therefore, SIGMa fields can capture a range of attributes from published or new geologic mapping. SIGMa does not define controlled lists of terms for these fields, however establishing a controlled list may prove to be advantageous to a project.

The DepositGeneral field is a first-order characterization of the map unit. The field is intended to record a single value, rather than a concatenated list. Attributes may be as general as “igneous,” “sedimentary,” “metamorphic,” and “surficial.” Alternatively, first- and second-order subdivisions can be combined (table 13). The amount of information available for map units will determine the level of detail in the DepositGeneral values.

Table 13.    

Examples of first-order and combined first- and second-order values in the DepositGeneral field.
First-order values First- and second-order values combined
Igneous Igneous-extrusive; igneous-intrusive
Sedimentary Sedimentary-marine; sedimentary-terrestrial
Metamorphic Metamorphic-metasedimentary; metamorphic-metaigneous
Surficial Surficial-alluvial; surficial-glacial; surficial-eolian
Table 13.    Examples of first-order and combined first- and second-order values in the DepositGeneral field.

The Material field records terms that describe map-unit lithology or composition. Generally, values in the Material field are directly related to the attribute in the DepositGeneral field, but minor contributions to the unit, unrelated to DepositGeneral, can also be included. For example, a map unit that has a DepositGeneral value of “surficial-eolian” may include “sand and gravel” as a term in the Material field because “sand and gravel” may represent a minor constituent of the compilation map unit. Examples of Material terms may include “sand,” “pebbles,” “clay,” or “mixed sediment” for unconsolidated deposits; “rhyolite,” “basalt,” or “andesite” for igneous rocks; “sandstone,” “shale,” or “conglomerate” for sedimentary rocks; and “quartzite,” “schist,” or “amphibolite” for metamorphic rocks. The Material field can be a single value or a concatenated list of values. Ranking of terms in Material fields need not necessarily reflect ranked abundance because (1) the relative abundance of map-unit constituents is not indicated on many source maps and (2) the relative abundance of materials can vary across the lateral extent of a map unit. Feature-level attributes could be used to document these lateral variations.

The GeneticType field captures the processes or environments related to genesis of a map unit. GeneticType terms can either directly state or imply processes and environments. Examples for surficial units could include “floodplain,” “talus,” “loess,” or “colluvium”; igneous units could include “lava flow,” “ignimbrite,” or “intrusive”; and sedimentary units could include “shallow marine,” “shoreline,” or “sabkha.” Terms for metamorphic units may be less process oriented and could include metamorphic grade, such as “greenschist facies” or “granulite facies.” However, characterization of metamorphic grade is often inconsistent across multiple maps and may prove to be difficult to apply over large areas. Alternatively, a more detailed provenance could be recorded, such as “mafic metavolcanic,” “metapelite,” or “metaconglomerate,” for example. GeneticType terms are usually related to the DepositGeneral attribute, but minor contributions to the map unit, unrelated to DepositGeneral, can also be included. As with the Material field, multiple values can be concatenated, but ranking of GeneticType terms to reflect order of dominance may not be practical for map units that have a large extent.

Age

SIGMa includes multiple fields to expand on unit age information. AgeMin and AgeMax fields record time terms from the geologic time scale. Values could include chronostratigraphic (position; Upper or Lower Cretaceous) terms, geochronologic (time; Early or Late Cretaceous) terms, or stage names. Separating these attributes provides more flexibility in display and analysis in a GIS, even though it does create redundancy with the Age field defined by GeMS (NCGMP, 2020). Divisions of time that populate the Age, AgeMin, and AgeMax fields are subject to modification over time. For example, the International Commission on Stratigraphy has released updated versions of the International Chronostratigraphic Chart for nearly two decades at a frequency that ranges from every few years to as often as several times a year (https://stratigraphy.org/chart; accessed October 5, 2021). Assembly of a regional geologic map database can span many years and may be subject to numerous time-scale revisions. Therefore, the TimeScale table (table 14) is included as an optional table in the SIGMa extension to define the temporal framework of the database. The TimeScale nonspatial table is intended as a reference table, but a relationship with the AgeMin and AgeMax fields is possible.

Table 14.    

Fields in the SIGMa extension and descriptions of their content in the TimeScale nonspatial table.

[Ma, mega-annum; ka, kilo-annum]

Field name (data type) Description
Name (text) Name of the chronostratigraphic or geochronologic age unit. Required field. Null values not permitted
FullName (text) Full name of chronostratigraphic or geochronologic age unit, indicating hierarchical relations with higher ranking age units. Required field. Null values not permitted
Rank (text) Rank of the age unit; for example, eon, era, or period for geochronologic age units; eonothem, erathem, or system for chronostratigraphic units. Required field. Null values not permitted
NumericAgeMin (text) Minimum numerical age determined for the minimum age unit boundary. Required field. Null values not permitted
NumericAgeMinError (text) Analytical error reported for the minimum age unit boundary. Required field. Null values permitted if error not reported
NumericAgeMax (text) Maximum numerical age determined for the maximum age unit boundary. Required field. Null values not permitted
NumericAgeMaxError (text) Analytical error reported for the maximum age unit boundary. Required field. Null values permitted if error not reported
NumericAgeUnits (text) Unit of measure for numerical ages and errors; for example, “Ma” or “ka.” Required field. Null values not permitted
Notes (text) Free-text field for additional information. Optional field. Null values permitted
AgeLabel (text) Character(s) used to represent ages in map-unit labels throughout the database; for example, “K” (for Cretaceous) in a map-unit label. Required field. Null values permitted if age division not used in map-unit labels
DataSourceID (text) Foreign key or keys to the DataSources table to document the source of age information. Required field. Null values not permitted
HierarchyKey (text) Delimited text string used to represent hierarchical relations between age units. Required field. Null values not permitted
TimeScale_ID (text) Primary key. Required field. Null values not permitted
Table 14.    Fields in the SIGMa extension and descriptions of their content in the TimeScale nonspatial table.

The NumAgeSummary, NumAgeMethod, NumAgeComment, and NumAgeSourceID fields provide a narrative summary of geochronologic age constraints (table 12). These fields are not restricted to representing an individual analysis because multiple analyses derived using many methods from different areas of a map unit can contribute quantitative age control. Rather, they are a summary of quantitative age information, methods, contextual information, and reference to the data source(s) where individual analyses are reported. Quantitative, single-sample geochronology data are better suited as a point feature class such as GeochronPoints defined by GeMS (NCGMP, 2020) or through integration with national datasets such as the USGS Geochron database (https://www.usgs.gov/centers/geosciences-and-environmental-change-science-center/science/usgs-geochron-database-usgs, accessed September 21, 2022) or Geochron (http://www.geochron.org, accessed July 7, 2022). Although a project may establish a standardized attribution format for the NumAgeSummary field, none is defined as part of SIGMa. Table 15 lists some examples of attributes that may populate these fields.

Table 15.    

Examples of attributes that could populate the NumAgeSummary field and complementary fields in the SIGMa extension.

[Descriptions use ASCII characters to match database requirements. SIGMa, Seamless Integrated Geologic Mapping; Ma, mega-annum (or million years ago); sigma, standard deviation; 40Ar-39Ar, argon-argon; |, pipe character]

NumAgeSummary NumAgeMethod NumAgeComment NumAgeSourceID
2.87 +/- 0.02 Ma (2 sigma) 40Ar-39Ar Groundmass concentrate. Age calculated relative to a Fish Canyon Tuff age assigned at 28.02 Ma Kelley and others, 2013
75.76 +/- 0.34 Ma (1 sigma) to 73.50 Ma (Chron 33n/32r) 40Ar-39Ar | paleomagnetic 40Ar-39Ar age on sanidine. Paleomagnetic age constraint extrapolated based on chron boundary Fasset, 2000
6.51 +/- 0.21 to 7.81 +/- 0.09 Ma (2 sigma) 40Ar-39Ar Age calculated relative to a Fish Canyon Tuff age assigned at 28.02 Ma Kelley and others, 2013
Table 15.    Examples of attributes that could populate the NumAgeSummary field and complementary fields in the SIGMa extension.
Feature-Level Application of Fields

Local variations in map units can be recorded through feature-level application of SIGMa map-unit attribute fields. Paragraph-style unit descriptions frequently record spatial variations in a map unit. For example, a sedimentary unit may include sandstone, shale, and limestone, but limestone may be absent in the northeastern part of the map area, and sandstone may be absent in the southwestern part of the map area. These variations are not recorded by SIGMa map-unit attribute fields in the DescriptionOfMapUnits table because fields in the DescriptionOfMapUnits table are intended to document a composite of map-unit attributes across the full extent of the map unit. Feature-level use of these fields is considered optional to SIGMa, but, if included, field names should include “Local” as a prefix. For example, the Material, GeneticType, AgeMin, and AgeMax fields would be represented as LocalMaterial, LocalGeneticType, LocalAgeMin, and LocalAgeMax, respectively, in a feature class. Other properties recorded at the feature level should also follow this format (for example, LocalThickness).

Geologic Provinces

Map units in the SIGMa extension to GeMS are organized on the basis of their genetic relation to definable geologic events, processes, or settings, referred to as geologic provinces. The predecessor to GeMS, called “NCGMP09” (NCGMP, 2011), and the Geoscience Markup Language data model (GeoSciML; https://www.ogc.org/standards/geosciml; accessed April 15, 2022) can incorporate geologic-event attributes to document the geologic history recorded in a map database. However, in both data models, the geologic-event attributes are not specifically intended for map-unit organization and hierarchies. Yager and others (2010) used a “geohierarchy” to organize igneous-rock sample data and to place that information into a time-space framework. The SIGMa extension builds upon these previous models but adds a more structured hierarchy designed to associate packages of map units into the framework of these geologic events (similar to Yager and others, 2010). Map units can be understood in geologic context at multiple levels of detail through a province hierarchy.

Geologic provinces applied to map-unit organization in a SIGMa database have a characteristic age range and spatial extent that are defined by the mapped rocks and deposits associated with each province. Geologic provinces can include depositional settings associated with major tectonic events (for example, foreland basins), magmatic events (for example, magmatic provinces or volcanic fields), stable environments between major events (for example, passive margins, ocean basins, drainage basins), or specific depositional processes (for example, alluvial, mass wasting). Present-day physiographic provinces may be appropriate geologic provinces for surficial map units because the depositional processes (for example, alluvial, eolian, or mass wasting) are actively modifying the land surface. However, geologic provinces for map units that underlie unconsolidated surficial deposits (for example, stratified bedrock, crystalline basement rocks, and volcanic rocks) are likely not genetically related to the present-day surface, making present-day physiography a poor categorization for bedrock geologic provinces. For example, in the case of young volcanic rocks, the best geologic province is likely associated with a volcanic field, which has more geologic information than a physiographic province. Map units consisting of deep-crustal, highly metamorphosed rocks can present some unique challenges when compared to other rock and deposit types. The primary genetic processes for the protolith may be completely obliterated, and regional correlation of these rocks can prove to be challenging. Nevertheless, provinces that are based on some combination of age, composition, or metamorphic history can provide a framework for organizing these rock types until an improved state of knowledge supports alternative approaches.

Geologic provinces in the context of a database using the SIGMa extension are conceptually different from the American Association of Petroleum Geologists (AAPG) geologic provinces. Meyer (1968) and Meyer and others (1970) define geologic provinces and a code map for the United States focused on petroleum production and to highlight the geologic elements related to petroleum. As a result, AAPG provinces are incomplete as they relate to igneous and metamorphic rocks (Meyer and others, 1970). The AAPG geologic provinces have a limited spatial extent but are not temporally restricted; consequently, the rocks that fall within an AAPG geologic province may not share a common genetic origin. Moreover, map units can be associated with multiple provinces depending on the spatial extent of a map unit. In contrast, the geologic processes related to the genesis of a group of rocks are the basis for SIGMa geologic provinces; therefore, SIGMa geologic provinces are temporally restricted and do not have fixed spatial extents. Rocks of a formation or group are associated with a single SIGMa geologic province regardless of their location.

Geologic provinces in a database using the SIGMa extension are organized using multiple hierarchical levels. SIGMa does not impose a limit on the number of hierarchical levels, as this should be defined by a project to address individual project needs. In our experience, three hierarchical levels adequately resolve the relations between geologic events and settings that range from continental (geologic province 1), to regional (geologic province 2), to local or single-basin scales (geologic province 3). Figure 5 lists some examples of possible geologic province 1 values that would be applicable to the southwestern United States from the late Paleozoic through the Cenozoic. Figure 6 shows an expansion of the hierarchy, down to the basin scale (geologic province 3), within “late Cordilleran orogenic basins” geologic province 1.

Examples of geologic province 1 values ranked relative to other geologic province
                              1 values. Subprovinces (geologic provinces 2 and 3) of “late Cordilleran orogenic
                              basins” (green background) are shown in figure 6. An application of the “Paleozoic Laurentian passive margin” (blue background) hierarchy
                              and related map units is shown in figure 10.
Figure 5.

Examples of geologic province 1 values ranked relative to other geologic province 1 values. Subprovinces (geologic provinces 2 and 3) of “late Cordilleran orogenic basins” (green background) are shown in figure 6. An application of the “Paleozoic Laurentian passive margin” (blue background) hierarchy and related map units is shown in figure 10.

Schematic representation of an example hierarchy within “late Cordilleran orogenic
                              basins” geologic province 1. The “(San Juan sag: San Juan Basin)” geologic province
                              3 is shown in parentheses to indicate a combined province (because of an undifferentiated
                              unit). See figure 7.
Figure 6.

Schematic representation of an example hierarchy within “late Cordilleran orogenic basins” geologic province 1. The “(San Juan sag: San Juan Basin)” geologic province 3 is shown in parentheses to indicate a combined province (because of an undifferentiated unit). See figure 7.

The spatial extent of a SIGMa geologic province includes the extent of all mapped units associated with a province but generally does not have a definite and fixed boundary. The full spatial extent of a province extends to known, inferred, or unknown occurrences of related subsurface materials; inferred or unknown materials subsequently removed by later erosion; and local areas of nondeposition associated with the province environment (for example, local uplifts and areas of sediment bypass). The informal Lava Creek B ash, identified in Quaternary deposits in New Mexico, is associated with a Yellowstone geologic province even though the occurrences are well outside the extent of more local and continuous volcanic deposits in the Yellowstone area. However, known occurrences of the Lava Creek B ash do not define a fixed boundary for the province because the ash may be unidentified in some areas and has certainly been removed from many areas. The complexity of potential province extent makes definitive boundaries problematic and spatial rankings difficult.

Temporal characteristics provide the framework for chronologic ranking of geologic provinces. Geologic provinces can overlap or interfinger, just like the individual map units of which they are composed, meaning that in some cases provinces can be fully or partly coeval. Relative age relations are determined by the stratigraphic relations between map units and geochronologic constraints. Geologic province 1 values are ranked chronologically relative to other geologic province 1 values (fig. 5). Subprovinces—geologic provinces 2 and 3—are ranked chronologically only relative to other geologic provinces that have the same parent, as shown in figure 6. When chronological ordering is not resolvable, a geologist’s best judgement will determine ordering. For example, geologic province 3 values within the “Laramide foreland basins” (fig. 6) are approximately age equivalent, as are the map units within each basin (fig. 7).

Schematic representation of map units ranked within geologic province 3 values. Geologic
                              provinces 1 and 2 of this hierarchy shown in figure 6. The “(San Juan sag: San Juan Basin)” geologic province 3 is in parentheses to indicate
                              a combined province because the undivided Blanco Basin and Animas Formations are associated
                              with different provinces.
Figure 7.

Schematic representation of map units ranked within geologic province 3 values. Geologic provinces 1 and 2 of this hierarchy shown in figure 6. The “(San Juan sag: San Juan Basin)” geologic province 3 is in parentheses to indicate a combined province because the undivided Blanco Basin and Animas Formations are associated with different provinces.

The connection between the geologic-province hierarchy and their associated map units combines mapped relations with a wider breadth of scientific research and understanding into a scaled geologic context. Lowest ranked provinces (geologic province 3) are local structural basins (fig. 6) or volcanic fields, where province characteristics are less interpretive. The stratigraphic framework, the geologic processes related to the map units, and the temporal range are often well defined. Geologic province 2 is generally more interpretive than geologic province 3 because it links provinces and map units that may be spatially, temporally, and genetically more diverse than is observed in geologic province 3. Geologic province 1 is the most interpretive, as it encapsulates a highly diverse range of map units that relate to a more prolonged and complex combination of genetic processes.

The geologic-province hierarchy places a map unit into a scaled geologic context that ranges from continental down to the local stratigraphic framework. This relation is shown in figure 6, where the geologic province 1 is continent-scale deformation of the North American Cordillera during late Mesozoic subduction of the Farallon Plate along the western margin of Laurentia. The intermediate-level provinces (geologic province 2) shown in figure 6 relate map units from regionally correlative yet noncontiguous depositional basins that have a similar genetic origin and timing (such as Laramide foreland basins) or vertical correlation of temporally sequential packages of map units that represent separate stages of a protracted genetic process (such as Sevier foreland basins). Many approaches may be taken to construct this framework through the selection and definition of provinces and assignment of map units to those provinces. The approach taken should be driven by individual project goals.

The hierarchical-province structure can similarly be extended to maps that are focused on surficial deposits. Figure 8A shows an example of a Correlation of Map Units in which surficial deposits are organized by depositional process as well as by age and regional setting; figure 8B shows a schematic representation of the geologic province structure that mirrors this organization. To retain the chronologic ordering of geologic provinces, a top-level geologic province 1 of “Surficial deposits” is set. Map units associated with “all drainage basins” in figure 8A are placed directly under geologic province 1 because these units are defined by process, but their physiographic-basin association and age are undifferentiated. For map units in “all drainage basins,” geologic provinces 2 and 3 values would be null. The remaining surficial deposits are split on the basis of geologic province 2 values, which differentiate drainage basins that contain partly coeval deposits; map units of the “Wenatchee and Columbia drainage basins” and the “Yakima and Peshatin drainage basins” are approximately coeval (fig. 8A). Beneath the regional organization of geologic province 2, map units are organized within geologic province 3 values that are process oriented. Finally, at the lowest level of the combined province and map-unit hierarchy, individual map units are differentiated on the basis of age, to the fullest extent possible.

Examples of Correlation of Map Units (CMU) and related province structure for surficial
                              map units. A, CMU of surficial map units (modified from Tabor and others, 1982). B, Partial schematic representation of units in CMU in A, organized into the hierarchical geologic-province structure.
Figure 8.

Examples of Correlation of Map Units (CMU) and related province structure for surficial map units. A, CMU of surficial map units (modified from Tabor and others, 1982). B, Partial schematic representation of units in CMU in A, organized into the hierarchical geologic-province structure.

Organizing map units into geologic provinces provides multiple benefits in constructing and publishing a geologic map database. In many DMUs, map units are commonly ranked chronologically, or they may be listed according to a higher level grouping that is based on rock type (for example, surficial, sedimentary, and volcanic) within which map units are ranked chronologically. This is an adequate organizational approach for maps that have a limited or fixed number of map units, but it can obscure the local to regional stratigraphic relations between map units in a more regionally extensive geologic map database. For example, sedimentary rocks listed chronologically in a national database could result in Mississippian rocks from Arkansas, Colorado, and Nevada in adjacent rows in the DescriptionOfMapUnits table. Although the temporal relations are communicated to the user, the local to regional stratigraphic relations and the genetic associations in a package of rocks are more difficult to extract. Without the geologic province hierarchy, the genetic relations among map units must be documented in the map-unit descriptions, which results in repeated information, a greater tendency for inconsistent documentation of the geologic history, a more complicated database query of paragraph-style descriptions, and a reduction in user comprehension of the stratigraphy. The geologic-province hierarchy is intended to compartmentalize the stratigraphy into groups of map units that have a spatial and stratigraphic relation and to record the genetic relations between those units.

This hierarchical structure offers several functional advantages within the map database. First, hierarchies are extensible and, therefore, support piecemeal construction of the stratigraphic framework to coincide with areas of active mapping; thus, a comprehensive stratigraphy is not required at the onset of a mapping project. Second, changes to the overall database are reduced when geologic provinces or map units are added to, modified, or removed from the database. For example, a new geologic province 3 added to the hierarchy shown in figure 7 has no effect on the ranking of geologic province 1, geologic province 2, and existing map units (fig. 9). Only the ranking of other geologic province 3 values, and their associated map units are affected. Similarly, if a new unit is later added to the “Raton Basin” (fig. 9), only units of the “Raton Basin” geologic province 3 are affected.

Schematic representation showing examples of adding a new map unit to an existing
                              geologic province and a new geologic province 3 and its units into the hierarchy shown
                              in figure 7 (new province and units are shown in red type). Geologic provinces 1 and 2 of this
                              hierarchy shown in figure 6. After adding a new geologic province 3 (“New Basin”) and its units, only lower ranked
                              provinces are reranked, and the ranking of their units is not affected. After adding
                              a new unit (“New unit X”) to an existing geologic province, only lower ranked units
                              within that province are reranked.
Figure 9.

Schematic representation showing examples of adding a new map unit to an existing geologic province and a new geologic province 3 and its units into the hierarchy shown in figure 7 (new province and units are shown in red type). Geologic provinces 1 and 2 of this hierarchy shown in figure 6. After adding a new geologic province 3 (“New Basin”) and its units, only lower ranked provinces are reranked, and the ranking of their units is not affected. After adding a new unit (“New unit X”) to an existing geologic province, only lower ranked units within that province are reranked.

Paleozoic carbonate and siliciclastic deposits in Colorado and Nevada offer a practical demonstration for developing a geologic province hierarchy that is later expanded to include map units in Arkansas (fig. 10). Mississippian to Cambrian units mapped in Colorado and Nevada share a genetic relationship to the Laurentian passive margin in the Paleozoic that developed following rifting of the supercontinent Rodinia (Stewart, 1972; Gutschick and Sandberg, 1983; Blakey and Ranney, 20181). Therefore, geologic province 1 is the long-lived, continent-scale depositional setting along the Laurentian passive margin. Regional variations along the passive margin are accommodated as geologic province 2 values that could include multiple geologic province 3 values to further specify depositional settings such as mid shelf, outer shelf to slope, or deep marine basin environments. For simplicity, only a single geologic province 3 is shown in each geologic province 2 in figure 10. To integrate stratigraphy from a new map area in Arkansas that is also related to the Laurentian passive margin, the hierarchy is expanded with new geologic provinces 2 and 3 following a parallel construction (fig. 10). Although only partial stratigraphic sections from the different map areas are represented in figure 10, the ability to represent field-based stratigraphic relations within geologic province 3 is demonstrated. Moreover, the hierarchical relationship between the geologic provinces places these stratigraphic sections into a continent-scale geologic context.

Schematic representation of a partial geologic province hierarchy and associated map
                              units that is modified to accommodate a new map area. Black lines and outlines indicate
                              geologic provinces and map units that existed in the hierarchy (Colorado and Nevada)
                              before the new map area in Arkansas is added (red lines and borders). Geologic map
                              graphic from the St. Joe quadrangle in northern Arkansas (Hudson and Turner, 2009).
Figure 10.

Schematic representation of a partial geologic province hierarchy and associated map units that is modified to accommodate a new map area. Black lines and outlines indicate geologic provinces and map units that existed in the hierarchy (Colorado and Nevada) before the new map area in Arkansas is added (red lines and borders). Geologic map graphic from the St. Joe quadrangle in northern Arkansas (Hudson and Turner, 2009).

Tables

Geologic provinces are recorded and described in the GeologicProvinces nonspatial table, whereas the DescriptionOfMapUnits nonspatial table includes only map units. In contrast, a GeMS database may also include headings that are not map units—similar to a geologic province in how map units may be organized—in the DescriptionOfMapUnits table (NCGMP, 2020). However, map units and geologic provinces are two distinct information types; map units are directly associated with mapped features, whereas geologic provinces are more interpretive and conceptual. Using separate tables organizes these distinct information types and allows for targeted attribution. Comprehension of the hierarchical organization is improved by consolidating geologic provinces in the GeologicProvinces table because, when sorted on the HierarchyKey,4 the provinces are continuous. In contrast, geologic provinces would be discontinuous if combined with map units in the DescriptionOfMapUnits table. A relationship between the two tables allows users to use the basic relate capabilities in a GIS to select map units of a province (or the province of a map unit or units). Table 16 lists required fields for the GeologicProvinces table.

4

A HierarchyKey value is a text string in a GeMS database that indicates the place of map unit or heading within the hierarchy of a Description of Map Units. Text string has form of “n-n-n,” “nn-nn,” “nn-nn-nn,” “nnn-nnn,” or similar. Each dash-delimited fragment in text string (1) is numeric, (2) has same length as others in string and in DescriptionOfMapUnits table, and (3) is left-padded with zeroes if values are greater than 9 (if they exceed one digit).

Table 16.    

Fields in the SIGMa extension and descriptions of their content in the GeologicProvinces nonspatial table.

[SIGMa, Seamless Integrated Geologic Mapping]

Field name (data type) Description
Name (text) Short name of the province. Required field. Null values not permitted
FullName (text) Full name of the province that includes any parent provinces that have higher rank. Required field. Null values not permitted
ProvinceRank (text) Rank of the province, as defined by user. The SIGMa extension assigns three hierarchical ranks for regional datasets that include, in order from most regional to most detailed, “geologic province 1,” “geologic province 2,” and “geologic province 3.” Additional or fewer ranks may be needed for datasets of different detail. Only single value allowed. Terms should be defined in the Glossary table. Required field. Null values not permitted
ProvinceType (text) Indicates either the prominent depositional, magmatic, or tectonic setting or the dominant process by which map units within the province are derived. Multiple terms can be concatenated. Users may choose to establish a controlled list relevant to their purposes, but none is prescribed here. Values could include “rift basin,” “rift magmatism,” “continental depositional system,” “foreland,” or “hinterland.” Required field. Null values not permitted
DepositGeneral (text) General characterization of dominant rock- or process-oriented category. Users may choose to establish a controlled list relevant to their purposes, but none is prescribed here. Values may include, but are not limited to, “igneous,” “sedimentary,” “metamorphic,” “igneous and sedimentary,” “igneous and metamorphic,” “alluvial,” “eolian,” or “mass wasting.” Required field. Null values not permitted
Age (text) Chronostratigraphic or geochronologic age term(s) that best describe the age of the province. Not the numerical age of the geologic province. It is recommended that age terms be defined in the TimeScale table. Required field. Null values not permitted
Description (text) Free-text description of the province. Required field. Null values not permitted
HierarchyKey (text) Delimited text string used to indicate order and hierarchical relations between parent and child provinces. Required field. Null values not permitted
DescriptionSourceID (text) Data sources used to define the province. Multiple sources can be concatenated using a character delimiter. Values must be defined in the DataSources table. Required field. Null values not permitted
GeologicProvinces_ID (text) Primary key for geologic province table. Required field. Null values not permitted
Table 16.    Fields in the SIGMa extension and descriptions of their content in the GeologicProvinces nonspatial table.

A relationship is established between the DescriptionOfMapUnits and GeologicProvinces nonspatial tables using the GeologicProvinces_ID primary key and the GeologicProvinceID foreign key (fig. 11). Some important characteristics about the relation between map units and geologic provinces include the following:

  • Map units can be associated with a geologic province of any hierarchical rank.

  • Map units must only be associated with a single, unique combination of geologic province values unless the unit also participates in an undivided, or lumped, map unit.

  • A map unit composed of two or more map units that are undivided, or have been lumped, is treated as a unique map unit (see figure 7 for an example), as opposed to maintaining a hierarchical parent or child relationship to the constituent map units.

  • Generally, the constituent map units of a lumped map unit should also be described individually in unique table records (for example, see units in “Raton Basin” in figure 7).

  • Lumped map units from different geologic provinces require a combined geologic province. No format is prescribed as part of the SIGMa extension, but one example is shown in figure 7.

  • Map units in the DescriptionOfMapUnits nonspatial table inherit part of their HierarchyKey values from their parent province.

Entity-relationship diagram illustrating the relationship between the GeologicProvinces
                                 and DescriptionOfMapUnits tables. All features that have map-unit information are
                                 related to the DescriptionOfMapUnits table (only MapUnitPolys is shown here). Black
                                 lines connect primary- and foreign-key fields that support the relationships. Field
                                 names that are standard to Geologic Map Schema, or GeMS (National Cooperative Geologic Mapping Program, 2020), are shown in
                                 regular type; Seamless Integrated Geologic Mapping (SIGMa) extension fields are shown
                                 in bold type.
Figure 11.

Entity-relationship diagram illustrating the relationship between the GeologicProvinces and DescriptionOfMapUnits tables. All features that have map-unit information are related to the DescriptionOfMapUnits table (only MapUnitPolys is shown here). Black lines connect primary- and foreign-key fields that support the relationships. Field names that are standard to Geologic Map Schema, or GeMS (National Cooperative Geologic Mapping Program, 2020), are shown in regular type; Seamless Integrated Geologic Mapping (SIGMa) extension fields are shown in bold type.

Each geologic province includes a paragraph-style description. This description allows for explanation of the geologic context as well as the relationships between map units within the province and other related provinces. In addition, searchable keywords can be provided to categorize the general nature of the province (for example, foreland, volcanic field, accretionary terrain) to provide easy query of a variety of depositional environments and processes across the province structure for applied geologic system-based analysis.

HierarchyKey

The HierarchyKey field was established by GeMS (NCGMP, 2020) as a delimited text string that, when sorted in a table, can demonstrate hierarchical relationships and properly sequences map units and headings in the DescriptionOfMapUnits nonspatial table. The SIGMa extension uses the HierarchyKey field in the DescriptionOfMapUnits and GeologicProvinces tables. Geologic province HierarchyKey values are independent of map units, whereas map-unit HierarchyKey values are dependent upon geologic provinces to reflect the proper sequencing of units in the DescriptionOfMapUnits nonspatial table. As such, geologic province HierarchyKey values are prepended to the HierarchyKey values of the map unit in the DescriptionOfMapUnits table (fig. 12). In figure 12, HierarchyKey values for map units in the DescriptionOfMapUnits table incorporate the three delimited fragments that represent the parent geologic province, followed by delimited fragments to the right for map-unit sequence and hierarchy. Map units can be associated with any rank of geologic province, which requires dash-delimited fragments that represent geologic provinces be fully occupied either by a nonzero value or entirely by zeroes (fig. 12). If this requirement is not maintained, combining geologic province HierarchyKey values with map-unit hierarchies, will result in HierarchyKey values that are not unique.

Diagram showing how character-delimited HierarchyKey values are used to rank geologic
                                 provinces and map units in the GeologicProvinces and DescriptionOfMapUnits nonspatial
                                 tables. HierarchyKey values of map units in the DescriptionOfMapUnits table are dependent
                                 upon the HierarchyKey values of the parent province in the GeologicProvinces table.
                                 HierarchyKey values shown here accommodate three geologic-province hierarchical levels
                                 and map units.
Figure 12.

Diagram showing how character-delimited HierarchyKey values are used to rank geologic provinces and map units in the GeologicProvinces and DescriptionOfMapUnits nonspatial tables. HierarchyKey values of map units in the DescriptionOfMapUnits table are dependent upon the HierarchyKey values of the parent province in the GeologicProvinces table. HierarchyKey values shown here accommodate three geologic-province hierarchical levels and map units.

MapUnit and UnitCode Fields

Map-unit labels are important elements of a geologic map that are generally unique within a single map but can be inconsistent across different maps. Meaningful map-unit labels—those that indicate the age, lithology, and name of the map units—are useful to users. GeMS (NCMGP, 2020) specified recording map-unit labels in the MapUnit and Label fields. In the GeMS schema, the MapUnit field is usually a plain-text identifier (no special characters; for example, “Qal” or “TRsu” [plain-text identifier for the Triassic unit “ ^ s u”]), whereas the Label field allows for inclusion of special characters that represent geologic age-symbol fonts (for example, “^su,”5 which represents the Triassic unit “ ^ s u” in the FGDCGeoAge font) or symbols to indicate scientific uncertainty (for example, “Qal?” where a query is added to the map-unit label [in feature classes only]). For a standard GeMS database, the MapUnit field is the primary key field that supports relationships between the DescriptionOfMapUnits nonspatial table and other feature classes or nonspatial tables (NCGMP, 2020), which necessitates maintaining unique values in the MapUnit field.

5

Character “^” (Shift-6) in the FGDCGeoAge font results in the geologic age symbol “[Private character Triassic]” (Triassic) (USGS, 2006).

In a geologic map database that continuously grows over a long-lived project there are significant challenges to maintaining stable primary-key values while also including meaningful map-unit labels, including the following:

  • Primary-key values should be stable over the life of the database. However, age indicators typically used in the map-unit label result in potentially unstable key values because time-period boundaries do change, and new data can redefine the age of map units. For example, if new geochronology indicates that a unit is Silurian instead of Devonian, the map-unit label of the unit would change from “Du” to “Su.”

  • The ability to generate meaningful map-unit labels in a systematic manner would become increasingly difficult as the number of map units increases and would likely require some arbitrary addition to the label (for example, numbered labels such as “Tv1” or “Tv2”) to differentiate the units. Including arbitrary differentiators reduces how meaningful the labels are.

  • Coordinating unique map-unit labels across a decentralized workforce would compound these challenges.

To maintain compliance with GeMS (NCGMP, 2020), the SIGMa extension uses the MapUnit field as the key field by which relationships to the DescriptionOfMapUnits table are based. However, because the traditional approach to meaningful, age-based map-unit labels are potentially unstable over the life of a long-lived project, users are encouraged to populate the MapUnit field with unique identifiers that have no obvious meaning, also referred to as surrogate or opaque identifiers (table 17). Although the DescriptionOfMapUnits_ID field is a required table unique identifier field and would likely be populated with an opaque identifier, it is not used to support any relationships in a standard GeMS database. There is no functional reason that would prohibit the MapUnit and DescriptionOfMapUnits_ID fields from containing equivalent values (table 17). This approach does introduce redundancy between the MapUnit and DescriptionOfMapUnits_ID fields. However, it results in stable primary-key values in a continuously changing database and meets requirements of a GeMS database (NCGMP, 2020).

Table 17.    

Example usage of MapUnit, UnitCode, and Label fields in the DescriptionOfMapUnits table.

[Character “^” (Shift-6) in FGDCGeoAge font results in Triassic geologic age symbol “ ^” (USGS, 2006) in unit “ ^ s u”; “TRsu” is plain-text identifier for “ ^ s u”]

UnitCode Label Name MapUnit DescriptionOfMapUnits_ID
QTf QTf Quaternary and Tertiary alluvial fan deposits MU9743 MU9743
Tlb Tlb Basalt lava flow MU932 MU932
Kd Kd Dakota Sandstone MU3150 MU3150
TRsu ^su Triassic sedimentary rocks, undivided MU879 MU879
Mm Mm Monte Cristo Group MU111 MU111
Mm Mm Madison Limestone MU135 MU135
Mm Mm Monteagle Limestone MU457 MU457
Table 17.    Example usage of MapUnit, UnitCode, and Label fields in the DescriptionOfMapUnits table.

The UnitCode field is introduced as part of the SIGMa extension to capture meaningful map-unit labels that can be nonunique within the database; it is added to all feature classes that have map-unit information and to the DescriptionOfMapUnits nonspatial table. Map-unit labels in the UnitCode field should contain the plain-text identifier (no special characters) for the map-unit label. The interrelationship between the UnitCode and Label fields within the SIGMa extension is equivalent to the relationship between the MapUnit and Label fields in a GeMS database (NCGMP, 2020). Therefore, the Label field will contain the equivalent value of the UnitCode field but can also include special characters that represent geologic age from symbol fonts such as FGDCGeoAge (USGS, 2006) or queries that indicate uncertainty (uncertainty in feature classes only, not in the DescriptionOfMapUnits table). For clarity, UnitCode values should be unique for units in the same geologic province and for colocated units, even if they are associated with different provinces.

Across a national-scale geologic map database, application of nonunique map-unit labels in the UnitCode and Label fields provides significant flexibility to follow traditional practices in the assignment of meaningful map-unit labels. For example, across southern Nevada, exposures of the widespread Mississippian Monte Cristo Group are commonly labeled on maps as “ Mississipian m.” Likewise, in the central Rocky Mountains of Montana and Wyoming, the Mississippian Madison Limestone and in Kentucky, Tennessee, and Alabama the Mississippian Monteagle Limestone of the Cumberland Plateau are also labeled as “ Mississipian m.” All three map units require unique, primary-key values in the MapUnit field (table 17) to support relationships between the DescriptionOfMapUnits table and other feature classes or tables (fig. 11). However, because these map units are mapped in widely separated regions and have distinct geologic province associations, the same UnitCode (“Mm”) can be assigned to all three units (table 17). Values in the Label field for the map units listed in table 17 reflect the UnitCode values. Use of the UnitCode and Label fields in this manner maintains a regional connection to standard map-unit labeling practices but does not violate the relational requirements and functionality of the data structure specified by GeMS (NCGMP, 2020).

Line Features and Polygon Topology

The degree to which formation-level stratigraphic detail is retained in a geologic map database depends on the terrain, thickness of units, and map scale. In a variable-scale database, all map units can be represented as polygons, which offers the most analytical functionality because all map-unit features are in a single feature class. However, if a fixed display scale is considered, narrow polygons may not be discernable. For a database that has a nominal mapping scale, combining stratigraphically adjacent map units into compound map units can improve the visibility of polygons, though this compromises the spatial accuracy of the constituent map units. An alternative is to capture map units as linear features, thereby facilitating a more detailed stratigraphic framework that has a higher spatial resolution than what might be shown using compound map units. For example, dikes and sills are frequently represented by linear features, even in a detailed 1:24,000-scale geologic map database. Representing stratified units as linear features is less common but offers a solution to representing a more detailed formation-level stratigraphic framework.

The SIGMa extension adds map-unit fields to the ContactsAndFaults feature class to facilitate linear map-unit features and to maintain compliance with GeMS (NCGMP, 2020; table 18). Although the MapUnitLines feature class is a GeMS-compliant feature class that is intended to capture linear map-unit features, the feature class does not participate in MapUnitPolys topology (NCGMP, 2020). GeMS stipulates that all polygon boundaries in the MapUnitPolys feature class be overlain by line features in the ContactsAndFaults feature class. Dikes or internal key beds may not be involved in defining polygon boundaries and would be adequately represented in the MapUnitLines feature class. Representing stratified units as linear features in most cases will necessitate involvement in map-unit polygon topology and, therefore, will need to be captured in the ContactsAndFaults feature class.

Table 18.    

Fields in the SIGMa extension and descriptions of their content added to the ContactsAndFaults feature class of a GeMS database to capture linear map-unit features.

[Fields included in GeMS (NGCMP, 2020) are omitted. GeMS, Geologic Map Schema; SIGMa, Seamless Integrated Geologic Mapping; FGDC, Federal Geographic Data Committee; USGS U.S. Geological Survey]

Field name (data type) Description
UnitCode (text) Easily readable, meaningful plain-text identifier (no special characters) for the map-unit label for linear map-unit features. Optional field. Null values permitted for features that are not map units
MapUnit (text) Foreign key to the DescriptionOfMapUnits nonspatial table. Optional field. Null values permitted for features that are not map units
LocalStratName (text) Map-unit name(s) used on source map. Field is reserved for recognized formal or informal unit names, not generic unit names that refer only to lithology or other physical characteristics of the map unit. Multiple values can be concatenated using a character delimiter. Optional field. Null values permitted
OrigMapUnit (text) Map-unit labels(s) used on the source geologic map(s). Field is heavily used in map compilations but may be of little use for new mapping. Multiple values can be concatenated using a character delimiter. Optional field. Null values permitted
MethodID (text) Foreign key to the Methods nonspatial table. Required field. Null values not permitted
Table 18.    Fields in the SIGMa extension and descriptions of their content added to the ContactsAndFaults feature class of a GeMS database to capture linear map-unit features.

With the modification to ContactsAndFaults in the SIGMa extension, linear map-unit features can be represented in multiple feature classes, which raises the question of which features go in ContactsAndFaults versus MapUnitLines feature classes. We suggest that consistency should be a primary consideration. For example, if some features of a specific type (for example, Type = “stratified unit,” “dike,” or “key bed”) participate in defining some polygon boundaries, all features of that type should be included in the ContactsAndFaults feature class. Conversely, for feature types that never participate in polygon topology, these features can be exclusively represented in the MapUnitLines feature class.

Relationships

The SIGMa extension incorporates multiple relationships that are not part of a basic GeMS database (table 19). Primary-key and foreign-key field names follow the naming format suggested by GeMS: primary-key fields are represented as TableName_ID, and foreign-key fields referencing the table are represented as TableNameID. Most relationships included as part of a GeMS database are unmodified and retain functionality using the SIGMa extension.

Table 19.    

Related feature classes and tables and their associated primary- and foreign-key fields.
Origin table Primary key Destination feature class or table Foreign key
DescriptionOfMapUnits MapUnit Feature classes or tables that contain map-unit information MapUnit
GeologicProvinces GeologicProvinces_ID DescriptionOfMapUnits table GeologicProvinceID
DataSources DataSources_ID Feature classes or tables that contain xxxSourceID fields xxxSourceID
DataSources1 DataSources_ID DataSourcesList table DataSourceID
DataSourcesList1 DataSourcesList_ID Feature classes or tables that contain xxxSourceID fields xxxSourceID
Methods Methods_ID All feature classes MethodID
Contributors Contributors_ID All feature classes and most tables ContributorID, ContributorOrgID
DatabaseReleaseVersions DatabaseReleaseVersions_ID All feature classes and most tables DatabaseVersionID, LastUpdateVersionID
Table 19.    Related feature classes and tables and their associated primary- and foreign-key fields.
1

If only single foreign-key values populate the xxxSourceID fields, the relationships involving the DataSourcesList table are not necessary.

Required and As-Needed Content

The SIGMa extension has minimal requirements beyond the requirements that are standard to a GeMS database. Figure 13 shows a database that has the SIGMa extension and its required and as-needed elements (nonspatial tables and feature classes). In addition to database elements, some fields are required for all feature classes, and some required fields are specific to individual nonspatial tables. The SIGMa extension intends to support digital publication of geologic map data, and therefore a database with the SIGMa extension may not be associated with the list of cartographic and GIS layout products required for a GeMS database (NCGMP, 2020).

List of required and as-needed feature classes and tables in a geologic map database
                        that uses the Seamless Integrated Geologic Mapping (SIGMa) extension.
Figure 13.

List of required and as-needed feature classes and tables in a geologic map database that uses the Seamless Integrated Geologic Mapping (SIGMa) extension.

Publication Data Package

A primary emphasis of the SIGMa extension is the production and publication of the geologic map database. The publication data package for a database-only publication, and particularly for a continuously growing and versioned database, will not include a publication-quality map graphic or layout and may not include a formatted report or a DMU, which are commonly included in a published geologic map. In such database-only publications, web-based feature services and a downloadable database compliant with Open Geospatial Consortium are expected to be the primary methods for data access. The downloadable database will be the more complete data package because metadata, symbology, and other resources can be combined with the database. Required, as-needed, and optional contents are established for a GeMS-compliant database publication package (see tables 35 in NCGMP, 2020). The only deviation from a standard GeMS-compliant publication data package is the lack of a map graphic because a publication-quality map graphic would not be created for a database-only publication. FGDC-compliant metadata, open-shapefile and text-document representations of tables, and files to support symbolizing the data are important parts of the data package for any published geologic map database.

Feature Classes and Tables

Only two tables, Methods and GeologicProvinces, are required to be added to a standard GeMS-compliant database as part of the SIGMa extension (fig. 13). The Methods table is required to define key values in the MethodID field. The GeologicProvinces table is required because geologic provinces are fundamental to map-unit organization using the SIGMa extension. However, incorporating optional tables will expand the capabilities of a GeMS-compliant database.

Fields

A limited number of additional feature-class and nonspatial table fields are required with the SIGMa extension. Because SIGMa records data sources and compilation methods in separate tables and combines these attributes in separate fields at the feature level, the MethodID field is required in all feature classes as a foreign key to the Methods nonspatial table (fig. 1). The MethodID field is not required for the nonspatial tables. The UnitCode field is a required field for the DescriptionOfMapUnits nonspatial table and any feature classes that contain map-unit information. Map-unit fields should be added to the ContactsAndFaults feature class as needed. If no linear map-unit features participate in defining polygon boundaries, the extension to this feature class is unnecessary. Optional fields for feature classes that contain map-unit information include the LocalStratName and OrigMapUnit fields. These fields are considered optional because the fields will have little use in a database that contains only new mapping. However, including LocalStratName and OrigMapUnit is highly encouraged for a geologic map database that uses existing geologic mapping, as they provide useful feature-level metadata.

Other required and optional nonspatial table fields are indicated in table 3 (DataSources), table 4 (Methods), table 12 (DescriptionOfMapUnits), table 14 (TimeScale), and table 16 (GeologicProvinces). Figure 1 shows the list of fields for some feature classes and nonspatial tables. The Methods, TimeScale, and GeologicProvinces tables introduced as part of the SIGMa extension are not part of a basic GeMS database. Fields for DataSources and DescriptionOfMapUnits tables are in addition to the required GeMS fields.

References Cited

Blakey, R.C., and Ranney, W.D., 2018, The Cordillera’s long-lived passive margin—Neoproterozoic to Middle Devonian periods—Ca. 1000 Ma–400 Ma, in Ancient landscapes of western North America—A geologic history with paleogeographic maps: Cham, Switzerland, Springer International Publishing, AG, p. 63–66, accessed October 31, 2021, at https://doi.org/10.1007/978-3-319-59636-5.

Brock, J., Berry, K., Faulds, J., Berg, R., House, K., Marketti, M., McPhee, D., Schmidt, K., Schmitt, J., Soller, D.R., Spears, D., Thompson, R.A., Thorleifson, H., and Walsh, G.J., 2021, Renewing the National Cooperative Geologic Mapping Program as the Nation’s authoritative source for modern geologic knowledge: U.S. Geological Survey Open-File Report 2021–1013, 10 p., accessed August 6, 2021, at https://doi.org/10.3133/ofr20211013.

Colman-Sadd, S.P., Ash, J.S., Hays, J.P., and Nolan, L.W., 1996, Management of geological map units in a geographic information system: Newfoundland Department of Natural Resources, Geological Survey Report 96–1, p. 227–251.

Colman-Sadd, S.P., Ash, J.S., and Nolan, L.W., 1997, GeoLegend—A database system for managing geological map units in a geographic information system: Computers & Geosciences, v. 23, no. 7, p. 715–724, accessed April 29, 2022, at https://doi.org/10.1016/S0098-3004(97)00069-1.

DeWitt, E., Langenheim, V.E., Force, E., Vance, R.K., Lindberg, P.A., and Driscoll, R.L., 2008, Geologic map of the Prescott National Forest and the headwaters of the Verde River, Yavapai and Coconino Counties, Arizona: U.S. Geological Survey Scientific Investigations Map 2996, 1 sheet, scale 1:100,000, 100-p. pamphlet, accessed September 13, 2021, at https://doi.org/10.3133/sim2996.

Fasset, J.E., 2000, Geology and coal resources of the Upper Cretaceous Fruitland Formation, San Juan Basin, New Mexico and Colorado, chap. Q of Kirschbaum, M.A., Roberts, L.N.R., and Biewick, L.R.H., eds., Geologic assessment of coal in the Colorado Plateau—Arizona, Colorado, New Mexico, and Utah: U.S. Geological Survey Professional Paper 1625–B, 132 p.

Federal Geographic Data Committee [FGDC], 1998, Content standard for digital geospatial metadata (revised June 1998): Washington, D.C., Federal Geographic Data Committee Document Number FGDC-STD-001-1998, 78 p., accessed April 8, 2022, at https://www.fgdc.gov/standards/projects/metadata/base-metadata/v2_0698.pdf.

Gutschick, R.C., and Sandberg, C.A., 1983, Mississippian continental margins of the conterminous United States: The Society of Economic Paleontologists and Mineralogists Special Publication 33, p 79–96.

Horton, J.D., San Juan, C.A., and Stoeser, D.B., 2017, The State Geologic Map Compilation (SGMC) geodatabase of the conterminous United States (ver. 1.1, August 2017): U.S. Geological Survey Data Series 1052, 46 p., accessed December 12, 2018, at https://doi.org/10.3133/ds1052.

Hudson, M.R., and Turner, K.J., 2009, Geologic map of the St. Joe Quadrangle, Searcy and Marion counties, Arkansas: U.S. Geological Survey Scientific Investigations Map 3074, 1 sheet, scale 1:24,000, accessed October 1, 2021, https://www.doi.org/10.3133/sim3074.

Johnson, B.R., Brodaric, B., Raines, G.L., Hastings, J.T., and Wahl, R., 1999, Digital geologic map data model—Version 4.3: Association of American State Geologists/U.S. Geological Survey Data Model Working Group Report, 69 p., accessed July 7, 2022, at https://ngmdb.usgs.gov/www-nadm/prd/Model43a.pdf.

Kelley, S.A., McIntosh, W.C., Goff, F., Kempter, K.A., Wolff, J.A., Esser, R., Braschayko, S., Love, D., and Gardner, J.N., 2013, Spatial and temporal trends in pre-caldera Jemez Mountains volcanic and fault activity: Geosphere, v. 9, p. 614–646, accessed November 8, 2019, at https://doi.org/10.1130/GES00897.1.

Levings, G.W., 1980, Water resources in the Sedona area, Yavapai and Coconino Counties, Arizona: Arizona Water Commission Bulletin 11, 37 p., 3 sheets, scale 1:50,000.

McKee, E.H., and Anderson, C.A., 1971, Age and chemistry of Tertiary volcanic rocks in north-central Arizona and relation of the rocks to the Colorado Plateau: Geological Society of America Bulletin, v. 82, no. 10, p 2767–2782, September 1, 2022, at https://doi.org/10.1130/0016-7606(1971)82[2767:AACOTV]2.0.CO;2.

National Research Council, 2012, Advancing strategic science—A spatial data infrastructure roadmap for the U.S. Geological Survey: Washington, D.C., The National Academies Press, accessed January 10, 2022, at https://doi.org/10.17226/13506.

Neuendorf, K.K.E., Mehl, J.P., Jr., and Jackson, J.A., eds., 2011, Glossary of geology (5th ed.): Alexandria, Va., American Geosciences Institute, 779 p.

North American Geologic Map Data Model [NADM] Steering Committee Data Model Design Team, 2004, NADM conceptual model 1.0—A conceptual model for geologic map information: U.S. Geological Survey Open-File Report 2004–1334, 58 p. [Also available at https://doi.org/10.3133/ofr20041334.]

Peirce, H.W., Damon, PE., and Shafiqullah, M., 1979, An Oligocene (?) Colorado Plateau edge in Arizona: Tectonophysics, v. 61, nos. 1–3, p. 1–24, accessed September 1, 2022, at https://doi.org/10.1016/0040-1951(79)90289-0.

Reed, J.C. Jr., Wheler, J.O., and Tucholke, B.E., 2005, Geologic map of North America—Perspectives and explanation: Boulder, Colo., Geological Society of America, Decade of North American Geology Continental Scale Map 001, scale 1:5,000,000. [Also available at https://doi.org/10.1130/DNAG-CSMS-v1.]

Stewart, J.H., 1972, Initial deposits in the Cordilleran geosyncline: Evidence of a Late Precambrian (<850 m.y.) continental separation: Geological Society of America Bulletin, v. 83, p. 1345–1360, accessed October 31, 2022, at https://doi.org/10.1130/0016-7606(1972)83[1345:IDITCG]2.0.CO;2.

Tabor, R.W., Waitt, R.B., Jr., Frizzell, V.A., Jr., Swanson, D.A., Byerly, G.R., and Bentley, R.D., 1982, Geologic map of the Wenatchee 1:100,000 quadrangle, central Washington: U.S. Geological Survey Miscellaneous Investigations Series Map I–1311, 1 sheet, scale 1:100,000, 44 p. [Also available at https://doi.org/10.3133/i1311.]

U.S. Geological Survey [USGS], 2006, FGDC Digital Cartographic Standard for Geologic Map Symbolization (PostScript Implementation): U.S. Geological Survey Techniques and Methods, book 11, chap. A2, accessed April 23, 2007, at https://pubs.usgs.gov/tm/2006/11A02/.

U.S. Geological Survey [USGS], 2021, U.S. Geological Survey 21st-century science strategy 2020–2030: U.S. Geological Survey Circular 1476, 20 p., accessed January 10, 2022, at https://doi.org/10.3133/cir1476.

U.S. Geological Survey National Cooperative Geologic Mapping Program [NCGMP], 2011 NCGMP09—Draft standard format for digital publication of geologic maps, version 1.1, in Soller, D.R., ed., Digital Mapping Techniques ’09—Workshop proceedings: U.S. Geological Survey Open-File Report 2010–1335, p. 93–146, 4 appendixes, accessed February 24, 2011, at https://doi.org/10.3133/ofr20101335.

U.S. Geological Survey National Cooperative Geologic Mapping Program [NCGMP], 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., accessed September 15, 2020, at https://doi.org/10.3133/tm11B10.

Weir, G.W., Ulrich, G.E., and Nealey, L.D., 1989, Geologic map of the Sedona 30′×60′ quadrangle, Yavapai and Coconino Counties, Arizona: U.S. Geological Survey Miscellaneous Investigations Series Map I–1896, scale 1:100,000, accessed February 29, 2020, at https://doi.org/10.3133/i1896.

Wells, R.E., Haugerud, R.A., Niem, A.R., Niem, W.A., Ma, L., Evarts, R.C., O’Connor, J.E., Madin, I.P., Sherrod, D.R., Beeson, M.H., Tolan, T.L., Wheeler, K.L., Hanson, W.B., and Sawlan, M.G., 2020, Geologic map of the greater Portland metropolitan area and surrounding region, Oregon and Washington: U.S. Geological Survey Scientific Investigations Map 3443, 2 sheets, scale 1:63,360, 55-p. pamphlet, accessed February 17, 2021, at https://doi.org/10.3133/sim3443.

Wilkinson, M.D., Dumontier, M., Aalbersberg, I.J., Appleton, G., Axton, M., Baak, A., Blomberg, N., Boiten, J.W., da Silva Santos, L.B., Bourne, P.E., and others, 2016, The FAIR Guiding Principles for scientific data management and stewardship: Scientific Data, v. 3, article 160018, accessed November 12, 2021, at https://doi.org/10.1038/sdata.2016.18.

Wilson, F.H., Hults, C.P., Mull, C.G, and Karl, S.M, comps., 2015, Geologic map of Alaska: U.S. Geological Survey Scientific Investigations Map 3340, 196-p. pamphlet, 2 sheets, scale 1:1,584,000, accessed February 2017, at https://doi.org/10.3133/sim3340.

Wolfe, E.W., 1983, Geologic map of the Arnold Mesa Roadless Area, Yavapai County, Arizona: U.S. Geological Survey Miscellaneous Field Studies Map MF–1577–B, accessed January 20, 2021, at https://doi.org/10.3133/mf1577B.

Yager, D.B., Hofstra, A.H., Fifarek, K., and Webbers, A., 2010, Development of an igneous rock database with geologic functions—Application to Neogene bimodal igneous rocks and mineral resources in the Great Basin: Geosphere, v. 6, no. 5, p. 691–730, accessed November 9, 2018, at https://doi.org/10.1130/GES00516.1.

Abbreviations

DMU

Description of Map Units

DOI

digital object identifier

FAIR

Findable, Accessible, Interoperable, and Reusable

FGDC

Federal Geographic Data Committee

GeMS

Geologic Map Schema

GIS

geographic information system

IMW

Intermountain West

NADM

North American Geologic Map Data Model

NCGMP

National Cooperative Geologic Mapping Program

NGMDB

National Geologic Map Database

SIGMa

Seamless Integrated Geologic Mapping

URL

uniform resource locator

USGS

U.S. Geological Survey

Disclaimers

Any use of trade, firm, or product names is for descriptive purposes only and does not imply endorsement by the U.S. Government.

Although this information product, for the most part, is in the public domain, it also may contain copyrighted materials as noted in the text. Permission to reproduce copyrighted items must be secured from the copyright owner.

Suggested Citation

Turner, K.J., Workman, J.B., Colgan, J.P., Gilmer, A.K., Berry, M.E., Johnstone, S.A., Warrell, K.F., Dechesne, M., VanSistine, D.P., Thompson, R.A., Hudson, A.M., Zellman, K.L., Sweetkind, D., and Ruleman, C.A., 2022, The Seamless Integrated Geologic Mapping (SIGMa) extension to the Geologic Map Schema (GeMS): U.S. Geological Survey Scientific Investigations Report 2022–5115, 33 p., https://doi.org/10.3133/sir20225115.

ISSN: 2328-0328 (online)

Publication type Report
Publication Subtype USGS Numbered Series
Title The Seamless Integrated Geologic Mapping (SIGMa) extension to the Geologic Map Schema (GeMS)
Series title Scientific Investigations Report
Series number 2022-5115
DOI 10.3133/sir20225115
Year Published 2022
Language English
Publisher U.S. Geological Survey
Publisher location Reston, VA
Contributing office(s) Geosciences and Environmental Change Science Center
Description vii, 33 p.
Online Only (Y/N) Y
Google Analytic Metrics Metrics page
Additional publication details