The painful reality of geocoding real estate data where street addresses don't exist

Dmitrii Kuznetsov — Mon, 19 Oct 2026 10:07:17 +0000

When we started mapping property developments across Cambodia, Thailand, and Bali for NovAsia, I assumed the location pipeline would be the easiest part of our stack.

The mental model was simple:

Extract the address string from the developer sheet.

Send it to Google Maps Geocoding API or Nominatim.

Save (lat, lng) into a PostGIS column.

Render pretty map pins on the frontend.

If you’ve only built location features for cities like London, New York, or Berlin, this works out of the box.

If you try running that same pipeline on emerging Southeast Asian markets, it fails instantly. Here is what broke, and how we had to rebuild our spatial data ingestion from scratch.

The address structure doesn't follow Western logic In Western markets, an address is a neat hierarchy: Number → Street → City → Zip Code.

In Cambodia and Thailand, addresses are often descriptive, administrative, or relational:

District-level fallback: An address like "Street 288, Sangkat Boeng Keng Kang 1, Khan Boeng Keng Kang, Phnom Penh" often causes standard geocoding APIs to shrug and drop the pin directly in the geographic center of the district (sometimes 2 km away from where the actual tower is being built).

The "Moo" system in Thailand: In coastal markets like Phuket or Pattaya, rural administrative divisions (Moo 5, Tambon Choeng Thale) cover huge geographic areas. A geocoder will happily drop a beachfront condominium pin in the middle of an inland rubber plantation 5 miles away.

Landmark-based directions: Many legal documents literally identify a plot as "200m south of the pagoda, opposite the market."

Off-plan projects have no street address yet: When a developer breaks ground on a 40-story residential tower, the municipal street number often doesn't exist yet. The project exists only as a plot boundary on a master development plan.

Transliteration phonetic traps The same district or road name is routinely spelled three different ways depending on who translated the Khmer or Thai script into the Latin alphabet:

Boeng Keng Kang vs. BKK vs. Beng Keng Kang

Na Kluea vs. Naklua

Rawai vs. Rawei

If you do naive string matching against address catalogs, you get duplicate entries, fragmented databases, and orphan records.

What we actually built to fix it Throwing expensive API calls at bad strings didn't work. We had to redesign our spatial ingestion into a three-step pipeline:

Step A: Hierarchical fuzzy matching with local aliases
Before geocoding, we pass raw location strings through a normalization step in Python. We maintain an open dictionary of administrative units (Provinces → Districts/Khans → Communes/Sangkats) mapped to their common phonetic variations and common acronyms. We use Levenshtein distance thresholds to lock down the exact administrative boundary first.

Step B: Polygon boundaries over single coordinate points
Instead of relying on single (lat, lng) points, we store development parcels as spatial polygons in PostGIS. For off-plan developments, our pipeline pulls the cadastral plot coordinates directly from planning permission filings and developer master plans. A polygon gives us verifiable bounds; a single geocoded point is almost always slightly wrong.

Step C: Heuristic sanity checks
We wrote automated spatial validation rules to catch geocoder hallucinations before data hits production. For example:

If a condominium is tagged as "beachfront" in Pattaya or Phuket, but the PostGIS query calculates the distance to the coastline polygon as > 400 meters, the record is automatically flagged for manual review.

If a project in Phnom Penh has coordinates outside the municipal city boundary polygon, the ingestion job fails loudly instead of silently committing bad coordinates.

The takeaway
If you're building location-heavy products in non-standardized regions, don't treat geocoding APIs as a silver bullet.

High-accuracy spatial search rarely comes from the API itself—it comes from building your own phonetic normalization layers and treating geographic validation with the same strictness you would apply to financial transactions.

Curious how other folks handle messy spatial data and non-standard addresses in emerging markets—what does your pipeline look like?

Why parsing real estate contracts with LLMs is ten times harder than tutorials claim

Dmitrii Kuznetsov — Sun, 18 Oct 2026 04:52:15 +0000

When we started building the data pipeline for NovAsia (a property catalog and market tool for Southeast Asia), the plan looked embarrassingly simple on paper:

Grab property PDFs and developer contracts (SPAs).

Run them through a modern vision LLM.

Dump structured JSON into PostgreSQL.

Call it a day.

Two weeks in, the pipeline was completely broken. Here is why standard tutorial advice fell apart in production, and what we had to change to get reliable data out of scanned documents.

The stuff tutorials don't warn you about
Most LLM document parsing demos use crisp, born-digital PDFs with clean typography. In emerging markets like Cambodia and Thailand, reality looks very different:

Phone scans: Half the documents are multi-generation scans or photos taken with a phone camera under uneven lighting.

Dual-language layout: Khmer or Thai text mixed with English, often in adjacent table columns where line baselines don't match.

Physical stamps: Red rubber stamps, signatures, and notary seals placed directly over critical numbers (payment milestone dates, sinking fund fees, transfer taxes).

The 40-page prompt trap: If you shove a 35-page PDF into a long-context model and ask for "all fees and payment dates", it will extract 80% correctly and quietly hallucinate the rest with total confidence.

Three practical changes that fixed it
Instead of trying to find one magic model that does everything, we broke the pipeline down into smaller, boring steps:

Aggressive image cleanup before text extraction

Before any model sees the page, we run basic OpenCV passes: deskewing, binarization, and contrast normalization. Removing phone-scan shadows did more for extraction accuracy than upgrading to a larger model tier.

Section-level chunking with rigid schema validation

We stopped asking the model to parse whole documents at once. We chunk by specific section (e.g., "Schedule of Payments", "Maintenance Obligations") and enforce strict Pydantic schemas. If a field fails validation or falls outside expected bounds, the pipeline flags it for manual check rather than guessing.

Treating tables and narrative text as separate problems

Vision models are great at answering qualitative questions ("under what conditions is the deposit refundable?"), but notoriously sloppy with columns in financial tables. We split table extraction into dedicated passes with explicit row-by-row checks.

The takeaway
If you're building with LLMs on messy, physical-world paperwork, raw context window size won't save you. Most of the reliability comes from image hygiene and strict schema boundaries.

Happy to trade notes if anyone else here is wrestling with noisy scans and table extraction.

DEV Community: Dmitrii Kuznetsov

The painful reality of geocoding real estate data where street addresses don't exist

Why parsing real estate contracts with LLMs is ten times harder than tutorials claim