Geocoding Real Estate Data Without Street Addresses
Learn why geocoding fails for real estate in emerging markets and how to build a reliable pipeline with local aliases, parcel polygons, and spatial checks.
Geocoding Real Estate Data Without Street Addresses
Why Real Estate Geocoding Breaks When Addresses Don't Exist
A location pipeline can look simple on paper: take an address, ask a geocoding service for coordinates, store the result, and drop a pin on a map. In places where street numbering is consistent and address data is tidy, that approach often gets you moving fast.
It starts to fall apart when you're mapping real estate in areas with incomplete addressing, informal directions, multiple transliterations, or projects that haven't been assigned official addresses yet. That's common with off-plan developments and in parts of Southeast Asia. The geocoder may return something that looks right - often a coordinate that's off by hundreds of metres, or even a few kilometres. At a glance the map looks complete. Under the hood, the location is wrong.
The fix isn't to keep retrying the same address against more APIs and hoping one of them "gets it." Treat geocoding as just one signal inside a bigger location-data pipeline. Normalize local names, use parcel polygons when you can, keep provenance, and validate results against geographic rules before you show them to users.
Why conventional geocoding fails
Most geocoding systems assume that a structured address points to a place you can pin down. In many Western cities, that assumption holds up: building number, street, locality, and postal code follow recognizable patterns. A developer can send a string, and a geocoder can often match it to a known road segment or building footprint.
The model breaks when local addressing follows different conventions - or when the specific place you care about isn't in the map data yet. The bigger issue isn't just "coverage." Sometimes the input simply doesn't describe a unique point.
Administrative areas can be mistaken for precise locations
Take an address that lists a street, commune, district, and city. A geocoder might recognize the district, but not the exact road or building. In those cases it can still return coordinates - often a centroid or another "representative" point for the larger administrative area.
The result is technically valid. It has latitude and longitude. It may even look close to the right neighbourhood when someone zooms out. But a district-centre pin isn't a property location. If you're doing apartment search, estimating travel time, or filtering by distance, a few hundred metres can change what the user sees.
In Thailand, labels like a moo and tambon can cover large, varied areas. A result that resolves to the right locality can still place a development inland when it's actually on the coast. In other words, the geocoder answers a different question - "where is this administrative area?" - than the product asks: "where is this parcel?"
Directions and planned developments are not street addresses
Some property locations are described using local landmarks: near a pagoda, opposite a market, or a short distance from a road. Those descriptions work for people who know the area, but they don't automatically map to a unique coordinate. Turning them into a point usually needs local knowledge and supporting evidence.
Off-plan projects create a separate problem. A development can be real commercially before it has a street number. It might be defined in a master plan or a planning-permission document, while public map data still shows an empty parcel. If you ask a geocoder to "locate" a building that isn't represented in its dataset yet, you shouldn't expect a reliable building-level answer.
This is why repeated API calls rarely fix the root issue. A more expensive service may have broader coverage, but it still can't invent missing addresses, or recover parcel boundaries from an ambiguous description.
Transliteration creates duplicate places
A single Khmer or Thai place name can appear in Latin characters in multiple common ways. You might see shortened forms, phonetic variants, or different spacing. Matching systems can treat those as separate entities, and the duplicates grow over time.
That shows up as:
- Duplicate administrative records stored in the database.
- Property listings failing to match the correct district or project.
- Search filters splitting results across spelling variants.
- Updates landing in one spelling but not another.
- Fuzzy matching grabbing a nearby but wrong name.
Naive string matching isn't a replacement for local place-name knowledge. Transliteration variation has to be represented explicitly, and matching needs to respect the administrative hierarchy. If two road names look similar but belong to different districts, that similarity isn't enough evidence.
A practical pipeline for messy location data
A solid workflow separates interpretation from verification. The raw address stays as evidence, not as the final location. The pipeline should turn that evidence into a normalized place candidate, attach the best available geometry, and track how confident the system is.
1. Preserve the original input
Don't overwrite the address a developer or broker gives you with a "cleaned" version. Store the raw text, source, date received, and any relevant documents or notes. Normalization rules will change, and you may need to explain later why a record matched in a particular way.
A useful starting data model keeps fields separated:
- Original address or location description.
- Normalized administrative units (province, district, commune).
- Candidate geocoder results and provider details.
- Final point or parcel geometry.
- Geometry source, verification status, and confidence.
That separation matters when something goes wrong. If a property appears in the wrong place, you want to know whether the original input was vague, the alias mapping was off, or the geocoder returned the wrong candidate. A single coordinates column hides all that context.
2. Normalize names with local aliases
Before you send anything to a geocoder, normalize address components using a maintained catalogue of local administrative units and aliases. The catalogue should cover official spellings, common transliterations, acronyms, and known variants.
Match within the hierarchy. Don't compare the full address as one undifferentiated string.
A practical sequence looks like this:
- Normalize case, whitespace, and punctuation without removing meaningful terms.
- Identify any known province, city, or district names and their aliases.
- Use the parent administrative unit to narrow the candidate set.
- Apply fuzzy matching only among plausible candidates.
- Store the matched canonical name plus the rule or alias used.
- Send unresolved or conflicting cases to review instead of forcing a match.
Levenshtein distance and similar similarity measures can help with spelling variants, but they shouldn't be the final decision by themselves. Short names can match many candidates, and what's "close enough" within one district can be wrong at a higher level.
Keep explicit no-match outcomes, and set thresholds that make sense for name length and hierarchy level.
The alias catalogue isn't a one-time cleanup. It's operational data. When reviewers resolve a recurring variant, add it back into the catalogue with a source and review date. That way, you reduce repeat work without pretending every incoming string can be fully automated.
3. Prefer parcel geometry to a guessed point
For a development without a street address yet, parcel geometry is usually more useful than a geocoded point. Planning filings, cadastral records, and developer master plans can contain coordinates for the plot. When you have the rights and the technical setup, store those as spatial geometry (for example in PostGIS).
A polygon holds more than a single point: its extent, shape, and relationship to nearby features. It also supports product features you can't do with a plain latitude/longitude pair - drawing the footprint, checking whether a user-selected point falls inside, or calculating distance to a road or coastline.
Keep points and polygons conceptually distinct. A map marker is often a derived location from a larger geometry. It shouldn't silently replace the parcel boundary or imply survey-level precision. If you need a marker, document how you derive it from the polygon. A simple centroid can fall outside a concave parcel or across multipart shapes.
When you don't have a trustworthy polygon, keep the lower-precision location and mark its status clearly. A district-level result can support broad browsing if your UI communicates uncertainty. The key is to avoid presenting a coarse fallback as an exact property location.
Validation, operations, and trade-offs
A normalized address and a returned geometry are still just candidates. Before you put them into production, test whether they make sense for the property and for the product. These checks catch failures that are easy to miss in spreadsheets and hard to spot on a map when you're viewing data at country scale.
Add rules that reflect the product
Spatial checks should encode real assumptions your users rely on - not generic confidence numbers. If a listing says "beachfront," compare its geometry to a coastline dataset and flag cases beyond a chosen distance. A threshold like 400 metres might work as a starting point in one market, but it's not universal. Coastline data can be incomplete, roads can separate parcels from the water, and marketing terms can be sloppy.
Other checks that tend to pay off:
- Confirm the project falls within its stated city or province boundary.
- Check parcel geometry validity and that it uses the expected coordinate reference system.
- Compare against known roads, coastlines, or administrative boundaries.
- Flag unusually large jumps from a previously approved location to a new update.
- Detect identical or overlapping geometries that could indicate duplicates.
In PostGIS, functions like ST_Within, ST_DWithin, and geometry validation tools can support these checks. The exact query depends on whether you store data as geometry or geography, which coordinate system you're using, and whether your distance threshold is in metres. Make those assumptions explicit in the database rather than relying on values that only "look plausible" in code.
If a check fails, your system should do something clear: accept, flag for review, or reject the ingestion job. Silent fallback is the dangerous path. If a Phnom Penh project lands outside the expected municipal boundary, don't save it as if nothing happened. Preserve the candidate and record which rule failed.
Make uncertainty visible and reviewable
Not every record deserves the same confidence level. A parcel boundary from a reviewed planning document isn't the same thing as a district-level geocoder result. Store that distinction in your data model and reflect it in the user experience so it affects decisions appropriately.
A practical status scheme might include:
- Verified parcel: supported by a reviewed boundary or an authoritative document.
- Verified point: checked against reliable local evidence, but no parcel boundary is available.
- Approximate: resolved to a neighbourhood or administrative area.
- Needs review: conflicting, low-confidence, or failed a validation rule.
Use labels that match what the evidence actually supports. Avoid numeric confidence scores unless you can explain how you calculated and calibrated them. A score like 0.92 can sound scientific while hiding arbitrary weighting.
Manual review isn't a failure of automation. It's a controlled path for ambiguous or high-impact cases. Prioritize review based on business risk: a location used for commute-time estimates, legal eligibility, or a buyer's shortlist deserves more scrutiny than a rough pin in a broad discovery view.
Treat source data as part of the system
Boundaries and addresses change. Developer files get revised, planning applications get amended, and map providers update coverage. Retain the source and version (or date) associated with each geometry, and define how updates are handled.
Also check licensing before using cadastral or planning data in a commercial product. "Available" doesn't automatically mean "redistributable." The same goes for map tiles, geocoder output, and third-party boundary datasets. These constraints affect what you can store, display, and expose through an API.
A reliable pipeline, then, is more than a geocoding call and a database column. It includes the input contract, alias catalogue, geometry sources, validation rules, review queue, and an audit trail. Each piece has maintenance overhead. Start with the checks that prevent the most damaging errors, then expand once real cases show you the next failure mode.
Conclusion
Geocoding is useful, but it isn't a complete location-data strategy. In markets where addresses are inconsistent, transliterated, or not assigned yet, a successful API response can still put a property in the wrong place.
Treat the geocoder as one candidate source, preserve the evidence you started with, normalize names using local knowledge, use parcel polygons when you have them, and validate every result with rules that reflect your product. Start small - one market, a focused set of high-value checks. Measure how often records get flagged, what caused the errors, and which fixes you can reuse. Then improve the alias catalogue and ingestion rules based on what actually happens in your data.
It takes more care than saving the first coordinate you get back, but it prevents building product features on top of precise-looking, unreliable information.
If you're building a location-heavy product, review your pipeline from raw input to map display and look for where uncertainty is being hidden. That's usually where the first improvements pay off.