Short answer

Digitizing a geologic map is not tracing colors — it is reconstructing the geologist's interpretation as structured, topologically clean spatial data with explicit confidence. A reliable workflow has five stages: georeference the scan to a real CRS, digitize contacts and faults as attributed lines, build map-unit polygons from that linework, attribute and link those polygons to a unit-description table, and validate topology and metadata before export. Done well, the result is queryable and archivable; done as a quick trace, it is just a slightly-more-clickable picture.

Stage 1 — Georeference the scan

A scanned sheet has no spatial meaning until it is tied to ground coordinates. Use the Georeferencer in QGIS or Georeference in ArcGIS Pro:

  1. Identify the CRS the map was originally drawn in (read the collar — it states the projection and datum, e.g. a UTM zone on NAD27 or a national grid).
  2. Place ground control points (GCPs) on identifiable features: graticule tick intersections and grid corners are best because their coordinates are printed on the sheet. Spread GCPs to the corners and interior, not clustered.
  3. Choose a transformation. For a flat, undistorted scan a polynomial order 1 (affine) transform is usually right. Reach for higher orders or thin-plate spline only when the paper is genuinely warped, and never to mask bad GCPs.
  4. Watch the residuals. The RMS error must be small relative to line width at map scale. At 1:24,000, a 0.4 mm cartographic line equals ~10 m on the ground, so an RMS of a few meters is acceptable; if any single GCP shows a large residual, it is likely mis-placed — fix it rather than averaging it away.

If the source is on an old datum (e.g. NAD27), georeference in that datum, then reproject the digitized vectors later with a proper datum transformation, rather than forcing the scan into a modern CRS up front and inheriting a grid-shift offset.

Stage 2 — Digitize contacts and faults as lines

Geologic boundaries are best captured as a single line layer, not as polygon outlines, because contacts and faults are shared edges between units and carry their own meaning.

Create a ContactsAndFaults line layer (GeMS naming) with at least:

  • type — contact, fault, marker bed, etc.
  • isConcealed — whether the line is beneath cover.
  • existenceConfidence and identityConfidence — certain / questionable, mirroring the dashed-vs-solid convention of paper maps.
  • dataSource — which sheet/observation the line came from.

Digitize at a consistent display scale near the source scale; zooming far in invites false precision that the source never had. Snap line endpoints together so that contacts terminate exactly on faults and on each other — snapping tolerance set in map units (a few meters at 1:24k) prevents the gaps that wreck polygon building later.

Stage 3 — Build map-unit polygons from the lines

Rather than tracing each polygon by hand (slow and error-prone), build them from clean linework:

  • QGIS: Processing → native:polygonize on the contacts/faults layer produces a polygon for every closed region. Then add a representative point per unit and use a spatial join, or attribute polygons directly.
  • ArcGIS Pro: Feature To Polygon does the same, with the boundary lines as input.

This is why endpoint snapping in Stage 2 matters: a single dangling contact leaves two regions merged or one region open, and polygonize will silently produce the wrong polygon. Build, inspect, fix the offending line, rebuild.

Stage 4 — Attribute polygons and link to unit descriptions

Each polygon gets a map-unit key (MapUnit) that references a separate DescriptionOfMapUnits table holding the full unit definition: name, lithology, age, stratigraphic rank, and the symbolization color (an RGB or CMYK value, ideally aligned to a standard color scheme). Keeping description in a linked table instead of repeating it per polygon is the core of the GeMS model and means a unit's age or color can be corrected in one place.

In a GeoPackage or file geodatabase this is a one-to-many relationship: many polygons → one map-unit row. In PostGIS it is a foreign key:

ALTER TABLE mapunitpolys
  ADD CONSTRAINT fk_unit FOREIGN KEY (mapunit) REFERENCES descriptionofmapunits(mapunit);

That constraint also doubles as a QA check — any polygon with a unit code not present in the description table is rejected on insert.

Stage 5 — Validate topology and metadata

Before anything ships, enforce rules:

  • Polygons must not overlap and must not leave gaps within the map area (every point inside the boundary belongs to exactly one unit).
  • Lines must not dangle except where geologically intended (a fault tip is legitimate; an unsnapped contact is not).
  • Every polygon carries a valid MapUnit present in DescriptionOfMapUnits.

Use QGIS Topology Checker (rules: "must not have gaps", "must not overlap", "must not have dangles") or an ArcGIS geodatabase topology with equivalent rules. Fix at the source linework, not by patching polygons, so a later rebuild stays consistent.

Record metadata that the next user will need: source map citation and scale, georeferencing RMS, CRS and datum, digitizing scale, and date. A map digitized from a 1:250,000 sheet must not be read as if it were 1:24,000 — the metadata is what stops that misuse.

Worked example, condensed

For a single 1:24,000 quadrangle:

  1. Georeference the GeoTIFF scan to UTM 11N on the source datum; achieve RMS ≈ 4 m with 6 graticule GCPs.
  2. Digitize ContactsAndFaults at 1:24,000 display, snapping at 5 m, attributing type and confidence.
  3. native:polygonize → 47 polygons; topology check flags 2 gaps from unsnapped contacts; fix the two lines and rebuild → 0 errors.
  4. Attribute polygons to 12 units; link to DescriptionOfMapUnits with RGB colors.
  5. Export to GeoPackage with both feature classes and the description table; write metadata.

Common pitfalls and why they happen

  • Tracing polygons directly. Adjacent units end up with slightly different shared edges, creating slivers and gaps; building from shared linework eliminates this by construction.
  • Digitizing at too fine a zoom. Implies precision the source never carried, and bloats vertex counts.
  • Dropping confidence. Solid and dashed lines carry real meaning; a digitized map that flattens them to "a line" loses the geologist's uncertainty.
  • Forcing the scan into a modern datum first. Bakes a datum-shift offset into every vertex; georeference in the native datum and reproject vectors with a real transformation.
  • Mixing source scales without flagging it. Stitching a 1:250k sheet to a 1:24k sheet makes the coarse data look more precise than it is.

QA / validation checklist

  • Georeferencing RMS reported and below line-width-at-scale.
  • Topology: no overlaps, no gaps, no unintended dangles.
  • Every polygon has a valid map-unit key (enforced by FK or join check).
  • Confidence and concealment attributes populated on contacts/faults.
  • Metadata: source citation, scale, CRS/datum, digitizing scale, date.

Bathyl perspective

A digitized geologic map earns trust when its geometry is topologically clean, its interpretation and confidence are explicit, and its provenance is written down — not when the colors match the paper. We build to the GeMS structure so that the geologist's uncertainty survives into the digital product and another analyst can audit exactly which source and scale every line came from.

Related reading

Sources