The short version
A geological map QA pass is the structured review you run before a digital geologic map leaves your hands. It checks four things that scanned-image maps never had to worry about: that polygon and line geometry is topologically clean, that every feature carries complete and controlled attribution, that the coordinate reference system and generalization match the source scale, and that the legend you publish is generated from the data rather than drawn by hand. Skip any of these and the map will still render fine on screen while quietly failing the moment someone queries it, overlays it, or measures from it.
The rest of this article is the checklist itself, organized so you can run it top to bottom on a GeMS-style map in QGIS or ArcGIS Pro.
Topology: the polygons and the lines must agree
A geologic map is two coupled layers — map-unit polygons and the contacts and faults that bound them — and the single most common defect is that they drift out of agreement. Three failure modes dominate:
- Gaps between adjacent polygons, which leave slivers of "no unit" along a contact.
- Overlaps, where two units claim the same ground.
- Dangles and unsnapped nodes on the line layer, where a fault stops just short of the contact it should terminate against.
In QGIS, enable the Topology Checker plugin and configure rules per layer: on MapUnitPolys add must not have gaps and must not overlap; on ContactsAndFaults add must not have dangles and end points must be covered by the polygon boundaries. Run it, then walk the error list — do not trust a zero-error result without spot-checking, because the checker only flags the rules you gave it. Set the snapping tolerance before you ever start editing (typically a few map units, e.g. 5 m in a UTM project at 1:24,000) so nodes coincide exactly rather than approximately. In ArcGIS Pro the equivalent is a geodatabase topology with the Must Not Have Gaps and Must Not Overlap rules validated across the feature dataset.
A subtler topology problem is the shared-boundary mismatch: the polygon edge and the contact line are two separate geometries that are supposed to be coincident but were edited independently. The fix is discipline at digitizing time — trace polygons from the contact layer, or derive polygons from closed linework — rather than QA after the fact.
Attribution: every feature must say what it is and how sure you are
This is where digital geologic maps earn their keep, and where the USGS GeMS schema (Geologic Map Schema) gives you a concrete target. At minimum:
- Each polygon in
MapUnitPolyscarries a MapUnit code that resolves to a row in the DescriptionOfMapUnits (DMU) table. No orphan codes, no blanks, no "tbd". - Each line in
ContactsAndFaultscarries a Type (contact, normal fault, thrust fault, etc.), an IsConcealed flag, and a LocationConfidenceMeters value — the horizontal uncertainty of the line's position, expressed as a real number in meters (e.g. 25, 100, 250), not a vague word. - Confidence on interpretation is split into ExistenceConfidence and IdentityConfidence, each drawn from a controlled vocabulary (typically "certain" / "questionable").
- Every feature points to a DataSourceID that resolves to a row in the DataSources table.
The QA action is a set of attribute audits. Run a query for MapUnit IS NULL OR MapUnit = '' and expect zero rows. Run a join from MapUnitPolys.MapUnit to DescriptionOfMapUnits.MapUnit and flag any code that fails to match. Confirm LocationConfidenceMeters is numeric and non-null on every line. In PostGIS these become trivial SELECT statements; in QGIS use the Field Calculator and the Select by Expression dialog. The point is to enforce the controlled vocabulary by query, because the human eye will not catch a single mistyped unit code among 400 polygons.
CRS, scale, and generalization
Check that the working CRS is a projected system appropriate to the area and to measurement — a UTM zone (e.g. EPSG:32613 for UTM 13N / WGS84) or a State Plane zone — and not unprojected geographic WGS84 (EPSG:4326), in which a "length" calculation returns degrees. Confirm every layer in the project shares that CRS rather than relying on on-the-fly reprojection that masks a mislabeled source.
Then check scale fidelity. A map compiled at 1:24,000 has a real horizontal resolution on the order of the line weight times the scale; digitizing contacts to sub-meter wiggle on a 1:100,000 source is fabricating precision the data does not have. The QA question is whether the vertex density and the LocationConfidenceMeters values are honest about the source. Note the source scale in the metadata and keep it visible.
Legend and symbology must come from the data
A frequent failure is a legend that no longer matches the polygons — a unit was merged or renamed in the data but the static legend image was never updated. Generate the legend from the DMU table and the layer symbology so the two cannot diverge. Verify that the map-unit color and pattern assigned in symbology key off the MapUnit field, that the unit ordering in the legend follows stratigraphic age (youngest at top), and that fault and contact line symbols (dashed for approximate, dotted for concealed, teeth/ticks for thrusts and normal faults) are driven by the Type and IsConcealed attributes rather than applied by hand to individual features.
A short worked pass
For a 1:24,000 quadrangle delivered as a GeoPackage:
ogrinfo -so map.gpkg MapUnitPolys— confirm geometry type (Multi Polygon), feature count, and the CRS line shows the expected EPSG code.- In QGIS, run Topology Checker (gaps, overlaps on polygons; dangles on lines). Resolve every flag.
- Select by Expression
"MapUnit" IS NULLon polygons and"LocationConfidenceMeters" IS NULLon lines — both must return empty. - Join polygons to the DMU table; inspect unmatched codes.
- Confirm
DataSourcesis populated and everyDataSourceIDresolves. - Regenerate the legend and compare unit list to distinct MapUnit values in the data.
- Export and re-open the export to confirm CRS, attributes, and symbology survived the round trip.
Common pitfalls and why they happen
- "It validated, so it's clean." Topology Checker only tests the rules you added; a missing must not overlap rule means overlaps go unreported. The cause is treating the tool as a verdict rather than a configurable test.
- Confidence stored as words in a notes field. Reviewers want to filter and symbolize by confidence; free text cannot be queried. GeMS exists precisely to replace prose with controlled, numeric fields.
- Shapefile round-tripping that truncates field names to 10 characters and silently renames
LocationConfidenceMeters. Keep the master in GeoPackage or a geodatabase; treat shapefile as export-only. - Legend drift after a last-minute unit merge, because the legend is a separate artifact. The fix is data-driven symbology.
Validation summary
Before sign-off you should be able to answer: zero topology errors on both layers; zero null or orphan MapUnit codes; numeric confidence on every line; a single, correct projected CRS across all layers; a populated DataSources table with no broken links; and a legend regenerated from the data. Record the result and the source scale in the metadata so the next reviewer inherits the audit rather than repeating it.
Bathyl perspective
We treat the QA checklist as part of the deliverable, not an afterthought. A geologic map that passes these checks can be queried, overlaid, and reused by someone who was not in the room when it was compiled — which is the whole reason to publish geology as structured data instead of a picture.
Related reading
- Geological Visualization Workflow
- Geological Units, Faults, and Structures in GIS
- How GIS Is Used in Geology
- Geological visualization