The Architecture of a Geospatial Workflow

In the modern era, you cannot survive by memorising software toolchains. To execute a rigorous Geospatial Workflow within a broader project, the practitioner must turn their back on button-clicking and adopt a Documentation-Driven Workflow.

To achieve this, the SemanticGIS methodology is structured around five core activities and the entire workflow is documented in a continuous track of Workflow Stewardship (the ongoing documentation of the design rationale).

Scoping the Workflow

Before touching any data, we must first establish the boundaries and conceptual structure of the inquiry. This involves three critical tasks:

• Extracting the Spatial Intent: Isolate the specific spatial questions demanded by the Domain Project (e.g., What are the potential traffic effects of this proposed development, and how can we communicate them to stakeholders?)
• Defining the “Universe of Discourse”: The “universe of discourse” is an unstructured ideal ontology of the Spatial Intent. It is a collection of concepts needed to address the spatial Intent as a spatial analytical problem. While the “Universe of Discourse” springs from the Spatial Intent, it is often necessary to confront domain expertise in the form of domain experts and even field observations.
• Mapping the Operational Context: Determine which resources are available, which stakeholders are involved, and, crucially, which political and ethical guidelines must constrain the workflow.

Establishing the Data Framework

This activity bridges human intent and computational reality. It consists of three tightly iterative phases, moving from an idealised conception of the “Universe of Discourse” identified in scoping activity to a digital instantiation of that model.

Phase one — Formalising the Domain of Discourse. We use the term Domain of Discourse to denote a narrower, more strictly defined version of the Universe of Discourse. Where the Universe of Discourse holds concepts in their unconstrained, ideal form, the Domain of Discourse holds them formalised: we call a concept, once bounded by the five commitments below, a Cognised Existence (die erkennbare Existenz)—a mass noun, denoting a kind rather than a countable instance of it. This formalisation requires five commitments the Universe of Discourse does not yet make.

Phase two — Auditing the Cognised Existence. This phase asks two distinct, sequential questions of each Cognised Existence formalised in Phase One: first, does the required data for representing it already exist, and if so, how faithfully does it correspond to the formalised Domain of Discourse? Second, where it does not exist, can it instead be represented by processing primary data—satellite imagery, Lidar, or similar—or through direct fieldwork, and at what cost? This formal order does not mean the practitioner arrives at Phase One blind to what data is available. In practice, formalising the Domain of Discourse is itself routinely informed by prior, often tacit, knowledge of existing datasets—a practitioner rarely commits to a Minimum Mapping Unit or a thematic boundary without some sense of what the available data can already support. Auditing the Cognised Existence formalises and makes explicit what informal knowledge may already have shaped Phase One, rather than triggering an official backflow each time it turns out a dataset falls short. It is worth noting that, like when formulating the “Universe of Discourse”, this audit needs input from domain expertise and even fieldwork. All existing datasets are formed by their original purposes, and while they might address the same concepts as in the Universe of Discourse, the data they yield might reveal a different story.

Phase three — Recording the Domain of Discourse. For those Cognised Existence in the Domain of Discourse that are not, or only partly, represented by existing data, data recording is necessary. Data recording can include fieldwork but can also involve extracting information from existing primary data such as satellite data or Lidar data. Recording the domain of Discourse is all about representing the domain of discourse as data by confronting the Sensoric Manifold proper, through field recording or through processing other primary data. Sensoric Manifold is used here in its Kantian sense: not the output of hardware instrumentation, but the sensoric manifold (Mannigfaltigkeit der Anschauung) — the raw, unstructured extent of given spatial reality prior to any conceptual synthesis. We accept that it can take the form of data recordings that support or extend the human senses.

A brief terminological note is owed here, since the next activity uses “GIS” in a way that could otherwise seem to contradict this phase. Recording typically does involve GIS software—a spatial table is, after all, usually built and populated using tools from the geospatial technology stack. But it uses that software as an instrument of record: creating a schema and entering data into it commits nothing about how that data will later be analysed. This use of the technology stack differs from Activity 5 (Executing the Analytical Schema), where GIS is used as an instrument of analysis—executing the mathematical verbs the Analytical Schema specifies.

Authoring the Analytical Schema

Design the abstract algorithmic logic (the mathematical “verbs”) required to bridge the gap between the chaotic data and the scientific intent. This must maintain strict tool-agnosticism. The schema dictates what must happen mathematically, not how the software will achieve it.

