AI · Geospatial

GeoEstateChat

A research prototype that uses an LLM to translate natural-language questions into deterministic PostGIS queries over NYC real-estate data, joining GIS-grade spatial analysis with the usability of a chat interface.

Methods

LLM automation · Geospatial analysis · Full-stack development

Stack

FastAPI · PostgreSQL + PostGIS · MapLibre GL · OpenAI API

Code

GitHub

GeoEstateChat is a research project exploring how LLMs can improve the interaction between geospatial analysis and real-estate decision-making. The LLM is studied as an analytical intermediary that translates natural-language questions into structured, multi-scale geospatial queries, rather than as a source of knowledge.

Diagram positioning the LLM as an intermediary between the user and a geospatial backend.

Overview

Geospatial tools are powerful and flexible but hard to use, so they stay mostly with domain experts, while consumer real-estate platforms are usable but shallow, offering little beyond location and price. By pairing an LLM reasoning layer with a deterministic geospatial backend, GeoEstateChat asks how user intent, spatial scale, data filtering, and analytical logic can be inferred from ambiguous human language, so a single system can be both deep and usable. The aim is to lower the technical barrier of GIS while preserving analytical rigor, transparency, and reproducibility, and to position the LLM as a new infrastructural layer for geospatial research.

How can NYC real estate be analyzed geospatially through a friendly platform in a way current tools cannot offer?

How can geospatial data be made more accessible and intuitive for non-experts?

How can experience design and visualization help users explore complex geospatial information?

LLM as Query Engine

Can an LLM reliably translate ambiguous natural-language intent into valid, multi-step SQL over a geospatial database?

A structured system prompt encodes the full database schema and spatial-operation semantics
The LLM infers spatial scale, filters, groupings, and sort order from conversational input
Deterministic SQL execution keeps results reproducible and auditable

Accessibility vs. Analytical Depth

How can one interface serve both casual users and domain experts without sacrificing usability or rigor?

Three interaction modes (Analyze, Search, Compare) target distinct user intents
No GIS expertise required: queries are expressed in plain language
The backend preserves full geospatial complexity, including multi-scale joins and aggregations

Spatial Visualization

How can query results over spatial data be rendered so geographic patterns are immediately legible?

Results map to building footprints, street blocks, and neighborhood polygons
Dynamic choropleth rendering responds to each query result set
Statistical summaries accompany the visuals to provide analytical context

The problem

Real-estate decisions are inherently spatial, yet the available tools sit at opposite ends of a usability-versus-complexity spectrum. GIS platforms like QGIS or ArcGIS offer deep analysis but demand specialized knowledge; consumer platforms like Zillow or StreetEasy are accessible but collapse rich geospatial data into a handful of listing attributes (price, bedrooms, photos). GeoEstateChat sits in that gap: the LLM turns natural language into structured queries that run against a deterministic geospatial backend, so results are always data-driven and reproducible, never hallucinated.

Dimension	GIS tools (QGIS / ArcGIS)	Consumer platforms (Zillow / StreetEasy)	GeoEstateChat
Required expertise	High: GIS knowledge required	None	None: plain-language interface
Analytical depth	Full spatial analysis	Basic: price, beds, location	Multi-scale geospatial queries
Query interface	Scripting / GUI tools	Filter dropdowns	Natural-language conversation
Spatial data layers	Any, user-configured	Point listings only	Buildings, street blocks, neighborhoods
Result reproducibility	High (deterministic)	Depends on live listings	High: LLM writes SQL, backend executes
Onboarding time	Hours to days	Seconds	Seconds

Data table features

Original NYC building and street-block data table.

Building & street-block table features:

built year
roof height
ground elevation
elevator
building value 2025
building value 2024
building gross sqft
residential gross sqft
building story
zoning
building class
average property value 2025 / 2024
value per sqft
land area
GeoID
borocode
population
building id number
last status
residential area share
…

The database integrates NYC PLUTO building data with street-block-level population and property-value statistics. Features were selected to support both spatial (geometry-based joins) and attribute-level queries, so the system can reason about proximity, density, land use, and value at once. Every table was spatially indexed with PostGIS for efficient bounding-box and distance queries at building, block, and neighborhood scales.

Project structure

Overall system architecture of GeoEstateChat.

Data flowchart

Data flow from user query through SQL generation to the frontend response.

When a query is submitted, it is combined with the system instruction, the model gathers the information it needs to generate SQL, and once the data is pulled from the database it returns to the frontend with a statistical summary and explanation.

LLM query pipeline

The core technical challenge is converting loosely structured natural language, for example "find street blocks near Central Park with high-rise buildings built after 2000", into valid, correct PostGIS SQL. GeoEstateChat uses a structured system prompt encoding the full schema, available spatial operations, column semantics, and expected output format. The LLM acts as a query planner: it selects tables, infers joins, and constructs spatial predicates. The resulting SQL runs unchanged against PostGIS, so results are deterministic and data-sourced.

User query

Plain-language question submitted via the chat interface

Prompt assembly

Query combined with the system prompt, column semantics, and spatial constraints

LLM inference

Model generates structured SQL with the right spatial joins and filters

PostGIS execution

SQL executed deterministically against the geospatial database

Response

Results returned with a statistical summary and plain-language explanation

System demonstration

Mode: Analyze

Mode: Search

Mode: Compare

Project demonstration

Animated demonstration of GeoEstateChat in use.

Technical stack

Frontend	Vanilla JavaScript · MapLibre GL · Canvas API
Backend	FastAPI · Uvicorn · Python 3
Database	PostgreSQL · PostGIS · GIST spatial indexing
LLM integration	OpenAI API · gpt-5-nano · structured system prompt · SQL-generation pipeline
Geospatial	GeoPandas · Shapely · PostGIS functions (ST_Within, ST_Distance, ST_DWithin)
Data sources	NYC PLUTO · street-block statistics · neighborhood polygon boundaries

Design principles

Three principles set GeoEstateChat apart from both GIS tools and consumer real-estate platforms.

LLM as translator, not oracle

The LLM never invents facts about the city. It translates intent into SQL, and the database provides ground truth, keeping analytical rigor while enabling natural interaction with no GIS expertise.

Deterministic backend

All results come from SQL executed against real data. The same query returns the same answer regardless of LLM non-determinism at the language level, so results stay auditable and reproducible.

Spatial transparency

The generated SQL is surfaced alongside results, so users and researchers can inspect the spatial logic, understand the filters, and verify how a conclusion was reached.