Data Science & Analysis · 2026
Cadaster AI Assistant
A proof of concept for a controlled conversational interface to cadastral data — ask a normal-language question, get an answer grounded in curated data, without ever handing the AI unrestricted database access.
The Problem
Working with clients on cadastral and land-information systems, I kept seeing the same pattern: users can only inspect cadastral data through predefined forms, filters, tables, reports or GIS layers. These workflows are structured and necessary — but they assume the user already knows which table holds the answer, which layer to open, which filter to apply, which spatial operation to run, and how the underlying data model is put together.
A user often knows the business question they want to ask — "what parcels overlap?", "what happened to this parcel?" — without knowing how to translate it into the system's menus and filters. That gap between the question someone has and the query the system expects is what this POC set out to explore.
The Product Idea
What if a user could ask a cadastral database a normal-language question, while the system kept strict control over what the AI is actually allowed to access and execute?
The Cadaster AI Assistant uses an LLM purely as an interpretation layer between the user and the cadastral data — not as a database client. The model does not receive unrestricted SQL access and has no freedom to query the database directly. It reads the user's intent and decides which of a small set of predefined, trusted tools to call; everything the tools are allowed to do is fixed in advance. This gets natural-language interaction without giving the AI unrestricted access to the underlying cadastral database.
How It Works
interprets intent → Approved tool
deterministic call → dbt model / view
curated, controlled → PostGIS → Answer + map
The agent's job stops at understanding the question and picking the right tool. It never writes or executes SQL itself. The tool queries a curated dbt model, the structured result comes back, and the agent explains that result in natural language — with any spatial results passed to the frontend as GeoJSON and drawn on the map. Database access stays deterministic and controlled at every step.
POC Capabilities
This is a proof of concept, not a production cadastral system. The current build implements a small set of tools demonstrating several kinds of cadastral queries:
- Retrieving current parcels
- Filtering parcels by district and status
- Viewing parcel history and lineage (splits, retirements, version chains)
- Identifying parcel overlaps
- Retrieving parcel statistics
- Returning spatial results that can be visualized on a map
Things you can ask the assistant in the live demo:
- "Can you show me the current approved parcels in District Mjini?"
- "What overlaps exist in the cadastral database?"
- "Can you show me the history of parcel PAR-101?"
Database statistics on request — the tool returns structured counts, the agent narrates them.
Overlap detection — the agent selects the overlap tool, and the result is rendered on the map.
Parcel history and lineage — split events, retirements and successor parcels explained in plain language.
The frontend is intentionally simple. Its purpose is to demonstrate the interaction pattern — conversational result to spatial visualization — rather than to be a full cadastral client. The same pattern could later be embedded into an existing cadastral information system, land information system, GIS portal or administrative application.
Architecture & Engineering Decisions
The architecture is deliberately designed around one constraint: the LLM interprets intent, and only trusted, predefined operations ever touch the database.
- No free-form SQL. The LLM cannot freely query PostgreSQL and never generates arbitrary SQL for execution — it can only call predefined tools.
- Curated data layer. Tools query curated views and models built with dbt, so the data layer is controlled separately from the AI layer.
- Grounded answers. Tool outputs — not model recall — provide the grounding for every final answer, reducing hallucination risk.
- Spatial results as GeoJSON. Results that carry geometry are passed back to the frontend as GeoJSON and rendered on a MapLibre map.
- Tracing. Agent runs are traced end-to-end with LangSmith, so tool selection and reasoning steps are inspectable rather than opaque.
Technology Stack
Database
- PostgreSQL
- PostGIS
- Aiven managed PostgreSQL/PostGIS (deployed POC)
Data Engineering
- dbt
- Raw cadastral source tables
- Staging models
- Curated marts / views for the application
- ELT workflow separating raw data from the application-facing layer
Backend / AI
- Python & FastAPI
- LangChain & LangGraph
- Google Gemini
- LangSmith (tracing & observability)
- Psycopg for PostgreSQL access
- Purpose-built cadastral query tools
Frontend
- React & Vite
- MapLibre GL
- React Markdown
- GeoJSON-based map updates
Deployment
- Netlify — frontend
- Render — FastAPI backend
- Aiven — PostgreSQL/PostGIS
- GitHub — source control & deployment integration
A note on the data
All data used in this project is synthetic. The demo dataset is loosely based on a Zanzibar cadastral context because I was physically working in Zanzibar while developing this POC — but no parcels, ownership records, boundaries, IDs, names or other information shown in the application represent real cadastral records. The dataset exists only for demonstration and portfolio purposes.
What This Could Become
This project is intentionally limited to a proof of concept. But the interaction model it demonstrates — natural-language questions answered through controlled, predefined tools over curated data — isn't specific to this dataset. The same pattern could be extended with a broader tool set and embedded into a real cadastral or land-information system, giving non-technical users a way to explore data conversationally without ever loosening control over what the AI is allowed to touch.
Code
Source is public on GitHub; the demo is deployed live.