Ingest (Vector)
About this feature
The Vector Ingest Wizard processes typical survey deliverable folders - detecting deliverable structure automatically. It maps source layers to SSDM feature classes, runs IOGP 462-02 §4.5.3 topology QC checks, and loads clean, compliant data into PostGIS in one guided workflow.
Once an operator specifies a folder, the wizard walks the delivery layout, classifies what is present (for example category ZIPs and related files), and builds a manifest—without unpacking any ZIPs at this stage. The wizard then derives suggested themes for ingest, loads existing surveys from the database for linking, and returns the scan result screen so the operator can review categories and tick which spatial deliverables to take forward to the next step (unpack, layer inventory, and mapping)
Once the operator has specified which deliverables to take forward the Review layer mapping wizard present a lists of each source layer and suggests which SSDM table it should load into. Operators can change the target, skip layers, and set a batch reference before continuing.
Vector topology QC
The system implements IOGP 462-02 §4.5.3 topology checks before reprojection to WGS84. Checks use the layer's source CRS; distance rules (metres) and need a projected CRS source—otherwise those checks are skipped (with a warning).
All geometry types
• Null or empty geometries • Validity (invalid rings, self-crossing boundaries, open/unclosed polygons) • Exact duplicates (identical WKB)
Lines
• Self-intersection (non-simple / crossing lines) • Dangles (~1 m tolerance: endpoint close to another line but not snapped) • Very short segments (< ~0.01 m: duplicate vertices, noise, or unnecessary splits)
Polygons
• Slivers (isoperimetric quotient below threshold — extremely thin polygons)
Findings are ERROR / WARNING / INFO, written per batch to provide an opportunity for operator review and resolution (ERROR) or acknowledgement (WARNING / INFO) before the ingest Run.
Each operator decision on mapping source data to SSDM is saved as a reusable rule. The next time a similar layer appears the system applies what was already approved. Tacit knowledge becomes a permanent asset; more ingests, faster runs.
Every suggested layer→table match carries a confidence score from the Mapping Rules library - built from system experience but can also be populated with organisation rules. Rules are ranked - often-used mappings surface first; each confirmed ingest updates the library, including overrides, so suggestions sharpen over time without ad-hoc alias spreadsheets.
Field mapping — how values are supplied
The wizard binds each SSDM column, either as:
• From field - map a source attribute or value (with optional numeric scaling)
• Constant (one value for every feature—useful when deliverables are already split by layer or theme), or Skip. Attributes that participate in an IOGP codelist are constrained to approved codes; where the model allows unconstrained text or literals, constants can be entered accordingly (dates and units follow the column type).
Visual cues
Indigo denotes codelist-governed fields (marker on the column, indigo-framed value-translation blocks). Emerald highlights rows where a saved mapping rule has pre-filled the target SSDM code for a given source value ("pre-filled from saved rules"); unassisted rows stay on the default indigo/white styling until the operator chooses a code.
After field mapping, the operator completes pre-ingestion topology/QC (reviewing or resolving reported issues), then starts Run, which executes the pipeline on the staged data using the confirmed layer and field mappings. Run transforms attributes, reprojects geometry to EPSG:4326, inserts features into the mapped ssdm.* tables in PostGIS, and records the ingest batch so the load is auditable and tied to the survey.
