Appendix 4. Frequently Asked Questions (FAQs)

How do I get started?

Scripts to create an empty GeMS database, to validate the GIS files and contents of the GeMS tables, and to export shapefile versions of the GeMS database are available at https://ngmdb.usgs.gov/Info/standards/GeMS/. The GeMS website also includes general guidance and examples of geologic maps published in the GeMS schema. Additional software tools and guidance are available at the GeMS Toolkit sites on GitHub (https://github.com/usgs/GeMS_Tools and https://github.com/usgs/gems-tools-pro).

I am publishing a new visualization of previously published digital geologic map data. Does this standard apply?

It could. However, GeMS was designed to apply to new geologic maps and to digital transcriptions (automations) of geologic maps that have previously been published in analog (paper or PDF) form. It has less applicability to new visualizations of previously published maps. (See discussion in objective section.)

How should I encode structure contours?

You have at least two choices:

1. Structure contours may be encoded in an IsoValueLines feature class (for example, Type = “top <Formation X>”, or whatever is being contoured), along with a corresponding entry in the Glossary table for “top <Formation X>” that clearly defines the contoured surface. The Glossary table entry should also define the units used for the Value field (for example, meters above NAVD88) and the ValueConfidence field (for example, meters).
2. Alternately, you could create a new, appropriately named line feature class (for example, StructureContourLines) and an elevation attribute.

Generally speaking, we have found that contours are difficult to analyze automatically. The information contained in structure contours might be better stored in a raster (Esri grid) or triangulated irregular network (TIN) format.

How do I represent dikes?

Dikes are intrusive bodies of rock that have a finite extent. Again, you have several choices:

1. If the map is at a large enough scale and the mapping is detailed enough, dikes may be represented as (a) polygons (in the MapUnitPolys feature class) of a particular map unit (MapUnit = “Tvd”), as defined in the DescriptionOfMapUnits table, and (b) contacts (in the ContactsAndFaults feature class) that bound the polygons. This representation works well for wide dikes and large map scales; as the scale decreases and the dikes narrow, this representation does not work well.
2. Dikes that are (effectively, usually at smaller scales) too narrow to show as a polygon at the scale of the map graphic but are part of a map unit described in the DMU may be represented in a MapUnitLines feature class.
3. Dikes that are (effectively, usually at smaller scales) too narrow to show as a polygon at the scale of the map graphic and are not part of a map unit described in the DMU may be represented as line features (Type = “dike” or, perhaps, Type = “Tertiary andesite dike”) in the GeologicLines feature class. Alternatively, they could be included in a DikesAndSills feature class.

How do I represent other small bodies of rock?

Small areas of a distinct rock type (for example, intrusive necks, limestone blocks in a continental-slope olistostrome, blueschist knockers in mélange) present similar choices as dikes, depending on scale:

1. You could represent them as small polygons in the MapUnitPolys feature class, bounded by contacts and (or) faults in the ContactsAndFaults feature class.
2. You could represent them as points in the MapUnitPoints feature class.
3. You could represent them as points (for example, Type = “intrusive neck” or “limestone block”) in a GeologicPoints feature class.

What about bedrock contacts under alluvium?

There are several options, all of which are valid in GeMS:

