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

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.

1. 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.

1. 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.

1. 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?