Appendix 2. Optional Database Elements

Overview

Cross sections and the Correlation of Map Units diagram in a geologic map report may, if present, be encoded as image files. At present, this is the conventional, and quite reasonable, approach. Alternatively, these elements may be encoded within the database as feature datasets, as described below. Encoding them within the database facilitates matching symbolization to the map graphic, facilitates queries and analysis, and eases reuse of these elements. We also define two optional nonspatial tables (MiscellaneousMapInformation and StandardLithology) below.

Cross Sections (Feature Datasets)

If cross sections are included in the database, each cross section should be in a separate feature dataset, as each cross section has its own spatial reference framework. A single cross-section feature dataset should be named CrossSectionA, and its feature-class names should include the abbreviation “CSA” (for example, CSAMapUnitPolys, CSAContactsAndFaults, etc.). Additional cross-section feature datasets should be named CrossSectionB, CrossSectionC, and so on (and abbreviated as “CSB”, “CSC”, etc., in the feature-class names).

Each cross-section feature dataset should have, at a minimum, two feature classes, one for its map units and one for the lines that bound them: for example, CrossSectionA would have CSAMapUnitPolys and CSAContactsAndFaults. The primary-key field for the CSAMapUnitPolys feature class would be CSAMapUnitPolys_ID (values = “CSAMUP1”, “CSAMUP2”, etc.); for CSAContactsAndFaults, it would be CSAContactsAndFaults_ID (values = “CSACAF1”, “CSACAF2”, etc.). Data types, usage, and topology rules for these two feature classes are identical to those for ContactsAndFaults and MapUnitPolys.

If other elements are depicted on the cross section, such as point features or certain line features that do not participate in map-unit topology, then the appropriate feature classes (for example, CSAOrientationPoints, CSAGeologicLines) should be created.

Correlation of Map Units (Feature Dataset)

The Correlation of Map Units (CMU) diagram found on many geologic maps can be encoded as a feature dataset in the database if so desired. The feature dataset should be named CorrelationOfMapUnits, and its feature-class names should include the abbreviation “CMU” (for example, CMUMapUnitPolys, etc.). The CMU dataset should have at least two feature classes (CMUMapUnitPolys, CMULines), and a third (CMUText) will almost always be needed. The additional feature classes CMUMapUnitLines and CMUMapUnitPoints may be needed as well (see discussion below).

CMUMapUnitPolys (Polygon Feature Class)

The CMUMapUnitPolys polygon feature class contains the units within the CorrelationOfMapUnits feature dataset. Table 2–1 describes the fields (and their values) in the CMUMapUnitPolys polygon feature class.

Table 2-1. Fields in CMUMapUnitPolys (a polygon feature class in the CorrelationOfMapUnits feature dataset).
[Abbreviation: CMU, Correlation of Map Units. See also, tables 7, 11, 12, 14]

Field name	Description	Notes
MapUnit	Short, easily understood ASCII-character1 identifier for the map unit represented by this CMU box. Foreign key to DescriptionOfMapUnits table	Examples of values are “Qal”, “Tg”, “Kit”, “Trdu” (see table 11). Use of special characters is discouraged. Null values not permitted
Label	Describes map-unit label for this CMU box. Field from which map-unit label in CMU is generated	May or may not be same as MapUnit value. Allows for special fonts to show geologic age symbols or other non-ASCII characters (see table 11). Generally, is equal to value in DescriptionOfMapUnits table. Null values permitted for unlabeled CMU boxes (for example, ghost boxes)
Symbol	References an area-fill symbol	Area-fill symbols (map-unit color, pattern, or color+pattern) must be included in accompanying .style file. Null values permitted only for CMU boxes that are not filled with color or pattern (for example, ghost boxes)
CMUMapUnitPolys_ID	Primary key	Examples of values are “CMUMUP1”, “CMUMUP2”. Values must be unique in database. Null values not permitted

Outlines of CMU unit boxes may be drawn either by symbolizing the edges of CMUMapUnitPolys polygons or by symbolizing coincident lines recorded in feature class CMULines (see below). Ghost boxes, which are empty CMU boxes sometimes used to depict the protoliths of metamorphic-rock units, may be shown in the CMUMapUnitPolys polygon feature class by setting the Symbol value = “blank” or null. Alternatively, the empty CMU box outlines could be stored alone in the CMULines line feature class, as discussed below.

CMULines (Line Feature Class)

Any brackets, horizontal rules, or leaders (and sometimes, outlines of ghost boxes) in the CMU diagram are stored in the CMULines feature class. Outlines of CMU unit boxes may be stored in this feature class, or they may be the symbolized edges of CMUMapUnitPolys polygons. Table 2–2 describes the fields (and their values) in the CMULines line feature class.

Table 2-2. Fields in CMULines (a line feature class in the CorrelationOfMapUnits feature dataset).
[Abbreviation: CMU, Correlation of Map Units. Content of fields in magenta type (in this case, the Type field) must be defined in Glossary table]