The Schema’s only legitimate starting point is the Recorded Domain of Discourse where the domain of discource has been given physical, digital shape whether by adopting and transforming existing data or by digitising newly collected field observations. Neither the unconstrained Concepts of the Universe of Discourse nor the raw Sensoric Manifold itself is an admissible input here: a mathematical verb cannot be applied to a phenomenon that has not yet been typed, bounded, and given a geometry.

The most useful way to conceive of the Analytical Schema itself is as a Directed Acyclic Graph (DAG): a network of nodes connected by one-directional edges, containing no path that loops back on itself. Each node in the Schema’s DAG is a single spatial operation—a buffer, an intersection, a spatial join, a reclassification—and each edge represents a Realisation flowing from the output of one operation into the input of the next. The graph is directed because data only ever flows forward, from Recorded input toward final result, never backward into an operation that has already run; it is acyclic because no operation may legitimately depend, even indirectly, on its own output—a constraint that is not a technicality but the formal guarantee that the Schema terminates in a finite, well-ordered sequence of steps rather than an undefined circular dependency.

4. Designing Spatial Results Communication

While a Geospatial Workflow can yield many deliverables, the brief will often specify the communication of results via reports, maps, and graphs. It is worth being precise, at the outset, about what design means in this context. This manuscript uses the term not in its colloquial sense of layout or aesthetic composition, but in the sense of suitability: design, here, denotes the fitness of a representational choice to the data it represents and the audience it must reach.

Two distinct suitability judgements govern this Vantage Point. The first concerns what kind of deliverable the result should take. MacEachren’s cartography cube (MacEachren and Taylor, 1994) is useful here: it positions any map or visualisation along three axes—from public to private audience, from presenting knowns to revealing unknowns, and from low to high interaction. A static report map intended for a public planning consultation occupies a very different position in this cube than an interactive digital twin built for a client’s internal exploratory analysis, and the practitioner’s first task is to judge, from the brief established at Scoping, where along these three axes the deliverable ought to sit.

The second judgement concerns how the chosen deliverable represents the underlying data, and here the practitioner’s decisions carry the same epistemic weight as any made at the Analytical Schema. Consider classification method alone: the same continuous surface, classified by equal interval, equal count (quantile), or natural breaks (Jenks), will produce visibly different maps from identical underlying data. Equal interval emphasises the extremes of a distribution, at the cost of collapsing distinctions among values clustered near the mean; equal count guarantees a balanced visual weighting across classes, at the cost of potentially separating near-identical values across a class boundary and merging quite different ones within it. Neither is more “correct” in the abstract—each is more or less suitable depending on what the map is meant to reveal, and to whom.

Because these representational choices depend directly on the statistical character and uncertainty of the analytical output, arriving at this Vantage Point requires a Backward Glance to the Analytical Schema: does the chosen representation honestly convey the uncertainty and distributional shape of the result, or does it imply a precision or evenness the underlying analysis does not support? Where it does not, the practitioner returns—not to redesign the map alone, but to establish, in dialogue with the Schema, a representation that is suitable to what was actually computed. Only once both judgements—deliverable and representation—are secured is the mathematical result legible to the Lifeworld it was produced to serve.

5. Executing the Analytical Schema

Only once the semantic workflow is fully documented is the logic delegated to the computational engine—the operational GIS—for syntactic execution. It is worth pausing here to restate, at the point where it matters most, the terminological convention this manuscript has held throughout: GIS, in this text, denotes strictly the technology stack—the software or code through which spatial logic is carried out, whether a desktop application such as QGIS or ArcGIS, or a heterogeneous ecosystem of Python or R libraries. Software of this kind may already have been used earlier, at Recording (Establishing the Data Framework, Phase Five), to build and populate a spatial table—but there it served only as an instrument of record. It is precisely at this fifth activity, and nowhere before it, that GIS in this narrow sense enters the workflow as an instrument of analysis.

This delayed entry is deliberate. The preceding four activities were conducted in deliberate tool-agnosticism: the Analytical Schema authored in Activity 3 specifies the mathematical verbs—buffer, overlay, interpolate, aggregate—required to bridge data and intent, without committing to how any particular software will carry them out. Execution is the activity in which that abstraction is finally surrendered. The Schema does not survive this activity unchanged; it is translated, and the translation is neither trivial nor value-neutral.