1. Show concealed (dotted) bedrock contacts within alluvium (MapUnit = “Qal”; Name = “alluvium”; fill color, yellow). No feature in the database directly records the nature of the underlying bedrock; the map user does the implicit analysis, extrapolating from the adjoining mapped bedrock units, to figure out which bedrock units underlie the alluvium. This is the simplest, most commonly implemented option.
2. If the map is a bedrock map, show the bedrock polygons and color them appropriately. Show the contacts between bedrock units as unconcealed (solid or dashed) contacts. Use an overlay polygon (perhaps symbolized with yellow dots or yellow diagonal lines) to show the extent of the overlying alluvium. If alluvium is described as a map unit in the Description of Map Units (DMU), the overlay is a polygon in the MapUnitOverlayPolys feature class (MapUnit = “Qal”), and “Qal” is defined in the DescriptionOfMapUnits table. If alluvium is described as a symbol in the Explanation of Map Symbols, the overlay is a polygon in the OverlayPolys feature class (Type = “alluvium”), and the term “alluvium” is defined in the Glossary table.
3. If the map is not a bedrock map, but one of the important bedrock units (important because it hosts economic silver mineralization) is covered by alluvium. You want the map user to immediately see where that bedrock unit is present, even where it is covered by alluvium. Show the buried bedrock contacts as concealed (dotted) lines and the alluvium as a yellow-filled polygon, as in option 1 (MapUnit = “Qal”; Name = “alluvium”); where the bedrock unit is present beneath alluvium, show a pattern (perhaps, fat diagonal dashed pink lines). You may think of this pattern as an underlay because it shows the map unit that underlies the alluvium, but cartographically (and in the database) it is an overlay pattern. Thus, the patterned area needs to be recorded as a polygon in one of the two ways that are discussed in option 2, either in the MapUnitOverlayPolys feature class (and defined in the DescriptionOfMapUnits table) or in the OverlayPolys feature class (and defined in the Glossary table).
4. Make a stack-unit map in which labels for both the overlying unit (for example, Qal) and the underlying unit (for example, Jm) are shown, separated by a slash. As an example, polygon Qal/Jm is adjacent to polygon Qal/Jk. There are several ways to symbolize the polygons and their bounding contacts, but we won’t go into them here (the geologic mapping community as a whole lacks sufficient experience with such maps to prescribe how it should be done). See the next FAQ for suggestions as to how to encode a stack-unit map.

How do I encode a stack-unit map? That is, I’d like to represent bedrock and overlying surficial geology in the same GeMS database. How might I do this?

There are several ways this could be done:

1. MapUnitOverlayPolys. The GeologicMap feature dataset contains a continuous representation of bedrock geology (that is, all areas are mapped). Within the GeologicMap feature dataset, surficial units are represented as a potentially discontinuous set of polygons within a MapUnitOverlayPolys feature class.
   Advantages.—This is a simple solution in GeMS and is easily implemented.
   Disadvantages.—There is no place to store information about the contacts that separate units within MapUnitOverlayPolys. Current GeMS tools do not examine topology of MapUnitOverlayPolys. It may not be obvious to the casual database user that MapUnitOverlayPolys contains a representation of surficial geology.
2. Stack-unit map. Kempton (1981) and Berg and Kempton (1988) described a protocol for multilayer maps of near-surface materials. These stack-unit maps are an elegant way to represent our knowledge of multilayered surficial geology while not requiring complete specification of three-dimensional (3D) geometry. Essential aspects of a stack-unit map include the following:
• A stack-unit map is logically a one-layer map
• A stack-unit map describes geology down to a prescribed, commonly shallow, depth (for example, 15 m)
• Each stack-unit polygon is characterized by a stack of concatenated standard map units—for example, stack-unit Qp/Qvt/Qva indicates peat (Qp) overlying Vashon Till (Qvt) overlying Vashon-age advance-outwash deposits (Qva). The individual map units are termed sublayers. To capture this, the MapUnit field in MapUnitPolys must be replaced with a StackUnit field
• If a sublayer is patchy (or its existence is uncertain), surround the sublayer unit label with parentheses—for example, stack-unit Qp/(Qvt)/Qva indicates that Vashon Till (Qvt) distribution is patchy
• To indicate sublayer thickness, append a number to the sublayer unit symbol—for example, stack-unit Qp2/Qvt3/Qva indicates that 2 m of peat (Qp) overlies 3 m of Vashon Till (Qvt)
• The stack-unit protocol, including the depth of depiction, use of parentheses, and thickness measures, should be described in the database-level metadata
• Some surface contacts will be scratch boundaries where the topmost unit is the same on both sides but a lower layer pinches out
• Implementing a stack-unit map in a GeMS-like database requires a nonspatial junction table that ties the StackUnit field to the MapUnit field in the DescriptionOfMapUnits table (see figure 4–1)
  Advantages.—This stack-unit protocol is well adapted to the limitations of much subsurface information.
  Disadvantages.—Requires the creation of a new nonspatial table (StackUnitsToMapUnits) and modification of the MapUnitPolys feature class. Substitution of the StackUnit field for the MapUnit field in the MapUnitPolys feature class leads to a database that adheres closely to the spirit of the GeMS schema but is not strictly GeMS compliant.


