Paper deep dive
Natural Language Interfaces for Spatial and Temporal Databases: A Comprehensive Overview of Methods, Taxonomy, and Future Directions
Samya Acharja, Kanchan Chowdhury
Intelligence
Status: succeeded | Model: google/gemini-3.1-flash-lite-preview | Prompt: intel-v1 | Confidence: 97%
Last extracted: 3/26/2026, 1:47:01 AM
Summary
This paper provides a comprehensive survey of Natural Language Interfaces to Databases (NLIDBs) specifically tailored for spatial, temporal, and spatiotemporal (ST-NLIDBs) domains. It categorizes existing methods, datasets, and evaluation metrics, highlighting the unique challenges posed by geospatial topological operators and temporal predicates compared to traditional relational databases. The authors identify current research gaps and propose future directions for advancing ST-NLIDB systems.
Entities (6)
Relation Signals (3)
PostGIS → extends → PostgreSQL
confidence 100% · PostGIS [8] for spatial functionality in PostgreSQL
MobilityDB → supports → Spatiotemporal Data
confidence 95% · MobilityDB [10]... with native trajectory types and spatiotemporal operators
ST-NLIDB → targets → Spatial Database
confidence 95% · ST-NLIDBs refer to the NLIDB systems for geospatial, time-series, and spatiotemporal database systems.
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
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.
Tags
Links
- Source: https://arxiv.org/abs/2603.23375v1
- Canonical: https://arxiv.org/abs/2603.23375v1
Trouble viewing inline? Open PDF directly →
Full Text
124,034 characters extracted from source content.
Expand or collapse full text
Received x x, x; accepted x x, x; date of publication x x, x; date of current version x x, x. Digital Object Identifier 10.1109/ACCESS.X.X Natural Language Interfaces for Spatial and Temporal Databases: A Comprehensive Overview of Methods, Taxonomy, and Future Directions SAMYA ACHARJA, KANCHAN CHOWDHURY Department of Computer Science, Marquette University, Milwaukee, Wisconsin, USA Corresponding author: Kanchan Chowdhury (kanchan.chowdhury@marquette.edu). 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. INDEX TERMS Natural language interfaces, spatial databases, GeoAI, moving object databases, GIS I. INTRODUCTION We live in an era where conversational agents are gaining more prominence over static interfaces requiring special- ized language expertise to query and retrieve data. Virtual agents with conversational ability such as Amazon Alexa and Google Assistant have become increasingly popular. While chatbots are used to give automatic response to user queries written in natural language, Amazon Alexa and Google Assistant allow users to communicate through natural language speech. In both the cases, these technologies need to understand the natural language query provided by the user and fetch the query answer from their data storage system. In order to use such technologies on systems where data is stored in databases, these automated question answering systems should be able to translate natural language ques- tions to database queries, which emphasizes the need for Natural Language Interfaces to Databases, shortly known as NLIDBs [1]–[4]. NLIDBs allow database query-agnostic users who lack database expertise to issue queries to the database in natural language (NL), such as English. Given such an NL query, an NLIDB system automatically generates the corresponding database query [5] and passes it to the database for execution. Because of the inherent complexity in translating NL questions to database queries, the task of building an efficient NLIDB is an open research problem. It should be noted that translating NL questions to database queries is different from predicting next database queries in a human-database interaction [6], [7]. VOLUME 4, 20161 arXiv:2603.23375v1 [cs.DB] 24 Mar 2026 The rapid growth of location-aware sensors has led to a sharp increase in spatial and spatiotemporal datasets, which supports a wide range of applications, such as mobility ana- lytics and location-based services. To meet the resulting data management and query processing demands, many database systems now provide spatial and temporal extensions that introduce geometric data types, spatial indexing, and special- ized operators for geospatial and temporal predicates. Repre- sentative examples include but are not limited to PostGIS [8] for spatial functionality in PostgreSQL, GeoSpark [9] for distributed geospatial analytics in SparkSQL, and Mobili- tyDB [10] for moving object functionality in PostgreSQL and PostGIS. However, writing database queries to retrieve and manage information is inherently challenging, and geospa- tial and temporal databases further increase this difficulty by introducing geospatial and temporal operators that often require domain expertise. That is why NLIDBs for geospatial and temporal databases [11], [12] have become an impor- tant research area, drawing interest from database, NLP, and geospatial research communities. Recent development of geospatial and temporal deep learning frameworks [13]–[16] also played a role in accelerating the research on spatial and temporal NLIDBs. While the complex structure of database queries coupled with the inherent ambiguity of NL questions makes build- ing an NLIDB system a challenging task, the spatial and temporal domains introduce extra challenges [17] [18] [19]. Spatial and temporal datasets include many attributes that must be considered together, like geometry, topology, and relative distances, which makes the reasoning complex [20]. Besides, NLIDBs for spatial and temporal databases need to handle the semantic interpretation of spatial and temporal operators, such as ST_Contains, ST_Distance, etc. [21], [22]. Recent works have started adopting neural models [23], large language models [24], and even multi-agent reasoning frameworks [24]. However, these approaches vary widely, and the research community lacks a unified overview of the methods used by NLIDBs in this domain, the datasets they use, and their evaluated strategy [25]. A. LIMITATIONS OF EXISTING SURVEYS Although a substantial number of review papers already exist on NLIDBs, most of them primarily focus on traditional, non- spatial relational settings. For example, several surveys [26]– [29] review early rule-based and grammar-driven NLIDB systems, as well as neural approaches for translating NL questions into SQL, but without considering spatial or tem- poral semantics. Other works provide comparative analyses of NLIDB architectures and interaction paradigms [30], or focus specifically on neural and deep learning models for NL to SQL (NL2SQL) tasks in standard relational databases [31], [32]. More recent review papers discuss broader trends in NL interfaces, including advances in learning-based methods and system design [33], [34], yet they do not explicitly address spatial predicates, spatiotemporal reasoning, or time-series querying. Some surveys move closer to database-oriented perspec- tives by examining NL interfaces across different database paradigms [17], [35], or by reflecting on future research di- rections for NLIDB systems [18], [36]. However, even these works largely treat databases as abstract relational structures and do not engage with the unique challenges posed by spa- tial geometries, topological relations, temporal intervals, or trajectory data. As a result, spatial SQL languages, spatiotem- poral query operators, and time-series–specific database con- structs remain outside the scope of these surveys. Another set of related works, [37] [38] [39] [40], broaden the discussion about NL interfaces for databases in general and provide useful information about system design and evaluation. Re- cent large language model (LLM)-focused surveys [41]–[47] further consolidate progress in LLM-based interfaces by re- viewing modern architectures, learning-based methods, and evaluation practices across NLIDB systems. However, the primary emphasis of these surveys remains on NLIDBs for general-purpose databases, and ST-NLIDBs are not treated as the primary target of analysis. Another category of LLM- based surveys [48] [49] has explored large models for time- series and spatio-temporal data more broadly. However, these studies focus on LLM architectures and pre-trained model paradigms for generic applications involving spatiotemporal and time-series data, rather than on natural-language inter- faces for querying spatial or spatiotemporal databases. A recent survey [50] also examines agentic AI systems for spatio-temporal intelligence. This survey focuses on agentic AI frameworks for spatio-temporal intelligence, emphasizing reasoning, tool use, and application domains rather than natural-language interfaces for querying spatial and temporal databases. Consequently, despite the richness of existing NLIDB survey literature, there is still a clear gap in comprehensive reviews that systematically focus on NLIDBs for spatial, spatiotemporal, and time-series databases, motivating the need for our study. B. CONTRIBUTIONS This is the first comprehensive review that offers a detailed analysis of the existing research on NLIDBs for database sys- tems in spatial and temporal domain, specifically geospatial, time-series, and spatiotemporal (moving object) databases. In the rest of the paper, we use ST-NLIDBs to refer to the NLIDB systems for geospatial, time-series, and spatiotem- poral database systems. The review aims to provide a deep understanding of the main methods, datasets, and evaluation strategies used in the literature, while also identifying the ma- jor limitations and pointing toward possible future research directions. The key novelty of this study includes defining various ST-NLIDBs with examples, comparative analysis of benchmark datasets in terms of key characteristics and target NLIDBs, formalizing the evaluation metrics used for evalu- ating ST-NLIDBs, summarizing the common methodologi- cal pipeline for ST-NLIDBs, elaborating various classes of methodologies with key takeaway messages, advantages, and 2VOLUME 4, 2016 disadvantages, discussing the limitations of various methods and datasets, and proposing future research directions. Our contributions can be summarized as follows. • We outline various database systems in general-purpose and spatiotemporal domains and define corresponding NLIDBs with example queries (Section I). • We summarize the datasets and evaluation metrics used for evaluating ST-NLIDBs. We provide a categorization of the benchmark datasets and list the key characteristics, advantages, and disadvantages of various datasets (Section I). • We summarize the common methodological pipelines among the NLIDBs in this domain (Section IV). • We provide a taxonomy of the methods and discuss details under every class of methods with key takeaway messages, strengths, and limitations (Section V). • We identify key limitations of existing datasets and meth- ods, and discuss future research directions (Section VI). We emphasize that this manuscript is a review article rather than an empirical study. Therefore, its purpose is not to present original experiments or benchmark results, but to analyze and critically discuss existing methods, datasets, evaluation metrics, strengths and limitations of current stud- ies, and open research challenges. I. BACKGROUND This section briefly outlines the inputs and outputs (I/Os) of NLIDBs for various database systems, in addition to classifying the database systems in terms of the presence of spatial and temporal features. At first, we define the I/Os of an NLIDB for a general-purpose relational database system. After that, we classify the spatial and temporal database systems and show sample I/Os for target NLIDBs. A. GENERAL PURPOSE NLIDBS As stated earlier in Section I, the task of an NLIDB is to trans- late an NL question into a database query, ultimately helping users who lack database expertise to retrieve information from databases. The target databases for these NLIDBs are usually relational databases which include but are not limited to PostgreSQL, Oracle, MySQL, and SQLite. Figure 1 shows a sample dataset in the form of a relational table named business, a sample input NL query and corresponding output database queries, and execution output of the ground truth database query. The complex structure of SQL queries coupled with the in- herent ambiguity of NL questions makes building an NLIDB system a challenging task. The difficulty in interpreting the correct semantic meaning of NL questions often results in the wrong synthesis of SQL queries. A small difference in the structure of a NL question might result in a huge difference in the semantic meaning of the question. Let us consider two NL queries for the relation business in Figure 1: (1) What is the number of businesses of all ratings in Nevada and (2) What is the total number of businesses in Nevada for each rating. Although these two NL queries are almost similar, the formation of SQL query for the second one requires a GROUP BY operation whereas the SQL query corresponding to the first one does not have any GROUP BY operation. Besides this kind of syntactic and semantic ambiguities of NL questions, use of phrases and system specific terms makes the interpretation of NL questions much more difficult. The semantic meaning of a word varies based on the context in which it is used. B. ST-NLIDBS By spatial and temporal databases, we refer to three categories of database systems: (i) spatial databases, (i) time-series databases, and (i) spatiotemporal/moving- object/trajectory databases. ST-NLIDBs can be classified into three general classes based on their target database systems and support for spatial and temporal features: (i) spatial NLIDBs, (i) time-series NLIDBs, and (i) spatiotemporal NLIDBs. 1) Spatial NLIDBs Most of the well-known relational databases support spatial extensions to support storage, querying, and management of geospatial datasets containing location coordinates. Un- der this category, we consider only databases or extensions of databases that have specialized support for location co- ordinates, but treat temporal columns similarly to generic relational databases. For example, PostGIS [8] extension provide native geospatial support for PostgreSQL database. Apache Sedona, formerly GeoSpark [9], extends SparkSQL with geospatial support for distributed cluster computing in Apache Spark. SpatialHadop [51] adds native support for handling and querying massive geospatial datasets di- rectly on Apache Hadoop’s MapReduce architecture. Se- donaDB [52] is a single-node analytical database engine that treats geospatial datasets as first-class citizen. These spatial databases extend relational tables with a dedicated geometry or geography column that can store location coordinates as geometric objects, including points, line strings, and polygons, and more complex types such as multipolygons. This representation enables the database to model real-world entities, such as sensor locations, road net- works, or administrative boundaries directly within database tables. To query and analyze these geospatial objects, spatial databases provide a rich library of spatial operators and func- tions, such as ST_Contains and ST_Intersects for topological relationships, and ST_Distance for distance-based filtering and ranking. Together with spatial indexing, these primitives allow efficient execution of common geospatial tasks such as point-in-polygon tests, proximity search, and spatial joins. Spatial NLIDBs intend to translate NL questions to spatial database queries. This task is more challenging than general purpose NLIDBs because spatial NLIDBs need to handle the semantics of geometry objects and topological and distance relationships between geometry objects. Query Example 1 shows a spatial NLIDB query from nanjingtest [53] dataset. VOLUME 4, 20163 business_idnamecitystateratingreview_count 1 2 3 4 5 Texas de Brazil Yeti Helpers Best Buy Jasmine Base Exchange Dallas Henderson Madison Las Vegas Nellis AFB Texas Nevada Wisconsin Nevada Nevada 4.0 4.5 2.5 3.5 3.0 1008 11 24 274 31 (a) Part of the business relation on Yelp Database NL Question: What are the names and average ratings of each business in Nevada with at least 31 reviews? Ground Truth SQL: SELECT name, rating FROM business WHERE state = ‘Nevada’ AND review_count >= 31 SQL1: SELECT name, rating FROM business WHERE review_count >= 31 AND state = ‘Nevada’ SQL2: SELECT rating FROM business WHERE state = ‘Nevada’ AND review_count > 31 SQL3: SELECT rating, city FROM business WHERE state = ‘Nevada’ AND review_count > 31 SQL4: SELECT city FROM business WHERE state = ‘Nevada’ AND review_count >= 31 (b) An example NL question with ground truth SQL query and 4 SQL queries translated by NLIDBs namerating Jasmine Base Exchange 3.5 3 Ground Truth SQL Answer rating 3 SQL2 Answer ratingcity 3.5 Las Vegas SQL3 Answer city Las Vegas Nellis AFB SQL4 Answer namerating Jasmine Base Exchange 3.5 3 SQL1 Answer (c) Output Relations for SQL Queries FIGURE 1: A sample of the Business relation in Yelp, a sample natural language question with the ground truth SQL query, and 4 queries translated by various NL-2-SQL approaches as well as the output relations for such queries. Query Example 1: Spatial NLIDB Query NL Query: List the name of all POIs that are available in Jiangning District. Executable Query (PostGIS): SELECT POI.name FROM POI JOIN district ON ST_Within(POI.geom, district.geom) WHERE district.name= ‘Jiangning District’; 2) Time-Series NLIDBs Time-series databases typically represent temporal data as records with an explicit timestamp column and often opti- mize physical storage and indexing around the time column. They commonly support time-aware operators and functions for windowed aggregation and trend analysis. Many database systems provide time-series functionality to support efficient querying and management of timestamped data. Under this category, we consider databases or extensions that treat time or timestamp as a first-class concept and provide special- ized support for time-indexed data, while not necessarily providing native support for geospatial data. For example, TimescaleDB [54] extends PostgreSQL with hypertables and time-oriented query optimizations for scalable time-series analytics. InfluxDB [55] is a time-series database that sup- ports time-centric querying for metrics and IoT data. These temporal analytics are supported through constructs such as time_bucket, continuous aggregates, and other built-in temporal operators. The purpose of a time-series NLIDB is to translate NL questions to time-series database queries. Query Example 2 shows a time-series NLIDB query from InfluxDB’s NOAA water sample dataset. Query Example 2: Time-Series NLIDB Query NL Query: How many water-level readings were recorded at the Coyote Creek station in 12-minute intervals between 00:00 and 00:30 UTC on Aug 18, 2019? Executable Query (InfluxQL): SELECT COUNT(water_level) FROM h2o_feet WHERE location = ‘coyote_creek’ AND time≥ ‘2019-08-18T00:00:00Z’ AND time≤ ‘2019-08-18T00:30:00Z’ GROUP BY time(12m); 3) Spatiotemporal NLIDBs In addition to purely spatial extensions, a growing class of systems provides specialized support for spatiotemporal or moving object data, where objects move or evolve over time and queries must jointly reason about where and when. Under this category, we consider databases and extensions that treat trajectories and time-indexed geometries as first-class entities, rather than simply pairing an ordinary timestamp column with a geometry column. Query Example 3: Spatiotemporal NLIDB Query NL Query: Find the 5 continuous nearest neighbors to train 100 between 6:00 and 19:00 o’clock. Executable Query (SECONDO): let t100 = Trains feed filter[.Id = 100] extract[Trip]; queryUTOrdered_rtreeUTOrderedfeedfil- ter[(deftime(.UTrip) intersects [const periods value (("2020- 11-20-06:00""2020-11-20-19:00"TRUETRUE))])] nearest_neighbor[UTrip, t100, 5] consume; Representative databases include MobilityDB [10], which extends PostgreSQL and PostGIS with native trajectory types and spatiotemporal operators for moving objects and SEC- ONDO [75], a research system that models moving regions and trajectories through dedicated spatiotemporal algebras. 4VOLUME 4, 2016 TABLE 1: Major dataset families used in ST-NLIDB research: representative datasets, strengths and limitations Dataset FamilyRepresentative DatasetsStrengthsLimitations Benchmark datasetsGeoQuery[56],Restaurants [56],GeoAnQuCorpus[22], GeoSQL-Bench [57], [58], TRUCE [59], SUSHI [59], TACO [60], NALMOBench [61], Text-to-PromQL Benchmark [62] Includepredefinednatural- 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 re- flect the ambiguity that appear in real-world GIS databases. Real-worldGIS datasets Oracle Spatial Layers [63], Den- ton 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] Thesedatasetscomefrom realGISdatabasesor OpenStreetMap layers, allowing NLIDB systems to be tested in realistic spatial environments. These datasets usually do not includepredefinednatural- languagequerysets,so researchersoftenneedto design their own evaluation queries, which makes results difficulttocompareacross different NLIDB systems. Synthetic/domain- specific datasets BerlinMOD trajectories [71], SEC- ONDO trajectory demo [72], MOQ + BT trains [73], Extended MOQ + BT [74] These datasets emphasize spe- cific spatial or spatiotemporal query tasks, which helps re- searchers examine how NLIDB systems interpret trajectory re- lations, temporal predicates, and moving-object queries. These datasets are artificially generated, often simplifying real geographic contexts, and there- fore may not capture the data irregularities and interpretation challenges commonly found in real GIS databases. Spatiotemporal or moving object databases typically repre- sent moving objects as sequences of time-stamped points, known as trajectories or as time-varying geometries, and they provide indexing schemes that couple spatial and temporal locality. This design enables efficient evaluation of queries that are difficult to express and optimize in standard spatial databases Accordingly, these systems support spatiotemporal predicates and operators for time slicing and temporal joins, distance-over-time and closest-approach queries, and trajec- tory similarity and pattern mining, in addition to traditional spatial predicates. Spatiotemporal NLIDBs, also known as moving ob- ject NLIDBs, aim to translate natural-language questions into spatiotemporal database queries. Compared to spatial NLIDBs, this translation is more challenging because the interface must interpret temporal expressions and event con- straints and map them to time-aware predicates, and correctly compose spatial and temporal semantics over trajectories. Note that spatiotemporal NLIDBs denote only one category ST-NLIDBs in our definition. Query Example 3 illustrates a representative spatiotemporal NLIDB query from BT Berlin Trains [76] dataset. I. DATASETS AND EVALUATION METRICS In this section, we provide a summary of the datasets and evaluation metrics used by NLIDBs for geospatial and tem- poral databases. A. DATASETS ANALYSIS Studies on ST-NLIDBs use a wide range of datasets that differ in spatial structure, temporal coverage, semantic rich- ness, and their intended evaluation purposes. Although their methodological structures vary, the datasets used across the literature can still be grouped into three broad families: benchmark datasets, real-world geographic information sys- tem (GIS) datasets, and synthetic or domain-specific datasets. These categories reflect both the evolution of NL interfaces for spatial data and the different methodological objectives of the systems being evaluated. Each of these dataset types plays a different role in system evaluation and comes with its own advantages and limitations. To give a quick overview before the detailed discussion of the datasets, Table 1 summarizes representative datasets in each family along with their main strengths and limitations. To provide a clearer picture of the data used in existing work, Table 2 summarizes the datasets employed across the included studies along with their key characteristics. As shown in the table, the datasets used by different systems are diverse. Many spatial NLIDB studies rely on real GIS datasets, including OpenStreetMap (OSM) layers and regional spatial databases, reflecting practical deploy- ment scenarios. Time-series NLIDB approaches typically rely on benchmark-style datasets designed for retrieval or comparison tasks rather than direct database querying. Table 2 illustrates the categories and publication years of datasets used across various ST-NLIDBs. Table 3 provides a detailed overview of the datasets used across the studies included in this review, along with their key characteristics. The table is designed to highlight how different types of data support NL interfaces for spatial, spa- tiotemporal, and time-series databases, and to make explicit the assumptions each study makes about data availability, query formulation, and evaluation setup. The column labeled #NLQs reports the number of NL VOLUME 4, 20165 TABLE 2: Categories and publication years of datasets used across various ST-NLIDBs Dataset (Short Name)YearSpatialTemporalBenchmarkRealGISSynthetic 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✓✗✓ MOQ + BT Trains [73]2021✓ GeoAnQu Corpus [22]2023✓✗✓✗ Extended MOQ + BT [74]2023✓ berlintest / nanjingtest [65]2023✓✗✓✗ NYC GIS + Socioeconomic DB [11]2024✓✗✓✗ TRUCE / SUSHI TS [59]2024✗✓✗✓ OSM Bavaria + SoilMap [67]2025✓✗✓✗ TACO Time-Series Differences [60]2025✗✓✗✓ GeoSQL-Bench [57], [58]2025✓✗✓✗✓ SpatialQueryQA + KaggleDBQA [68]2025✓✗✓✗ SpatiaLite (Ada / Edu / Tour / Traffic) [12]2025✓✗✓✗ GeoQueryJP / KaggleDBQA [69]2025✓✗✓✗ berlintest / nanjingtest / chinawater [66]2025✓✗✓✗ TourismQA + MapQA [70]2025✓✗✓✗ NALMOBench [61]2025✓ Text-to-PromQL Benchmark [62]2025✗✓✗ queries associated with a dataset when such queries are explicitly defined. The value N/A is used in cases where a dataset does not provide a fixed or explicitly enumerated set of NL queries. The Query Language column describes the formal lan- guage or representation to which NL queries are translated. Here, SQL refers to standard relational SQL, while Spatial SQL [77] denotes SQL dialects extended with spatial data types and operators, such as those supported by PostGIS. Geo-Analytical QL [22] refers to higher-level geo-analytical query formalisms that express spatial analysis workflows or transformations rather than direct database queries, as used in geo-analytical question answering systems. For spa- tiotemporal systems, languages such as SECONDO represent executable algebras that natively support moving objects and temporal operators, whereas time-series benchmarks rely on specialized query or difference operators designed for signal retrieval and comparison. In addition to SQL-based and alge- braic query languages, some datasets rely on domain-specific query languages tailored to particular data ecosystems. In particular, OverpassQL is used by datasets such as Over- passNL [78] to query OSM data [79] via the Overpass API [80]. OverpassQL is a declarative, read-only query language that supports spatial constraints and semantic tag-based fil- tering over OSM entities (nodes, ways, and relations), and is distinct from Spatial SQL dialects used in database sys- tems such as PostGIS. We therefore list OverpassQL sep- arately in the Query Language column to reflect its OSM- specific data model and execution environment. The NLQ Origin column indicates how the NL queries were created, distinguishing between human-authored queries, syntheti- cally generated queries, or mixed settings. The Split column specifies whether an explicit train–test or evaluation split is defined, which is common for benchmark-style datasets but often absent in operational or demonstration-oriented systems. Finally, the Public column indicates whether the dataset is publicly available. By organizing datasets into operational GIS databases, NL query corpora, time-series benchmarks, executable NL to query benchmarks, and NL to action datasets, Table 3 shows that existing NLIDB research relies on a wide range of data sources with very different assumptions. This diversity helps explain differences in sys- tem design and evaluation practices across studies, but also highlights the lack of standardized datasets that NL querying in a unified manner. Benchmark datasets form a substantial part of the em- pirical foundation of NLIDB research. These datasets are designed to be clean, structured, and suitable for evaluat- ing different methods. For example, GeoSQL-Bench and GeoSQL-Eval [57], [58] generate thousands of synthetic GeoSQL tasks targeted at operator-level reasoning, covering distance predicates, topological relations, buffering, spatial joins, and multi-table queries. Semantic parsing corpora such as GeoQuery [84] and its variants used in earlier work like SpatialNLI [56] provide canonical NL questions paired with executable logical forms. More recent benchmarks extend this idea beyond static geometry. TRUCE [86] and SUSHI [59], [60] incorporate NL descriptions of temporal signals and time-series differences, expanding evaluation into the temporal domain. The key strength of these benchmark datasets is their ability to isolate reasoning behavior. If a system succeeds or fails on a benchmark, it usually points to whether the issue lies in operator selection, schema ground- ing, or some part of the logical interpretation. But at the same time, these datasets rarely include the kind of noise, irregularity, or semantic ambiguity that shows up in prac- tical GIS deployments. Because of that, strong benchmark performance does not always translate well to real-world robustness. Real-world GIS datasets fall into a different kind of 6VOLUME 4, 2016 TABLE 3: Key characteristics of datasets across all included studies Dataset / Data SourcePaper(s) Using Dataset#NLQsQuery LanguageNLQ OriginSplitPublic Operational GIS Databases (Execution-Centric) Oracle Spatial Layers [63][63]N/ASpatial SQLNone✗✓ Denton County GIS [81][21]30SQLHuman✗✓ BerlinMOD Trajectories [71][71]N/ASECONDONone✗✓ SECONDO Demo Traj [76][72]N/ASECONDONone✗✓ BT Berlin Trains [76][73], [74]N/ASECONDONone✗✓ berlintest [82] / nanjingtest [53] / chinawater [66] [53], [65], [66]N/ASECONDONone✗ NYC GIS + Socioecon [83][11]∼200SQLMixed✗✓ Natural Language Query Corpora GeoQuery [84][56]880λ-calculus / SQLHuman✓ Restaurants [85][56]∼300λ-calculusHuman✓ GeoAnQu Corpus [22][22]309Geo-Analytical QLHuman✗✓ MOQ (2021) [73][73]240SECONDOSynthetic✗✓ Extended MOQ (2023) [74][74]280SECONDOSynthetic✗✓ GeoQueryJP [69][69]∼500Spatial SQLHuman✓ Time-Series Language–Signal Benchmarks TRUCE [86][59]∼300TS Query OpsHuman✓ SUSHI [87][59]∼300TS Query OpsHuman✓ TACO TS Differences [88][60]∼100TS-Diff OpsSynthetic✓ Executable NL-to-Query Benchmarks GeoSQL-Bench [58][58], [57]14,178Spatial SQLSynthetic✓ SpatialQueryQA [68][68]90SQLHuman✓ KaggleDBQA [89][68], [69]∼2,500SQLHuman✓ SpatiaLite(Ada/Edu/Touris- m/Traffic) [90] [12]∼50SQLMixed✗✓ OverpassNL [78][78]8,352OverpassQLMixed✓ NALMOBench [61][61]600SECONDOMixed✓ Natural Language to Action / API Datasets IoD-520 (Drone API) [91][91]520REST APIMixed✓✗ evaluation setting, where the goal is more about ecological validity than having everything neatly controlled. Systems like NALSD [65], NALSpatial [66], and NALMO [73], [74] usually rely on operational SECONDO spatial databases such as berlintest [65], nanjingtest [65], or chinawater [66]. More recent LLM based systems, for example ChatGPT for PostGIS [11] and multi agent frameworks [67], [68], tend to use municipal GIS layers, OSM derived data, and a few socio economic datasets as well. These real world spatial databases often come with irregular geometries, inconsistent naming, missing attributes, and multi layer schemas that reflect historical or operational quirks rather than any ideal relational design. Because of all that, evaluating spatial and temporal NLIDB systems on real GIS data brings out challenges that bench- mark datasets do not reveal, like schema ambiguity, ge- ographic noise, entity matching issues, and even spatial variability from place to place. In that sense, real world GIS datasets reveal the actual robustness of spatial NLIDB systems, especially the ones that depend on LLM prompting or schema-aware reasoning. Synthetic and domain specific datasets occupy a third methodological structure, where they target the evaluation of particular spatial or temporal reasoning cases that are hard to isolate with real data. Moving object datasets created through the SECONDO trajectory model, used in NLMO and NALMO [72]–[74], make it possible to test dynamic predi- cates such as overlaps, during, enters, leaves, and trajectory similarity. The BerlinMOD vehicle movement benchmark [71] has become a common dataset for testing spatiotemporal query processing in this area. More recent systems also generate synthetic thematic databases that are tailored for LLM evaluation [57], [58], which allows fine grained testing of edge case geometries, complex joins, and operator accuracy. Time series datasets such as TRUCE [86] and SUSHI [59], [60] provide NL supervision for temporal patterns and temporal reasoning. Synthetic datasets offer a high degree of experimental con- trol and help researchers test very specific reasoning abilities. At the same time, they can miss the contextual and semantic richness of real-world environments, and because of that they may oversimplify the challenges that are usually expected in operational GIS systems. Putting everything together, these dataset families reveal both conceptual progress and practical fragmentation in the research of ST-NLIDBs. Still, no single dataset family really captures all the dimensions that are needed for a full and complete evaluation. Benchmark datasets usually underrep- VOLUME 4, 20167 TABLE 4: Significance of various evaluation metrics across spatial, spatiotemporal, and time-series NLIDB systems Evaluation Dimension Spatial NLIDBSpatiotemporal NLIDBTime-Series NLIDB Execution-Based accuracy Correct execution of spatial queriesCorrect execution of time-aware queries Not applicable Interpretation /Translation Accuracy Correct mapping of NL queries to spatial intent Correct identification of spatiotem- poral intent Correct alignment of text with signal semantics Precision-Oriented accuracy Precision of spatial resultsPrecision of trajectory or temporal outputs Precision of retrieved time-series segments Structural / Syntac- tic accuracy Optional SQL structure matchingRarely usedNot applicable RetrievalQuality (Ranking-Based) RareOccasionalPrimary (e.g., mAP) Efficiencyand Scalability Runtime and performanceTrajectory-length and time-range ef- ficiency Embedding and retrieval latency Qualitative / Hu- man Evaluation Manual spatial inspectionManual trajectory inspectionManual semantic inspection Benchmark- Specific Composite Metrics RareOccasionalOccasional resent ambiguity and geographic noise. Synthetic datasets often simplify the semantic context more than they should. Therefore, it becomes hard to judge performance across gen- eral settings. The field would benefit a lot from having unified benchmark suites that mix controlled operator diversity with real-world geographic irregularity and natural user questions, allowing a more solid and holistic evaluation of spatial and spatiotemporal NL interfaces. Key Takeaway: Current ST-NLIDB research relies on three main dataset types: benchmark datasets, real-world GIS databases, and synthetic datasets, each serving different evaluation goals. While benchmarks enable controlled test- ing and real GIS data reveal practical challenges, no single dataset type captures the full complexity of natural language interaction with spatial databases, highlighting the need for more unified and realistic evaluation benchmarks. B. EVALUATION METRICS Evaluation of ST-NLIDBs is inherently more heterogeneous than in standard NL to SQL (NL2SQL) settings. A key reason is that multiple formal queries can express the same user intent, particularly when spatial predicates (distance buffers, containment relations, spatial joins) or temporal constructs (time windows, intervals, trajectory segments) are involved. As a result, many studies focus less on reproducing an exact reference query and more on whether a system produces a semantically correct outcome. Table 4 summarizes the main evaluation dimensions re- ported across the included studies and illustrates how their interpretation varies across modalities. These dimensions capture evaluation goals rather than specific numeric for- mulas, and together they reflect the diverse ways NLIDB systems are assessed. a: Execution-Based accuracy. The most common evaluation dimension in ST-NLIDB sys- tems is execution-based accuracy. Under this criterion, a system is considered correct if the generated query executes successfully and returns the expected objects, regions, or trajectories. Importantly, syntactic equivalence with a refer- ence query is not required. This outcome-oriented evaluation is particularly suitable for geospatial queries, where seman- tically equivalent alternatives are frequent and strict string matching would be misleading. Execution-based accuracy is generally not applicable to time-series interfaces that do not produce executable database queries. b: Interpretation / Translation Accuracy. Another important evaluation dimension is interpretation or translation accuracy, which focuses on whether a natural- language query can be correctly translated into a meaningful internal representation. Rather than checking for an exact match with a reference query, this metric evaluates whether the system produces a semantically complete and executable formulation that reflects the user’s intent. In executable-language, this notion is commonly cap- tured through the concept of translatability [61]. A natural- language query is considered correctly interpreted if the system can generate an executable query that preserves the required entities and logical structure, even if the output obtained from execution on database differs from that of the gold query. Interpretation accuracy is therefore reported as the proportion of input queries that can be successfully translated into valid executable queries: TA = |EQ| |N| (1) where EQ denotes the set of executable queries generated 8VOLUME 4, 2016 by the system and N denotes the total number of natural- language queries. This interpretation-oriented metric is particularly appro- priate for ST-NLIDB systems, where multiple executable formulations may express the same user intent and strict exact-match evaluation would be overly restrictive. c: Precision-Oriented accuracy. In addition to interpretation accuracy, several systems report precision-oriented accuracy, which is also referred to as translation precision [61]. A translated query is considered precise if it not only executes successfully, but also produces results that are equivalent to those of the corresponding gold query. In this setting, equivalence means same execution results. Precision-oriented accuracy is typically computed as: TP = 1 N N X n=1 I(S n , G n )· I(R(S n ), R(G n )) ,(2) where I(A, B) is an indicator function defined as I(A, B) = ( 1, if A = B, 0, otherwise. Here, S n and G n denote the generated and gold executable queries for the n-th example, respectively, and R(·) denotes the corresponding execution result set. d: Retrieval Quality (Ranking-Based). For time-series NLIDB systems and retrieval-oriented in- terfaces, retrieval quality becomes a central evaluation di- mension. Rather than generating executable queries, these systems retrieve relevant sequences or segments based on learned representations, and are therefore evaluated using ranking-based metrics. Common examples include mean av- erage precision (mAP), Recall@k, or related information- retrieval measures: mAP = 1 Q Q X q=1 Average Precision(q), where Q denotes the number of queries. Such metrics are primary in time-series NLIDBs, occasional in spatiotemporal systems, and rare in purely spatial NLIDBs. e: Efficiency and Scalability. Beyond accuracy, many studies report efficiency and scalabil- ity metrics. These include runtime, translation latency, query execution time, and scaling behavior with respect to data size or query complexity. In spatial databases, performance is of- ten influenced by indexing and spatial joins, while trajectory length and temporal range impact the spatiotemporal sys- tems. Time-series systems are mainly affected by embedding computation and retrieval latency. f: Qualitative / Human Evaluation. A number of systems rely on qualitative or human evaluation, where outputs are manually inspected for semantic accu- racy, spatial reasoning quality, or practical usefulness. This evaluation dimension is common in early-stage systems or exploratory studies and typically complements quantitative metrics rather than replacing them. g: Benchmark-Specific Composite Metrics. Finally, a smaller set of works introduces benchmark-specific composite metrics that combine multiple evaluation aspects, such as syntactic validity, execution success, robustness, or partial accuracy, into a single framework-defined score. While these metrics facilitate comparison within a specific benchmark, they are often not directly comparable across different evaluation setups. Key Takeaway: Although metric names and reporting styles vary widely across studies, the underlying evaluation objec- tives tend to align with a small number of dimensions. The lack of consistent terminology across modalities complicates cross-study comparison and highlights the need for better reporting practices and more widely adopted benchmarks for ST-NLIDB systems. IV. OVERVIEW OF METHODS In this section, we do not jump into how various ST- NLIDBs handle spatial and temporal semantics of their datasets methodologically, which will be detailed in Section V. Instead, we initially present a structured summary of ST- NLIDBs, where we focus on the types of models that have been proposed, the datasets they used, the database systems they targeted, and the range of query types they addressed. Then, we discuss various methodological pipelines which are common in various ST-NLIDBs. A. SUMMARY OF STUDIES Among the studies in spatiotemporal NLIDBs, we observed a wide range of system designs, database platforms, and methodological choices. Earlier studies mostly relied on rule- based parsing or handcrafted grammars, while more recent studies have started to adopt neural models, multi-agent LLM pipelines, and larger evaluation setups. The studies also differ in the types of geospatial or spa- tiotemporal databases they target, such as PostGIS, Oracle Spatial, SECONDO, SpatiaLite, and a mix of synthetic or benchmark datasets. They also vary in the kinds of queries they handle. For example, some studies focus only on spa- tial operators like within, intersects, or nearest neighbor, while others cover spatiotemporal queries, or time-series comparisons. A smaller group of studies deal with multi- step spatial reasoning and schema-aware SQL generation using LLM-based agents. Evaluation approaches range from basic qualitative examples to execution accuracy, semantic correctness, and ranking-based metrics. Table 5 provides a summary of the included studies by listing the publication VOLUME 4, 20169 TABLE 5: Summary of included studies with evaluation metrics and NLIDB category PaperYearModel TypeDBMSEvaluation Metric (Normalized)NLIDB Category [92]2000Fuzzy grammar + possibility theory- based semantic parsing Relational GIS (SQL preproces- sor) Qualitative / Human EvaluationSpatial NLIDB [63]2007Menu-based NLI + rule-based grammarOracle SpatialQualitative / Human EvaluationSpatial NLIDB [21]2009Rule-based NLP + semantic parsingPostGISExecution-Based AccuracySpatial NLIDB [71]2009Data generation and benchmark frame- work SECONDOEfficiency and Scalabilityspatiotemporal NLIDB [64]2015MapReduce spatial framework (non-NLI)HDFS / SpatialHadoopEfficiency and ScalabilitySpatial NLIDB (Con- text) [56]2019Seq2Seq GRU + spatial comprehension model Custom geospatial DBInterpretation / Translation AccuracySpatial NLIDB [72]2020Rule-based NLP + structured language generation SECONDOExecution-Based Accuracyspatiotemporal NLIDB [73]2021Hybrid NLP + LSTM classifier + rulesSECONDOInterpretation / Translation Accuracy; Precision-Oriented Correctness spatiotemporal NLIDB [22]2023Rule-based CFG, concept transforma- tions No DBMS (abstract workflows)Qualitative / Human EvaluationSpatial NLIDB [74]2023Hybrid semantic parsing + LSTMSECONDOInterpretation / Translation Accuracyspatiotemporal NLIDB [65]2023NLP + LSTM classifier + rule templatesSECONDOInterpretation / Translation Accuracy; Efficiency and Scalability spatiotemporal NLIDB [59]2024Contrastive learning (signal + text embed- dings) N/A (time-series learning)RetrievalQuality(Ranking-Based); Qualitative / Human Evaluation Time-Series NLIDB [11]2024LLM prompting for spatial SQLPostGIS (NYC datasets)Execution-Based AccuracySpatial NLIDB [68]2025Multi-agent spatial text-to-SQLPostGISQualitative / Human EvaluationSpatial NLIDB [60]2025Contrastive retrieval modelN/A (TACO-based TS pairs)Retrieval Quality (Ranking-Based)Time-Series NLIDB [67]2025Multi-agent LLM + semantic searchVector DB + OSM layersQualitative / Human EvaluationSpatial NLIDB [58]2025LLM evaluation frameworkPostGIS(syntheticthematic DBs) Benchmark-Specific Composite Met- rics; Structural / Syntactic Correctness Spatial NLIDB [12]2025GPT-based text-to-SQL with schema prompts SpatiaLiteExecution-Based AccuracySpatial NLIDB [69]2025LLM + dynamic schema mappingPostGIS + GeoQueryJPTranslation AccuracySpatial NLIDB [66]2025NLP + LSTM type classifier + rule-based SLM SECONDOExecution-Based Accuracy; Interpreta- tion / Translation Accuracy Spatial NLIDB [93]2025Multi-agent LLM pipeline (ReAct-style reasoning + tool use) Relational SQL DBs (location- based check-in datasets) Execution-Based Accuracy; Qualitative / Human Evaluation Spatial NLIDB [61]2025Text-to-EXE benchmark + evaluation (LLMs + baselines) SECONDO(executable language for MOD) Benchmark-Specific Composite Met- rics; Execution-Based Accuracy spatiotemporal NLIDB [62]2025LLM + knowledge retrieval for text-to- PromQL Prometheus / PromQLInterpretation / Translation Accuracy; Precision-Oriented Correctness Time-Series NLIDB year, model type, database system, supported query types, and the evaluation metrics reported in each study. B. COMMON METHODOLOGICAL PIPELINE As stated earlier in this section, this subsection aims at discussing the common pipelines in various methodologies, instead of diving deeper into how spatial and temporal se- mantics are handled by these NLIDBs, which will be dis- cussed later in Section V. Across research on spatial and spatiotemporal NLIDBs, a fairly consistent methodological pattern appears. Whether a system is designed for static GIS data, moving objects, or time-series data, most approaches rely on a multi-stage translation process. In this process, an NL query is gradually transformed into an executable structured form, such as SQL, GeoSQL, SECONDO algebra, or another domain-specific query language. Figure 2 shows the unified methodological pipeline com- monly used in ST-NLIDBs, illustrating how natural lan- guage questions are progressively transformed into exe- cutable database queries. To better understand how ST-NLIDB systems differ across data modalities, we summarize their end-to-end processing pipelines in Table 6. The table compares spatial, spatiotem- poral, and time-series NLIDB systems by breaking them down into a common set of pipeline stages, ranging from NL parsing to final output generation. Each row in the table corresponds to a distinct stage in the processing pipeline, describing what the system does at that step, while each column shows how this stage is executed for a particular data type. Spatial and spatiotemporal NLIDBs typically follow a schema-driven pipeline that culminates in executable queries, whereas time-series NLIDBs increas- ingly rely on representation learning and similarity-based retrieval rather than explicit query generation. By comparing pipeline stages side by side, the table highlights both the shared structure and key differences among spatial, spatiotemporal, and time-series NLIDB sys- tems, helping explain their differing modeling, execution, and evaluation strategies. The first stage typically involves NL preprocessing [94] and entity extraction [95]. Most systems use standard NLP techniques such as tokenization, part-of-speech tagging, and named-entity recognition to identify key elements of the query, including spatial entities, temporal expressions, nu- meric constraints, and relational terms. Earlier and more spatially focused systems [96], such as studies by Xu et 10VOLUME 4, 2016 FIGURE 2: Unified methodological pipeline for NL interfaces to spatial, spatiotemporal, and time-series databases al. [22], Zhang et al. [21], and Liu et al. [66], largely rely on rule-based extractors and manually curated vocabularies. In contrast, more recent studies increasingly incorporate neural models or LLM-based parsers to better capture implicit intent and handle more complex or flexible query phrasing, as seen in Yu et al. [69] and Redd et al. [59]. A second step that appears across many systems is re- trieving domain information through the use of external knowledge sources. In spatial and spatiotemporal NLIDBs, this means relying on domain knowledge such as spatial rela- tion knowledge bases, location dictionaries, database schema metadata, or prefix-tree indexes of place names. For spatiotemporal databases, this process is further ex- tended to include temporal representations, trajectory identi- fiers, and predefined region definitions, as discussed by Wang et al. [73]. The third methodological component involves identifying the type of query. Many systems begin by classifying an NL query into one of a small set of supported categories, such as range queries, nearest-neighbor searches, spatial joins, trajectory similarity queries, or temporal interval queries. Earlier approaches typically rely on rule-based heuristics for this step, whereas more recent systems often use lightweight neural classifiers, such as LSTM-based, trained on curated collections of NL queries to infer the intended query type (Wang et al. [74], Liu et al. [65]). After the system identifies the user’s intent, the next step is to build a structured query. In most spatial and spatiotemporal NLIDB systems, this is done using predefined templates or operator mappings rather than fully end-to-end neural model-based generation. The typical approach is slot filling, where previously extracted elements such as spatial relations, distances, time intervals, or object identifiers are inserted into fixed query templates. These slots correspond to concrete database operators such as intersects, within, k-nearest neigh- bors, passes, or atperiods. Using this rule-guided construction ensures that the resulting query is both syntactically valid and executable, which is important for complex spatial and temporal operations that unconstrained neural models often struggle to generate reliably. More recent works extend this template-based pipeline by incorporating agentic or retrieval-augmented reasoning components. In these systems, complex questions are broken down into smaller sub-tasks, relevant schema information or documentation is retrieved as needed, and candidate queries are refined iteratively. Some systems also execute intermedi- VOLUME 4, 201611 TABLE 6: Pipeline characteristics across spatial, spatiotemporal, and time-series NLIDB systems. Pipeline StageSpatial NLIDBSpatiotemporal / Moving Objects NLIDB Time-Series NLIDB NaturalLanguage Parsing Entity extraction focused on places, spatial relations, and numeric con- straints Entity extraction extended with tem- poral expressions, object identities, and trajectory references Text understanding aligned to signal patterns, trends, or comparative de- scriptions Domain MappingMapping to spatial schemas, lay- ers, and geometry types (point, line, polygon) Mapping to spatiotemporal schemas, trajectory identifiers, regions, and temporal indexes Alignment between text descrip- tions and signal representations in a shared embedding space Query / Task Identi- fication Classification into spatial query types (range, N, spatial join, aggre- gation) Richer classification including in- terval, 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 alge- braic operators Structured spatiotemporal operators with time-aware constraints and in- dex selection No explicit SQL generation; re- trieval via embedding similarity and contrastive learning Execution ModelSingle-shot spatial query executionExecutionwithtemporal filtering,trajectoryoperators, and optimization-aware planning Similarity-basedretrievalover learned representations, not database execution Result ValidationExecution success and spatial result correctness Execution accuracy combined with efficiency and trajectory correctness Retrieval accuracy based on embed- ding similarity and ranking metrics Output FormSpatial objects or map-based visual- izations Trajectories, time-filtered spatial ob- jects, or aggregated movement sum- maries Retrieved time-series segments or ranked signal comparisons ate queries to check results before producing a final answer (Redd et al. [59]; Yu et al. [69]; Kazazi et al. [68]). Even with the introduction of LLMs, the overall pipeline remains largely unchanged, typically consisting of entity extraction, use of knowledge-bases, planning, structured query genera- tion, execution, and result interpretation. Most studies also include an execution-based validation step, where generated queries are run against spatial or spatiotemporal databases to confirm correctness. The out- puts usually take the form of result sets, spatiotemporal trajectories, or spatial features, and are often paired with visualizations such as maps or plots. As a result, evaluation focuses on whether the query executes correctly and returns the intended results, rather than on how closely the generated query text matches a reference query. To summarize, the literature shows that ST-NLIDB sys- tems consistently favor hybrid architectures that combine rule-based logic, lightweight neural models, and, increas- ingly, LLM-based components, rather than relying on purely end-to-end learning. V. TAXONOMY OF ST-NLIDBS The ST-NLIDB systems differ in how they translate nat- ural language queries into executable spatial and tempo- ral database queries. Across all ST-NLIDB systems, we can see four main methodological families: (i) rule-based and grammar-driven systems, (i) neural net and seman- tic parsing-based hybrid systems, (i) LLM prompting ap- proaches, and (iv) multi-agent architectures. These method- ological differences show a gradual shift from more de- terminisitic, hand-engineered pipelines toward flexible and agentic frameworks. This section details the methodology used by each category of NLIDBs. For each category, we be- gin by giving an overview of how general-purpose NLIDBs translate NL questions into executable queries, and then we examine how ST-NLIDBs extend the corresponding ap- proach to handle spatial and temporal semantics. Each methodological family offers distinct advantages and limitations in translating natural language questions into ex- ecutable spatial and temporal database queries. These dif- ferences reflect the evolution of ST-NLIDB systems from early rule-based pipelines to learning-based and agentic ap- proaches. Table 7 summarizes these four methodological categories, along with their representative techniques, main strengths, and limitations. A. RULE-BASED AND GRAMMAR-DRIVEN NLIDBS In rule/grammar-based systems, the interpretation of a user’s question is governed by explicit linguistic rules or formal grammars that describe how valid spatial queries can be expressed. Instead of learning mappings from data, the sys- tem relies on manually defined grammar productions, se- mantic rules, and domain knowledge to identify entities, spatial relations, and query intent. Once the input sentence matches a known grammatical structure, it is deterministi- cally translated into a structured spatial query or analytical workflow. These approaches mainly focus on the syntac- tic structure of the NL question and the database query. In non-spatiotemporal general-purpose NLIDBs [70], [97]– [99], [108], [110]–[116] under this category, an NL query is parsed based on its syntactic structure, and a parse (syn- tax) tree is generated. The parse tree nodes are mapped to database nodes for the purpose of generating a database query. The syntax structure captured by the parse tree plays a significant role in generating the corresponding database 12VOLUME 4, 2016 TABLE 7: Method families in ST-NLIDB systems: representative techniques, strengths, and limitations Method FamilyRepresentative ApproachesStrengthsLimitations Rule-based/Grammar- driven NLIDBs Rule-basedNLPpipelines[97]–[99], Handcrafted grammars [22], [63], [92], Template-based query generation [21] Thesesystemstranslate queries through predefined linguistic rules, making the reasoning process easier to trace and the generated queries easier to inspect. These systems rely on hand- crafted grammars and rules, which makes them difficult to scale and adapt to diverse or evolving query formula- tions. Neural / Machine-learning NLIDBs Seq2Seq models [1], [2], LSTM-based clas- sifiers [65], [66], [73], Neural semantic parsing [3], [100]–[102] Thesesystemslearn relationshipsbetween natural-languagequeries anddatabaseoperations from training data, allowing them to handle linguistic variation more effectively thanpurelyrule-based systems. These systems depend on labeled training data and learnedrepresentations, whichcanreduce interpretability and limit generalization to unseen query types or database schemas. LLM-based NLIDBsPrompt-based text-to-SQL systems [11], [103], [104], Schema-aware LLM prompt- ing [12], [69], [105], [106] These systems use LLMs to interpretnatural-language questionsandgenerate database queries through prompt-basedreasoning, allowing them to handle a wide range of query expressions without relying on handcrafted rules. These systems still suffer from spatial reasoning er- rors and may hallucinate database tables, columns, or spatial functions that do not exist in the database schema. Multi-agent NLIDBsAgentic LLM pipelines [93], Task decom- position frameworks [67], [68], Reasoning + tool use [35], [107]–[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 onmultipleinteracting agents,theyintroduce additionalsystem complexity, increase query latency due to multiple model calls, and require higher computational cost. counterpart for the NL query. While this approach offers transparency and control over query interpretation, it also requires substantial manual effort to design and maintain the grammars, and it typically struggles to handle linguistic variation or unexpected query formulations. Rule-based and grammar-driven natural language inter- faces represent some of the earliest attempts in spatial NLIDB research. Early research on NL interfaces for spa- tial databases relied heavily on rule-based reasoning and grammar-driven parsing, where the structure of a user query was explicitly defined through linguistic rules. These ap- proaches were motivated by the limited availability of large training datasets and the need for predictable, interpretable behavior in spatial query translation. One of the earliest examples is the work by Wang et al. (2000) [92], where a fuzzy grammar and possibility the- ory–based NL interface were proposed for spatial queries. The system focused on handling the inherent vagueness of natural language, such as terms like near or far, by combin- ing fuzzy grammar rules with possibility theory. The input sentence was first parsed using a predefined fuzzy gram- mar, after which vague spatial expressions were converted into quantitative representations using fuzzy logic. The fi- nal interpretation was then translated into an SQL query executable on a spatial database. This work highlighted the importance of explicitly modeling linguistic uncertainty in spatial queries, although the approach required substantial manual rule design. Following this, Chintaphally et al. (2007) [63] extended traditional NL interfaces by incorporating geospatial query- ing capabilities. Their system employed a menu-based, pre- dictive interface constrained by a domain-specific attributed grammar. Users were guided to construct valid NL queries ensuring grammatical correctness. The grammar rules di- rectly mapped NL phrases to relational joins and spatial joins, which were then translated into Oracle Spatial SQL query. Query results were returned in Geography Markup Language (GML) format and further converted to Keyhole Markup Language (KML) for visualization in tools such as Google Earth Engine. While this approach reduced parsing ambiguity, it also limited user expressiveness by restricting queries to predefined grammatical patterns. In a similar rule-driven work, Zhang et al. (2009) [21] presented a natural language interface for crime-related spa- tial queries. Their method combined part-of-speech tagging and syntactic parsing with rule-based semantic interpretation. VOLUME 4, 201613 NL Question Linguistic Parser Parse Tree NL Node to DB Node Mapper User Database Data & Metadata Database Query Mapped DB Nodes DB Query Rule/Grammar Matching Query Tree DB Query Generator FIGURE 3: General flow structure of rule-based and grammar-driven NLIDBs Each query was decomposed into a semantic triplet consist- ing of a target object, a spatial predicate, and a reference object. These components were then matched to database schemas using weighted string similarity, followed by spatial predicate evaluation within the database. The results were vi- sualized using KML. This work demonstrated how carefully designed semantic rules could support real-world, domain- specific spatial querying, although the system depended strongly on handcrafted rules and domain assumptions. More recently, Xu et al. (2022) [22] revisited grammar- based methods from a more conceptual perspective in a grammar for interpreting geo-analytical questions as concept transformations. Rather than directly generating SQL, their approach aimed to capture the analytical intent behind geo- analytical questions. Natural-language input was processed using named entity recognition and mapped to core spatial concepts such as objects, fields, and events. A context-free functional grammar was then used to identify functional roles within the question, producing a parse tree that was trans- formed into a directed acyclic graph of concept transforma- tions. The output was an abstract GIS workflow specification, independent of any specific GIS platform. This work empha- sized interpretability and analytical clarity, but still relied on manually defined grammars and concept dictionaries. Overall, rule-based and grammar-driven approaches laid the foundation for natural language interaction with spatial databases. They offered transparency and deterministic be- havior but required extensive manual effort to design gram- mars, rules, and domain knowledge. As spatial queries grew more complex and diverse, these limitations motivated later shifts toward learning-based and LLM-driven methods. Figure 3 shows a flow diagram that summarizes these methods. It captures the common steps that appear across those papers, even though each system implements them in its own slightly different way. Key Takeaway: Rule-based and grammar-driven NLIDBs represent early approaches to natural-language querying of spatial databases, where queries are interpreted using manually defined linguistic rules and grammars. While this design provides clear and predictable query translation, the reliance on handcrafted rules makes these systems difficult to scale as query language and database schemas become more complex. B. NEURAL NET AND SEMANTIC PARSING-BASED HYBRID NLIDBS As natural language interfaces for databases evolved, re- searchers began to move beyond fully rule-based systems toward neural and semantic parsing-based hybrid models. The idea of these approaches were initially introduced by generic non-spatiotemporal NLIDBs [1]–[4], [100]–[102], [117], [118]. These approaches still preserve a structured view of spatial querying but introduce machine learning components to handle linguistic variability, ambiguity, and scalability. Instead of relying solely on handcrafted gram- mars, hybrid systems typically combine traditional NLP preprocessing and domain knowledge with neural models, most commonly for tasks such as entity extraction, query type classification, or semantic disambiguation. However, the final query generation step, often remains template-driven or operator-based, ensuring execution reliability while benefit- ing from learned representations. An early example of this transition in the moving ob- jects domain is NLMO by Xu et al. (2020) [72]. This sys- tem applied standard NLP preprocessing and named-entity recognition to extract temporal expressions, numeric values, and object identifiers from natural-language queries. A key contribution was the use of a learned classifier to distinguish between different spatiotemporal query types, such as range and nearest-neighbor queries. Based on the predicted type, the system mapped extracted entities into predefined spa- tiotemporal operators and generated executable queries for the SECONDO moving-objects database. While the overall translation process remained structured, the introduction of learning-based components improved robustness compared to purely rule-based systems. Building on similar ideas, Wang et al. (2021) [73] pro- posed NALMO, a natural language interface specifically designed for moving object databases. Their approach com- bined spaCy-based semantic parsing and entity recognition with a location knowledge base to resolve spatial references. An LSTM-based classifier was trained to identify query intent categories, such as time interval, range, or trajectory similarity queries. Once the query type was identified, ex- tracted entities were mapped to corresponding SECONDO operators using predefined rules. This hybrid design allowed the system to balance interpretability and flexibility while maintaining reliable execution on spatiotemporal data. In a later extension, Wang et al. (2023) [74] further refined the NALMO framework by improving entity normalization and semantic parsing. The system incorporated more detailed handling of temporal expressions, numeric normalization, and relation extraction using domain rules, followed by LSTM-based query type prediction. Compared to earlier versions, this work focused on better alignment between natural language expressions and structured spatiotemporal operators, particularly for more complex trajectory-based queries. Despite these improvements, the system still relied on predefined operator compositions, reflecting the struc- tured nature of hybrid semantic parsing approaches. 14VOLUME 4, 2016 Parallel developments occurred in the spatial database domain. Liu et al. (2023) [65] introduced NALSD, a natural language interface that combined neural query classification with template-based spatial query generation. Their system first performed tokenization and named-entity recognition to extract spatial relations, locations, and numeric constraints. An LSTM classifier then determined whether the query corresponded to a range query, nearest-neighbor query, or spatial join. Based on this classification, the system selected appropriate spatial operators and generated executable SEC- ONDO queries. This design demonstrated how limited neural components could significantly reduce the manual burden of rule specification while retaining structured execution. In the same year, Liu et al. (2023) [53] also proposed NALSpatial, which followed a similar hybrid architecture but placed greater emphasis on knowledge-base support. The system leveraged both a location knowledge-base and a spatial-relation knowledge-base to refine entity extraction and disambiguation. A manually curated corpus of spatial NL questions was used to train an LSTM classifier for query type identification. Once classified, queries were translated using predefined templates with placeholders for spatial relations, locations, distance thresholds, and aggregation parameters. This work highlighted the effectiveness of combining learned intent classification with explicit domain knowledge in spa- tial query translation. More recently, Liu et al. (2025) [66] extended the NALSpatial framework with a distinct separation between natural language understanding and translation phases. Coarse entity extraction was followed by refinement us- ing knowledge bases, after which an LSTM classifier pre- dicted the query category. A structured language model then mapped extracted entities into operator templates cor- responding to different spatial query types. While neural components played an important role in interpretation, the execution logic remained deterministic, reflecting the hybrid nature of the approach. Finally, NALMOBench by Wang et al. (2025) [61] pro- vided both a benchmark and a strong baseline representa- tive of this category. The baseline system employed a two- stage entity extraction process, followed by neural query type classification and structured slot filling. Although this study mainly proposed an evaluation framework, the baseline architecture closely mirrors earlier hybrid semantic parsing systems, reinforcing this design pattern as a dominant ap- proach prior to the widespread adoption of large language models. Overall, neural and semantic parsing-based hybrid models lie in the middle of early grammar-based systems and modern LLM-driven approaches. By combining learned components with structured query generation, these systems improved robustness and scalability while preserving control over spa- tial query execution. However, their reliance on predefined query types and operator templates still limits expressiveness, motivating later shifts toward end-to-end and agent-based LLM solutions. NL Question Tokenizer Tokens NL Tokens to DB Entity & ST Operator Mapper User Database Data & Metadata Database Query Mapped Entities & Operators Trained Classifier Model Predicted Query Type DB Query Generator Query Rules/Grammar FIGURE 4: Generic pipeline of neural net and semantic parsing-based hybrid NLIDBs Figure 4 illustrates the general pipeline used by neural net and semantic parsing–based hybrid NLIDBs, where natural language queries are processed through NLP preprocessing, neural classification, and template-based query generation. Key Takeaway: Neural net and semantic parsing–based hy- brid NLIDBs combine machine-learning models with struc- tured query templates to interpret natural-language ques- tions. Learning components help identify entities and query types, while template-based translation keeps query execu- tion reliable. However, because these systems still rely on predefined templates and operators, they struggle with spa- tial queries that fall outside the expected patterns. C. LLM-BASED NLIDBS With the emergence of large language models, research on natural language interfaces for databases began to shift away from rigid templates and task-specific neural models toward LLM-driven interpretation and generation. In these approaches (non-spatiotemporal) [103]–[106], [119]–[121], the LLM plays a central role in understanding user intent, relating NL queries in database schemas, and generating executable spatial queries. Unlike earlier hybrid systems, LLM-based interfaces rely primarily on prompt design, in- context learning, and semantic reasoning rather than explicit query type classification or handcrafted operator mappings. In the spatial and temporal domain, one of the earliest stud- ies exploring this direction is Jiang et al. (2023) [11], who investigated whether ChatGPT can function as a geospatial data analyst. Their system treated spatial query translation as a prompt-based text-to-SQL task. Database schemas and sample data were provided to the LLM using CREATE TABLE statements and example rows, along with the user’s NL question. The LLM then generated PostGIS SQL queries directly, which were executed on a spatial database. Query results were subsequently transformed into natural-language responses. This work demonstrated the feasibility of using general-purpose LLMs for spatial SQL generation, while also highlighting issues related to execution reliability. Building on this idea, Wang et al. (2025) [12] proposed a more structured prompt-engineering strategy in GPT-Based Text-to-SQL for Spatial Databases. Their approach decom- posed the prompt into multiple components, including spatial database knowledge, in-context examples, schema defini- tions, geographic descriptions, and feedback derived from previous execution errors. If the generated SQL failed during VOLUME 4, 201615 execution, schema-related errors were extracted and injected back into the prompt as guidance for subsequent iterations. This iterative prompting mechanism improved execution suc- cess rates compared to single-shot generation, while still maintaining a single-LLM pipeline. More advanced schema handling was introduced by Yu et al. (2025) [69] in Monkuu, which focused on dynamic schema mapping for geospatial databases. Instead of directly exposing full schemas to the LLM, Monkuu generated com- pact schema abstractions from expert-verified documentation and used the LLM to map query semantics to relevant tables and columns. The system also incorporated human-in-the- loop disambiguation for geographic entities when ambigu- ity was detected. Once entities and schema elements were resolved, the GIS-aware SQL were generated with LLM using few-shot prompting with spatial function guidance. This work addressed one of the major limitations of earlier LLM-based systems, namely poor scalability to complex or evolving schemas. In parallel, Yu et al. (2025) [70] also proposed Spatial- RAG, which extended LLM-based interfaces beyond direct SQL generation. Instead of relying solely on query transla- tion, Spatial-RAG combined spatial database retrieval with embedding-based semantic scoring. The system first used an LLM to parse spatial intent and generate a spatial SQL query to retrieve candidate objects. These candidates were then ranked using both spatial relevance metrics and semantic similarity derived from embeddings. A Pareto-based filtering step was applied to balance spatial and semantic relevance, after which the LLM selected the final answer and generated a natural-language response. This approach illustrated how LLMs can be integrated with retrieval-augmented reasoning rather than acting purely as SQL generators. A related but domain-specific application of LLM-based interfaces was presented by Sezgin et al. (2025) [122] in the context of Internet of Drones (IoD) platforms. Their system used sentence-level embeddings and vector search to retrieve relevant API examples, which were then incorporated into a few-shot prompt for an LLM. The LLM inferred the ap- propriate API endpoint and parameters, generating structured JSON calls validated against OpenAPI specifications. Al- though not strictly focused on spatial SQL, this work demon- strated how LLM-based interfaces can support structured query generation over spatially systems with strong schema and safety constraints. Overall, LLM-based natural language interfaces represent a significant shift from earlier semantic parsing paradigms. By leveraging pretrained language models and prompt-based reasoning, these systems reduce the need for task-specific training data and handcrafted rules. LLM-based NLIDBs provide a high level of flexibility, but they also come with several limitations due to the nature of generative models. One key challenge is geo-hallucination [123], a form of spatial reasoning error that results in the generation of spa- tial queries with incorrect location mappings. Beyond geo- hallucination, prompt brittleness [124] is another challenge. Prompt Construction Prompts Large Language Model User Database Schema Correct Database Query Prediction Post-Processing & Corrections Feedback NL Questions FIGURE 5: A general illustration of how LLM-prompting approaches generate database queries. Small changes in how a user describes a geographic region or a time range can lead the model to produce very different query plans. Another practical limitation is computational cost. LLM-based NLIDBs often rely on long prompts that include database schemas, spatial metadata, and example queries. These large prompts increase inference latency and computational cost, particularly when external LLM services are used for real-time query generation. Privacy is another important concern. Since schema details or example data are sometimes included in prompts, sensitive information about the database structure or its underlying data could be exposed, especially when external LLM services are used [125]. As a result, challenges remained in execution reliabil- ity and control, which have motivated further developments toward multi-agent architectures. Figure 5 shows the general workflow of LLM-based NLIDBs, where database schemas and example queries are included in the prompt to guide the generation of executable spatial SQL queries. Key Takeaway: LLM-based NLIDBs use large language models to interpret natural-language questions and gener- ate database queries through prompt-based reasoning. This allows them to handle a wide variety of query expressions without relying on handcrafted rules or predefined templates. However, due to geo-hallucination and prompt brittleness, the system may sometimes produce incorrect SQL or refer- ence tables, columns, or spatial functions that do not exist in the database schema. D. MULTI-AGENTIC NLIDBS More recent work has moved beyond single-model pipelines toward multi-agent architectures, where the task of interpret- ing and executing spatial or spatiotemporal queries is explic- itly decomposed across multiple cooperating components. In these systems, different agents are assigned specialized roles such as entity extraction, planning, schema reasoning, query generation, validation, and explanation. Rather than relying on a single pass of query generation, multi-agent approaches emphasize iterative reasoning, verification, and correction, aiming to improve robustness, interpretability, and execution reliability for complex queries. In the non- spatiotemporal domain, multi-agentic approach was adopted by NLIDBs [35], [107]–[109], [126], [127]. Figure 6 illustrates the general workflow of multi-agentic NLIDBs, where different agents cooperate to interpret the 16VOLUME 4, 2016 NL Question Coordinator Agent Query Components User Database Schema & Metadata Correct Database Query Generated Query Verifier Relation Analyzer ST Predicate Mapper DB Query Generator Agents Feedback FIGURE 6: A general illustration of how multi-agent ap- proaches generate database queries. query, generate SQL statements, and validate the final results. In the spatiotemporal domain, an early example of this direction is the work by Redd et al. (2025) [93], who pro- posed an agentic LLM pipeline for spatiotemporal text-to- SQL. In this system, an LLM agent alternates between rea- soning, action, and observation. Given an NL query, the agent first interprets the intent and inspects the database schema, including tables, columns, and sample rows. A baseline text- to-SQL model is then invoked as a tool to generate an initial query, which is executed and evaluated. If errors occur or re- sults are empty, the agent refines the query through repeated plan–act–observe cycles, potentially decomposing the task or injecting external knowledge such as spatial boundaries or temporal constraints. This approach highlights how agentic control can compensate for the brittleness of single-shot LLM query generation. A more explicitly structured multi-agent design was pre- sented by Kazazia et al. (2025) [68], where the framework assigns distinct responsibilities to separate agents, including entity extraction, metadata retrieval, query logic construc- tion, SQL generation, and review. The system first validates the user query and coordinates agent execution through an orchestration component. Extracted entities are mapped to database schemas using metadata embeddings, after which a query logic agent constructs an abstract logical plan de- scribing joins, spatial predicates, and aggregations. This plan is translated into PostGIS SQL by a dedicated generation agent and then verified by a review agent that checks syntax, schema consistency, and spatial function correctness. Errors trigger automatic regeneration, resulting in a validated spatial SQL query. This work demonstrates a separation of concerns within the pipeline of query translation system, improving control and debuggability. In a broader GeoQA context, Feng et al. (2025) [67] proposed a multi-agent architecture aimed at building a barrier-free geospatial question-answering portal. Their sys- tem begins with a router agent that classifies user intent and dispatches the query to analysis, explanation, or visualization modules. Within the analysis path, specialized agents per- form semantic parsing, task decomposition, region selection through geocoding, and hybrid entity retrieval using keyword matching, vector search, and LLM-guided disambiguation. Spatial operations are executed using predefined geometry processing functions, and intermediate results are stored for reuse. Separate explainer and visualizer agents generate tex- tual explanations and interactive map outputs, respectively. This design emphasizes user interaction and transparency, al- lowing users to inspect intermediate steps rather than treating the system as a black box. Overall, multi-agent natural language interfaces represent a shift toward explicit reasoning and control in spatial query processing. By decomposing complex tasks into coordinated subtasks and incorporating verification loops, these systems address many of the limitations observed in earlier LLM- based pipelines, particularly in terms of reliability and error handling. However, the added architectural complexity and computational cost introduce new challenges, suggesting a trade-off between robustness and system simplicity. Key Takeaway: Multi-agentic NLIDBs approach the query translation problem by dividing it into several smaller tasks handled by different agents, such as understanding the query, reasoning over the schema, generating the SQL, and check- ing the result. This collaborative process helps the system handle more complex spatial queries and improves reliability. However, coordinating multiple agents also makes the system more complex and usually requires several model calls to complete a single query. E. SUMMARY OF ST-NLIDBS TAXONOMY To provide a structured overview of how natural language in- terfaces to spatial, spatiotemporal, and time-series databases are designed, we categorize the reviewed systems according to their underlying methodological characteristics. Rather than focusing on individual implementations, this taxonomy highlights the core design choices that differentiate existing approaches, including how NL queries are interpreted, how learning is incorporated and how queries are planned and exe- cuted. Table 8 summarizes these methodological dimensions and organizes prior work into four broad method classes, ranging from traditional rule-based systems to recent large language model and multi-agent architectures. This abstrac- tion allows common patterns and trade-offs to be identified across systems that otherwise differ substantially in scope, data modality, and technical realization. VI. DISCUSSION The research in natural language interfaces for spatial, spa- tiotemporal, and time series databases has grown in several varying directions, but there are still limitations. This section focuses on our observations and the limitations we noticed across the existing studies. The limitations can be seen on both the datasets and the methodological perspectives, and they often appear together in ways that affect how well these systems can be used in real settings. A. LIMITATIONS OF EXISTING DATASETS One major limitation is the lack of a standard, widely used benchmark for this domain, unlike general NL2SQL research, which has widely adopted datasets such as Wik- iSQL [128] and Spider [129]. Most datasets used in ST- NLIDBs are small, synthetic, or tied to particular database VOLUME 4, 201617 TABLE 8: Methodological characteristics of natural language interfaces for spatial, spatiotemporal, and time-series databases. Method ClassInterpretation Mechanism Learned Components Schema Un- derstanding Query Planning Execution & Validation Ambiguity Handling Extensibility Rule-Based& Grammar-Driven Handcrafted grammars and rules NoneManual, rule- based mapping DeterministicBuilt-in constraints Explicit rule encoding Low Neural & Hybrid Se- mantic 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 learnedPrompt- and schema- context understanding GenerativeLimited or iterative ImplicitHigh Multi-Agent Architec- tures Coordinated agent reasoning Fully learnedAgent- mediated schema reasoning Planned and iterative Explicit agent validation Explicit reasoning steps Very High environments, making it difficult to conduct fair comparisons across different systems. Recent works such as GeoSQL Bench and GeoSQL Eval [57], [58] provide a large set of synthetic tasks and help with operator coverage, but they still do not capture real geographic irregularities or authentic user queries. Other datasets, such as SpatialQueryQA [68] and GeoQueryJP [69], are useful for testing specific situations, but they are relatively small and lack the range of spatial and temporal operators needed for an evaluation representing real-world conditions. Spatiotemporal datasets like BerlinMOD [71] and the SECONDO moving-object collections used in NLMO [72] and NALMO [73], [74] cover only a narrow slice of spa- tiotemporal reasoning, mostly focusing on movement pat- terns or time windows. Time-series datasets such as TRUCE, SUSHI, and the TACO-based pairs [59], [60] support natural- language supervision for temporal patterns, but they are not linked to any spatial geometry. Therefore, they cannot test how systems combine time with location. Across all these categories, noisy place descriptions and multi-step reason- ing, which are common in real applications, remain mostly untested. Another limitation is that existing ST-NLIDB datasets rarely include ambiguous or underspecified [130]–[132] user queries. Real-world questions often contain vague spatial or temporal expressions such as “near”, “around”, or “recent”, where the intended distance or time range is not clearly de- fined. However, such evaluation settings are still largely miss- ing in ST-NLIDB benchmarks. Finally, current ST-NLIDB benchmarks do not test systems under schema anonymization or obfuscation [133], [134] . To handle sensitive information, ST-NLIDB benchmarks can replace table and column names with neutral identifiers. However, this type of evaluation is still missing in ST-NLIDB benchmarks. Putting everything together, current ST-NLIDBs lack a common evaluation and benchmarking system. Many sys- tems perform well on the datasets they were trained or designed around, but their generalization to new cities or more natural user queries remains uncertain. The absence of a large, widely adopted benchmark that covers spatial and/or temporal reasoning is therefore one of the central limitations of current work. B. LIMITATIONS OF CURRENT METHODS 1) Rule-based and grammar systems break easily with schema or language changes Rule-based and grammar-driven approaches [21], [22], [63] are highly sensitive to phrasing and often require manual updates whenever the schema or vocabulary shifts. They do not adapt smoothly when new geographic layers are intro- duced or when users phrase queries in a more informal or inconsistent way. 2) Neural net and semantic parsing-based models rely on small, domain-Specific Corpora Neural and Semantic systems [56], [73], [74] reduce some of the rigidity of rule-based designs, but they are still trained on small, highly domain-specific datasets. Many spatial rea- soning steps continue to depend on handcrafted constraints, which limits scalability and makes the models struggle with varied geographic structures or unseen spatial operators. 3) LLM prompting lacks deep spatial understanding and is highly prompt-sensitive LLM prompting methods [11], [12] may choose spatial oper- ators based on surface-level word similarity rather than real geometric understanding, and hallucination remains a chal- lenge [135]. They also depend heavily on schema descrip- tions and carefully engineered prompts, and the quality of the output shifts significantly depending on how the prompts are phrased. 18VOLUME 4, 2016 4) Multi-agent pipelines are powerful but prone to coordination errors and high cost Multi-agent systems [67], [68], [93] introduce heavier com- putational cost and require careful coordination between model agents and the environment. If any agent misinterprets schema information or generates an incorrect intermediate reasoning step, the entire pipeline can drift away from the intended query logic. Their performance depends on the capabilities of the underlying LLM and on how well each agent’s role is defined. 5) ST-NLIDBs lack adoption of geospatial representation learning techniques Recent NL2SQL research [35], [136] in general relational databases now uses advanced neural ideas such as schema linking through learned embeddings [137], cross-attention between natural language and tables [138], and large-scale SQL pretraining. Systems such as RAT-SQL [139], LGESQL [140], T5-based text-to-SQL architectures [40], dense re- trieval and representation learning approaches [141], and broader NL2SQL models [142] have been adopted widely. None of the spatial systems incorporate similar techniques, even though spatial data naturally contains strong geometric and topological structure that could benefit from learned embeddings. Overall Gap: Existing methods still lack full spatial and temporal reasoning capabilities. Across all these categories, there is still a gap between the complexity of spatiotemporal reasoning and what current systems provide. Representation learning techniques widely adopted in NL2SQL research have not yet been integrated into ST-NLIDBs, leaving room for significant improvement. C. FUTURE RESEARCH DIRECTIONS Our findings suggest that research on ST-NLIDBs have made good progress, but there are still room for major improve- ments. The main gap between controlled experiments and real-world use means that future systems will need to focus more on robustness rather than only accuracy on a small benchmark. One important area for future work is the development of stronger and more consistent benchmark datasets, similar to WikiSQL [128] and Spider [129] for general-purpose NLIDBs. A benchmark that combines spatial and/or tem- poral reasoning, noisy geographic descriptions, and realis- tic schema variation would better represent the real-world scenarios. Another useful direction is the design of bench- marks that include ambiguous or underspecified queries, as discussed in Section VI-A. New benchmarks can also be designed to evaluate systems under schema anonymization or obfuscation. Such settings would help assess whether ST- NLIDB systems rely on schema names or actually interpret the query. In addition, geospatial representation learning techniques and advances from general NL2SQL research, such as schema linking, cross-attention between text and tables, or pretraining on SQL logs, may be integrated into ST-NLIDB systems. Databases such as PostGIS [8] also support managing satellite imagery datasets. Therefore, It is time to generate NLIDB benchmarking datasets for remote-sensing images and extend the NLIDB research in this direction. Overall, the future work in ST-NLIDBs should focus on building systems that are not just accurate in simplified settings but are also more generalizable and able to deal with the messy and sometimes unpredictable nature of real-world geographic data. VII. CONCLUSION This article presents a comprehensive review of natural language interfaces for spatial and temporal databases. We first outlined the representative database systems and defined the corresponding NLIDB tasks through illustrative example queries. We then enumerated the datasets and evaluation metrics in the literature of spatiotemporal NLIDBs. After defining the common methodological pipelines in NLIDBs in this domain, we organized the taxonomy and analyzed every class of methods. Finally, we discussed key limitations of current research, spanning data coverage, modeling assump- tions, and practical deployment considerations, and outlined promising research directions for future work. Collectively, these contributions provide a unified perspective on the state of the art and offer guidance for advancing NLIDBs for spatial and temporal data management. REFERENCES [1] V. Zhong, C. Xiong, and R. Socher, “Seq2sql: Generating structured queries from natural language using reinforcement learning,” arXiv preprint arXiv:1709.00103, 2017. [2] X. Xu, C. Liu, and D. Song, “Sqlnet: Generating structured queries from natural language without reinforcement learning,” arXiv preprint arXiv:1711.04436, 2017. [3] T. Yu, Z. Li, Z. Zhang, R. Zhang, and D. Radev, “Typesql: Knowledge-based type-aware neural text-to-sql generation,” arXiv preprint arXiv:1804.09769, 2018. [4] T. Yu, M. Yasunaga, K. Yang, R. Zhang, D. Wang, Z. Li, and D. Radev, “Syntaxsqlnet: Syntax tree networks for complex and cross-domaintext- to-sql task,” arXiv preprint arXiv:1810.05237, 2018. [5] T. Yu, Z. Li, Z. Zhang, R. Zhang, and D. Radev, “Typesql: Knowledge- based type-aware neural text-to-sql generation,” in Proceedings of the 2018 Conference of the North American Chapter of the Association for Computational Linguistics: Human Language Technologies, Volume 2 (Short Papers).Association for Computational Linguistics, 2018, p. 588–594. [6] V. V. Meduri, K. Chowdhury, and M. Sarwat, “Evaluation of machine learning algorithms in predicting the next sql query from the future,” ACM Trans. Database Syst., vol. 46, no. 1, Mar. 2021. [Online]. Available: https://doi.org/10.1145/3442338 [7] —, “Recurrent neural networks for dynamic user intent prediction in human-database interaction,” in EDBT, 2019, p. 654–657. [Online]. Available: https://doi.org/10.5441/002/edbt.2019.79 [8] PostGIS Project Steering Committee and others, “Postgis: Spatial and geographic objects for postgresql,” https://postgis.net, accessed: 2025- 09-05. [9] J. Yu, J. Wu, and M. Sarwat, “Geospark: a cluster computing frame- work for processing large-scale spatial data,” in Proceedings of the 23rd SIGSPATIAL International Conference on Advances in Geographic Information Systems, ser. SIGSPATIAL ’15.New York, NY, USA: Association for Computing Machinery, 2015. VOLUME 4, 201619 [10] E. Zimányi, M. Sakr, and A. Lesuisse, “Mobilitydb: A mobility database based on postgresql and postgis,” ACM Trans. Database Syst., vol. 45, no. 4, Dec. 2020. [11] Y. Jiang and C. Yang, “Is chatgpt a good geospatial data analyst? exploring the integration of natural language into structured query lan- guage within a spatial database,” ISPRS International Journal of Geo- Information, vol. 13, no. 1, p. 26, 2024. [12] H. Wang, L. Guo, Y. Liang, L. Liu, and J. Huang, “Gpt-based text-to-sql for spatial databases,” ISPRS International Journal of Geo-Information, vol. 14, no. 8, p. 288, 2025. [13] B. Rozemberczki, P. Scherer, Y. He, G. Panagopoulos, A. Riedel, M. Astefanoaei, O. Kiss, F. Beres, G. López, N. Collignon, and R. Sarkar, “Pytorch geometric temporal: Spatiotemporal signal processing with neural machine learning models,” in Proceedings of the 30th ACM International Conference on Information & Knowledge Management, ser. CIKM ’21.New York, NY, USA: Association for Computing Machinery, 2021, p. 4564–4573. [Online]. Available: https://doi.org/10.1145/3459637.3482014 [14] K. Chowdhury and M. Sarwat, “Geotorch: a spatiotemporal deep learning framework,” ser. SIGSPATIAL ’22.New York, NY, USA: Association for Computing Machinery, 2022. [Online]. Available: https://doi.org/10.1145/3557915.3561036 [15] —, “Deep learning with spatiotemporal data: A deep dive into geotor- chai,” in 2024 IEEE 40th International Conference on Data Engineering (ICDE), 2024, p. 5156–5169. [16] —, “A demonstration of geotorchai: A spatiotemporal deep learning framework,” in Companion of the 2023 International Conference on Management of Data, ser. SIGMOD ’23.Association for Computing Machinery, 2023, p. 195–198. [17] X. Liu, S. Shen, B. Li, P. Ma, R. Jiang, Y. Zhang, J. Fan, G. Li, N. Tang, and Y. Luo, “A survey of nl2sql with large language models: Where are we, and where are we going?” arXiv preprint arXiv:2408.05109, 2024. [18] Y. Fan, Q. Weng, Y. Chen, and X. S. Wang, “Rethinking data in nl2sql: a survey of what we have and what we expect,” Vicinagearth, vol. 2, no. 1, p. 15, 2025. [19] C. Voß, “Form vs function: Database normalization’s effect on zero-shot nl2sql.” [20] M. D. Siampou, J. Li, J. Krumm, C. Shahabi, and H. Lu, “Poly2vec: Polymorphic fourier-based encoding of geospatial objects for geoai ap- plications,” arXiv preprint arXiv:2408.14806, 2024. [21] C. Zhang, Y. Huang, R. Mihalcea, and H. Cuellar, “A natural language interface for crime-related spatial queries,” in 2009 IEEE International Conference on Intelligence and Security Informatics.IEEE, 2009, p. 164–166. [22] H. Xu, E. Nyamsuren, S. Scheider, and E. Top, “A grammar for interpret- ing geo-analytical questions as concept transformations,” International Journal of Geographical Information Science, vol. 37, no. 2, p. 276– 306, 2023. [23] Y. Zhou, Y. He, S. Tian, Y. Ni, Z. Yin, X. Liu, C. Ji, S. Liu, X. Qiu, G. Ye et al., “r3-nl2gql: A model coordination and knowledge graph alignment approach for nl2gql,” in Findings of the Association for Computational Linguistics: EMNLP 2024, 2024, p. 13 679–13 692. [24] Y. Liang, T. Xie, G. Peng, Z. Huang, Y. Lan, and W. Qian, “Nat-nl2gql: A novel multi-agent framework for translating natural language to graph query language,” arXiv preprint arXiv:2412.10434, 2024. [25] C. Chu and C. Shahabi, “Geo2vec: Shape-and distance-aware neural representation of geospatial entities,” arXiv preprint arXiv:2508.19305, 2025. [26] N. Nihalani, S. Silakari, and M. Motwani, “Natural language interface for database: a brief review,” International Journal of Computer Science Issues (IJCSI), vol. 8, no. 2, p. 600, 2011. [27] E. Reshma and P. Remya, “A review of different approaches in natural language interfaces to databases,” in 2017 International Conference on Intelligent Sustainable Systems (ICISS). IEEE, 2017, p. 801–804. [28] W. Zhang, Y. Wang, Y. Song, V. J. Wei, Y. Tian, Y. Qi, J. H. Chan, R. C.- W. Wong, and H. Yang, “Natural language interfaces for tabular data querying and visualization: A survey,” IEEE transactions on knowledge and data engineering, vol. 36, no. 11, p. 6699–6718, 2024. [29] M. LIU, X. WANG, J. XU, W. YI, and O. WOLFSON, “A systematic re- view of natural language interfaces for databases,” Frontiers of Computer Science, vol. 20, no. 11, p. 2011623, 2025. [30] K. Affolter, K. Stockinger, and A. Bernstein, “A comparative survey of recent natural language interfaces for databases,” The VLDB Journal, vol. 28, no. 5, p. 793–819, 2019. [31] R. C. A. Iacob, F. Brad, E.-S. Apostol, C.-O. Truic ̆ a, I. A. Hosu, and T. Rebedea, “Neural approaches for natural language interfaces to databases: A survey,” in proceedings of the 28th International Conference on Computational Linguistics, 2020, p. 381–395. [32] A. Wong, D. Joiner, C. Chiu, M. Elsayed, K. Pereira, Y. Khmelevsky, and J. Mahony, “A survey of natural language processing implementation for data query systems,” in 2021 IEEE International Conference on Recent Advances in Systems Science and Engineering (RASSE).IEEE, 2021, p. 1–8. [33] A. Das and R. Balabantaray, “A review of datasets for nlidbs,” Informa- tion and Communication Technology for Competitive Strategies (ICTCS 2022), p. 213–223, 2023. [34] G. Katsogiannis-Meimarakis and G. Koutrika, “A survey on deep learn- ing approaches for text-to-sql,” The VLDB Journal, vol. 32, no. 4, p. 905–936, 2023. [35] Y. Luo, G. Li, J. Fan, C. Chai, and N. Tang, “Natural language to sql: State of the art and open problems,” Proceedings of the VLDB Endowment, vol. 18, no. 12, p. 5466–5471, 2025. [36] Z. Hong, Z. Yuan, Q. Zhang, H. Chen, J. Dong, F. Huang, and X. Huang, “Next-generation database interfaces: A survey of llm-based text-to-sql,” IEEE Transactions on Knowledge and Data Engineering, 2025. [37] M. Liu and J. Xu, “Nli4db: A systematic review of natural language interfaces for databases,” arXiv preprint arXiv:2503.02435, 2025. [38] X. Liu, S. Shen, B. Li, P. Ma, R. Jiang, Y. Zhang, J. Fan, G. Li, N. Tang, and Y. Luo, “A survey of text-to-sql in the era of llms: Where are we, and where are we going?” IEEE Transactions on Knowledge and Data Engineering, 2025. [39] Z. Tang, W. Wang, Z. Zhou, Y. Jiao, B. Xu, B. Niu, D. Zhou, X. Zhou, G. Li, Y. He et al., “Llm/agent-as-data-analyst: A survey,” arXiv preprint arXiv:2509.23988, 2025. [40] A. Singh, A. Shetty, A. Ehtesham, S. Kumar, and T. T. Khoei, “A survey of large language model-based generative ai for text-to-sql: Benchmarks, applications, use cases, and challenges,” in 2025 IEEE 15th Annual Computing and Communication Workshop and Conference (CCWC). IEEE, 2025, p. 00 015–00 021. [41] L. Shi, Z. Tang, N. Zhang, X. Zhang, and Z. Yang, “A survey on employing large language models for text-to-sql tasks,” ACM Computing Surveys, vol. 58, no. 2, p. 1–37, 2025. [42] W. Zhang, Y. Wang, Y. Song, V. J. Wei, Y. Tian, Y. Qi, J. H. Chan, R. C.-W. Wong, and H. Yang, “Natural language interfaces for tabular data querying and visualization: A survey,” 2024. [43] X. Zhu, Q. Li, L. Cui, and Y. Liu, “Large language model enhanced text- to-sql generation: A survey,” 2024. [44] X. Liu, S. Shen, B. Li, P. Ma, R. Jiang, Y. Zhang, J. Fan, G. Li, N. Tang, and Y. Luo, “A survey of text-to-sql in the era of llms: Where are we, and where are we going?” 2025. [45] Z. Hong, Z. Yuan, Q. Zhang, H. Chen, J. Dong, F. Huang, and X. Huang, “Next-generation database interfaces: A survey of llm-based text-to-sql,” 2025. [46] X. Zhang, R. R. Chowdhury, R. K. Gupta, and J. Shang, “Large language models for time series: A survey,” arXiv preprint arXiv:2402.01801, 2024. [47] X. Huang, Z. Tu, X. Ye, and M. Goodchild, “The role of open-source llms in shaping the future of geoai,” Annals of GIS, p. 1–10, 2026. [48] M. Jin, Q. Wen, Y. Liang, C. Zhang, S. Xue, X. Wang, J. Zhang, Y. Wang, H. Chen, X. Li et al., “Large models for time series and spatio-temporal data: A survey and outlook,” arXiv preprint arXiv:2310.10196, 2023. [49] Q. Ma, Z. Liu, Z. Zheng, Z. Huang, S. Zhu, Z. Yu, and J. T. Kwok, “A survey on time-series pre-trained models,” IEEE Transactions on Knowledge and Data Engineering, vol. 36, no. 12, p. 7536–7555, 2024. [50] M. Hashemi and A. Züfle, “A comprehensive survey of agentic ai for spatio-temporal data,” 2026. [51] A. Eldawy, “Spatialhadoop: towards flexible and scalable spatial pro- cessing using mapreduce,” in Proceedings of the 2014 SIGMOD PhD Symposium, ser. SIGMOD’14 PhD Symposium. New York, NY, USA: Association for Computing Machinery, 2014, p. 46–50. [52] TheApacheSoftwareFoundation,“Sedonadb,” https://sedona.apache.org/sedonadb, accessed: 2025-12-05. [53] M. Liu, X. Wang, J. Xu, and H. Lu, “Nalspatial: An effective natural language transformation framework for queries over spatial data,” in Proceedings of the 31st ACM International Conference on Advances in Geographic Information Systems, 2023, p. 1–4. [54] “Timescaledb : Sql made scalable for time-series data,” 2017. [Online]. Available: https://api.semanticscholar.org/CorpusID:34446750 20VOLUME 4, 2016 [55] M. Nasar and M. Abu Kausar, “Suitability of influxdb database for iot applications,” International Journal of Innovative Technology and Exploring Engineering, 08 2019. [56] J. Li, W. Wang, W.-S. Ku, Y. Tian, and H. Wang, “Spatialnli: A spatial domain natural language interface to databases using spatial compre- hension,” in Proceedings of the 27th ACM SIGSPATIAL International Conference on Advances in Geographic Information Systems, 2019, p. 339–348. [57] S. Hou, H. Jiao, Z. Liu, L. Xie, G. Chen, S. Wu, X. Guan, and H. Wu, “Geosql-eval: First evaluation of llms on postgis-based nl2geosql queries,” arXiv preprint arXiv:2509.25264, 2025. [58] S. Houa, H. Jiaob, Z. Liua, L. Xiea, G. Chenb, S. Wua, X. Guan, and H. Wua, “From nl2sql to nl2geosql: Geosql-eval for automated evaluation of llms on postgis queries.” [59] A. Ito, K. Dohi, and Y. Kawaguchi, “Clasp: Learning concepts for time-series signals from natural language supervision,” arXiv preprint arXiv:2411.08397, 2024. [60] K. Dohi, T. Nishida, H. Purohit, T. Endo, and Y. Kawaguchi, “Retrieving time-series differences using natural language queries,” arXiv preprint arXiv:2503.21378, 2025. [61] X. Wang, W. Yi, M. Liu, and C. Zong, “Nalmobench: Towards bench- marking natural language interfaces for moving objects databases,” Pro- ceedings of the VLDB Endowment. ISSN, vol. 2150, p. 8097. [62] C. Zhang, B. Zhang, D. Yang, X. Peng, M. Chen, S. Xie, G. Chen, W. Bi, and W. Li, “Promassistant: Leveraging large language models for text-to- promql,” arXiv preprint arXiv:2503.03114, 2025. [63] V. R. Chintaphally, K. Neumeier, J. McFarlane, J. Cothren, and C. W. Thompson, “Extending a natural language interface with geospatial queries,” IEEE Internet Computing, vol. 11, no. 6, p. 82–85, 2007. [64] A. Eldawy and M. F. Mokbel, “Spatialhadoop: A mapreduce framework for spatial data,” in 2015 IEEE 31st international conference on Data Engineering. IEEE, 2015, p. 1352–1363. [65] M. Liu, X. Wang, and J. Xu, “Nalsd: A natural language interface for spatial databases,” in Proceedings of the 18th International Symposium on Spatial and Temporal Data, 2023, p. 175–179. [66] M. Liu, X. Wang, J. Xu, H. Lu, and Y. Tong, “Nalspatial: A natural lan- guage interface for spatial databases,” IEEE Transactions on Knowledge and Data Engineering, 2025. [67] Y. Feng, P. Zhang, G. Xiao, L. Ding, and L. Meng, “Towards a barrier- free geoqa portal: Natural language interaction with geospatial data using multi-agent llms and semantic search,” arXiv preprint arXiv:2503.14251, 2025. [68] A. Khosravi Kazazi, Z. Li, M. Naser Lessani, and G. Cervone, “From questions to queries: An ai-powered multi-agent framework for spatial text-to-sql,” arXiv e-prints, p. arXiv–2510, 2025. [69] C. Yu, Y. Yao, X. Zhang, G. Zhu, Y. Guo, X. Shao, M. Shibasaki, Z. Hu, L. Dai, Q. Guan et al., “Monkuu: a llm-powered natural language interface for geospatial databases with dynamic schema mapping,” Inter- national Journal of Geographical Information Science, p. 1–22, 2025. [70] D. Yu, R. Bao, G. Mai, and L. Zhao, “Spatial-rag: Spatial retrieval augmented generation for real-world spatial reasoning questions,” arXiv preprint arXiv:2502.18470, 2025. [71] C. Düntgen, T. Behr, and R. H. Güting, “Berlinmod: a benchmark for moving object databases,” The VLDB Journal, vol. 18, no. 6, p. 1335– 1368, 2009. [72] X. Wang, J. Xu, and Y. Wang, “Nlmo: towards a natural language tool for querying moving objects,” in 2020 21st IEEE International Conference on Mobile Data Management (MDM). IEEE, 2020, p. 228–229. [73] X. Wang, J. Xu, and H. Lu, “Nalmo: A natural language interface for moving objects databases,” in Proceedings of the 17th International Symposium on Spatial and Temporal Databases, 2021, p. 1–11. [74] X. Wang, M. Liu, J. Xu, and H. Lu, “Nalmo: Transforming queries in natural language for moving objects databases,” GeoInformatica, vol. 27, no. 3, p. 427–460, 2023. [75] V. Teixeira de Almeida, R. Hartmut Guting, and T. Behr, “Querying moving objects in secondo,” in 7th International Conference on Mobile Data Management (MDM’06), 2006, p. 47–47. [76] R. H. Güting and M. Schneider, Moving objects databases.Academic Press, 2005. [77] P. Ramsey and V.-B. Columbia, “Introduction to postgis,” Refractions Research Inc, p. 34–35, 2005. [78] M. Staniek, R. Schumann, M. Züfle, and S. Riezler, “Text-to-overpassql: A natural language interface for complex geodata querying of open- streetmap,” Transactions of the Association for Computational Linguis- tics, vol. 12, p. 562–575, 2024. [79] J. Bennett, OpenStreetMap. Packt Publishing Ltd, 2010. [80] R. Olbricht et al., “Overpass api,” Anwenderkonferenz für Freie und Open Source Software für Geoinformationssysteme, 2011. [81] D. Abugov, N. Alexander, B. Blackwell, R. Chatterjee, D. Geringer, M. Horhammer, Y. Hu, B. Kazar, R. Kothuri, S. Ravada et al., “Oracle spatial developer’s guide, 11g release 1 (11.1) b28400-05.” [82] U. Yaramanci, G. Lange, and M. Hertrich, “Aquifer characterisation using surface nmr jointly with other geophysical techniques at the nauen/berlin test site,” Journal of Applied Geophysics, vol. 50, no. 1-2, p. 47–65, 2002. [83] H. Xu, E. Hamzei, E. Nyamsuren, H. Kruiger, S. Winter, M. Tomko, and S. Scheider, “Extracting interrogative intents and concepts from geo- analytic questions,” AGILE: GIScience Series, vol. 1, p. 23, 2020. [84] C. A. Thompson, R. J. Mooney, and L. R. Tang, “Learning to parse natural language database queries into logical form,” in Workshop on Automata Induction, Grammatical Inference and Language Acquisition, 1997. [85] P. Liang, M. I. Jordan, and D. Klein, “Learning dependency-based compositional semantics,” Computational Linguistics, vol. 39, no. 2, p. 389–446, 2013. [86] H. Jhamtani and T. Berg-Kirkpatrick, “Truth-conditional captioning of time series data,” in EMNLP, 2021. [87] Y. Kawaguchi, K. Dohi, and A. Ito, “Sushi: A dataset of synthetic unichannel signals based on heuristic implementation (tiny),” Sep. 2024. [Online]. Available: https://doi.org/10.5281/zenodo.13882998 [88] K. Dohi, A. Ito, H. Purohit, T. Nishida, T. Endo, and Y. Kawaguchi, “Domain-independent automatic generation of descriptive texts for time- series data,” 09 2024. [89] C. Lee, O. Polozov, and M. Richardson, “Kaggledbqa: Realistic evaluation of text-to-sql parsers,” CoRR, vol. abs/2106.11455, 2021. [Online]. Available: https://arxiv.org/abs/2106.11455 [90] A. Furieri, “Spatialite: An open source spatial database engine,” 2011. [91] A. Sezgin, “Natural language interfaces for structured query generation in iod platforms,” Drones, vol. 9, no. 6, 2025. [Online]. Available: https://w.mdpi.com/2504-446X/9/6/444 [92] F. Wang, “A fuzzy grammar and possibility theory-based natural lan- guage user interface for spatial queries,” Fuzzy sets and systems, vol. 113, no. 1, p. 147–159, 2000. [93] M. Redd, T. Zhe, and D. Wang, “From queries to insights: Agentic llm pipelines for spatio-temporal text-to-sql,” in Proceedings of the 1st ACM SIGSPATIAL International Workshop on Generative and Agentic AI for Multi-Modality Space-Time Intelligence, 2025, p. 6–14. [94] K. Chowdhary, “Natural language processing,” Fundamentals of artificial intelligence, p. 603–649, 2020. [95] T. Al-Moslmi, M. G. Ocaña, A. L. Opdahl, and C. Veres, “Named entity extraction for knowledge graphs: A literature overview,” IEEE access, vol. 8, p. 32 862–32 881, 2020. [96] V. Kumar, M. I. Iqbal, and R. Rathore, “Natural language processing (nlp) in disease detection—a discussion of how nlp techniques can be used to analyze and classify medical text data for disease diagnosis,” AI in Disease Detection: Advancements and Applications, p. 53–75, 2025. [97] W. A. Woods, “Progress in natural language understanding: an applica- tion to lunar geology,” in Proceedings of the June 4-8, 1973, national computer conference and exposition, 1973, p. 441–450. [98] A.-M. Popescu, O. Etzioni, and H. Kautz, “Towards a theory of natural language interfaces to databases,” in Proceedings of the 8th international conference on Intelligent user interfaces, 2003, p. 149–157. [99] F. Li and H. V. Jagadish, “Nalir: an interactive natural language interface for querying relational databases,” in Proceedings of the 2014 ACM SIGMOD international conference on Management of data, 2014, p. 709–712. [100] L. S. Zettlemoyer and M. Collins, “Learning to map sentences to logical form: Structured classification with probabilistic categorial grammars,” arXiv preprint arXiv:1207.1420, 2012. [101] B. Wang, R. Shin, X. Liu, O. Polozov, and M. Richardson, “Rat-sql: Relation-aware schema encoding and linking for text-to-sql parsers,” in Proceedings of the 58th annual meeting of the association for computa- tional linguistics, 2020, p. 7567–7578. [102] T. Scholak, N. Schucher, and D. Bahdanau, “Picard: Parsing incremen- tally for constrained auto-regressive decoding from language models,” arXiv preprint arXiv:2109.05093, 2021. VOLUME 4, 201621 [103] B. Ding, C. Qin, L. Liu, Y. K. Chia, B. Li, S. Joty, and L. Bing, “Is gpt-3 a good data annotator?” in Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), 2023, p. 11 173–11 195. [104] M. Pourreza and D. Rafiei, “Din-sql: Decomposed in-context learning of text-to-sql with self-correction,” Advances in Neural Information Processing Systems, vol. 36, p. 36 339–36 348, 2023. [105] H. Li, J. Zhang, C. Li, and H. Chen, “Resdsql: Decoupling schema linking and skeleton parsing for text-to-sql,” in Proceedings of the AAAI Conference on Artificial Intelligence, vol. 37, no. 11, 2023, p. 13 067– 13 075. [106] R. Sun, S. Ö. Arik, A. Muzio, L. Miculicich, S. Gundabathula, P. Yin, H. Dai, H. Nakhost, R. Sinha, Z. Wang et al., “Sql-palm: Improved large language model adaptation for text-to-sql (extended),” arXiv preprint arXiv:2306.00739, 2023. [107] N. M. Shelke, R. Dharaskar, and V. Thakre, “An approach for solving of natural language queries and transliteration using multi-agent system.” [108] B. Wang, C. Ren, J. Yang, X. Liang, J. Bai, L. Chai, Z. Yan, Q.-W. Zhang, D. Yin, X. Sun et al., “Mac-sql: A multi-agent collaborative framework for text-to-sql,” in Proceedings of the 31st International Conference on Computational Linguistics, 2025, p. 540–557. [109] O. R. Heidari, S. Reid, and Y. Yaakoubi, “Agentiql: An agent-inspired multi-expert framework for text-to-sql generation,” arXiv preprint arXiv:2510.10661, 2025. [110] K. Lin, B. Bogin, M. Neumann, J. Berant, and M. Gardner, “Grammar- based neural text-to-sql generation,” arXiv preprint arXiv:1905.13326, 2019. [111] M. Deng, A. Ramachandran, C. Xu, L. Hu, Z. Yao, A. Datta, and H. Zhang, “Reforce: A text-to-sql agent with self-refinement, format restriction, and column exploration,” in ICLR 2025 Workshop: VerifAI: AI Verification in the Wild, 2025. [112] B. Zhai, C. Xu, Y. He, and Z. Yao, “Optimizing reasoning for text- to-sql with execution feedback,” in Findings of the Association for Computational Linguistics: ACL 2025, 2025, p. 19 206–19 218. [113] P. Ghosh, A. Jain, and P. Yenigalla, “Sqlgenie: A practical llm based system for reliable and efficient sql generation,” 2025. [114] R. Feng, K. A. Brennan, Z. Azizi, J. Goyal, B. Deb, H. J. Chang, P. Gane- san, P. Clopton, M. Pedron, S. Ruiperez-Campillo et al., “Engineering of generative artificial intelligence and natural language processing models to accurately identify arrhythmia recurrence,” Circulation: Arrhythmia and Electrophysiology, vol. 18, no. 1, p. e013023, 2025. [115] J. Patel, “Natural language to sql: A semantic mapping and metadata approach for database interaction,” in International Conference on Com- puter Science and Communication Engineering (ICCSCE 2025).At- lantis Press, 2025, p. 1405–1418. [116] S. Sharma, S. Jain, M. K. Tiwari, and S. lal, “Classifying the state of knowledge-based question answering: patterns, progress, and prospects,” International Journal of Computers and Applications, vol. 47, no. 1, p. 93–105, 2025. [117] J. Kim and R. Mooney, “Generative alignment and semantic parsing for learning from ambiguous supervision,” in Coling 2010: Posters, 2010, p. 543–551. [118] R. J. Kate and R. J. Mooney, “Learning language semantics from am- biguous supervision,” in AAAI, vol. 7, 2007, p. 895–900. [119] M. Hazoom, V. Malik, and B. Bogin, “Text-to-sql in the wild: A naturally-occurring dataset based on stack exchange data,” arXiv preprint arXiv:2106.05006, 2021. [120] J. Fan, Z. Gu, S. Zhang, Y. Zhang, Z. Chen, L. Cao, G. Li, S. Madden, X. Du, and N. Tang, “Combining small language models and large language models for zero-shot nl2sql,” Proceedings of the VLDB En- dowment, vol. 17, no. 11, p. 2750–2763, 2024. [121] K. T. Pham, T. H. Nguyen, J. Jo, Q. V. H. Nguyen, and T. T. Nguyen, “Multilingual text-to-sql: Benchmarking the limits of language models with collaborative language agents,” arXiv preprint arXiv:2509.24405, 2025. [122] X. Wang and J. Xu, “Towards advanced natural language interfaces for moving objects databases,” in Proceedings of the 19th International Symposium on Spatial and Temporal Data, 2025, p. 111–114. [123] X. Huang, “Geo-hallucination in urban analytics: What it is and why it matters,” Environment and Planning B: Urban Analytics and City Science, p. 23998083251409526, 2025. [124] L. Ngweta, K. Kate, J. Tsay, and Y. Rizk, “Towards llms robustness to changes in prompt format styles,” in Proceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Compu- tational Linguistics: Human Language Technologies (Volume 4: Student Research Workshop), 2025, p. 529–537. [125] R. Liu, X. Chen, J. Zhang, Q. Zhang, Y. Zhang, and B. Yang, “Safenlidb: A privacy-preserving safety alignment framework for llm-based natural language database interfaces,” arXiv preprint arXiv:2511.06778, 2025. [126] M. Rauch, “Conversational interfaces for data analysis: Evaluating mod- ular agent architectures,” 2025. [127] J. Li, T. Wu, Y. Mao, Y. Gao, Y. Feng, and H. Liu, “Sql-factory: A multi- agent framework for high-quality and large-scale sql generation,” arXiv preprint arXiv:2504.14837, 2025. [128] W. Hwang, J. Yim, S. Park, and M. Seo, “A comprehensive exploration on wikisql with table-aware word contextualization,” arXiv preprint arXiv:1902.01069, 2019. [129] T. Yu, R. Zhang, K. Yang, M. Yasunaga, D. Wang, Z. Li, J. Ma, I. Li, Q. Yao, S. Roman et al., “Spider: A large-scale human-labeled dataset for complex and cross-domain semantic parsing and text-to-sql task,” arXiv preprint arXiv:1809.08887, 2018. [130] B. Wang, Y. Gao, Z. Li, and J.-G. Lou, “Know what i don’t know: Handling ambiguous and unknown questions for text-to-sql,” in Findings of the Association for Computational Linguistics: ACL 2023, 2023, p. 5701–5714. [131] C.-K. Wu, Z. R. Tam, C.-C. Wu, C.-Y. Lin, H.-y. Lee, and Y.-N. Chen, “I need help! evaluating llm’s ability to ask for users’ support: A case study on text-to-sql generation,” in Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing, 2024, p. 2191– 2199. [132] Y. Zhang, X. Dong, S. Chang, T. Yu, P. Shi, and R. Zhang, “Did you ask a good question? a cross-domain question intention classification benchmark for text-to-sql,” arXiv preprint arXiv:2010.12634, 2020. [133] A. Fieschi, P. Hirmer, C. Stach, and B. Mitschang, “Characterising and categorising anonymization techniques: A literature-based approach.” in ICISSP (1), 2025, p. 107–118. [134] M. Templ and M. Sariyar, “A systematic overview on methods to protect sensitive data provided for various analyses,” International Journal of Information Security, vol. 21, no. 6, p. 1233–1246, 2022. [135] Z. Ji, T. Yu, Y. Xu, N. Lee, E. Ishii, and P. Fung, “Towards mitigating llm hallucination via self reflection,” in Findings of the Association for Computational Linguistics: EMNLP 2023, 2023, p. 1827–1843. [136] G. Zhan, G. Shi, X. Liu, and N. Wang, “Natural language to sql using large language models,” in 2025 21st International Conference on Natural Computation, Fuzzy Systems and Knowledge Discovery (ICNC-FSKD). IEEE, 2025, p. 495–502. [137] A. Kaygude, O. Rajguru, S. Karad, and G. Avhad, “Text-to-sql con- version by using deep learning/machine learning: Integrating natural language with database queries.” [138] Y. Liu and T. Zhang, “Graph-fusion resdsql: Enhancing nl2sql robustness with dynamic schema linking and contextual integration,” in 2025 IEEE 7th International Conference on Communications, Information System and Computer Engineering (CISCE). IEEE, 2025, p. 221–225. [139] S. Lyu, H. Luo, R. Li, Z. Ou, J. Sun, Y. Qin, X. Shang, M. Song, and Y. Zhu, “Sql-o1: A self-reward heuristic dynamic search method for text- to-sql,” arXiv preprint arXiv:2502.11741, 2025. [140] W. Zhao, F. Wu, Z. Zheng 1 , and H. Jin 1 , “Enhancing interaction graph of data schema and syntactic structure,” in Big Data: 12th CCF Conference, BigData 2024, Qingdao, China, August 9–11, 2024, Proceedings, vol. 2301. Springer Nature, 2025, p. 159. [141] R. Li, Y. Feng, Z. Fan, G. Carenini, W. Zhang, M. Pourreza, and Y. Zhang, “Detriever: Decoder-representation-based retriever for improving nl2sql in-context learning,” in Proceedings of the 31st International Conference on Computational Linguistics, 2025, p. 8173–8183. [142] N. Srikanth, V. Bursztyn, P. Mathur, and A. Nenkova, “Sqlspace: A representation space for text-to-sql to discover and mitigate robustness gaps,” arXiv preprint arXiv:2510.27532, 2025. 22VOLUME 4, 2016