From Schema to Recipe. The product of this translation is what we termed, among the Semantic Assets, the Analytical Recipe: a decoupled, reproducible, and now tool-bound script—a Directed Acyclic Graph of operations—capable of being executed, audited, or handed to another practitioner (human or computational agent) without requiring their presence in the room. Where the Schema answers what must happen mathematically, the Recipe answers how, in this specific software environment, it was made to happen. The same Schema may legitimately yield several different Recipes: a chained sequence of native tools within a desktop GIS, a scripted pipeline in Python using GeoPandas and rasterio, or a hybrid of both. None of these Recipes is more “correct” than another with respect to the Schema; they diverge only in their operational form, not in their semantic intent.

The Reality of Iteration (Workflow Stewardship)

The five activities of the Geospatial Workflow are best understood not as sequential steps but as five Vantage Points the practitioner occupies and revisits over the course of a workflow. Each Vantage Point discloses an aspect of the workflow that no other vantage can: Scoping reveals human intent and constraint; the Data Framework reveals ontological fit between the ideal and the given; the Analytical Schema reveals the mathematical logic required to bridge them; Communication reveals legibility to the Lifeworld the workflow ultimately serves; and Execution reveals the operational reality of a specific computational engine. No single Vantage Point offers a complete view of the workflow—this is precisely why the practitioner must be able to move between them. Two are fixed in position: Scoping is always the first Vantage Point occupied, and Execution is always the last. Between these two fixed points, the practitioner may return to any Vantage Point as often as the Domain Project’s complexity demands—authoring the Schema may reveal a flaw visible only from the Data Framework; designing Communication may surface a gap only Scoping can resolve. What matters is not the order in which these Vantage Points are visited, but that the practitioner always knows which one they currently occupy, what it does and does not show them, and can account—through Workflow Stewardship—for why they moved.

Movement between Vantage Points is not merely spatial repositioning; it is accompanied by the Backwards Glance—the phase, within Workflow Stewardship, in which the practitioner identifies what backflow is required and documents its cause. A Backwards Glance is not confined to the immediately preceding Vantage Point. Because each Vantage Point depends on the integrity of every Vantage Point before it, a single unresolved question can cascade backwards through the entire chain. Discovering, while authoring the Analytical Schema, that private-hire and taxi services were never included in a transport dataset is, on its surface, a Data Framework problem—but it frequently is not, at root: it may reveal that the scope of “transport” was never explicitly agreed with the client at all. The Backwards Glance, in such cases, does not stop at the nearest plausible vantage; it travels back to wherever the unresolved question actually originates—here, to Scoping itself, where the boundary of the Domain Project’s intent must be renegotiated before the Schema can proceed. This cascading property is not a failure of the framework; it is the mechanism by which Workflow Stewardship keeps the entire chain of Vantage Points honest to one another.

The Epistemological Nature: Heuristics vs. Teleology

It is important to understand that the path connecting the five vantage points is not one-way, and there is almost always some going back and forth between them, especially if the project is a bit more complex. Another factor that determines how we move between the vantage points is the type of workflow. It is here relevant to distungish betwee two types of workflow Exploratory (Heuristic) and Prescriptive (Teleological) workflows

Exploratory (Heuristic) Workflow: The Path of Discovery

The brief poses an open-ended question where the outcome is unknown (e.g., “Investigate the spatial correlation between urban canopy cover and respiratory health”).

• The Intent: To uncover patterns, relationships, or anomalies hidden within the data’s extent.

• The Process: This follows the numerical order of the five activities. However, it is rarely linear; it is characterised by Heuristic Backflow, in which findings from Authoring the Analytical Schema may require a return to Establishing the Data Framework or even a refinement of the initial Intent in the project scoaping.

Prescriptive (Teleological) Workflow: The Path of Purpose

The brief requires a definitive, actionable output based on pre-defined criteria (e.g., “Identify all rooftops suitable for Grade-A solar panel installation”).

• The Intent: To reach a specific goal (Telos) or deliverable.

• The Process (Reverse Engineering): In a teleological workflow, we perform a “preliminary run” in reverse order:

  • Designing Spatial Results Communication: What does the final prescription look like? (e.g., a list of addresses).

  • Author the Analytical Schema: What logical recipe is required to generate that list?

  • Establishing the Data Framework: What specific datasets are required to satisfy that recipe?

• **Executing the Analytical Schema:

The Semantic Continuum

In professional practice, these are poles of a continuum. Most projects are Hybrid.

Copenhagen Case Study: We must first use a Heuristic approach to discover where the party zones actually are. Once we have a “Formula for Vibrancy,” we switch to a Teleological mode to deliver a weekly “Prescription Map” for the cleaning crews.