Figure 4-1. GeMS implementation of a stack-unit map. A, Part of a map that shows geologic materials to a depth of 20 ft, in the Pingree Grove 7.5-minute quadrangle, Illinois (Kempton, 1981, his fig. 6). B, Corresponding parts of the GeMS tables MapUnitPolys, StackUnitsToMapUnits, and DescriptionOfMapUnits, showing relations that tie values of StackUnit in feature class MapUnitPolys to their constituent MapUnit entries in the nonspatial table DescriptionOfMapUnits. Note that, in StackUnitsToMapUnits, all values of Modifier are <null>; in other locations on this map, values are, for example, “patchy” or “3 ft thick”. Click the figure to enlarge.

3. Surficial and bedrock attributes for each polygon. Add BedrockMapUnit and SurficialMapUnit fields to the MapUnitPolys feature class. Populate as appropriate; for each polygon, either the BedrockMapUnit value or the SurficialMapUnit value will be equal to the MapUnit value. To produce a surficial map, access (by coloring or querying on) the SurficialMapUnit field; to get a bedrock map, access the BedrockMapUnit field; or to get a generalized geologic map that incorporates some bedrock and some surficial geology, access the MapUnit field. The Geologic Map of Alaska (Wilson and others, 2015) uses a schema similar to this.
   Advantages.—Can be GeMS compliant.
   Disadvantages.—Requires processing to calculate which polygon-bounding contacts should be drawn and how they should be drawn—for example, on a surficial map, as dotted contacts for polygons that have identical surficial units but different bedrock units, or, on a bedrock map, as scratch boundaries for polygons that have different surficial units over the same bedrock unit. Such processing can be automated, and the results could be stored as additional attributes of the ContactsAndFaults feature class. Such extensions to the GeMS schema should be clearly documented in associated database-level metadata.
4. Multipatch map. “Multipatch” is the Esri term for a GIS object that consists of a collection of planar patches that represent the boundary of a 3D solid. Like polygons, lines, and points, multipatches are stored in a feature class and may have nonspatial attributes. In a 3D (multilayer) geologic map, constituent multipatches should be adjoining, without gaps or overlaps.
   Advantages.—A GeMS-compliant 3D database can be created simply by making MapUnitPolys with the geometry type “MULTIPATCH”. This schema allows for complete representation of subsurface-unit geometry.
   Disadvantages.—Esri software is currently unable to enforce appropriate topology for a multipatch feature class or to easily create and edit multipatch features. If a multipatch schema is desirable, geometries will likely be generated within other software and then translated into an Esri database. Implementing a 3D analog of ContactsAndFaults requires a geometry type that is not currently supported by Esri software. Specification of a multipatch geologic map requires a density of subsurface information that is rarely available outside of the mineral and hydrocarbon exploitation realms.
5. Multidataset map. Each layer in a multilayer map (for example, a surficial layer, a stratified-bedrock layer, and a crystalline-basement layer) is essentially a separate geologic map and, thus, is stored in a separate feature dataset. To preserve GeMS compliance, one of these feature datasets should be named GeologicMap. Others could be named, for example, SurficialGeologicMap or BasementMap. Each feature dataset contains (at a minimum) feature classes xxxMapUnitPolys and xxxContactsAndFaults, where xxx is a prefix that identifies the enclosing feature dataset (for example, Layer1). By convention, each feature dataset (layer) has the same map extent. Where material of a layer is not present, set MapUnit = “not present”. A contact between a “not present” polygon and other map units is a layer pinch-out line, where the layer above (if present) and the layer below come in contact. Some polygons may have MapUnit = “unmapped area”. All layers share DataSources, DescriptionOfMapUnits, GeoMaterialDict, Glossary, and MiscellaneousMapInformation tables. Optionally, the database may contain an elevation surface (raster, TIN, or contours) for the top of each layer. If Layer1 MapUnit = “not present”, the elevations of Layer1 and Layer2 are the same. Layer order, elevation-surface names, and layer descriptions are recorded in the nonspatial table LayerList (see table 4–1).

Table 4-1. Examples of selected fields (and their values) in LayerList (a nonspatial table), which organizes and describes datasets within a multidataset map.

