- A coordinate is not yet a spatial meaning: a system must preserve what a record represents, its source, units, and uncertainty.
- The model can coordinate an investigation; exact geometry, transformation, and file checks belong to explicit tools.
- Long-running work needs durable context: evidence references, hypotheses, tool state, unresolved questions, and permitted next actions.
- A result is ready only when the evidence, artefact, checks, and reviewer decision travel together.
A spatial agent is not made spatial by giving a language model a map tool. It needs to understand what each representation means, assemble a situation from incomplete evidence, do work in real geospatial software, preserve state, and prove the result.
That is a systems question. The model is one component in an evidence-bound workflow. It can help choose the next question, explain a result, and coordinate tools. It should not silently decide what a coordinate means, claim that a rendered map is correct, or hide an unresolved failure.
Start with spatial meaning
Geospatial work begins before analysis. A coordinate, an image, a polygon, a road segment, a raster cell, and a database row can all refer to the same place while carrying different meanings. The system must retain the representation, its coordinate reference, units, time, source, and limits. The OGC Simple Features standard associates geometry with a spatial reference system, while GeoJSON fixes a narrower WGS 84 longitude-latitude convention. The format changes what must be preserved. [1] [2]
| Representation | Question to preserve | Typical failure |
|---|---|---|
| Coordinate | Where is it, in which reference system and units? | A plausible point in the wrong reference system. |
| Image or observation | What is visible, when, and with what coverage? | A scene is treated as current or complete without support. |
| Geometry | What shape, relationship, precision, and scale are intended? | Invalid topology or a valid shape with the wrong meaning. |
| Map or project | How is the information symbolised and filtered? | A clean rendering hides missing or misclassified data. |
The language model can describe these questions and identify a missing field. Deterministic tools must handle exact geometry, coordinate transformations, topology, units, and file checks. Keeping those responsibilities separate makes a failure visible instead of turning it into confident prose. PostGIS, for example, exposes different operations for transforming coordinates and testing whether a geometry is well formed. [3]
Situate the problem
A useful request is more than a prompt. It is a bounded case: a question, an area and time, the sources that may be used, the candidate interpretations, constraints, missing evidence, and an acceptance check. Without those boundaries, the system can produce a technically tidy answer to the wrong spatial question.
A practical case record should make the evidence chain legible. Record where an observation came from, which transformation was applied, what was inferred, and which alternatives were rejected. Ten records copied from the same source are not ten independent witnesses. Provenance and dependence matter more than row count. W3C PROV provides a public model for relating entities, activities, and agents; it does not by itself decide whether two observations are independent. [4]
Evidence boundary
If the case cannot state what would count as a supported result, the next action is to ask for more evidence or refuse the task. A polished answer is not a substitute for a defined check.
Operate in the real tools
The work happens in a chain of tools, not in the chat window. A spatial agent should be able to select a permitted operation, pass a clear input contract, inspect the output, and stop when a check fails. The exact division depends on the workflow, but the responsibilities should remain explicit.
| Role | Useful responsibility | Required boundary |
|---|---|---|
| Model | Choose the next question, coordinate work, and explain uncertainty. | No silent changes to geometry, evidence, or acceptance rules. |
| GIS or spatial database | Run spatial predicates, topology checks, joins, and reference-system operations. | Inputs, versions, units, and outputs are recorded. |
| Code runtime | Perform repeatable transforms, file checks, and small calculations. | Operations are bounded, inspectable, and safe to retry. |
| Reviewer | Accept, reject, or request more evidence for the result. | The decision and its basis remain with the artefact. |
This is the practical meaning of Understand · Situate · Operate · Prove. Understand the representation. Situate the case and its evidence. Operate through bounded tools. Prove the output before it is trusted. The model can help move through the loop; it is not the surveyor, the source, or the reviewer.
Keep context across the job
Spatial work often outlasts one exchange. Files arrive at different times, a tool may fail, a reviewer may ask a narrower question, and a long operation may need to resume. A useful system therefore keeps a durable case record instead of relying on the latest conversation turn.
At minimum, keep the case identity; evidence references and provenance; hypotheses and rejected alternatives; tool actions and results; checkpoints; budgets and timeouts; unresolved questions; and the next permitted action. These are design requirements for a reliable workflow, not a claim that the public website provides a finished workspace.
- Make each checkpoint state what was known, changed, and checked.
- Make retries safe to identify and repeat, or record why they are not.
- Keep a failed or partial result visible rather than replacing it with a summary.
- Require a new decision when the evidence or task boundary changes.
Prove the result
A result is more than a file and a sentence. The evidence package should let another person understand what went in, what happened, what came out, and what remains uncertain. A rendered map helps a person inspect the work, but rendering alone does not prove the underlying data or operation.
This is where a spatial agent earns trust: not by sounding certain, but by making the evidence and limits inspectable. The honest outcome may be to act, to send the case for review, to ask for more evidence, or to refuse it. NIST's voluntary AI Risk Management Framework likewise treats documented roles, oversight, testing, and evaluation as system-level governance concerns; it is not a spatial-agent specification. [5]
When not to use this
An agent is not automatically the best tool. Use a direct GIS operation or a normal scripted workflow when the task is a single, deterministic transformation with a known input and a clear check. The extra coordination is not useful if it only hides a simple operation behind more moving parts.
Do not delegate the task to an agent when:
- the evidence is too incomplete to define a meaningful check;
- the decision is high consequence and no authorised reviewer is available;
- the scope, ownership, or permitted data access is unclear; or
- the workflow cannot preserve the inputs, operations, outputs, and failures.
Start with the smallest workflow that can be checked. Add model coordination only when it helps with changing questions, multiple tools, or a sequence that a person can still review.
Sources and boundary
This article is a generalised Axis Spatial research note based on geospatial engineering practice. It intentionally leaves out private project names, customer material, benchmark inputs, and unverified performance figures. The claims above are a current design frame and should be tested against a named task, dataset, tool configuration, verifier, and review record before they are treated as a result.
For the wider public research programme, see the current research programme. It explains how Axis Spatial approaches spatial intelligence, evidence, and verifiable geospatial work.