Short answer

A fault in GIS is normally a line feature carrying a structured set of attributes — fault type, sense of slip, dip and dip direction, existence and location confidence, mapping scale, and a source citation — not just a red line on a map. Geometry tells you where the fault trace is; the attributes tell you what kind of fault it is and how much to trust it. The USGS GeMS schema is the de facto standard for organising this; for shared, queryable storage, PostGIS with topology rules keeps the linework clean and the attribution intact.

A fault is data, not a symbol

The single most common mistake is treating the cartographic symbol — barbs on a thrust, ticks on a normal fault, arrows on a strike-slip — as the information. In a robust dataset the symbol is derived from the attributes, not the other way round. If you record Type = thrust fault and ExistenceConfidence = inferred, the renderer draws barbed teeth with a dashed line automatically. Encode the geology in fields, and symbology, queries, and analysis all follow.

This separation matters because faults are interpretations with varying reliability. A fault mapped from a continuous outcrop scarp and one inferred beneath cover from a magnetic lineament both deserve to be in the dataset, but they must be distinguishable by attribute so downstream users can filter by confidence.

The minimum attribute model

For a fault line feature class, capture at least:

  • Unique ID — a persistent identifier (e.g. integer or UUID), not the row number.
  • Type — normal, reverse, thrust, strike-slip (dextral/sinistral), oblique, or undifferentiated. Use a controlled vocabulary so spelling never varies.
  • ExistenceConfidence — does the fault exist? (definite / inferred / questionable).
  • LocationConfidence — how well is its trace located? (accurate / approximate / concealed), ideally with a metres value.
  • Dip and DipDirection — the dip angle (0–90°) and azimuth of dip (0–360°) where measured or inferred; null where unknown.
  • Slip sense / displacement — hanging-wall-down for normal, etc., and offset magnitude if known.
  • Scale — the source mapping scale (e.g. 1:50,000), which bounds the positional precision.
  • DataSource — a citation ID linking to a sources table.

Recording confidence as data, not as a line style, is what lets a structural geologist later query "show me all definite thrusts dipping steeper than 45° from 1:25,000 mapping."

GeMS: the standard worth following

The USGS Geologic Map Schema (GeMS) defines a relational structure for digital geologic maps. Faults and depositional contacts share the ContactsAndFaults feature class, with:

  • a controlled Type field,
  • ExistenceConfidence and LocationConfidence fields,
  • an IsConcealed flag for faults hidden beneath younger units,
  • a DataSourceID linking to the DataSources table,
  • a Symbol field referencing the FGDC cartographic standard.

Even if you do not adopt GeMS wholesale, mirroring its confidence fields and source linkage makes your data publishable and interoperable with the National Geologic Map Database. The schema is designed for archiving, so it forces you to record provenance you would otherwise lose.

Storing faults in PostGIS

For multi-user editing and analysis, a spatial database beats a pile of shapefiles (which also truncate field names to 10 characters — fatal for LocationConfidence). A minimal PostGIS table:

CREATE TABLE faults (
  fault_id     bigserial PRIMARY KEY,
  fault_type   text,
  exist_conf   text,
  loc_conf     text,
  dip_deg      numeric,
  dip_dir_deg  numeric,
  slip_sense   text,
  map_scale    integer,
  source_id    integer REFERENCES data_sources(source_id),
  geom         geometry(LineString, 32633)
);
CREATE INDEX faults_gix ON faults USING GIST (geom);

Set the SRID explicitly (here EPSG:32633, a UTM zone) and add the GiST index for fast spatial queries. Build geometry with ST_SetSRID(ST_GeomFromText(...), 32633) and reproject inputs on load with ST_Transform. Validate every line with ST_IsValid(geom) before committing.

For shared connectivity, PostGIS Topology (CREATE TOPOLOGY, topology.AddTopoGeometryColumn) enforces that faults and contacts share nodes, so polygons build correctly and a fault that cuts a contact actually splits it.

Topology and the clean-linework problem

Faults rarely live alone — they truncate contacts, terminate against other faults, and bound geologic polygons. The errors that break everything downstream are geometric:

  • Dangles / undershoots — a fault that should reach a contact stops short, leaving a gap so the polygon never closes.
  • Overshoots — a fault crosses past its intended termination, creating slivers.
  • Unsnapped nodes — two faults that meet in the field are 0.3 m apart in the data, so a network query treats them as disconnected.

Apply topology rules: must not have dangles, must not self-overlap, must not overlap with other faults of the same type, and must be covered by boundary of the geologic polygons. In QGIS use the Topology Checker and Snapping with a tolerance matched to your mapping scale; in ArcGIS Pro build a geodatabase topology. Fix errors before publication, never after.

Worked example: from a scanned map to queryable faults

  1. Georeference the scanned sheet to its stated CRS and scale.
  2. Digitise fault traces into a line layer at consistent vertex density; snap to contacts as you go.
  3. Populate Type, ExistenceConfidence, LocationConfidence, Dip/DipDirection, Scale, and DataSource per feature — never leave confidence blank.
  4. Run topology checks; repair dangles and overshoots within a tolerance set by scale (e.g. ±25 m at 1:50,000).
  5. Load into PostGIS with ST_Transform to a single project CRS; index with GiST.
  6. Symbolise from the Type and confidence fields, and link cross-sections and dip data for 3D interpretation.

Common pitfalls and why they happen

  • Editing in shapefile. The 10-character field-name limit silently mangles attribute names, so ExistenceConfidence becomes Existen_1. Use GeoPackage or PostGIS.
  • Mixing mapping scales without flagging it. A 1:250,000 regional fault and a 1:10,000 detailed fault drawn together imply false precision. Store and display the scale.
  • No confidence attribution. Without existence/location confidence, an inferred fault is indistinguishable from a measured one and gets over-trusted.
  • Dropping the source link. Faults compiled from multiple maps become unverifiable when no DataSourceID ties each feature to its origin.
  • Ignoring dip. A trace alone is 2D; without dip and dip direction you cannot project the fault to depth or build a cross-section.

Quality checks

  • Confirm CRS and SRID are consistent across faults, contacts, and the basemap.
  • Run ST_IsValid (or QGIS Check Validity) on all geometry; repair invalids.
  • Verify topology: no dangles where faults should connect, no unsnapped junctions.
  • Confirm every feature has Type, confidence, scale, and a resolvable source citation.
  • Cross-check a sample of dips and slip sense against the original field notes or map.

Bathyl perspective

We model faults as interpretations with provenance and confidence baked into the schema, so a structural geologist can filter by reliability and a reviewer can trace any line back to its source. Clean topology and explicit dip attribution are what let the same fault layer drive both a 2D map and a 3D cross-section without rework.

Related reading

Sources