Field name	Description	Notes
Type	Specifies type of line feature represented by this database row	Examples of values are “CMU box border”, “CMU leader”, “CMU rule”, “CMU bracket”. Values must be defined in Glossary table. Null values not permitted
Symbol	References a line symbol	Line symbols must be included in accompanying .style file. Null values permitted
CMULines_ID	Primary key	Examples of values are “CMULIN1”, “CMULIN2”. Values must be unique in database. Null values not permitted

The CMUMapUnitPolys polygon feature class contains the units within the CorrelationOfMapUnits feature dataset. Table 2–1 describes the fields (and their values) in the CMUMapUnitPolys polygon feature class.

Outlines of CMU unit boxes may be drawn either by symbolizing the edges of CMUMapUnitPolys polygons or by symbolizing coincident lines recorded in feature class CMULines (see below). Ghost boxes, which are empty CMU boxes sometimes used to depict the protoliths of metamorphic-rock units, may be shown in the CMUMapUnitPolys polygon feature class by setting the Symbol value = “blank” or null. Alternatively, the empty CMU box outlines could be stored alone in the CMULines line feature class, as discussed below.

CMUMapUnitLines and CMUMapUnitPoints (Optional Line and Point Feature Classes)

If map units have been depicted on the map graphic as line or point features because they are too small to show at the map scale, they will need to be depicted in the CMU that way as well. If such is the case, then feature classes CMUMapUnitLines and (or) CMUMapUnitPoints are needed. A CMUMapUnitLines feature class should have an _ID field named CMUMapUnitLines_ID, and the Symbol field should reference a line symbol. Other field names, values, and usage should be identical to those shown in table 2–1. Similarly, a CMUMapUnitPoints feature class should have an _ID field named CMUMapUnitPoints_ID, and the Symbol field should reference a point symbol. Other field names, values, and usage should be the identical to those shown in table 2–1.

CMUText (Annotation Feature Class)

Annotation text in the CMU, as well as annotation attributes such as font, font size, font effects, and text angle, are stored in the CMUText annotation feature class. Esri’s ArcGIS dictates the fields for this type of feature class; thus, they are not described here.

MiscellaneousMapInformation (Nonspatial Table)

Most published map reports have a significant amount of miscellaneous information printed in the collar area around the map (that is, the map margin). Such miscellaneous information may include the title, authorship, publication date, publishing agency, publication series and number, scale, geologic mapping credit, data-compilation credit, GIS database and cartography credit, editing credit, cartographic-production credit, manuscript approval date, local magnetic declination, base-map information, trade-name and other disclaimers, publication URL, International Standard Serial Number(s) (ISSNs),¹⁴ and suggested citation. This information is helpful for a full understanding of the associated database and could be captured in the database in the MiscellaneousMapInformation table.

A common characteristic of these map marginalia is that they are single statements that apply to the map as a whole; accordingly, information can be harvested from the MiscellaneousMapInformation table to populate formal metadata. However, the details of this information can vary from map to map and from agency to agency, and so we do not attempt to prescribe which map properties should be encoded in the table nor what they should be named. Table 2–3 describes the fields (and their values) in a MiscellaneousMapInformation table.

Table 2-3. Fields in MiscellaneousMapInformation (a nonspatial table).

Field name	Description	Notes
MapProperty	Name of map property	Examples of values are ”scale”, “authors and affiliations”, “magnetic declination”, “date of approval”. Null values not permitted
MapPropertyValue	Value of map property	Examples of values are “1:24,000”, “G.S. Smith1 and J. Doe2, 1-Division of Geology, Some State, 2-Big University”, “16.5 degrees”, “approved for publication on 23 September 2017”. Null values not permitted
MiscellaneousMapInformation_ID	Primary key	Examples of values are “MMI01”, “MMI03”. Values must be unique in database. Null values not permitted

StandardLithology (Nonspatial Table)

A mapmaker may choose to provide descriptions of map units that are more detailed than the GeoMaterial values and more structured than the free-text in the Description field in the DescriptionOfMapUnits table. StandardLithology (described in table 2–4) provides a structure for such descriptions of geologic map units.

Table 2-4. Fields in StandardLithology (a nonspatial table).
[Abbreviation: CGI, Commission for the Management and Application of Geoscience Information. Content of fields in magenta type (in this case, the ScientificConfidence field) must be defined in Glossary table. See also, tables 11, 14, 2–5]

