Backdrop Digitalisation — Task

Related: 2.2 Establishing the Data Framework (Part 2) and Primary Data Collection: Field Work (Part 3) — this is the data-entry step that follows fieldwork. Depends on Georeferencing (Task) as a prerequisite. Implementation: Backdrop digitalisation (Recipe - QGIS).

Editorial note: the digitising mechanics this Task’s Recipe describes are grounded in the transcript of your “basic GIS operations in QGIS” video, supplied manually. That video covers general digitising over an OpenStreetMap basemap — it does not itself demonstrate reconciling hand-drawn field notes against an aerial photo, so the field-note-reconciliation material below (decision point 3) is still a general reconstruction, not verified against a source specific to backdrop digitalisation. Correct it once you have that material to hand.

Backdrop digitalisation is the Task of translating a Pilot Fieldwork session — hand-drawn sketch maps and paper notes, recorded with deliberately unstructured tools — into a structured spatial table, by tracing over a georeferenced aerial photograph. Where the field session produced a rough, expressive record of what was observed and where, backdrop digitalisation is the Final Registration step: applying the (by now refined) Domain of Discourse consistently, to produce clean, precisely located data.

It sits, in workflow terms, at the boundary between Confronting the Sensoric Manifold and Executing the Analytical Schema — the Realisation exists first as a sketch, and only becomes a Realisation an Analytical Schema can act on once it has been digitised against the Attribute Framework and geometry.

Flow

flowchart TD
    A[Obtain a georeferenced backdrop] --> B{Source is a paper map<br/>not yet georeferenced?}
    B -- yes --> C["Georeferencing (Task)"]
    B -- no, already a live basemap --> D[Load basemap]
    C --> E{Digitised data goes into...}
    D --> E
    E -- a new table --> F[Create geospatial table]
    E -- existing data needing an update --> G[Enable editing]
    F --> H[Digitise features against backdrop]
    G --> H
    H --> I[Reconcile against field notes]
    I --> J[Enforce shared-boundary topology]
    J --> K[QA pass against field notes]

Nodes in this flow:

1. Obtain a georeferenced backdrop
2. Source is a paper map not yet georeferenced?
   • yes → Georeferencing (Task)
   • no → Load basemap (not yet its own Task note)
3. Digitised data goes into…
   • a new table → Create geospatial table (not yet its own Task note)
   • existing data needing an update → Enable editing (not yet its own Task note)
4. Digitise features against backdrop
5. Reconcile against field notes
6. Enforce shared-boundary topology
7. QA pass against field notes

Only Georeferencing (Task) is a real click-through link — the other nodes are steps internal to this Task, not separate notes (yet). This list exists because Mermaid’s own click links don’t resolve reliably in both Obsidian and the published site (see discussion in the vault’s working notes); an ordinary markdown/wikilink list under the diagram does resolve reliably in both, so this is the actual navigation — the diagram is the overview.

This is also a first pass at sketching the Task as a flow rather than a numbered list — the two decision points above (georeference-or-load-basemap; new-table-or-enable-editing) aren’t both reflected in the numbered Schema below yet. The Schema currently only covers the new-table branch (step 1); the “existing data needing an update → enable editing” branch is new, surfaced by drawing this out, and still needs its own paragraph — see open item below step 1.

Prerequisites

• A georeferenced aerial photograph of the study area — see Georeferencing (Task) if it isn’t already one. Most student work will start from an already-referenced orthophoto (e.g., in Denmark, Dataforsyningen’s WMS/WMTS service) and can skip straight to digitising.
• Your hand-drawn field maps and notes from the Pilot Fieldwork session, ideally photographed or scanned so they can be viewed alongside the digitising software.
• A finalised Attribute Framework — the NOIR-typed table from your (refined) Domain of Discourse — so that the fields you create match a specification you have already committed to, rather than being improvised feature by feature.

Task Schema (tool-agnostic)

1. Obtain the backdrop, and prepare the target table (decision point + Operation) — first: if the backdrop source is a paper map or otherwise un-referenced image, it must go through Georeferencing (Task) first; otherwise, load an already-georeferenced basemap directly. Second: instantiate an empty spatial table per entity — matching the geometry type your thematic specification already settled on for that Cognised Existence (point, line, or polygon), the target CRS, and the Attribute Framework’s fields exactly (a nominal field as text with an appropriate maximum length, a ratio or interval field as a numeric type) — or, where the digitised data is an update to existing data rather than a new capture, enable editing on the existing table instead of creating a new one. Building the schema before digitising a single feature — rather than adding fields as you go — is what keeps this step a Recipe rather than an improvisation.

   Open item: the “existing data needing an update → enable editing” branch needs its own worked-through paragraph, parallel to the “new table” case above — what changes about steps 2–5 below when you’re editing an existing Realisation rather than creating a fresh one (e.g., does reconciliation against field notes work the same way against pre-existing attribute values)?

2. Digitise each feature against the backdrop (Operation, with an embedded decision point) — place each feature’s geometry using the aerial photo for precise, metrically accurate placement, and the hand-drawn notes as the record of what was observed and where it should belong — the sketch tells you which bench, path, or zone boundary you are looking at; the orthophoto tells you exactly where its geometry belongs. Populate attributes directly from the field notes as each feature is completed.

   Decision point: where a Cognised Existence has an interior exclusion — a courtyard cut out of a building footprint, a paved-over patch excluded from a wider polygon — it must be represented as a hole in that same feature, never as a second, separately-owned polygon placed on top. A separate overlapping polygon will not behave as an exclusion in later spatial operations, however visually similar it looks on screen.

3. Reconcile deliberately, and log the reconciliation (decision point) — a hand-drawn sketch is never as precise as an aerial photo, and reconciling the two is an interpretive act, not a mechanical one: deciding exactly where a sketched “picnic area” boundary falls against the orthophoto’s actual tree lines and paths is the same kind of judgement call as the GeoDanmark specification’s skønnes (“is assessed”), discussed under thematic specification in Part 2. Where the reconciliation is not obvious, note the decision in your Design Rationale rather than letting it pass silently.

4. Enforce shared-boundary topology while digitising, not after (decision point) — for any Domain of Discourse rule that depends on two features meeting exactly (no gap or overlap between adjacent zone polygons; a path endpoint that must land precisely on a boundary), the adjacency must be enforced at the moment the second feature is drawn. Correcting a near-miss afterwards is far more error-prone than preventing it as you draw. This addresses adjacency/shared-boundary constraints only — a containment rule (e.g., “must fall entirely within Tivoli’s boundary”) or a connectivity rule (e.g., a harbour-front severance test) still needs a separate manual check or follow-up geoprocessing step; neither is something boundary-snapping alone can catch.

5. Close out with a QA pass against the original field notes (Operation) — not to re-decide anything, but to catch anything transcribed incorrectly or left out. This closes the loop from Observation, through Recording, to a spatial table ready to enter the Analytical Schema.

Output: a populated spatial table, faithful to the Attribute Framework and the field observations, ready to enter the Analytical Schema.

Task Recipes (tool-bound)

• QGIS: Backdrop digitalisation (Recipe - QGIS)
• ArcGIS: (not yet written)