Geocoding vs Place-Name Matching

Geocoding tries to locate a textual query geographically, whereas place-name matching tries to decide whether two names or records refer to the same place.

Those tasks overlap, but they produce different outputs. If your boundary dataset already contains the geometry you need, geocoding a table of region names into new point coordinates may be the wrong operation. You may only need to resolve identity and join the records.

Geocoding produces a location candidate

A forward geocoder receives text and returns one or more geographic candidates, usually with coordinates and contextual metadata.

That is useful when your input has no geometry, as with customer addresses, facility names, place descriptions or survey locations written as text.

The central question is:

Where is this textual description likely to refer to?

The output can be a point even when the real feature is an area, such as a city or country.

Place-name matching produces an identity decision

Place-name matching starts with records that already refer to geographic entities.

Suppose one table contains:

Côte d'Ivoire
Cote d Ivoire
Ivory Coast

and your geographic layer contains a country with a stable ISO identifier.

The task is to determine whether those names refer to the same entity and map them to the canonical identifier, without generating a new coordinate for the country.

The output is typically a match such as:

input_name -> canonical_id

rather than input_name -> longitude/latitude.

Why the distinction matters

Geocoding can accidentally collapse an entity-resolution problem into a point-placement problem.

If you geocode Cameroon and receive a representative point near the country's centre, that point is not a substitute for the country's polygon or identifier; joining statistics to it would change the geometry model and may lose the relationship to the authoritative boundary version.

Matching the name to a known country identifier keeps the existing geography and simply establishes identity.

Context resolves many ambiguous names

Place names are rarely unique.

Springfield, Victoria, San José and many other names refer to multiple geographic features. A matching process should use contextual fields such as:

country;
parent administrative area;
feature type;
stable code;
language or alternate name;
expected geographic level.

A name-only exact match is often insufficient.

Why Place Names Are Ambiguous explains the underlying causes.

Stable identifiers should take priority when available

If both sources contain a shared authoritative identifier, use it instead of fuzzy name matching.

Identifiers are less affected by spelling, transliteration and language. Although they can still change across versions or administrative reforms, making the namespace and version important, they provide a more explicit join key than display labels.

If one source lacks the identifier, a gazetteer or crosswalk can help map names to canonical codes.

When matching should remain uncertain

Do not force every input to a place.

If Kumba could refer to more than one entity in the available reference data and the source provides no country or administrative context, the correct result may be unresolved.

A useful matching workflow distinguishes:

exact/high-confidence match;
probable match requiring review;
multiple plausible candidates;
no match.

This is better than silently assigning the top search result.

When geocoding is actually appropriate

Use geocoding when the output location itself is missing and required, as in:

converting street addresses to map points;
locating named facilities without existing geometry;
assigning coordinates to descriptive place records;
searching for a locality interactively.

Use place-name matching when the target geography already exists and you need to connect records to it.

Keep the original text

Whether you geocode or match, preserve the source name. Normalisation should add a canonical identifier or matched label rather than erase the evidence that produced the decision.

That allows later review when:

the reference database changes;
a spelling was interpreted incorrectly;
administrative boundaries change;
a new identifier becomes available.

Identity and coordinates are separate decisions

A geographic entity can have many representative coordinates and many names but still be one entity. Conversely, two places can share the same name while being geographically distinct.

The safest workflow is therefore to ask first: do I need to locate a textual record, or do I need to identify which known place it refers to?

That question determines whether you need geocoding or place-name matching.