Short answer

GeMS — the Geologic Map Schema — is the USGS standard data model for publishing and archiving geologic maps as structured data. Instead of treating a geologic map as symbolised geometry plus a legend image, GeMS defines a fixed arrangement of feature classes, non-spatial tables, mandatory fields, controlled vocabularies, and key relationships so that every unit, contact, fault, observation, and source is explicitly recorded and machine-readable. It exists because a geologic map must remain scientifically interpretable decades after the mapping geologist has moved on, and a folder of coloured polygons does not survive that test.

If you are digitising or publishing geology and want it reusable, GeMS gives you the schema that the National Geologic Map Database (NGMDB) and federal mapping programs expect.

The core structure

A GeMS dataset is organised around one feature dataset, GeologicMap, plus a set of related tables. The pieces that matter most:

Required feature classes

  • MapUnitPolys — the polygon coverage of map units. Each polygon carries a MapUnit code (the join key), a DataSourceID, and an IdentityConfidence. The polygon does not store the unit's full description; it points to it.
  • ContactsAndFaults — the linework. A single feature class holds contacts, faults, and other boundary lines, distinguished by a Type field drawn from a controlled vocabulary, plus IsConcealed, ExistenceConfidence, LocationConfidenceMeters, and DataSourceID.

These two carry most of a map's information. Supporting point and line feature classes (OrientationPoints for strike/dip, GeologicLines, MapUnitOverlayPolys, and others) are added when the map needs them.

Required non-spatial tables

  • DescriptionOfMapUnits (DMU) — the heart of the schema. One row per map unit, holding MapUnit, Name, FullName, Age, Description, GeoMaterial, GeoMaterialConfidence, and a hierarchy (HierarchyKey) that encodes the legend order and nesting. This is where lithology, stratigraphic age, and interpretation live as text — not in a colour.
  • DataSources — one row per source, keyed by DataSourceID, so every feature can be traced to where it came from.
  • Glossary — definitions of every controlled term used in Type, confidence, and other vocabulary fields, so the map is self-documenting.

The design principle is normalisation: spatial features stay lightweight and reference rich descriptions through stable keys. A thousand polygons of the same unit all share one DMU row, so editing the unit's age changes it everywhere at once.

Confidence and uncertainty are first-class

A defining feature of GeMS is that uncertainty is encoded explicitly, not left implicit in line styling:

  • ExistenceConfidence / IdentityConfidence — controlled values (typically certain, questionable, or a Glossary term) recording whether a feature exists and whether its classification is sure.
  • LocationConfidenceMeters — a numeric horizontal location uncertainty in metres, so "this fault is mapped to ±50 m" is a queryable value, not a dashed-versus-solid convention a reader has to decode.

This is the difference between a geologic map as a picture and as data: you can filter for all contacts with location confidence worse than 100 m, or all units of questionable identity, because the uncertainty is in fields.

Worked example: implementing the join

The standard relationship you rely on constantly is MapUnitPolys to DescriptionOfMapUnits on MapUnit. In a GIS this drives both labelling and analysis. If you re-implement GeMS in PostGIS, the join is a plain SQL relationship:

SELECT p.geom, p.mapunit, d.name, d.age, d.geomaterial
FROM   mapunitpolys p
JOIN   descriptionofmapunits d USING (mapunit)
WHERE  d.age ILIKE '%Cretaceous%';

To enforce the controlled vocabulary that a geodatabase would handle with a domain, you add a check or a foreign key to a lookup table:

ALTER TABLE contactsandfaults
  ADD CONSTRAINT fk_type
  FOREIGN KEY (type) REFERENCES glossary(term);

Loading an existing GeMS file geodatabase into PostGIS is a straightforward ogr2ogr pass per layer:

ogr2ogr -f PostgreSQL "PG:dbname=geo" map.gdb \
  MapUnitPolys ContactsAndFaults DescriptionOfMapUnits DataSources Glossary \
  -lco SCHEMA=gems -lco GEOMETRY_NAME=geom

GeMS is defined natively against the Esri file geodatabase (which gives you subtypes, domains, and relationship classes for free), but the table-and-key structure transfers cleanly to GeoPackage or PostGIS. What you lose — domains, subtypes — you re-create as lookup tables and constraints.

CRS and scale discipline

GeMS does not prescribe a coordinate system, but the scale of the source mapping must be honoured. A 1:24,000 field map and a 1:250,000 compilation describe boundaries at very different precisions, and LocationConfidenceMeters should reflect that — roughly, location uncertainty scales with map scale (a 0.5 mm pen line at 1:24,000 is about 12 m on the ground). Store the data in a projected CRS appropriate to the area (e.g. the relevant UTM zone, recorded by EPSG code) and never merge mapping of different scales into one feature class without recording the difference in DataSourceID and confidence fields.

Common pitfalls and why they happen

  • Putting the description in the polygon. Storing unit name, age, and lithology as attributes on every polygon instead of in the DMU table denormalises the data and guarantees inconsistency the first time someone edits one polygon and not the others. The join key exists precisely to avoid this.
  • Encoding meaning in colour. Symbology is presentation, not data. If the only place a fault is distinguished from a contact is the line style, the information is lost on export. GeMS forces the distinction into the Type field.
  • Dropping confidence fields. Skipping LocationConfidenceMeters or the existence/identity confidence fields because they are "extra work" discards the uncertainty that makes a geologic map scientifically honest.
  • Mixing scales silently. Compiling a regional map from sources at 1:24,000 and 1:100,000 without recording it produces a map whose precision is wildly uneven and undocumented.
  • Ignoring the Glossary. Using controlled-vocabulary terms without populating the Glossary breaks the self-documenting property; a future reader cannot tell what concealed contact, approximate was meant to mean in this dataset.

Validation

USGS publishes GeMS validation tools (the GeMS Tools toolbox for ArcGIS) that check schema conformance: required fields present, controlled values valid, MapUnit codes in MapUnitPolys all resolving to DMU rows, no orphaned DataSourceID, topology of ContactsAndFaults closed around polygons. Before publication, also run a topology check so that every MapUnitPolys boundary coincides with a ContactsAndFaults line and there are no slivers or gaps. Confirm the CRS is recorded and matches the source scale.

Bathyl perspective

We treat GeMS less as a compliance hoop and more as a discipline that keeps a geologic map queryable: descriptions normalised into the DMU, sources traceable through DataSourceID, and uncertainty stored as numbers rather than line styles. When geology is structured this way, it can be filtered, joined to terrain and geochemistry, and re-interpreted long after the field season — which is the whole reason to digitise it at all.

Related reading

Sources