Order from top	Feature dataset name	ElevationObject	Description	LayerList_ID
1	SurficialMap	QuadXX_LidarDEM	Unconsolidated-deposit geology at Earth surface	LL1
2	GeologicMap	<null>	Bedrock geology	LL2
3	UpperMantleMap	MohoContours	Tomographically guesstimated upper mantle geology	LL3

6. Advantages.—Builds on single-layer GeMS database and honors GeMS’ expectations for internal metadata. Existing GeMS tools should work with few or no modifications. The schema looks like the real world (in some regions) where deposits of different geologic episodes are separated by significant unconformities.
   Disadvantages.—Does not describe map-unit boundaries within a layer but, rather, only at the top of a layer (though this may be a strength). Inclusion of layer-top-elevation raster data may create unacceptably large databases.

Such multilayer maps do not replace stack-unit maps with their useful ambiguity about thicknesses and extents of subsurface materials. Nor do they replace multipatch-like maps with their explicit depiction of 3D contacts and map-unit volumes. The USGS–AASG–DMT geologic mapping community does not have sufficient experience with these (and other) options to recommend a particular choice. In general, when deciding amongst options, the mapmaker should consider several questions:

1. Are sufficient data available to populate the chosen schema? Traditional two-dimensional geologic maps are descriptions of a fundamentally three-dimensional world, using a set of conventions (map units on the surface, ornamented line symbols that portray the geometry of line features, and explicit or implicit information about the dip of strata) that capitalizes on known surface outcrops and requires few, if any, statements about unobserved subsurface phenomena. Geologists have always desired an explicit 3D representation of the world, but in many instances there are not sufficient data to warrant publishing one.
2. Are naming conventions and documentation clear enough that others will be able to use the dataset? A GeMS map benefits from the availability of GeMS documentation. Extensions to the schema must have names that make their purpose obvious and be well documented in associated metadata.
3. Is it desirable to symbolize the map with surficial geology draped over (and, therefore, obscuring) bedrock geology? The ease of collapsing layers and defining appropriate contact symbolization varies significantly among these schemas.
4. Is the layer-cake approximation intrinsic to multilayer schemas appropriate? For much of North America it is, as a profound regional unconformity separates surficial deposits from significantly older sedimentary and volcanic rocks, which themselves unconformably overlie crystalline bedrock. But, for some areas of the continent, it is not.

How do I encode a three-dimensional (3D) geologic map?

ArcGIS, along with most other GIS software, is not designed to handle 3D (volume) data. See the preceding question for approximations that may be useful. In the future, consideration will be given to more fully adapting GeMS for 3D information.

The Notes field is empty for all records in my ContactsAndFaults feature class. May I delete this field?

Yes, the Notes field is always optional and may be deleted if desired.

What about my fault map? It doesn’t show geologic map units.

Strictly speaking, a fault map is not a geologic map, so GeMS does not fully apply. Most fault maps, however, are analogous to certain parts of a geologic map, and so this standard can provide useful guidance. For example, faults could be encoded in the GeologicLines feature class and its associated tables.

May I give the map database to users in another format?

Certainly. But also make the GeMS format available.

My report has an auxiliary map that shows the distribution of sedimentary facies in the Miocene. Where does this map fit in this design?

The answer varies; use your judgment. Not all information depicted in an auxiliary map needs to be a separate digital map (in other words, a separate feature dataset), although that is an acceptable approach. Alternatively, the distribution of Miocene sedimentary facies could be (1) encoded in an optional ExtendedAttributes table for the polygons that represent Miocene sedimentary rocks, (2) portrayed as overlay polygons (in the OverlayPolys feature class), or (3) added as a new polygon feature class. If the map is not complex, then an image of the sedimentary-facies map may suffice.

How can I tell if a database is GeMS-compliant?

