Natural Language Interfaces for Spatial and Temporal Databases: A Comprehensive Overview of Methods, Taxonomy, and Future Directions
Organizations: Department of Computer Science, Marquette University, Milwaukee, Wisconsin, USA
Abstract
The task of building a natural language interface to a database, known as NLIDB, has recently gained significant attention from both the database and Natural Language Processing (NLP) communities. With the proliferation of geospatial datasets driven by the rapid emergence of location-aware sensors, geospatial databases play a vital role in supporting geospatial applications. However, querying geospatial and temporal databases differs substantially from querying traditional relational databases due to the presence of geospatial topological operators and temporal operators. To bridge the gap between geospatial query languages and non-expert users, the geospatial research community has increasingly focused on developing NLIDBs for geospatial databases. Yet, existing research remains fragmented across systems, datasets, and methodological choices, making it difficult to clearly understand the landscape of existing methods, their strengths and weaknesses, and opportunities for future research. Existing surveys on NLIDBs focus on general-purpose database systems and do not treat geospatial and temporal databases as primary focus for analysis. To address this gap, this paper presents a comprehensive survey of studies on NLIDBs for geospatial and temporal databases. Specifically, we provide a detailed overview of datasets, evaluation metrics, and the taxonomy of the methods for geospatial and temporal NLIDBs, as well as a comparative analysis of the existing methods. Our survey reveals recurring trends in existing methods, substantial variation in datasets and evaluation practices, and several open challenges that continue to hinder progress in this area. Based on these findings, we identify promising directions for future research to advance natural language interfaces to geospatial and temporal databases.
Figures & tables
| Dataset Family | Representative Datasets | Strengths | Limitations |
|---|---|---|---|
| Benchmark datasets | GeoQuery [ 56 ] , Restaurants [ 56 ] , GeoAnQu Corpus [ 22 ] , GeoSQL-Bench [ 57 , 58 ] , TRUCE [ 59 ] , SUSHI [ 59 ] , TACO [ 60 ] , NALMOBench [ 61 ] , Text-to-PromQL Benchmark [ 62 ] | Include predefined natural-language questions paired with executable queries, which makes it easier to evaluate whether a system correctly interprets spatial or temporal operators. | These datasets often do not reflect the ambiguity that appear in real-world GIS databases. |
| Real-world GIS datasets | Oracle Spatial Layers [ 63 ] , Denton County GIS [ 21 ] , TIGER/OSM/MODIS [ 64 ] , berlintest [ 65 , 66 ] , nanjingtest [ 65 , 66 ] , chinawater [ 66 ] , NYC GIS [ 11 ] , OSM Bavaria + SoilMap [ 67 ] , SpatialQueryQA [ 68 ] , KaggleDBQA [ 68 , 69 ] , SpatiaLite [ 12 ] , GeoQueryJP [ 69 ] , TourismQA [ 70 ] | These datasets come from real GIS databases or OpenStreetMap layers, allowing NLIDB systems to be tested in realistic spatial environments. | These datasets usually do not include predefined natural-language query sets, so researchers often need to design their own evaluation queries, which makes results difficult to compare across different NLIDB systems. |
| Synthetic / domain-specific datasets | BerlinMOD trajectories [ 71 ] , SECONDO trajectory demo [ 72 ] , MOQ + BT trains [ 73 ] , Extended MOQ + BT [ 74 ] | These datasets emphasize specific spatial or spatiotemporal query tasks, which helps researchers examine how NLIDB systems interpret trajectory relations, temporal predicates, and moving-object queries. | These datasets are artificially generated, often simplifying real geographic contexts, and therefore may not capture the data irregularities and interpretation challenges commonly found in real GIS databases. |
| Dataset (Short Name) | Year | Spatial | Temporal | Benchmark | RealGIS | Synthetic |
|---|---|---|---|---|---|---|
| Oracle Spatial Layers [ 63 ] | 2007 | ✓ | ✗ | ✗ | ✓ | ✗ |
| Denton County GIS [ 21 ] | 2009 | ✓ | ✗ | ✗ | ✓ | ✗ |
| BerlinMOD Trajectories [ 71 ] | 2009 | ✓ | ✓ | ✓ | ✗ | ✓ |
| TIGER / OSM / MODIS [ 64 ] | 2015 | ✓ | ✗ | ✗ | ✓ | ✗ |
| GeoQuery / Restaurants [ 56 ] | 2019 | ✓ | ✗ | ✓ | ✗ | ✗ |
| SECONDO Traj (Demo) [ 72 ] | 2020 | ✓ | ✓ | ✗ | ✗ | ✓ |
| Dataset / Data Source | Paper(s) Using Dataset | #NLQs | Query Language | NLQ Origin | Split | Public |
| Operational GIS Databases (Execution-Centric) | ||||||
| Oracle Spatial Layers [ 63 ] | [ 63 ] | N/A | Spatial SQL | None | ✗ | ✓ |
| Denton County GIS [ 81 ] | [ 21 ] | 30 | SQL | Human | ✗ | ✓ |
| BerlinMOD Trajectories [ 71 ] | [ 71 ] | N/A | SECONDO | None | ✗ | ✓ |
| SECONDO Demo Traj [ 76 ] | [ 72 ] | N/A | SECONDO | None | ✗ | ✓ |
| BT Berlin Trains [ 76 ] | [ 73 ] , [ 74 ] | N/A | SECONDO | None | ✗ | ✓ |
| Evaluation Dimension | Spatial NLIDB | Spatiotemporal NLIDB | Time-Series NLIDB |
|---|---|---|---|
| Execution-Based accuracy | Correct execution of spatial queries | Correct execution of time-aware queries | Not applicable |
| Interpretation / Translation Accuracy | Correct mapping of NL queries to spatial intent | Correct identification of spatiotemporal intent | Correct alignment of text with signal semantics |
| Precision-Oriented accuracy | Precision of spatial results | Precision of trajectory or temporal outputs | Precision of retrieved time-series segments |
| Structural / Syntactic accuracy | Optional SQL structure matching | Rarely used | Not applicable |
| Retrieval Quality (Ranking-Based) | Rare | Occasional | Primary (e.g., mAP) |
| Efficiency and Scalability | Runtime and performance | Trajectory-length and time-range efficiency | Embedding and retrieval latency |
| Paper | Year | Model Type | DBMS | Evaluation Metric (Normalized) | NLIDB Category |
|---|---|---|---|---|---|
| [ 92 ] | 2000 | Fuzzy grammar + possibility theory-based semantic parsing | Relational GIS (SQL preprocessor) | Qualitative / Human Evaluation | Spatial NLIDB |
| [ 63 ] | 2007 | Menu-based NLI + rule-based grammar | Oracle Spatial | Qualitative / Human Evaluation | Spatial NLIDB |
| [ 21 ] | 2009 | Rule-based NLP + semantic parsing | PostGIS | Execution-Based Accuracy | Spatial NLIDB |
| [ 71 ] | 2009 | Data generation and benchmark framework | SECONDO | Efficiency and Scalability | spatiotemporal NLIDB |
| [ 64 ] | 2015 | MapReduce spatial framework (non-NLI) | HDFS / SpatialHadoop | Efficiency and Scalability | Spatial NLIDB (Context) |
| [ 56 ] | 2019 | Seq2Seq GRU + spatial comprehension model | Custom geospatial DB | Interpretation / Translation Accuracy | Spatial NLIDB |
| Pipeline Stage | Spatial NLIDB | Spatiotemporal / Moving Objects NLIDB | Time-Series NLIDB |
|---|---|---|---|
| Natural Language Parsing | Entity extraction focused on places, spatial relations, and numeric constraints | Entity extraction extended with temporal expressions, object identities, and trajectory references | Text understanding aligned to signal patterns, trends, or comparative descriptions |
| Domain Mapping | Mapping to spatial schemas, layers, and geometry types (point, line, polygon) | Mapping to spatiotemporal schemas, trajectory identifiers, regions, and temporal indexes | Alignment between text descriptions and signal representations in a shared embedding space |
| Query / Task Identification | Classification into spatial query types (range, NN, spatial join, aggregation) | Richer classification including interval, trajectory similarity, cross-region, and detour queries | Implicit task formulation as retrieval or comparison rather than explicit query typing |
| Query Construction Strategy | Template-based spatial SQL or algebraic operators | Structured spatiotemporal operators with time-aware constraints and index selection | No explicit SQL generation; retrieval via embedding similarity and contrastive learning |
| Execution Model | Single-shot spatial query execution | Execution with temporal filtering, trajectory operators, and optimization-aware planning | Similarity-based retrieval over learned representations, not database execution |
| Result Validation | Execution success and spatial result correctness | Execution accuracy combined with efficiency and trajectory correctness | Retrieval accuracy based on embedding similarity and ranking metrics |
| Method Family | Representative Approaches | Strengths | Limitations |
|---|---|---|---|
| Rule-based / Grammar-driven NLIDBs | Rule-based NLP pipelines [ 97 , 98 , 99 ] , Handcrafted grammars [ 92 , 63 , 22 ] , Template-based query generation [ 21 ] | These systems translate queries through predefined linguistic rules, making the reasoning process easier to trace and the generated queries easier to inspect. | These systems rely on handcrafted grammars and rules, which makes them difficult to scale and adapt to diverse or evolving query formulations. |
| Neural / Machine-learning NLIDBs | Seq2Seq models [ 1 , 2 ] , LSTM-based classifiers [ 73 , 65 , 66 ] , Neural semantic parsing [ 100 , 3 , 101 , 102 ] | These systems learn relationships between natural-language queries and database operations from training data, allowing them to handle linguistic variation more effectively than purely rule-based systems. | These systems depend on labeled training data and learned representations, which can reduce interpretability and limit generalization to unseen query types or database schemas. |
| LLM-based NLIDBs | Prompt-based text-to-SQL systems [ 11 , 103 , 104 ] , Schema-aware LLM prompting [ 12 , 69 , 105 , 106 ] | These systems use LLMs to interpret natural-language questions and generate database queries through prompt-based reasoning, allowing them to handle a wide range of query expressions without relying on handcrafted rules. | These systems still suffer from spatial reasoning errors and may hallucinate database tables, columns, or spatial functions that do not exist in the database schema. |
| Multi-agent NLIDBs | Agentic LLM pipelines [ 93 ] , Task decomposition frameworks [ 68 , 67 ] , Reasoning + tool use [ 107 , 108 , 35 , 109 ] | These systems split the query task across multiple agents, allowing complex queries to be solved through step-by-step reasoning, tool use, and verification. | Because these systems rely on multiple interacting agents, they introduce additional system complexity, increase query latency due to multiple model calls, and require higher computational cost. |
| Method Class | Interpretation Mechanism | Learned Components | Schema Understanding | Query Planning | Execution & Validation | Ambiguity Handling | Extensibility |
|---|---|---|---|---|---|---|---|
| Rule-Based & Grammar-Driven | Handcrafted grammars and rules | None | Manual, rule-based mapping | Deterministic | Built-in constraints | Explicit rule encoding | Low |
| Neural & Hybrid Semantic Parsing | Neural classifiers with structured templates | Partial (e.g., LSTM, embeddings) | Knowledge-base assisted | Template-driven | Deterministic execution | Learned + rule-based | Medium |
| LLM-Based Interfaces | Prompt-based language reasoning | Fully learned | Prompt- and schema-context understanding | Generative | Limited or iterative | Implicit | High |
| Multi-Agent Architectures | Coordinated agent reasoning | Fully learned | Agent-mediated schema reasoning | Planned and iterative | Explicit agent validation | Explicit reasoning steps | Very High |