Field name	Description	Notes
MapUnit	Short, easily understood ASCII-character1 identifier for the label for this map unit. Foreign key to DescriptionOfMapUnits table	Examples of values are “Qal”, “Tg”, “Kit” (see table 11). Null values not permitted
PartType	Indicates how lithology is found within this map unit. Domain is CGI’s Geologic Unit Part Role vocabulary (available at http://resource.geosciml.org/def/voc/)	Examples of values are “blocks”, “marker bed”, “inclusion”, “dike”. Null values not permitted
Lithology	Indicates lithology found within this map unit. Domain is CGI’s Simple Lithology vocabulary (available at http://resource.geosciml.org/def/voc/)	Examples of values are “limestone”, “basalt”, “carbonate-rich mudstone”, “monzodiorite”. Null values not permitted
ProportionTerm	Indicates proportion (as qualitative term) of this map unit in which lithology is found. Recommended domain is CGI’s Proportion Term vocabulary (available at http://resource.geosciml.org/def/voc/); however, map producers may wish to restrict vocabulary to a shorter and less expressive, but easier to use, list (see discussion in text below)	Examples of values are “dominant”, “variable”, “rare”. Null values permitted; however, value in either ProportionValue or ProportionTerm should be non-null
ProportionValue	Indicates proportion (as numeric value) of this map unit in which lithology is found	Data type = float. Values must range between 0 and 1.0; note that values must not sum to more than 1.0 for a given map unit. Null values permitted; however, value in either ProportionValue or ProportionTerm should be non-null
ScientificConfidence	Indicates how confidently existence and identity of lithology is identified as being found within this map unit	Examples of values are “existence certain”, “identity uncertain”. Values must be defined in Glossary table. Null values not permitted; suggest setting default value to “existence and identity certain”
DataSourceID	Identifies source of StandardLithology description. Foreign key to DataSources table	Null values not permitted
StandardLithology_ID	Primary key	Example values are “STL1”, “STL2”. Values must be unique in database. Null values not permitted

Alternatively, a mapmaker may choose to create a table (form not specified here) for lithologic classification that best suits the geology of the map area and the intended audience. Such a table could differ significantly from StandardLithology.

The StandardLithology table represents the lithologic composition(s) of map units by associating the unit with one or more lithology categories from CGI’s¹⁵ “Simple Lithology” controlled vocabulary (available at http://resource.geosciml.org/def/voc/; see discussion in the “GeoMaterial Terms” section, in appendix 1 above).

Note that descriptions for a single map unit may span several rows in this table. This allows the description of multipart (for example, interbedded) units using a quantitative or qualitative description of the relative abundance of each component. Each associated lithology category has a PartType field that indicates how the rock type is found within the unit (for example, vein or dike lithosome, layer lithosome, stratigraphic part, inclusion, blocks, etc.) and either a ProportionTerm field (a qualitative term) or a ProportionValue field (a numeric value) that indicates its proportion within the unit.

For values in the ProportionTerm field, CGI’s Proportion Term list (available at http://resource.geosciml.org/def/voc/) is recommended. But for parsing certain map-unit descriptions, especially those for already compiled and published maps, into a controlled-term list, a simpler list of proportion terms whose definitions are less precise may be more appropriate, particularly the case in which the percentage proportions, especially among the dominant lithologic constituents, cannot readily be determined. Such a list might include the following proportion terms (highlighted in bold type):

• all – the lithology constitutes all of the map unit
• major – the lithology is a major or significant component of the map unit
• minor – the lithology is a minor or relatively insignificant component of the map unit
• trace – the lithology is present but is a very small component of the map unit

Table 2–5 lists some examples of StandardLithology records. Use either the ProportionTerm field or the ProportionValue field as appropriate; note that, for a given record, only one value is permitted to be null. The ProportionValue values are fractional, ranging between 0.0 and 1.0; for a single map unit, these values should sum to no more than 1.0.

Table 2-5. Examples of records in a StandardLithology table.
[Each row represents separate data instance. Values in PartType, Lithology, and ProportionTerm fields are from CGI’s (Commission for the Management and Application of Geoscience Information’s) Geologic Unit Part Role, Simple Lithology, and Proportion Term vocabularies, respectively (available at http://resource.geosciml.org/def/voc/). See also, table 2–4]

Field name
StandardLithology_ID	MapUnit	PartType	Lithology	ProportionTerm	ProportionValue
STL026	Tx	Bed lithosome	Generic sandstone	Dominant
STL327	Tx	Stratigraphic part	Siltstone	Minor
STL579	Tx	Stratigraphic part	Chalk	Minor
STL264	Txt	Bed lithosome	Siltstone	Dominant
STL265	Kit	Only part	Tonalite	Dominant
STL266	KJz	Bed lithosome	Limestone	Dominant	.55
STL770	KJz	Bed lithosome	Generic mudstone	Subordinate	.45

If you generate records in a StandardLithology table by interpreting map-unit descriptions in an existing map or database, we recommend that you set the DataSourceID value to point to an entry in the DataSources table, such as “DAS2”, Source = “Smith, J.G., 1899, Geologic map of XYZ quadrangle: USGS GQ 9999, scale 1:125,000. Georeferenced and digitized by authors of this report”, or something similar (see table 6).

Deprecated Nonspatial Tables

The NCGMP09 v.1.1 (U.S. Geological Survey National Cooperative Geologic Mapping Program, 2010) specification described the optional nonspatial tables ExtendedAttributes and GeologicEvents, which could be used to specify arbitrary properties and their values for any feature in the map database, as well as to attach multiple ages to map units or map features. To our knowledge, these tables were rarely, if ever, implemented; therefore, they have been omitted from this GeMS specification. If map authors or publishers wish to encode multiple ages or to link otherwise unspecified attributes to some items within the database, they may consult the NCGMP09 v.1.1 documentation and specification.

Reference Cited in Appendix 2