The script GeMS_ValidateDatabase_Arc10.py or its replacement (available at the GeMS toolkit sites on GitHub; see https://github.com/usgs/GeMS_Tools and https://github.com/usgs/gems-tools-pro) tests compliance to the GeMS schema. This script checks that (1) the required tables and feature classes are present, (2) all tables and feature classes (both the required ones and any others defined in this schema) have the required fields and field characteristics, (3) non-null values are present in all the fields in which they are required, (4) all tables and feature classes have an xxx_ID field (a user-controlled primary key), (5) the values in the xxx_ID field (primary keys) are unique within the database, (6) all values in the xxxSourceID field have corresponding entries in the DataSources table, (7) no unreferenced entries are in the DataSources table, (8) all values in the Type, IdentityConfidence, and ExistenceConfidence fields have corresponding entries in the Glossary table, (9) no unreferenced entries are included in the Glossary table, (10) no false null values (that is, no empty or whitespace strings) are present, (11) values of the MapUnit field in the MapUnitPolys feature class (and in the CMUMapUnitPolys and any CSxMapUnitPolys [for cross sections] feature classes, if present) correspond to values in the DescriptionOfMapUnits table, and (12) values of the HierarchyKey field in the DescriptionOfMapUnits table are well structured.

The script GeMS_TopologyCheck_Arc10.py (also available at the GeMS toolkit sites on GitHub) or its replacement provides additional checks for both automation errors and (potentially) geologic blunders. This script builds and evaluates an ArcGIS topology using the following rules: (1) no overlaps, self-overlaps, or self-intersections are in the ContactsAndFaults feature class, (2) no gaps or overlaps are in the MapUnitPolys feature class, and (3) all boundaries in the MapUnitPolys feature class are covered by (that is, exactly coincident with) lines in the ContactsAndFaults feature class. The script also evaluates node topology, summarizes the map units that bound lines in the ContactsAndFaults feature class, and checks for duplicate point features. Note that results of the GeMS_TopologyCheck_Arc10.py script should be taken with a grain of salt, as some issues flagged by this script may not be errors.

What about annotation?

There are multiple ways to create and store annotation. We are not sure what data structure will best facilitate publication-quality cartography and allow for the economical creation and editing of annotation (and leaders), and so we have not prescribed a protocol for annotation. Map authors may wish to create one or more Esri annotation feature classes to store their annotation, along with instructions on how to use them.

How do I use a GeMS-compliant database to make a publication-quality map graphic?

The answer to this question is not trivial, but by standardizing the database design, we hope to see the emergence of tools from the community to provide answers. The following are some suggestions:

1. Use high-quality symbology such as that contained in the ArcGIS .style file FGDC_GSC_20100414.style, prepared by the Geological Survey of Canada (see discussion in the “Symbolization” section, in the main document above).
2. Create visually pleasing symbolization of highly segmented faults that have complex line ornamentations (for example, sawteeth on thrust faults) by making continuous, throughgoing fault traces (known as metafaults in GIS jargon, these are analogous to routes in Workstation ArcInfo), in order to reduce or eliminate overcrowding of line ornamentations. To do this, draw individual fault segments using thick (fault-weight) solid, dashed, or dotted line symbols, as appropriate, without the sawteeth; merge these line segments into metafaults and then smooth (generalize, spline) them; then draw the smoothed metafaults using the sawteeth only, without the line stroke.
3. Create effective annotation (see previous FAQ for discussion on annotation). Map-unit symbols, dip and plunge values for measured orientations, text associated with line features or other types of point data, and place names all may need to be repositioned, duplicated, or eliminated to create a legible map graphic. Some map-unit labels may need to have leaders added. Note that at this time we are not aware of any tools that can successfully automate this task.
4. To the greatest extent possible, prepare as much of the map (inside the neatline) as is possible in ArcMap. Avoid cartographic work inside the neatline using desktop publishing software such as Adobe Illustrator, as doing so increases the likelihood of synchronization problems between the geology portrayed on the map and that which is recorded in the database.
5. Prepare the layout of the map sheet (outside the neatline) using desktop publishing software, as text formatting and figure placement are much easier than doing so in ArcMap.

I don’t know what metadata for a geologic map should look like. What should I do?

Please refer to USGS’s website on formal, FGDC-compliant metadata (see https://geology.usgs.gov/tools/metadata/).

Who is going to enforce the use of GeMS?

When GeMS is fully adopted by the National Cooperative Geologic Mapping Program, conformance will be required upon delivery of products funded by the Program. If widely adopted, users will demand conformance so that tools developed to manipulate the databases work properly.

References Cited in Appendix 4