C - Authoring the Recipe (The Analytical Schema in Action)

Authoring the Recipe: Decoupling Logic from Execution

In traditional GIS, students are often taught to “click their way” to an answer. They follow a sequence of software buttons—Buffer, Clip, Intersect—without ever documenting the underlying logic. In SemanticGIS, we reject this “tool-first” approach in favour of Documentation Driven Development (DDD).

The second half of Phase 3 is about writing the Analytical Recipe. This is a human-readable, logically sound description of your analysis that exists independently of any software.

1. The Principle: Think First, Code Later

The goal of this step is to move from your audited, grounded dataset to a Scientific Result by defining a logical pipeline. We treat the analysis as a “Recipe” that can be “compiled” into different languages:

• The Recipe (Intent): “Identify all residential buildings within 200m of a noise-complaint cluster.”

• The Compilation (Extent): This could be a Python script using geopandas, a SQL query in PostGIS, or a model in QGIS.

By writing the recipe first, you ensure that your science is driven by your Intent, not by the limitations of your software’s user interface.

2. Documentation Driven Development (DDD)

Your Design Rationale becomes your development environment. You do not open your GIS software yet. Instead, you write the “Documentation” of your analysis first.

• The Abstract Logic: You define the spatial predicates (the “if/then” rules of your world).

• The Threshold Justification: You record why you chose a 500m search radius or a specific classification method.

This creates a Transparent Provenance. If someone questions your results, you don’t show them a map; you show them the Recipe.

---

3. Case Study: The Party Zone Recipe

To illustrate this step, let us look at how we define the logic for identifying Copenhagen’s entertainment hotspots.

The Analytical Recipe (from the Design Rationale):

1. Define Intensity: We will use Kernel Density Estimation (KDE) to transform our grounded bar locations into a continuous surface of “vibrancy.”

2. The Parameters: We choose a Quartic Kernel with a 500m radius.

   • Rationale: 500m represents the “Relational Reach” of a venue—the distance a typical patron is willing to walk between establishments.

3. Synthesis (Boolean Logic): We will then intersect this “Vibrancy Surface” with our “Late Night” filter from Phase 2.

   • Logic: [High Density] AND [Open after 02:00].

4. The Result: The final output will be a “Party Potential” raster.

The AI as the Compiler

Once this recipe is written in your Design Rationale, you can hand it to an AI Agent for Phase 4 (Delegate the Operation). Because the agent can be pointed at your Phase 2 audited dataset, you can provide a prompt like:

“Using the Analytical Recipe in my Rationale, write a Python script that performs a KDE on the grounded_bars layer in my GeoPackage. Use a 500m radius and save the result as party_intensity.tif.”

The AI handles the Extent (the Python syntax), while you remain the master of the Intent (the scientific logic).