Georeferencing — Task

See also: Backdrop digitalisation (The technology stack/QGIS) — a walkthrough that assumes this Task’s output as a prerequisite. Implementation: Georeferencing (Recipe - QGIS).

Georeferencing is the Task of assigning a Coordinate Reference System to an image (a scanned map, an aerial photograph, a satellite image) that does not yet carry one, so that it can be used as a Realisation-bearing source alongside other spatial data. It is tool-agnostic: every Stack that offers georeferencing implements the same underlying Task Schema below, with different interfaces and defaults.

Task Schema (tool-agnostic)

The Task decomposes into decision points and Operations. The order below is fixed; the content of each step is not.

  1. Identify control points (decision point) — locate a set of points on the image being georeferenced that are also identifiable in a reference source (Ground Control Points, GCPs). This is a human judgement call, not an Operation: it requires recognising the same real-world feature in two representations — a road intersection, a building corner, a natural landmark — and is not mechanically executable. The number and spatial distribution of control points needed depends on the transformation chosen in step 3.

  2. Obtain corresponding coordinates (decision point + acquisition) — for each control point identified in step 1, obtain its known real-world coordinates from another source. Common sources: an already-georeferenced basemap or orthophoto (visually matching a point on both), a field-surveyed GCP with measured coordinates, or an existing georeferenced dataset. This step may itself be a nested Task (e.g., a field GCP survey has its own decision points and Operations) rather than a single Operation — see the note on Task composition as a graph, not a hierarchy, in the terminology glossary (concepts.md, §9).

  3. Choose and apply a transformation (Operation) — with control-point/coordinate pairs established, apply a transformation that warps/rectifies the image into the target CRS. This is the Operation proper: mechanically executable by an Operator (a person following a defined procedure, or software) once its inputs are fixed. Two families:

    • First-order (affine) transformation — scales, rotates, and translates the image, assuming a flat surface with no lens distortion. Sufficient when the source has no optical distortion to correct — typically a scanned paper map or historical map.
    • Higher-order (polynomial, second-order and above) transformation — warps the image using polynomial equations to correct non-linear distortion, needed when the image was captured through a lens (an aerial or satellite photograph), where perspective and lens distortion bend the image, especially near its edges. Higher polynomial order corrects more precisely but requires more control points and computation — this is itself a judgement call, not a fixed rule: over-fitting the polynomial to too few control points can warp the image to match noise rather than genuine distortion.

    Choice of transformation order is a judgement informed by the source of the image, not a mechanical default — e.g., aerial/satellite imagery and urban-planning overlay work typically warrant higher-order rectification, while a scanned map typically does not.

Output: a georeferenced image, ready to serve as a backdrop/reference for further work — e.g., feeding into Backdrop digitalisation as its step 1 prerequisite, or directly into Recording the Domain of Discourse.

Task Recipes (tool-bound)


Open item: this is the first Task write-up using the Task/Schema/Recipe template — once a second or third Task exists (e.g., “correct a hydrologically-sound DTM”, “create a table”), revisit this template for consistency rather than treating this file’s exact shape as final.