Spatial-Agent: A New Concept‑Transformation Paradigm for Map Agents

When large language models are equipped with map, search, routing, and POI tools, the intuitive expectation is that an agent can answer complex geospatial questions simply by invoking enough tools. In practice, many tasks require the system to organize a sequence of spatial analyses rather than just call individual APIs.

Spatial‑Agent and the GeoFlow Graph

Spatial‑Agent proposes that geospatial QA should be modeled as a concept transformation : starting from spatial concepts in natural language and progressively converting them into an executable geospatial workflow. The core of this approach is the GeoFlow Graph , a directed acyclic graph that captures objects, conditions, supporting structures, and final metrics, and maps them to concrete tools such as geocoding, place search, routing, distance matrix, spatial filtering, and trip optimization.

Five‑Step Workflow

Identify spatial concepts and functional roles from the question.

Retrieve common geospatial analysis templates to form candidate transformation structures.

Compose a GeoFlow Graph that satisfies all constraints.

Decompose the graph into operator‑concept pairs and map them to specific tools.

Execute the tools in topological order, record intermediate states, and generate the final answer.

Core Concepts and Functional Roles

Borrowing from GIScience, Spatial‑Agent distinguishes two categories of theoretical components.

Core concepts of spatial information answer “what spatial entities appear in the question.” The paper lists:

Location – cities, regions, coordinates, anchors.

Object – discrete entities such as restaurants, schools, hospitals.

Field – continuous distributions like distance fields, temperature, elevation.

Event – time‑stamped occurrences such as accidents or traffic incidents.

Network – connected structures like road, transit, or river networks.

Amount – aggregated quantities such as total area or population.

Proportion – normalized metrics like density or coverage rate.

Functional roles answer “what role each concept plays in the analysis.” The roles include Extent, Temporal Extent, Sub‑condition, Condition, Support, and Measure. For example, in a query about the proportion of specific facilities in a region, the region is the Extent, the facility filter is the Condition, the set of objects to be counted is the Support, and the final proportion is the Measure.

The paper defines a procedural priority order: Sub‑condition → Condition → Support → Measure, ensuring that constraints are handled before context, and metrics are computed last.

Ensuring Executability of the GeoFlow Graph

A valid GeoFlow Graph must satisfy five constraints:

Acyclicity : no cycles, guaranteeing an executable order.

Role Ordering : transformation edges must respect the functional‑role precedence.

Type Compatibility : upstream output types must be accepted by downstream operators.

Data Availability : each transformation must map to an actual tool.

Connectivity : intermediate nodes must link both to context and to the final metric.

These constraints address common hidden failures such as mismatched data types, missing intermediate results, or irrelevant intermediate calculations.

Factorized Operator‑Concept Hypergraph

At the execution layer, the GeoFlow Graph is converted into a factorized operator‑concept hypergraph. This representation captures the multiple inputs and auxiliary parameters required by real tools (e.g., routing needs start/end points, travel mode, waypoints, and time windows). Factor nodes encode these extra parameters, allowing the graph to be grounded in concrete tool calls.

Template Library

To avoid the combinatorial explosion of constructing graphs from scratch, Spatial‑Agent maintains a library of verified macro‑templates that encode common geospatial analysis patterns. The model selects and composes these templates, then binds specific parameters to generate a complete, executable graph.

Experimental Evaluation

Spatial‑Agent is evaluated on two benchmarks:

MapEval‑API : API‑driven tasks covering Place Info, Nearby, Routing, and Trip across 54 countries and 180 cities.

MapQA : An open‑domain geospatial QA dataset derived from OpenStreetMap with 3,154 question‑answer pairs.

Key findings:

Spatial‑Agent + GPT‑4o‑mini significantly outperforms the MapEval‑API baseline, showing that structuring tool usage matters.

Performance is comparable across LLaMA‑70B, Qwen2.5‑72B‑Instruct, and GPT‑4o‑mini, indicating that the GeoFlow Graph representation transfers across model families.

Removing the template library drops overall accuracy to 39.32 % and degrades each task category, confirming that macro‑templates contribute more than mere engineering speed‑ups.

Two‑stage fine‑tuning experiments on Qwen‑14B show that supervised‑fine‑tuning (SFT) raises accuracy from 49.59 % to 56.84 %, DPO to 55.13 %, and the combination of SFT + DPO reaches 60.58 %.

Error Analysis

Manual inspection of 68 MapEval‑API failures reveals that most errors occur during execution rather than graph construction. The distribution is:

Data Quality Issues – 45.6 %

Search Result Mismatch – 33.8 %

Concept & Role Assignment – 10.3 %

Response Generation – 10.3 %

Thus, once a reliable geospatial workflow is built, the bottleneck shifts to external data quality and API reliability (e.g., ambiguous place names, missing POI data, incomplete opening hours, or mismatched routing results).

Latency and Cost

Direct LLM calls have the lowest latency but lack tool grounding, limiting accuracy. Among agentic methods, Spatial‑Agent is fastest on Routing and comparable to ReAct on Nearby and Trip. Using GPT‑4o‑mini pricing, all methods cost less than $0.003 per query; Spatial‑Agent averages about $0.0022, achieving a good balance between cost and accuracy.

References

Spatial-Agent: Agentic Geo‑spatial Reasoning with Scientific Core Concepts

Code: https://github.com/ecerybao/Spatial-Agent