GeoContra: From Fluent GIS Code to Verifiable Spatial Analysis with Geography-Grounded Repair
| Authors | Yinhao Xiao et al. |
| Year | 2026 |
| Field | AI / ML |
| arXiv | 2605.00782 |
| Download | |
| Categories | cs.SE, cs.AI |
Abstract
Reliable spatial analysis in GIScience requires preserving coordinate semantics, topology, units, and geographic plausibility. Current LLM-based GIS systems generate fluent scripts but rarely enforce these geographic rules at scale. We present GeoContra, a verification and repair framework for LLM-driven Python GIS workflows. It represents each task as an executable geospatial contract-including natural-language questions, schemas, CRS metadata, expected outputs, spatial predicates, topology, metrics, required operations, and forbidden shortcuts. Generated programs undergo static rule inspection, runtime validation, and semantic verification, with violations fed back into a bounded repair loop. Evaluated on 7,079 real geospatial tasks across 15 Boston-area zones, 9 task families, and 11 open-source models (600 runs each), GeoContra improves spatial correctness on closed models from 47.6% to 77.5% for DeepSeek-V4 and from 57.7% to 81.5% for Kimi-K2.5. Across 11 open models, average correctness rises by 26.6%. GeoContra turns fluent code production into verifiable spatial analysis, catching negative travel times, CRS/field-schema violations, missing predicates, and brittle output casts that otherwise yield executable but geographically invalid results.
Engineering Breakdown
Plain English
GeoContra is a verification and repair framework that fixes LLM-generated GIS (geographic information systems) Python code to enforce geographic rules and spatial correctness. The paper addresses a critical gap: current LLMs can generate fluent GIS scripts but frequently violate coordinate systems, topology, units, and geographic plausibility constraints. Evaluated on 7,079 real geospatial tasks across Boston, the system combines static rule inspection, runtime validation, and semantic verification to catch and repair errors. The approach uses executable 'geospatial contracts' that encode domain constraints like CRS metadata, spatial predicates, and forbidden operations, then feeds violations back into a bounded repair loop to correct the generated code.
Core Technical Contribution
The core innovation is the geospatial contract abstraction—a structured representation that packages natural-language intent, schema definitions, coordinate reference system metadata, expected outputs, spatial predicates, topology rules, metrics, required operations, and anti-patterns into a single verifiable specification. Rather than trusting LLM outputs directly, GeoContra treats geospatial code generation as a verification and repair problem, implementing a three-stage pipeline: static rule inspection before execution, runtime validation during execution, and semantic verification after execution. This differs from prior LLM-for-code approaches that focus on syntax correction or general-purpose code quality; GeoContra is domain-specific, embedding geographic domain knowledge into the verification logic. The bounded repair loop allows violations to be iteratively fixed without unbounded retraining or expensive prompt engineering.
How It Works
The system takes a natural-language geospatial query and a geospatial contract (which contains the task specification, schema, CRS info, and spatial rules) as input. An LLM generates Python GIS code (likely using libraries like GeoPandas or Shapely). The generated code then enters a three-stage verification pipeline: (1) Static rule inspection examines the code for violations of forbidden operations and required operations before execution, catching logical errors early; (2) Runtime validation executes the code in a sandbox and checks that coordinate systems, data types, and topology constraints are satisfied during execution; (3) Semantic verification compares the output against expected outputs and spatial predicates. When violations are detected at any stage, the contract and violation details are fed back into a repair module that either auto-corrects the code or re-prompts the LLM with the specific error context. The bounded repair loop limits iterations to prevent infinite correction cycles while maximizing the chance of generating correct code on the second or third attempt.
Production Impact
For teams building GIS automation or spatial analysis platforms, GeoContra solves a real reliability crisis: LLM-generated geospatial code looks plausible but silently produces wrong results when coordinate systems don't match, topology is invalid, or units are misapplied. Adopting this approach would require: (1) defining explicit geospatial contracts for each task family in your system—a one-time engineering cost but critical for safety and auditability; (2) adding a verification layer that executes generated code in a sandbox and checks domain constraints before deployment; (3) implementing a repair loop that re-prompts or auto-fixes code when violations occur. The latency impact is moderate—adding verification and possible re-generation adds seconds to code generation, but this is acceptable for batch geospatial workflows. The main trade-off is engineering complexity: you must encode domain knowledge (CRS rules, topology constraints, metric ranges) explicitly rather than hoping the LLM learns it implicitly. For mission-critical applications like urban planning, environmental monitoring, or infrastructure analysis, this framework reduces hallucination and ensures geographic correctness without requiring expert review of every generated script.
Limitations and When Not to Use This
GeoContra assumes that geospatial contracts can be hand-authored upfront for each task family—this is scalable for well-defined domains like Boston zoning analysis but may be tedious or error-prone when task families are numerous, underspecified, or evolving. The paper evaluates on 7,079 tasks across 15 zones and 9 families, which is substantial but still bounded; it's unclear how repair success rates degrade with novel task types unseen during contract design or with out-of-distribution geographic regions. The framework also assumes that violations are detectable through static inspection, runtime assertion, and semantic validation—some subtle geographic errors (e.g., incorrect buffer radius for a spatial join) might pass all checks and only become apparent in downstream analysis. Finally, the repair loop is described as 'bounded' but the paper doesn't detail the iteration budget, timeout strategies, or failure modes when repair exhausts its bounds; in production, you need a clear degradation path (log error, escalate to human, return null result) when the system cannot self-correct.
Research Context
This work sits at the intersection of LLM-for-code generation and domain-specific verification, building on recent successes in using LLMs for scientific and engineering code but addressing a gap specific to geospatial systems. It extends the contract-based verification tradition (DbC, formal methods) into the LLM era, where code is generated rather than hand-written. The paper likely improves upon prior GIS automation work (e.g., rule-based spatial query systems, few-shot prompting for geospatial tasks) by adding a robust verification layer that doesn't require perfect LLM outputs. The evaluation on real Boston-area data and 9 task families (presumably including buffer operations, spatial joins, CRS transformations, etc.) provides a grounded benchmark for future work in domain-specific code generation verification, opening a research direction toward similar frameworks for other technical domains (astronomy, climate modeling, physics simulation) where output correctness and unit/constraint preservation are critical.
:::tip Subscribe Get weekly breakdowns of papers like this in AI Letters - the newsletter for engineers building production AI systems. :::