How is a geologic map legend stored as data in GIS?

As a Description of Map Units (DMU) table where each row is one unit, with its label, name, age, rank, color, and pattern. Map-unit polygons reference this table by key, so the legend is generated from the data rather than drawn by hand.

How do I keep map units in correct stratigraphic order in a legend?

Add an explicit ordering field (a HierarchyKey or sort index) to the unit table, because alphabetical or import order does not equal youngest-to-oldest. The legend is then sorted on that field, not on the label.

What color and pattern standards apply to geologic legends?

Many surveys follow standardized schemes such as the international Commission for the Geological Map of the World colors and the USGS FGDC geologic map symbolization for patterns and lithology overlays, so units read consistently across maps.

How do I generate symbology from a map-unit table automatically?

Use a categorized or rule-based renderer keyed on the map-unit field, with fill colors and patterns supplied by the unit table. The legend then updates automatically when a unit's color or definition changes.

Geological Map Legends in Digital GIS Systems

Short answer

In a digital system, a geologic map legend should be data, not decoration. Each map unit lives as a row in a Description of Map Units (DMU) table — label, full name, age, lithology, stratigraphic rank, fill color, and pattern — and the map-unit polygons reference that table by a key. The map's symbology and its legend are then generated from the table, so they stay consistent with each other and update automatically when a unit is corrected. The hard parts are getting stratigraphic ordering right (it is not alphabetical) and applying color and pattern standards so the map reads the way a geologist expects.

The legend is a table, not a graphic

On paper, the legend (the "explanation") is a hand-laid block of colored boxes in stratigraphic order with text. The digital equivalent is the DescriptionOfMapUnits table, a core GeMS object. Modeling it as a table buys three things:

Single source of truth. A unit's age, color, or definition is stored once; every polygon of that unit inherits it. Fixing the color of "Tertiary basalt" is a one-row edit, not a re-style of hundreds of polygons.
Queryability. You can select all units of a given age, rank, or lithology — impossible if the legend is only a static image.
Generated symbology. A categorized renderer keyed on the map-unit field reads colors straight from the table, and the legend block is produced from the same rows in the same order.

A minimal DMU schema:

Field	Example	Purpose
`MapUnit`	Tb	join key to polygons
`Name`	Tertiary basalt	full unit name
`Age`	Miocene	geologic age / span
`RGB`	0/153/76	fill color
`pattern`	igneous overlay code	lithology pattern
`HierarchyKey`	003-002	stratigraphic sort order
`description`	flow basalt, vesicular...	unit text

Stratigraphic ordering: the field everyone forgets

A geologic legend is conventionally listed youngest at the top, oldest at the bottom, with intrusive and special units grouped separately. Software has no idea about this — it will sort alphabetically (Kb before Qal) or by import order, both of which are geologically wrong. You must store the order explicitly.

GeMS uses a HierarchyKey, a dotted/zero-padded string like 001-002-001 that encodes both rank and sequence so a simple text sort reproduces the correct nested legend (eras → systems → units). Even a simpler integer sort_order works for a single map. The rule is: the legend is sorted on the ordering field, never on the label. Without it, a perfectly correct dataset produces a nonsensical legend that no geologist will trust.

Color and pattern standards

Color carries meaning on geologic maps, and consistency across maps matters. Two widely used references:

The Commission for the Geological Map of the World (CGMW) maintains an international color scheme tying chronostratigraphic ages to specific colors (the same palette used by the ICS chronostratigraphic chart). Using it lets a reader recognize "Jurassic" by its color across different maps.
The USGS FGDC Digital Cartographic Standard for Geologic Map Symbolization specifies patterns, line symbols, and lithology overlays (the stipples and hachures that indicate sandstone, limestone, etc.) so that, for example, a fault or an anticline axis looks the same everywhere.

In practice, store the intended color as an RGB (or CMYK) value in the DMU table and, where a lithologic overlay is wanted, store a pattern code that maps to an SVG/symbol fill. That keeps the map both standards-aligned and reproducible.

Worked example: generating symbology and legend from the table

Suppose mapunitpolys joins to dmu on MapUnit.

QGIS. Add a categorized renderer on the MapUnit field. To drive fill from the table's RGB column without hand-picking each class, use a data-defined fill color expression:

color_rgb(
  to_int(regexp_substr("RGB", '^(\\d+)')),
  to_int(regexp_substr("RGB", '/(\\d+)/')),
  to_int(regexp_substr("RGB", '/(\\d+)$'))
)

Then control legend order with the layer's "Legend" settings sorted by HierarchyKey. Pattern overlays are applied as a second symbol layer using an SVG fill keyed on the pattern code.

ArcGIS Pro. Symbolize by Unique Values on MapUnit, import colors from the table, and use the layer's symbology sort to follow the ordering field. The legend element in the layout then mirrors that order.

Because both the polygon fills and the legend draw from the same DMU rows in the same HierarchyKey order, they cannot disagree — which is the whole point.

Linking legend entries to descriptions

A digital legend can do more than a paper one: each entry can link to its full unit description, lithology, age range, and source. In a web map, clicking a unit's legend swatch (or a polygon) surfaces the DMU row. This is only possible because the legend is backed by a table with a stable key — another reason to model it as data rather than baking the explanation into an exported image.

Common pitfalls and why they happen

Hard-coding colors per polygon. Editing becomes a mass re-style and colors drift between polygons of the same unit; drive color from the DMU table instead.
Letting software sort the legend. Alphabetical/import order is not stratigraphic order; without a HierarchyKey the legend is geologically wrong even when the data is right.
Ignoring standard palettes. Ad-hoc colors break cross-map recognition; align to CGMW/ICS where possible.
Exporting the legend as a flat image. Loses the link from swatch to unit description and freezes any later correction.
Mismatched legend and map. Happens when symbology and legend are maintained separately; generating both from the DMU table eliminates it.

QA / validation checklist

Every map unit on the map has a DMU row; every DMU row is used (no orphans either way).
An explicit ordering field (HierarchyKey/sort index) exists and the legend sorts on it.
Colors stored in the table and applied by data-defined/unique-value renderer, not per-polygon.
Standard palette/patterns applied where the survey requires them.
Legend order and symbology both derive from the same table.

Bathyl perspective

A legend that lives as a table is the difference between a map you can maintain and one that quietly rots. We model the Description of Map Units as the single source for color, order, and definition, generate both the symbology and the legend from it, and keep stratigraphic order in an explicit key — so a unit can be corrected once and the whole map, legend included, stays consistent and queryable.

Geological Map Legends in Digital Systems