Coordable (Posts about geocoding)

We built a free tool to benchmark geocoding provider accuracy

François Andrieux — Fri, 24 Apr 2026 10:00:00 GMT

Why we built it

Most teams pick a geocoding provider once and never look back. Usually Google. It is reliable, well-documented, and familiar. But it is also one of the most expensive options, and on some datasets, it is not even the most accurate.

Accuracy varies a lot depending on the country, the address format, and the quality of the input data. A provider that works great for residential addresses might struggle with POI inputs. And it works the other way too: some free, official APIs (like government address registries) outperform paid commercial ones on their home turf. Beyond accuracy, cost and usage rights also differ significantly between providers.

That is why knowing which provider performs best on your data matters. We built a free tool so you can find out in a few minutes, without writing any code and without providing your own API keys.

How the benchmark tool works

You upload a CSV (or Excel file, up to 500 rows), map the columns that form your addresses, and select the providers you want to compare. We run the geocoding on our side; no account, no API keys required from you. The whole thing takes a few minutes. You get a side-by-side accuracy and cost breakdown for each provider, plus a full report by email.

Upload a dataset, map address columns, select providers, and start. No API keys required on your side.

One important detail: we do not count every response as a success. A result is considered valid only if it returns a house number, a street name, and a confidence above 80%. For Google, we also discard GEOMETRIC_CENTER and APPROXIMATE precision types; these place a point somewhere vaguely in an area, which is not useful for industries that need a precise location (logistics, real estate, route planning, insurance).

Accepting every returned coordinate would artificially inflate accuracy scores and hide the silent errors that eventually cause real problems downstream. That's actually a more common problem than you might think: geocoding providers often return false results, and detecting them is not easy. Using confidence scores and other quality rules is the only way to avoid this.

Example 1: 500 US addresses

The first dataset is 500 well-formed US street addresses, the kind of clean, structured input that geocoding providers generally handle best.

Results for 500 US addresses: per-provider accuracy, estimated cost, and Coordable Cascading with +1.4 pts and -97% cost vs a Google-only approach.

Provider	Accuracy	Cost per request
HERE	97.4%	$0.0008
Mapbox	96.8%	$0.0008
US Census	92.2%	Free
Google Geocoding	91.2%	$0.0050
OpenCage	80.6%	$0.0002
Coordable Cascading	98.8%	~$0.0000

Two things stand out. First, HERE outperformed Google by 6 percentage points, while costing 6x less. Second, the US Census (a free, public API that requires no account or key) scored 92.2%, beating Google on this dataset. That is not a fluke: the Census Geocoder is built on TIGER/Line, the official US address dataset, and it handles clean residential addresses very well. We have written more about this in a dedicated comparison.

Running all five providers through Coordable Cascading brought accuracy to 98.8% (494/500 matched) at almost $0 effective cost per request, because US Census resolved the bulk of the file at no charge and the cascade only paid commercial rates for the small fraction it could not handle. That is +1.4 points over the best single provider and -97% cost compared to routing everything through Google.

See geocoding prices in 2026 for a full price comparison.

Example 2: 300 French addresses (mixed POIs and house addresses)

The second dataset is more representative of real-world messiness: 300 French rows mixing residential house addresses with POIs (streets, neighbourhoods, landmarks, business names). No clean housenumber in many rows.

Results for 300 French rows: Google leads single providers on mixed inputs; Coordable Cascading adds +5.6 pts and cuts cost by 93%.

Provider	Accuracy	Cost per request
Google Geocoding	70.7%	$0.0050
HERE	67.3%	$0.0008
Mapbox	62.0%	$0.0008
French BAN	54.3%	Free
OpenCage	31.3%	$0.0002
Coordable Cascading	76.3%	~$0.0004

Google leads here, which makes sense: it handles POIs, business names, and loose address formats better than most providers. The French BAN (the official national address registry, free to use) scores 54.3%, not because it is inaccurate on house addresses, but because it rejects anything that does not look like a structured housenumber + street address. Streets, neighbourhoods, and POI-style rows all come back empty under our strict quality rules. On a dataset of pure French residential addresses, BAN alone typically reaches well above 90%.

The headline numbers stay in the 70% range for this dataset, and that is honest: our quality bar is strict, and mixed input data is genuinely harder. Coordable Cascading reached 76.3% (229/300), +5.6 points over Google, at around $0.0004 per request (a 93% cost reduction). BAN handled the house addresses it could resolve for free; commercial providers covered the rest.

More context on French provider performance: best geocoding providers for France and how we cut French geocoding cost by 67%.

Conclusion

I hope these two examples show how much results can vary from one dataset to another. There is rarely a clear winner among commercial providers, even though some do a genuinely great job. The better strategy is to combine several providers: take advantage of the strengths of each, and prioritize the cheapest ones first. This approach, cascading geocoders, helps reduce the number of incorrect or unmatched geocodings while drastically cutting costs.

What works best truly depends on your country, your address quality, and your specific use case. For example, a clean dataset of US residential addresses is a very different challenge from a mixed French file containing POIs, street-level inputs, neighborhood names, or business names. The right cascade or provider combination for one scenario might not suit the other.

That’s exactly why we built this tool: your results will depend on your actual data and your context. Run it on your own files and see what happens—you may discover that a free public API covers most of your addresses, or that a cheaper commercial provider outperforms the one you're currently paying for. Ultimately, the best strategy is tailored to your country and input quality: experiment, compare, and don’t assume a single provider (or cascade) will be optimal in every situation.

Open the free benchmark tool

Where to go from here

When a bad geocode changes your flood risk classification

Julien Crétin — Sun, 19 Apr 2026 08:00:00 GMT

French home insurers don't price flood risk by intuition. They price it by zone, specifically by the PPRI (Plan de Prévention des Risques d'Inondation), a government-issued flood risk map that classifies every address in France into one of three statuses: Risque Existant (known flood zone), Risque non Connu (municipality at risk, precise address not mapped), or no risk.

The classification feeds directly into the premium. A property in a Risque Existant zone typically carries a 10 to 30% surcharge on the natural disaster component of the home insurance premium, and in high-risk zones, coverage can be refused altogether.

What happens when the geocode is wrong? We tested 300 addresses where two geocoders disagreed; 1 in 7 ended up in a different PPRI classification depending on which one was used.

The mechanics

One common approach: an insurer's system geocodes the address, converting a street address into latitude/longitude coordinates, then queries the PPRI database with those coordinates. The system trusts the coordinates it receives; it has no way to verify whether the geocode is accurate.

If the geocode places the address 1.2 km from its actual location, the PPRI query runs against the wrong point on the map. Whether that matters depends entirely on where the wrong point lands: in a flood zone, out of one, or across a municipal boundary where the PPRI itself changes.

What we measured

We ran 300 French addresses through two geocoders, BAN (Base Adresse Nationale, the French open-source reference) and Google Maps, and queried the Géorisques PPRI API for both coordinate pairs. We selected addresses where the two providers disagreed on location by at least 50 metres.

1 in 7 addresses ended up in a different PPRI classification depending on which geocoder was used.

That's not 1 in 7 addresses overall. It's 1 in 7 among addresses where the geocoders already disagreed.

The right question for a portfolio audit isn't "how many addresses have a bad geocode?"; it's "how many addresses have a geocode divergence large enough to cross a PPRI boundary?"

Three cases

On all maps: orange pin = BAN coordinate, green pin = Google coordinate. Red/blue zones = flood risk areas (PPRI). Source: Géorisques / georisques.gouv.fr · © OpenStreetMap contributors.

Case 1 — Loire-Atlantique (dept. 44): 1.3 km, flood zone missed

An address in the Loire-Atlantique estuary area. BAN placed it at 47.2807°N, 2.4322°W, in a known flood zone (Risque Existant). Google placed it at 47.2691°N, 2.4331°W, 1,294 metres away, outside the mapped zone (Risque non Connu). BAN confidence score: 0.681.

An insurer using Google's coordinates would classify this property as outside the flood zone. No surcharge. Potentially a significant underpricing of risk.

Case 2 — Vendée (dept. 85): 1.1 km, flood zone added

An address on the Vendée coast. BAN placed it at 46.4963°N, 1.8072°W, outside the mapped flood zone (Risque non Connu). Google placed it at 46.4974°N, 1.7925°W, 1,135 metres away, inside a flood zone (Risque Existant). BAN confidence score: 0.702.

Here the error runs in the other direction. An insurer using BAN would miss the flood zone entirely, no surcharge applied to a property that should carry one. A loss exposure that doesn't show up in the underwriting model.

Case 3 — Moselle (dept. 57): three addresses, same divergence pattern

Three addresses on the same street in the Moselle valley showed a consistent 1,850 to 1,900 metre gap between BAN and Google. All three: BAN in a flood zone (Risque Existant), Google outside (Risque non Connu). BAN score: 0.551.

This is the pattern that matters at portfolio scale. A single address with a bad geocode is a one-off. Three addresses with the same systematic divergence, likely sharing a street, a building, or a postal code, suggest a structured data quality problem that will recur across every address in that zone.

What this means for a portfolio audit

The 14.5% reclassification rate we observed applies to addresses with a known geocoding divergence. The prior question, how many addresses in a typical insurance portfolio have a divergence large enough to matter, is the one worth answering first.

Our benchmark on 10,000 French addresses suggests that roughly 3% produce a gap of 500 metres or more between BAN and a premium provider. Applied to a portfolio of 1,000,000 home insurance policies, that's approximately 30,000 addresses worth auditing.

At a 14.5% reclassification rate: roughly 4,350 policies may be incorrectly classified for flood risk. For the subset under-classified as standard risk, the annual premium shortfall runs from €33,000 to €196,000. Beyond the premium impact, these policies carry an unrecognised claims exposure: at a conservative 1% annual flood event probability, roughly 20 under-classified policies will generate a claim in any given year, each potentially running to €20,000 to €80,000 in damages on a contract priced for standard risk.

A geocoding audit doesn't require re-underwriting the entire portfolio. It requires identifying the addresses where the geocode is uncertain enough to cross a risk boundary, and those addresses are identifiable before any claim is filed.

The signal is already in your data: the BAN confidence score. Addresses with a score below 0.7 are the ones most likely to produce a divergence large enough to matter. In our sample, every fine-category reclassification came from an address with a BAN score below 0.71.

Running an audit on your portfolio

One simplified approach for a portfolio audit, noting that in practice, any geocoder can be wrong, and more robust workflows would cross-reference three or more providers:

Run your address file through BAN and flag addresses with a confidence score below 0.7
For flagged addresses, run a secondary geocoder and compute the coordinate gap
For addresses with a gap above ~500 metres, query the PPRI API for both coordinate pairs
Surface the cases where the two coordinates produce different PPRI classifications

Steps 1 to 3 can be automated with a cascading geocoding pipeline. Step 4 is a one-time enrichment.

Coordable builds multi-provider geocoding pipelines that automate exactly this kind of cascade, surfacing address uncertainty before it becomes a classification error. If you're thinking about a portfolio audit, we'd be happy to talk through the approach.

Methodology note

Dataset: 300 French addresses drawn from the ADEME DPE database (10,000-address stratified sample across urban and rural zones), geocoded with BAN and Google Maps. Only addresses where both providers returned valid French metropolitan coordinates were included.

Selection: Addresses split into two groups, fine (50m to 2km gap, 200 addresses) and gross (2km to 50km gap, 100 addresses). Gaps above 50km excluded as geocoding errors.

PPRI API: Géorisques /api/v1/resultats_rapport_risque, queried for both coordinate pairs. 72 of 300 address pairs returned network errors (24%), reducing the effective sample. 3 communes returned HTTP 404 (no PPRI data available).

Reclassification rate: Computed on address pairs where both coordinates returned a valid, non-null PPRI status. "Risque Inconnu" normalised to "Risque non Connu" (API variant).

This post is part of a series on geocoding quality in French operations. For the cost impact on last-mile logistics, see our failed delivery cost models and routing impact benchmark.

Your routing engine is only as good as your coordinates

Julien Crétin — Tue, 14 Apr 2026 14:00:00 GMT

Route optimization gets most of the attention in last-mile logistics. The tooling has become genuinely sophisticated.

The input data has not received the same scrutiny.

A routing engine optimizes the problem it is given. When coordinates are off - resolved to the wrong street, the wrong side of a building, or a town center instead of a specific address - the engine is still mathematically correct. It just optimizes the wrong problem. We ran the numbers on what that costs: up to €18,966/month in avoidable driver time, against €165 in geocoding API calls to avoid it.

The setup

We used the same 10,000 French addresses from our geocoding benchmark (DPE database, stratified by density zone). For each address, we had two sets of coordinates: BAN results and Google results.

Two categories matter here: degraded stops (low BAN score) and risky stops (degraded + gap > 100m). The second is the operational problem. The first is the signal that predicts it.

Degraded addresses: BAN confidence score below 0.7. In our benchmark, 20–40% of these show a coordinate gap above 100 metres - the threshold above which a driver can no longer reliably locate the right building. The lower the score, the higher the proportion of large divergences.

We ran the simulation on 10 routes per zone, using actual stop counts representative of each context. Each route was drawn from a geographically constrained pool - stops selected within a realistic radius around a random centroid, to reflect actual last-mile clustering rather than department-wide dispersion.

Zone	Dept	Radius	Stops per route	Degraded stops (avg)	Risky stops (avg)
1 — Dense urban	92	8 km	25	24.6 (98%)	4.1
2 — Peri-urban	60	15 km	20	10.1 (51%)	2.8
3 — Rural	85	20 km	12	7.0 (58%)	4.8

The model

Route planning uses BAN coordinates throughout - this is the realistic scenario where an operator geocodes addresses once and builds routes on the result.

When a driver arrives at a risky stop, two things happen. First, the coordinates are off by more than 100 metres: the driver spends time searching for the right building or entrance. We model this conservatively at 3 minutes per stop. Second, once the driver locates the actual address, they need to travel from the real position to the next stop in the planned sequence - a sequence that was built around the BAN coordinates, not the real ones.

This second cost is the one that is almost never accounted for. The routing engine planned a direct path from stop A to stop B. In reality, the driver leaves stop A, travels to the actual building, makes the delivery, then drives to stop B - from the wrong starting point. The detour compounds across every risky stop in the route.

Route 9, Stop 3 - Seine-Saint-Denis (93) - BAN score 0.587 - Gap BAN vs Google: 1,542 m - Map: Leaflet · © OpenStreetMap contributors · © CARTO.

We computed this detour using road distances from OpenRouteService Directions API for each risky stop individually. Route planning used OpenRouteService Matrix API.

Results

Before the numbers: the dense urban figure (+19.7 km) is higher than other contexts in our simulations. In dense urban areas, large geocoding errors tend to resolve to a different street or neighborhood entirely - likely failed deliveries rather than recoverable detours. The peri-urban and rural figures are more representative of typical detour costs.

Zone	Risky stops (avg)	Extra distance (median)	Extra time (median)
1 — Dense urban	4.1	+19.7 km	+55.7 min
2 — Peri-urban	2.8	+1.9 km	+10.3 min
3 — Rural	4.8	+3.8 km	+29.1 min

Zone	Cost per route	Google fallback cost	ROI
1 — Dense urban	€15.61	€0.12	126x
2 — Peri-urban	€5.14	€0.08	65x
3 — Rural	€7.94	€0.06	138x

Costs based on €17/h fully loaded driver cost (French CCN Transport 2025). Google fallback cost: €0.005/call applied to degraded stops only.

For every euro spent routing degraded addresses through a quality geocoder as fallback, between €65 and €138 in driver time is avoided. The rural zone shows the highest ROI at 138x - a combination of high degradation rate (58% of stops) and the relative cost of re-routing in areas where roads are less redundant.

A note on the dense urban zone. The urban figures should be read as a combined effect of detours and likely failed deliveries - not detours alone. For the cost of those failures, see our urban and peri-urban models.

The variance problem — and why it matters

Results vary significantly between routes in the same zone. A rural route with 7 risky stops generates +10.9 km of extra distance. Another with 0 risky stops generates nothing. This is not noise - it is the actual distribution.

The implication is that average-based cost estimates understate the tail risk. An operator running 100 routes per day will occasionally have routes that cost €20–25 in extra time due to coordinate errors alone.

Those routes are invisible in the planning system. They show up as driver delay, late deliveries, and overtime - attributed to traffic or difficulty, not to data quality.

Projection — 45,000 deliveries per month

Assuming a typical French last-mile operator with a mix of urban (40%), peri-urban (30%), and rural (20%) deliveries:

Zone	Deliveries/month	Degraded stops	Extra km	Extra time	Cost of degradation	Fallback cost	Net saving
1 — Dense urban	20,000	19,680	15,526 km	44,064 min	€12,485	€98	€12,386
2 — Peri-urban	15,000	7,575	2,669 km	13,598 min	€3,853	€38	€3,815
3 — Rural	10,000	5,833	2,013 km	9,275 min	€2,628	€29	€2,599
Total	45,000	33,088	20,208 km	66,937 min	€18,966	€165	€18,800

For routing detours alone (peri-urban + rural): €6,481/month against €67 in fallback costs - a 97:1 ratio.

The urban figure (€12,485) includes large geocoding errors that likely result in failed deliveries rather than recoverable detours - bringing the total to €18,966. For the cost of those failures, see our urban and peri-urban cost models.

At scale, address quality is not a data engineering concern. It is a P&L line.

What the routing engine cannot fix

A routing engine optimizes the problem it is given. If the input coordinates are degraded, the optimization is degraded - and the optimizer has no way to know.

No amount of algorithmic sophistication changes this. A state-of-the-art solver running on wrong coordinates produces a worse result than a simple nearest-neighbor heuristic running on correct ones. The quality of the output is bounded by the quality of the input.

In French last-mile logistics, degraded geocoding costs approximately €0.60 per degraded stop in extra driver time, against a fallback cost of €0.005. The ratio holds across all three geographic contexts tested.

The fix is not a better routing engine. It is better coordinates going in.

Limitations

3-minute search penalty is a floor, not an average. The 3-minute search penalty per risky stop is deliberately conservative - the actual cost is likely higher in areas where buildings are not clearly numbered or GPS signal is unreliable.

Simulated routes, not observed ones. Routes were generated by OR-Tools on real addresses, not drawn from actual carrier data. Real routes may have different stop density, time window constraints, and geographic clustering.

Deviations modeled in isolation. In practice, a driver who arrives at the wrong location may also affect the next 2–3 stops through cascade delays - the same dynamic documented in our failed delivery cost models. We modeled only the direct detour cost, not the downstream schedule disruption.

Google as the reference. We use Google coordinates as the reference position for risky stops. Google can also be wrong - as documented in our benchmark, 0.76% of Google results were located outside France entirely. The model assumes Google is correct where BAN is degraded, which is an approximation.

Deep rural zone excluded. The deep rural zone showed insufficient risky stops per route to generate a reliable signal. The projection covers 45,000 of the assumed 50,000 monthly deliveries.

Want to fix the input, not the algorithm?

If you're working on route optimization and want to understand where coordinate quality is limiting your results, we'd be happy to talk through your setup.

Coordable builds multi-provider geocoding pipelines that automatically route degraded addresses through a quality fallback - so your routing engine gets the right coordinates from the start. Get in touch to run the numbers on your own operation.

Methodology

Dataset: 10,000 French addresses from the ADEME DPE database (existing residential buildings, post-July 2021). Stratified sample across four INSEE density zones. Zones tested: Dept 92 (dense urban), Dept 60 (peri-urban), Dept 85 (rural).

Geographic constraint: Each route drawn from addresses within a fixed radius of a randomly selected centroid - 8 km (urban), 15 km (peri-urban), 20 km (rural). Routes with geographic span exceeding 2× the radius were discarded.

Route simulation: OR-Tools (Google) with PATH_CHEAPEST_ARC + GUIDED_LOCAL_SEARCH, 10-second time limit per route. Route planning distances from OpenRouteService Matrix API (driving-car profile). Depot set to centroid of each route's stops.

Degraded stops: BAN confidence score < 0.7. Validated as predictive of significant coordinate divergence in benchmark analysis.

Risky stops: Degraded stops where BAN↔Google Haversine distance ≥ 100m.

Deviation cost: For each risky stop, extra distance = road_distance(BAN → Google) + road_distance(Google → next_BAN) − road_distance(BAN → next_BAN). Road distances from OpenRouteService Directions API. Fallback to Haversine × 1.3 when ORS unavailable. Time cost = extra travel time + 3 min on-site search per risky stop.

Driver cost: €17/h fully loaded (French CCN Transport routier, 2025, including employer social charges at ~30%).

Google fallback cost: €0.005/call (Google Geocoding API standard pricing), applied only to degraded stops.

Projection figures: Based on medians. Extrapolated linearly from simulated routes.

Note on geocoding cost estimates

Geocoding pipeline cost - Estimated using BAN (free, open source) as primary geocoder, with a premium provider (Google Geocoding API, ~€0.005/address) triggered only on addresses where BAN confidence score falls below 0.7 - roughly 15-20% of a typical French address file. This cascading approach is the architecture Coordable is built around: coordable.co.

String Distance Metrics for Address Comparison: Levenshtein, Damerau, Jaro, and Jaro-Winkler

François Andrieux — Wed, 01 Apr 2026 10:00:00 GMT

Comparing addresses is not a simple equality check

When you compare two address strings to decide if they refer to the same location, an exact match is rarely enough. Real-world addresses come with typos, abbreviations, inconsistent casing, and missing components. "15 Baker St" and "15 Baker Street" are the same address, but "15 Baker St" == "15 Baker Street" evaluates to False.

String distance metrics can be used to solve this problem. They assign a number to two strings that quantifies how different (or similar) they are. This number lets you set a threshold: "if the distance is less than 2, or the similarity is above 0.9, treat them as the same address."

In this guide, we cover the four most widely used metrics for address comparison:

Levenshtein distance - the classic edit distance
Damerau-Levenshtein distance - edit distance with transpositions
Jaro similarity - character matching with position awareness
Jaro-Winkler similarity - Jaro with a bonus for matching prefixes

For each one, we explain how it works, walk through a concrete address example, and discuss when it is (and is not) a good fit. At the end, a summary table and practical recommendations.

Table of contents:

A quick note before diving in

There are two flavors of metric:

Distance metrics (Levenshtein, Damerau-Levenshtein): return 0 for identical strings, and a higher integer for more different strings. Think of them as counting "how many operations to fix this?"
Similarity metrics (Jaro, Jaro-Winkler): return 1.0 for identical strings, and a lower value (down to 0.0) for more different strings. Think of them as "what fraction of characters match?"

Neither type is universally better. Which one to use depends on your data and your use case.

1. Levenshtein distance

How it works

The Levenshtein distance between two strings is the minimum number of single-character edits needed to transform one into the other. The allowed operations are:

Insertion: add a character (e.g., "Streeet" - one character - to "Street")
Deletion: remove a character (e.g., "Streeet" + one deletion - to "Street")
Substitution: replace one character with another (e.g., "Straat" - replace 'a' with 'e' - to "Street")

A distance of 0 means the strings are identical. A distance of 1 means a single operation is enough.

Address example

Compare "15 baker srteet" (a common keyboard transposition typo) to "15 baker street":

15 baker srteet
15 baker street

To fix "srteet" into "street", Levenshtein needs 2 substitutions: replace 'r' with 't' at position 9, and 't' with 'r' at position 10.

Distance = 2.

This is technically correct, but it feels like a lot for what is clearly a single typing mistake. We will fix this in the next section.

In Python

import jellyfish

jellyfish.levenshtein_distance("15 baker srteet", "15 baker street")
# → 2

Install with pip install jellyfish.

Pros and cons

Pros	Cons
Simple and well understood	Counts a transposition (swap of two adjacent chars) as 2 operations instead of 1
Handles insertions and deletions well (great for abbreviations like "St" vs "Street")	Raw distance is hard to compare across string pairs of different lengths
Available in virtually every language and library	Does not give extra weight to matching prefixes
Fast on short strings

When to use it for addresses

Levenshtein is a solid default, especially when the main source of variation is abbreviations or missing characters. Set a relative threshold to make comparisons fair across different string lengths:

def normalized_levenshtein(a, b):
    dist = jellyfish.levenshtein_distance(a, b)
    return dist / max(len(a), len(b))

# Treat as same address if < 15% different
normalized_levenshtein("15 baker street", "15 baker st") # → 0.267
normalized_levenshtein("15 baker street", "15 baker sreet") # → 0.067

2. Damerau-Levenshtein distance

How it works

Damerau-Levenshtein extends Levenshtein by adding one more operation:

Transposition: swap two adjacent characters (e.g., "srteet" to "street" - swap 'r' and 't')

This single addition makes a big practical difference. Studies of typing errors show that transpositions (adjacent character swaps) are one of the most frequent mistakes people make when typing by hand. Recognizing them as a single error rather than two substitutions gives a much more realistic picture of "how many mistakes did the user make?"

Address example

Same pair as before: "15 baker srteet" vs "15 baker street".

15 baker srteet
15 baker street
         ^^     ← 'rt' transposed to 'tr'

Damerau-Levenshtein distance = 1 (one transposition).

Compare this to the Levenshtein distance of 2 for the same pair. One error, one operation - much more intuitive.

Another example: "rue de al paix" vs "rue de la paix" (the words "al" and "la" are swapped - a common cut-and-paste error):

rue de al paix
rue de la paix
       ^^       ← 'a' and 'l' transposed

Levenshtein = 2, Damerau-Levenshtein = 1.

In Python

import jellyfish

jellyfish.damerau_levenshtein_distance("15 baker srteet", "15 baker street")
# → 1

jellyfish.damerau_levenshtein_distance("rue de al paix", "rue de la paix")
# → 1

Pros and cons

Pros	Cons
More realistic for human typing errors	Slightly more complex to implement from scratch
Transpositions (very frequent mistakes) cost 1, not 2	Same issue with raw distance across different string lengths
Strict superset of Levenshtein - always <= Levenshtein distance

When to use it for addresses

Prefer Damerau-Levenshtein over plain Levenshtein whenever your input comes from users typing addresses manually (web forms, search boxes, mobile apps). It gives a better answer to the question "how careless was this input?" and lets you set tighter thresholds while still tolerating common slip-of-the-finger errors.

3. Jaro similarity

How it works

Jaro takes a completely different approach. Instead of counting edit operations, it measures the proportion of characters that match between two strings, with a penalty for characters that are far apart or out of order.

Two characters are considered matching if: 1. They are the same character, and 2. Their positions are not too far apart. The maximum allowed distance between two matching characters is: floor(max(len(s1), len(s2)) / 2) - 1

Once you count the matching characters m and the number of matching characters that are out of order t (transpositions), the Jaro similarity is:

Jaro(s1, s2) = (1/3) * (m / |s1| + m / |s2| + (m - t) / m)

The result is between 0.0 (nothing matches) and 1.0 (identical).

Address example

Compare "church rd" (abbreviated) to "church road" (full form):

s1 = "church rd" (9 characters), s2 = "church road" (11 characters)
Matching window = floor(11 / 2) - 1 = 4

Every character in "church rd" can be matched to a character in "church road" within the window: c, h, u, r, c, h, (space), r, d all appear in the same relative order. So m = 9, t = 0.

Jaro = (1/3) * (9/9 + 9/11 + 9/9)
     = (1/3) * (1.000 + 0.818 + 1.000)
     ≈ 0.939

A similarity of 0.939 for what is clearly the same street, just abbreviated. That is the right answer.

In Python

import jellyfish

jellyfish.jaro_similarity("church rd", "church road")
# → ~0.939

jellyfish.jaro_similarity("main street", "mane street")  # typo: i→e
# → ~0.970

Pros and cons

Pros	Cons
Normalized score between 0 and 1 - easy to threshold	Formula is less intuitive than edit distance
Handles abbreviations and length differences naturally	Can give surprisingly high scores to long strings with many common characters
Well suited for comparing individual address components	Does not give extra weight to matching prefixes - we fix this with Jaro-Winkler

When to use it for addresses

Jaro is a good fit for comparing individual address fields (just the street name, just the city) rather than full concatenated address strings. It is also useful for detecting near-duplicate records in a database.

4. Jaro-Winkler similarity

How it works

Jaro-Winkler builds on Jaro by adding a prefix bonus: if two strings share the same first characters, their similarity is boosted. The motivation is that strings that start the same way are more likely to refer to the same thing than strings that diverge immediately.

The formula is:

JaroWinkler(s1, s2) = Jaro(s1, s2) + l * p * (1 - Jaro(s1, s2))

Where: - l = length of the common prefix, up to a maximum of 4 characters - p = scaling factor, conventionally 0.1

The effect is a modest upward adjustment when the prefix matches. With p = 0.1 and l = 4, the maximum bonus is +4 * 0.1 * (1 - Jaro), which boosts a Jaro of 0.90 by at most 0.04. Small but meaningful for ranking candidates.

Address example

Take "church rd" vs "church road" again (Jaro = 0.939, common prefix "chur", l = 4):

JaroWinkler = 0.939 + 4 * 0.1 * (1 - 0.939)
            = 0.939 + 0.4 * 0.061
            ≈ 0.963

Now consider two streets that differ at the very beginning:

"avenue du general leclerc" vs "boulevard du general leclerc"

These share no prefix at all (l = 0), so Jaro-Winkler equals Jaro exactly. No bonus is applied, and the score is lower than it would be for two strings with the same beginning. This is exactly the intended behavior: a difference at the start is a stronger signal of a mismatch than a difference in the middle.

Now consider a house number mismatch:

"12 rue de la paix" vs "21 rue de la paix": the prefix is "1" vs "2", so l = 0. The score penalizes the mismatch at the start, which is what we want - these are two completely different addresses.

In Python

import jellyfish

jellyfish.jaro_winkler_similarity("church rd", "church road")
# → ~0.963

jellyfish.jaro_winkler_similarity("12 rue de la paix", "21 rue de la paix")
# → ~0.980  (lower score due to no prefix match)

jellyfish.jaro_winkler_similarity("12 rue de la paix", "12 rue de la pai")
# → ~0.988  (strong prefix, only one char missing at end)

Pros and cons

Pros	Cons
Prefix bonus aligns with how we read addresses (number first, then street name)	Prefix bonus requires consistent formatting - mixed case will kill the bonus
Often more accurate than plain Jaro for addresses and proper names	`p = 0.1` is conventional; tuning it for your data takes experimentation
Normalized 0-1 score, easy to threshold	Like Jaro, harder to explain to non-technical stakeholders than edit distance

When to use it for addresses

Jaro-Winkler is the best general-purpose choice for full address comparison when strings are properly normalized (lowercase, consistent formatting). The prefix bonus is particularly useful when the house number is at the start of the string - it correctly penalizes address strings that start with different numbers, since those represent different physical locations regardless of the rest.

Summary table

Metric	Type	Score range	Transpositions	Prefix bonus	Best for
Levenshtein	Distance	0 to +inf	Costs 2	No	Abbreviations, insertions, deletions
Damerau-Levenshtein	Distance	0 to +inf	Costs 1	No	User-typed input, keyboard typos
Jaro	Similarity	0 to 1	Handled	No	Individual address fields
Jaro-Winkler	Similarity	0 to 1	Handled	Yes (up to 4 chars)	Full normalized address strings

Quick decision guide:

User types addresses into a form - use Damerau-Levenshtein. Transpositions are very common in manual input.
You are deduplicating a database of street names - use Jaro or Jaro-Winkler on the street name component alone.
You want a single score for a full address string - use Jaro-Winkler on normalized strings.
Your main problem is abbreviations ("Blvd" vs "Boulevard") - normalize abbreviations first (see below), then any metric will do.

Normalization: the step that matters more than metric choice

No string metric can compensate for what normalization ignores. Before comparing two addresses, apply at least these basics:

Lowercase everything: "Baker Street" and "baker street" should score 1.0, not 0.9.
Expand abbreviations consistently: "St" -> "street", "Blvd" -> "boulevard", "Ave" -> "avenue", "Rd" -> "road". Or shorten everything to a consistent short form.
Remove punctuation: "St. James's" and "St Jamess" will score very differently if you keep periods and apostrophes.
Normalize whitespace: collapse multiple spaces, strip leading/trailing whitespace.

With these steps, "15 Baker St." and "15 Baker Street" become "15 baker street" and "15 baker street" - identical strings that score perfectly on any metric.

import re

def normalize_address(addr):
    addr = addr.lower()
    addr = re.sub(r"[.,'\-]", "", addr)
    addr = re.sub(r"\bst\b", "street", addr)
    addr = re.sub(r"\bblvd\b", "boulevard", addr)
    addr = re.sub(r"\bave\b", "avenue", addr)
    addr = re.sub(r"\brd\b", "road", addr)
    addr = re.sub(r"\s+", " ", addr).strip()
    return addr

normalize_address("15 Baker St.")   # "15 baker street"
normalize_address("15 Baker Street")  # "15 baker street"

After normalization, both strings are identical and any metric returns a perfect score.

Putting it all together: a complete address comparison

Here is a short example that combines normalization with all four metrics:

import jellyfish
import re

def normalize_address(addr):
    addr = addr.lower()
    addr = re.sub(r"[.,'\-]", "", addr)
    addr = re.sub(r"\bst\b", "street", addr)
    addr = re.sub(r"\bblvd\b", "boulevard", addr)
    addr = re.sub(r"\bave\b", "avenue", addr)
    addr = re.sub(r"\brd\b", "road", addr)
    addr = re.sub(r"\s+", " ", addr).strip()
    return addr

pairs = [
    ("15 Baker St.", "15 Baker Street"),
    ("15 Baker Srteet", "15 Baker Street"),
    ("12 Rue de la Paix", "21 Rue de la Paix"),
    ("Church Rd", "Church Road"),
]

for a, b in pairs:
    na, nb = normalize_address(a), normalize_address(b)
    lev = jellyfish.levenshtein_distance(na, nb)
    dlev = jellyfish.damerau_levenshtein_distance(na, nb)
    jaro = jellyfish.jaro_similarity(na, nb)
    jw = jellyfish.jaro_winkler_similarity(na, nb)
    print(f"{a!r} vs {b!r}")
    print(f"  Levenshtein: {lev}, Damerau-Levenshtein: {dlev}")
    print(f"  Jaro: {jaro:.3f}, Jaro-Winkler: {jw:.3f}")

Expected output:

'15 Baker St.' vs '15 Baker Street'
* Levenshtein: 0, Damerau-Levenshtein: 0  # normalization made them identical
* Jaro: 1.000, Jaro-Winkler: 1.000

'15 Baker Srteet' vs '15 Baker Street'
* Levenshtein: 2, Damerau-Levenshtein: 1  # one transposition, not two substitutions
* Jaro: 0.978, Jaro-Winkler: 0.987

'12 Rue de la Paix' vs '21 Rue de la Paix'
* Levenshtein: 2, Damerau-Levenshtein: 1  # different house number
* Jaro: 0.980, Jaro-Winkler: 0.980        # no prefix bonus (1 != 2)

'Church Rd' vs 'Church Road'
* Levenshtein: 0, Damerau-Levenshtein: 0  # normalization expanded Rd -> Road
* Jaro: 1.000, Jaro-Winkler: 1.000

Note how the normalization step handles "St" vs "Street" and "Rd" vs "Road" completely, leaving the metrics to handle what normalization cannot catch (typos, transpositions, genuine differences).

Where to go from here

String similarity metrics are one tool in the address quality toolbox. In geocoding workflows, they are commonly used to:

Verify that a geocoded result actually matches the input address (compare the returned address label to the input).
Deduplicate address lists before batching geocoding requests.
Build fuzzy search over a local address database before calling a paid API.

If you are working on address data quality as part of a geocoding pipeline, these resources may also be useful:

Learn how to geocode large batches cost-effectively: How to reduce geocoding costs by 67%
See what geocoding providers are available and how their prices compare: Geocoding prices in 2026
Find the best geocoding provider for your country: Best geocoding providers for France, UK, Germany

Try address geocoding with Coordable

US Census + Google Maps: How to cut geocoding costs by 90% for US addresses

François Andrieux — Sat, 21 Mar 2026 10:00:00 GMT

The setup

We wanted to test the effectiveness of a cascading geocoding strategy for US addresses. We took 1,000 real US addresses (a mix of residential and business addresses, of variable quality but overall correct) and ran three geocoding tests.

Here is the summary of the results:

Test	Provider(s)	Addresses resolved	Cost per 1,000
1	US Census only	91.9%	$0.00
2	Google Maps only	92.6%	$5.00
3	US Census → Google Maps (cascade)	97.3%	$0.41

The cascade delivers 97.3% addresses found at $0.41, compared to $5.00 for Google Maps alone. That is a 90% cost reduction with a +5.4 percentage point improvement in addresses resolved. Amazing right?

Read on to see how each test was run and what the results look like.

Table of contents:

Test 1: US Census Geocoder

What is the US Census Geocoder?

The US Census Geocoder is a public and free API provided by the US federal government. It is not open source (the underlying software and data are maintained by the Census Bureau), but it is freely accessible, requires no API key, and has no published usage limits or cost.

It is built on TIGER/Line data, the official US address dataset. Results are interpolated on the street rather than placed at the exact building location (no rooftop precision). For most use cases (delivery routing, territory analysis, customer mapping), street-level interpolation is entirely sufficient.

The output data is in the public domain, with no licensing restrictions on how you store or use the coordinates.

Important limitation: US Census only understands structured street addresses. It cannot geocode points of interest, business names, or company names. If your dataset contains entries like "Starbucks, Chicago" or "Boeing headquarters", US Census will return nothing for those rows. In that case, the 90% cost reduction figure will not hold: a commercial provider will need to handle a much larger share of your requests. This strategy works best for datasets of clean street addresses ; see below for a solution.

Results

Accuracy: 91.9% (919 out of 1,000 addresses resolved)
Cost: $0.00

Test 1, US Census only: 919/1,000 addresses resolved, at no cost.

91.9% is a strong result for a free API. The 8.1% of unresolved addresses are typically due to non-standard formatting, missing components, or addresses that simply do not appear in the TIGER/Line dataset.

Test 2: Google Maps Geocoding API

What is Google Maps Geocoding?

Google Maps is one of the most widely used geocoding providers. At $5.00 per 1,000 addresses (after the free quota), it is also one of the most expensive.

It returns different precision levels: ROOFTOP for exact building locations, and RANGE_INTERPOLATED for street-level interpolation. For a fair comparison with US Census, which only returns street-level results, we accept both ROOFTOP and RANGE_INTERPOLATED in this test.

Licensing note: Google Maps results come with significant restrictions beyond the price. Google's Terms of Service do not allow you to store geocoded coordinates long-term or use them outside of a Google Maps display context. If you need to build a database of geocoded addresses, use the results in a non-Google mapping tool, or export coordinates for analysis, you may be violating Google's terms. This is an important constraint to factor in before committing to Google as your primary geocoding provider.

Note: Google free quota is excluded from these cost figures, as its effective value depends on overall usage across all Google Maps products. The $5.00 figure reflects the standard pay-as-you-go rate.

Results

Accuracy: 92.6% (926 out of 1,000 addresses resolved)
Cost: $5.00

Test 2, Google Maps only: 926/1,000 addresses resolved at ROOFTOP or RANGE_INTERPOLATED level, at $5.00 per 1,000.

Google Maps edges out US Census by 0.7 percentage points (92.6% vs 91.9%), but at a cost of $5.00 per 1,000 addresses vs $0. For this dataset, paying for Google Maps buys very little extra accuracy on its own.

Test 3: US Census + Google Maps (cascade)

How the cascade works

The cascading strategy is straightforward:

Send every address to US Census first. If US Census returns a valid result, use it. Cost: $0.
For addresses that US Census could not resolve, send them to Google Maps. Cost: $5.00 per 1,000 for this subset only.

In our test, approximately 90% of addresses were resolved by US Census (free), and only ~8% required Google Maps, at a total cost of $0.41. The remaining ~2.7% were not resolved by either provider.

This is why the cost drops so dramatically: instead of paying $5.00 for every address, you only pay Google's rate for the small fraction that US Census could not handle.

The two-provider cascade configured in Coordable: US Census first, then Google Maps for unresolved addresses, accepting both ROOFTOP and RANGE_INTERPOLATED results.

Results

Accuracy: 97.3% (973 out of 1,000 addresses resolved)
Cost: $0.41
Provider split: ~90% resolved by US Census · ~8% resolved by Google Maps · ~2.7% unresolved

Test 3, US Census → Google Maps cascade: 973/1,000 addresses resolved, at $0.41 per 1,000.

The cascade delivers a +5.4 percentage point improvement over either provider alone, at 8% of the cost of Google Maps. The key insight is that US Census and Google Maps fail on different addresses. Addresses that US Census cannot parse or match are often resolved by Google's more robust parsing engine, and vice versa.

Set up cascading geocoding with Coordable

Going further: adding a third provider

This two-provider cascade already delivers strong results, but you can push accuracy even higher by adding a third provider.

For example, adding HERE as a second fallback (after Google Maps) would catch some of the 2.7% of addresses that neither US Census nor Google resolved. HERE has strong US address coverage and is significantly cheaper than Google Maps at $0.83 per 1,000 addresses. A three-provider cascade (US Census → Google Maps → HERE) would likely push accuracy above 97.3% while keeping the overall cost low, since HERE would only handle the tiny fraction of addresses that both previous providers missed.

We ran a similar experiment with French addresses using the BAN API (the French government geocoder), Google Maps, and HERE, and achieved 97.7% accuracy at $1.62 per 1,000, a 67% cost reduction compared to Google alone. The principle is identical: route easy addresses through the cheapest provider, and reserve expensive providers for the hard cases. See How to reduce geocoding costs by 67% for the full breakdown.

Conclusion

For US address geocoding, the US Census Geocoder is a powerful and underused tool. It is free, requires no API key, and handles the vast majority of clean street addresses correctly. Pairing it with Google Maps as a fallback gives you the best of both worlds: near-complete coverage at a fraction of the cost.

Test	Provider(s)	Found	Cost per 1,000
1	US Census only	91.9%	$0.00
2	Google Maps only	92.6%	$5.00
3	US Census → Google Maps (cascade)	97.3%	$0.41

The key caveat: this strategy works for street address datasets. If your data contains business names, POIs, or unstructured inputs, US Census will not help and you will need a commercial provider for a larger share of requests.

However, it would have been possible to plug a low-cost provider to handle the remaining addresses as well : HERE, Nominatim (OSM), OpenCage, etc.

If you want to implement this cascade without writing custom code, Coordable lets you configure multi-provider workflows with quality rules at each step, so only good results pass through.

Try cascading geocoding with Coordable

Where to go from here

See how the same cascading approach cuts costs by 67% for French addresses: How to reduce geocoding costs by 67%
Compare geocoding prices across all major providers: Geocoding prices in 2026
Learn more about Google Maps Geocoding: Google Maps Geocoding API

How to reduce geocoding costs by 67%

François Andrieux — Sun, 08 Mar 2026 10:00:00 GMT

The use case: a logistics company paying way too much for geocoding

If you work in logistics, insurance, or routing software, you know the drill: geocoding volumes are massive, and the bills that come with them are too.

In this article, we show how Coordable helped a logistics company cut geocoding costs by 67% while also increasing its share of valid geocoding results from 94% to 97.7%. Total savings: $20,280 per year. 🤩

Let's dive in.

Table of contents:

The problem: choosing between cost and quality

You have probably faced this tradeoff: premium providers like Google Maps deliver excellent results, but they come at a price. Cheaper alternatives may leave some addresses unresolved.

Most of the time, though, you do not actually need the premium option; addresses are clean and unambiguous, so any decent geocoder will do the job. The real challenge appears when your address data is messy: in those cases, you are forced to choose between paying for Google Maps to guarantee correct results, or accepting that a cheaper provider will miss some.

The solution: cascading providers

Good news: there is a strategy that gives you the best of both worlds, cascading geocoders. The principle is straightforward:

Use an open-source or low-cost provider for ~90% of geocoding requests (the clean, unambiguous addresses).
Use a premium geocoder (or several) to resolve the remaining ~10%.

This approach raises geocoding success rates while keeping costs down. In our case, it reduced costs by 67% and increased the share of successfully geocoded addresses by +3.7%. Here is how we did it.

The workflow: 3 providers

Our logistics client needed to geocode mostly residential addresses in France. France has an excellent government API for this purpose, the Base Adresse Nationale (BAN), which covers French residential addresses very well, though it does not handle points of interest or addresses outside France. Many commercial providers actually use BAN data to improve their own results.

The downside of BAN's API is that it is less robust at parsing and matching poorly formatted input. So we still needed to pair it with at least one commercial provider to ensure no addresses slip through. For that, we chose Google Maps. Finally, we added HERE as a second fallback because HERE also leverages BAN data, making it a strong option for the French addresses that Google could not resolve to rooftop level.

Here is our strategy:

French BAN: confidence score > 0.75 required.
Google Maps API: ROOFTOP location type required (if not resolved in step 1).
HERE: confidence score > 0.75 required (if not resolved in step 2).

The three-provider cascade configured in Coordable: BAN → Google Maps → HERE, each step gated by a quality rule.

We apply quality rules at each step to discard results that are not good enough. For French BAN and HERE, the confidence score reflects how closely the geocoder matched the input string. Although computed slightly differently across providers, both scores are a reliable way to filter out poor results. Setting the threshold at 0.75 is fairly strict, but the cascade makes this safe; any address rejected at one step simply moves to the next provider.

Google Maps does not provide a confidence score, so instead we filter on the location type returned (ROOFTOP, APPROXIMATE, GEOMETRIC_CENTER). For residential addresses, we require ROOFTOP only, to ensure the coordinates are placed in front of the building rather than somewhere in the middle of the street.

The results

To measure the impact, we ran two geocoding sessions on the same dataset and compared them:

Google Maps only: the client's initial setup.
Cascading strategy: BAN → Google Maps → HERE.

The test dataset contains 1,000 residential addresses, mostly clean and well-formed. That is large enough to get a reliable picture of how this strategy performs at scale.

In practice, the client geocodes about 500,000 addresses per month.

Session 1: Google Maps only

Session 1, Google Maps only: 940/1,000 addresses resolved at ROOFTOP level, at $5 per 1,000.

Results:

94% valid geocoding results (addresses resolved to ROOFTOP).
Estimated cost: $5.00 per 1,000 addresses.

Note: these costs ignore the Google free quota, which is shared across all Google Maps products. Its effective value depends on each client's overall usage, so we exclude it for a fair comparison.

Session 2: BAN + Google Maps + HERE (cascading)

Session 2, Cascading strategy: 977/1,000 addresses resolved, at $1.62 per 1,000.

Results:

97.7% valid geocoding results, a +3.7% improvement.
Estimated cost: $1.62 per 1,000 addresses.

Provider breakdown: BAN 64.5% · Google Maps 31.7% · HERE 3.8%

Using BAN means that 64.5% of addresses cost nothing to geocode. Our strict rules then sent 31.7% of addresses to Google Maps, and HERE handled the remaining 3.8%.

Total cost reduction: 67%, while improving geocoding quality.

Yearly cost savings

At 500,000 addresses per month, the client was spending about $2,500/month on Google Maps alone. With the cascading strategy, that bill drops to $810/month, without any loss of quality; on the contrary.

	Monthly cost	Annual cost
Google Maps only	$2,500	$30,000
Cascading (BAN + Google + HERE)	$810	$9,720
Savings	$1,690	$20,280

That is $20,280 saved per year, while resolving +3.7% more addresses correctly.

Conclusion

If you are paying Google Maps rates for every address, you are likely overpaying. This real-world example shows how large the gap can be: by routing the bulk of clean French addresses through the free BAN API, reserving Google Maps for harder cases, and using HERE as a final safety net, the client went from 94% to 97.7% geocoding success while paying 67% less.

The key is combining the right providers in the right order, and enforcing quality rules at each step so only genuinely good results pass through. The result is a system that is both cheaper and more reliable than relying on a single provider.

Set up cascading geocoding with Coordable

Where to go from here

Learn more about the providers used in this workflow: Google Maps Geocoding API, HERE Geocoding API.
See how providers compare in France: Best geocoding providers for France.
Compare Google and HERE head-to-head: Google vs HERE for geocoding.
See current geocoding prices at a glance: Geocoding prices in 2026.

HERE price increase by 6% in 2026

François Andrieux — Fri, 06 Mar 2026 12:00:00 GMT

HERE Technologies is updating its pricing from April 2026. This post summarizes what matters for geocoding users: effective date, what changes, and who is affected.

Table of contents:

What HERE announced

From April 1, 2026, the price of the HERE Base Plan will increase by 6% for new contracts, renewals, and extensions. Existing contracts remain unchanged until renewal or extension.

HERE Technologies communicated the following:

The prices of all 35 HERE Location Services and Data IO using the pay-per-transaction model will increase by 6%.
This price increase applies to all new subscriptions and (auto-)renewals from April 1, 2026 onwards.
The price of the Developer technical support plan remains unchanged.
These pricing updates will be reflected in all future contracts and invoices from April 1, 2026 onwards.

What this means for you

If you sign a new contract or renew on or after April 1, 2026, you will see the new 6% pricing. For coverage, rate limits, licensing, and current pricing details, see our HERE Geocoding API guide.

Where to go from here

HERE Geocoding API — coverage, rate limits, and licensing.
Geocoding prices in 2026 — compare HERE with other providers.
Google vs HERE for geocoding — head-to-head comparison.

Geocoding prices in 2026

François Andrieux — Fri, 06 Mar 2026 10:00:00 GMT

Here’s a clear overview of what the main geocoding services cost in 2026, and whether anything changed recently. Use the table and the interactive chart below to compare prices at a glance and to simulate your costs. 🙂

Table of contents:

Pricing overview

Roughly what you pay after the free tier (per 1,000 requests, in USD). Free tiers and volume discounts vary; check each provider for exact terms.

Provider	Free tier	Price per 1,000 (after free)	Note
Google Maps	10,000/month	$5.00	Volume discounts; see March 2025 changes below.
HERE	30,000/month	$0.83	Volume discounts; 6% increase from April 2026 for new contracts and renewals.
TomTom	2,500/day (~75k/month)	$0.75	Volume discounts.
Mapbox (Temporary)	100,000/month	$0.75	Temporary results only; no long-term storage.
Mapbox (Permanent)	—	$5.00	Allows indefinite storage of results.
OpenCage	2,500/day (~75k/month)	from ~$0.15–0.17	Subscription-based; volume discounts. Permissive storage.
Nominatim (OSM)	Public API rate-limited	Free	Self-hosting has infra costs.

Many countries also have free or low-cost official APIs (e.g. France's BAN, Spain's CartoCiudad, UK's OS Places under certain schemes). For local addresses, check our country-specific comparisons linked at the end.

Compare costs at your volume

The difficulty is that most providers have different pricing tiers and different free tiers. So you need to know exactly how many addresses you need to geocode to know which provider is the cheapest. Also, prices typically decrease as volume increases, so your per-request cost depends heavily on your total usage.

You can simulate your costs with the interactive chart below. Just select the number of addresses you need to geocode and the chart will show you the cost per provider!

Did prices change?

Google (March 2025): Google replaced the previous $200/month credit with per-SKU free usage (e.g. around 10,000 free billable events per month for the Geocoding API). Volume discount tiers were expanded for high usage. So the effective free tier for geocoding is lower than before, but heavy users can see lower marginal costs at scale. Details: Google Maps Geocoding API guide and Google Maps Platform March 2025 changes.

HERE (April 2026): From April 1, 2026, the HERE Base Plan and all pay-per-transaction Location Services and Data IO increase by 6% for new contracts, renewals, and extensions. Existing contracts are unchanged until renewal. See HERE price increase by 6% in 2026 for details.

Other major providers: TomTom, Mapbox, and OpenCage have kept their published pricing stable into 2026. Our source dates in the repo are October 2025 / January 2026; always confirm current prices on each provider’s site before committing.

How to reduce geocoding cost

Relying on a single premium provider (e.g. Google at $5 per 1,000 requests) can become very expensive at scale. A proven way to cut costs without sacrificing quality is cascading geocoders: use several providers in a defined order, and only fall back to the next when the current one fails or does not meet your criteria.

What is cascading? You define an ordered list of providers (e.g. OpenStreetMap or OpenCage → HERE → Google). For each address, you try the first provider; if that fails or the result does not pass validation, you automatically try the next one, and so on. Cheaper or free providers handle the bulk of easy addresses; premium providers are used only for the harder cases. The result: higher success rates (often 98–99% instead of ~90% with one provider) and lower total cost, because most requests are served by the least expensive option.

Reduce your costs with Coordable cascading geocoding

The diagram below illustrates the idea: send 100% of requests to a free or low-cost provider first (e.g. OSM); only the unresolved share (e.g. 10%) goes to a mid-tier provider (e.g. HERE); and only the remainder (e.g. 4%) hits the premium provider (e.g. Google). You still reach a very high overall geocoding rate (e.g. 99.9%) while paying the premium rate for a small fraction of traffic.

Cascading geocoders: prioritize cheap or free providers, fall back to premium only when needed. Quality and cost scale with each step.

You can implement cascading in your own code (call provider A, then B on failure, etc.) or do it easily with Coordable: choose your providers, define the cascade order and fallback rules, and optionally validate results so only good coordinates reach your database. Either way, the principle is the same: prioritize cheaper solutions and only fall back to premium when it is truly necessary.

Try Coordable to easily implement cascading geocoding for your business.

Price is not everything

Pricing does not always reflect quality. The cheapest option is not necessarily the worst, and some geocoders can match or beat large commercial providers depending on region and data type (addresses vs POIs, local vs global). To see how providers actually perform where you operate, check the best geocoding provider for your country. We have in-depth comparisons for:

Where to go from here

For more detail on a single provider (coverage, rate limits, licensing), see our guides: Google Maps Geocoding API, HERE Geocoding API, Mapbox Geocoding API. For a head-to-head in 2026, see Google vs HERE for geocoding.

UK Address and Postal Data FAQ: AddressBase, UPRN, PAF, and PSGA Explained

François Andrieux — Sun, 02 Nov 2025 10:00:00 GMT

If you work with UK addresses, you've probably encountered terms like AddressBase, UPRN, PAF, and PSGA. These are fundamental components of the UK's address infrastructure, but they can be confusing.

This FAQ answers the most common questions about UK address and postal data systems. I hope it will help you as it helped me! 🙂

Looking for practical geocoding solutions? See our comparison of UK geocoding providers to find the best API for your needs.

Table of contents:

What is a UPRN?

UPRN stands for Unique Property Reference Number. It's a unique 12-digit identifier assigned to every addressable location in Great Britain (England, Scotland, and Wales).

Each property has one UPRN that never changes, even if the address changes. These are simple 12-digit numbers (e.g., 100023336956) that cover residential homes, commercial buildings, sheds, garages, and even mailboxes. The system is managed by GeoPlace, a partnership between the Local Government Association and Ordnance Survey.

Example: the 10 Downing Street UPRN is 10008517798 (source)

For example, 100023336956 is the UPRN for 10 Downing Street, London SW1A 2AA (the Prime Minister's residence). Even if the building's use or occupant changes, this 12-digit identifier remains constant, ensuring consistent identification across all government systems and databases.

This UPRN is associated to the 8400071 USRN (Unique Street Reference Number) for the street "Downing Street".

What is a USRN?

USRN stands for Unique Street Reference Number. It's a unique identifier assigned to every street in Great Britain, that can go up to 10 digits long.

Each street has one USRN that never changes, even if the street name changes. For example, 8400071 is the USRN for the street "Downing Street".

Why do UPRNs exist?

Using addresses as identifiers is problematic because:

Addresses change: Streets get renamed, building numbers change
Typos and variations: "High St", "High Street", "HIGH STREET" are all the same place
Inconsistent formatting: Different systems store addresses differently

UPRNs solve this by providing a stable, unique identifier that connects all systems and databases.

For example, if 123 High Street, London is renamed to 123 King Avenue, London, the UPRN remains the same (e.g., 100023336956). This allows:

Government records to stay linked
Utility companies to maintain service history
Emergency services to find the correct location
Council tax records to remain accurate

How to check for a UPRN?

You can use the website uprn.uk to check for a UPRN.

Example lookup for the UPRN 100023336956 (source)

What is AddressBase?

AddressBase is the most comprehensive and authoritative address database for Great Britain, maintained by Ordnance Survey.

AddressBase combines UPRNs, addresses, coordinates, and property metadata into a comprehensive database.

It contains all UPRNs (every property's unique identifier), full addresses (building number/name, street, locality, town, postcode), geographic coordinates (latitude and longitude in British National Grid and WGS84), property classification (residential, commercial, etc.), local authority information (which council area the property belongs to), and multiple address formats (official address, alternative names, historical addresses).

What are the different AddressBase products?

Ordnance Survey offers three AddressBase products with varying levels of detail:

AddressBase Core provides basic address information with UPRNs and coordinates, suitable for simple address lookup and validation.

AddressBase Plus is an enhanced dataset with additional address details, multiple address formats (e.g., Welsh language variants), and property status information.

AddressBase Premium is the most comprehensive dataset, including full address history, alternative addresses (e.g., previous names), detailed metadata and relationships. It's best for complex applications requiring complete address intelligence.

Can you give an example of AddressBase data?

Here's a sample record from AddressBase Plus showing an address in Exeter, United Kingdom:

uprn: 10094201708
udprn: ""
parent_uprn: 55508903
sub_building: "FLAT 404"
building_name: "CLIFFORD HOUSE"
building_number: ""
dependent_thoroughfare: ""
thoroughfare: "STADIUM WAY"
double_dependent_locality: ""
dependent_locality: ""
post_town: "EXETER"
postcode: "EX4 6AX"
rpc: "S"
coordinates:
  x: 292839.08
  y: 093519.86
  latitude: 50.7313689
  longitude: -3.5197896
classification: 2
status: "E"
state: "I"
dates:
  start_date: 2018-07-03
  last_update: 2019-11-20
  entry_date: 2020-06-13
record_type: "R"

This record represents Flat 404, Clifford House, Stadium Way, Exeter EX4 6AX, with coordinates and metadata showing when the address was created and last updated.

What is Royal Mail PAF?

PAF stands for Postcode Address File. It's Royal Mail's database of all "delivery points" (addresses that receive mail) in the UK.

Managed by Royal Mail (the UK's postal service), PAF is delivery-focused and contains only addresses where mail is delivered. It's updated regularly to reflect new builds and address changes, covers all UK countries (England, Scotland, Wales, and Northern Ireland), and every address is linked to its postcode.

Each PAF record contains: building name/number, street name, locality, town, county, postcode, and a delivery point suffix (DPS) — a unique identifier within a postcode.

PAF vs AddressBase: What's the difference?

Let's take an example:

Feature	Royal Mail PAF	AddressBase
Coverage	UK (including Northern Ireland)	Great Britain only (England, Scotland, Wales)
Focus	Mail delivery points	All addressable locations
Identifier	Postcode + DPS	UPRN
Includes	Only addresses receiving mail	All properties (including non-postal)
Managed by	Royal Mail	Ordnance Survey / GeoPlace
Coordinates	Not included (usually)	Included

To illustrate: a property might be in PAF if it receives mail (e.g., 123 High Street, London SW1A 1AA), but in AddressBase whether or not it receives mail (e.g., a shed, garage, or temporary structure). Some properties (like construction sites or private roads) may have a UPRN but no PAF entry because Royal Mail doesn't deliver there.

Is AddressBase free and open data?

Short answer: Partially open — it depends on who you are and how you'll use it.

✅ Free access:

For UK public sector organizations, AddressBase is available through the Public Sector Geospatial Agreement (PSGA) (see below about this). This includes AddressBase Core and Plus, free to use for public sector purposes.

For others, some local authorities publish UPRN data as open data (not universal), and Ordnance Survey's OpenData products exist, but AddressBase is NOT included.

💰 Paid licenses required:

For commercial use, businesses need a paid license. Various developer license tiers are available based on usage volume. AddressBase Premium requires a paid license even for many public sector uses beyond basic PSGA coverage.

Important note: While UPRN itself is just a number, accessing the full database requires licensing. Using UPRNs in your application may require a license even if you obtain them elsewhere. Always check current terms on the Ordnance Survey website.

Is Royal Mail PAF free and open data?

No, PAF is not free or open data. Royal Mail licenses PAF commercially (see Royal Mail PAF pricing).

You can access PAF in three ways: directly from Royal Mail (various commercial licenses available, with pricing based on usage and application type, offering the full dataset or subsets for specific regions), through licensed resellers (many address validation and geocoding providers like Loqate, Postcode Anywhere, and Ideal Postcodes license PAF, allowing you to access it indirectly through their APIs), or for public sector (some limited access via PSGA, often supplemented with AddressBase).

Check out our comparison of UK geocoding providers to find the best API for your needs.

Royal Mail is a commercial company, and PAF is valuable intellectual property. Maintaining and updating the database requires significant resources, funded through licensing fees.

What is the Public Sector Geospatial Agreement (PSGA)?

The PSGA is a UK government initiative that provides free access to Ordnance Survey data for public sector organizations.

Who qualifies? UK public sector organizations, including central government departments, local councils and authorities, NHS organizations, police and fire services, educational institutions (schools, universities), and other public bodies.

What data is included? The PSGA provides access to AddressBase Core (free), AddressBase Plus (free), AddressBase Premium (limited access, may require additional licenses), OS MasterMap and other Ordnance Survey datasets, plus API access for online services.

What are the terms? The data is free to use for public sector business but cannot be shared with commercial third parties, cannot be resold or used for purely commercial purposes, and must be used for public sector functions.

How to access PSGA data: Check if your organization qualifies, register on the Ordnance Survey website, download data or access APIs, and use in compliance with PSGA terms.

What are the alternatives to AddressBase and PAF?

If you need free or open UK address data, consider these alternatives:

OpenAddresses UK is a crowdsourced, open-source address database with good coverage in many areas (though not complete), available under open data (public domain) license at openaddresses.io.

OpenStreetMap (OSM) offers community-maintained map data with UK addresses. Coverage varies by area (excellent in cities, patchy in rural areas), licensed under ODbL (Open Database License), accessible at openstreetmap.org.

ONS Postcode Directory (ONSPD) from the Office for National Statistics provides all UK postcodes with geographic info under the Open Government License at ONS Geoportal. Note: it contains postcodes and coordinates, not full addresses.

Local Authority open data: Some councils publish their address data (coverage varies widely by council), usually under the Open Government License. Check individual council open data portals.

Good to know: AddressBase and PAF are more complete and accurate, commercial data is updated more frequently, licensed data comes with support while open data is "as-is", and commercial licenses are clear while open data usage can be complex.

How do UPRN, AddressBase, and PAF work together?

In short, they complement each other in the UK address ecosystem.

Here's an example workflow: imagine a utility company needs to manage customer accounts. A customer signs up with address "10 Downing Street, London SW1A 2AA". The system looks up the address in AddressBase, gets UPRN 10008517798 and coordinates 51.5034, -0.1276, validates the postcode using PAF to confirm it's a mail delivery point, stores the UPRN as the primary identifier, and links all services to this UPRN (billing, service calls, maintenance history).

The UK address ecosystem: UPRNs identify properties, AddressBase provides comprehensive data, and PAF focuses on mail delivery.

The benefits are clear: if the address changes, the UPRN stays the same; coordinates enable field service routing; the postcode confirms mail delivery is possible; and there are no duplicate customer records.

Which should I use: AddressBase or PAF?

It depends on your use case:

Use PAF if you need postcode validation, mail delivery confirmation, address formatting for postal services, Northern Ireland addresses, or simple address lookup by postcode.

Use AddressBase if you need UPRNs for data linking, geographic coordinates, all addressable locations (not just postal), property classification, local authority boundaries, or historical address data.

Use both if you need complete address intelligence, geocoding with postal validation, maximum coverage and accuracy, or integration with multiple systems.

Many organizations use both: AddressBase for the authoritative address register and UPRNs, and PAF for postal validation and formatting.

Can I geocode UK addresses without AddressBase or PAF?

Yes! You have several options:

Global geocoding providers include Google Maps Geocoding API (excellent for UK addresses), HERE Geocoding (good UK coverage), Mapbox Geocoding (uses OpenStreetMap + proprietary data), and TomTom Geocoding (commercial-grade accuracy). These services have their own address databases, often incorporating multiple sources.

UK-specific geocoding services include Ideal Postcodes (uses OS data, licensed), Loqate (uses PAF and other data), and Postcode Anywhere (UK-focused address validation).

Open-source geocoding options include Nominatim (OpenStreetMap geocoder, free and open-source) and Pelias (open-source geocoder that can use OpenAddresses).

Learn more in our comparison of UK geocoding providers: Best Geocoding Providers for the United Kingdom.

Where can I learn more?

Official sources:

Ordnance Survey: ordnancesurvey.co.uk
GeoPlace (UPRN): geoplace.co.uk
Royal Mail PAF: royalmail.com/business/services/marketing/data-optimisation/paf
PSGA Information: ordnancesurvey.co.uk/psga

Related articles:

How geocoding works: A simple guide
UK Country Analysis — Geocoding performance in the UK

Need help with UK addresses? Coordable can help you geocode, validate, and manage UK addresses with high accuracy, supporting multiple providers and data sources.

How geocoding works ? A simple guide

François Andrieux — Wed, 22 Oct 2025 10:00:00 GMT

What is geocoding and why it matters?

Every day, we interact with addresses and places; whether we're searching for a nearby coffee shop on our phone, or entering our delivery address at checkout. But here's the thing: computers don't naturally understand "123 Main Street" or "Central Park." They work with numbers and more specifically, with latitude and longitude coordinates.

That's where geocoding comes in: Geocoding is the process of translating human-readable addresses into geographic coordinates that computers can use to pinpoint locations on a map. It's the invisible bridge between how we describe places and how machines navigate, analyze, and visualize them.

A simple geocoding example.

This guide will walk you through what geocoding is, how it works behind the scenes, what can go wrong, and how to get the best results. Let's dive in! 🙂

Note: You don't need to be technical to use geocoding well. Understanding a few key concepts will help you troubleshoot issues and make better decisions.

Table of contents:

The two ways of geocoding

Geocoding actually works in two directions, and each serves a different purpose.

Forward geocoding: turning addresses into coordinates

Forward geocoding takes a text address (like 57 Rue de Varenne, Paris, France) or place name (like Tour Eiffel) and returns a pair of coordinates (latitude and longitude).

This is the exact process that happens when you search for a location in Google Maps or Apple Maps on your phone:

In Google Maps, typing "57 Rue de Varenne, Paris, France" and getting the coordinates is a forward geocoding process.

Forward geocoding is an essential tool for a wide variety of operations. I don't want to sound too boring already by listing all the examples, but here are just a few.

For consumers:

Finding places: Forward geocoding lets you search for locations in navigation apps, just type a name or address to find a coffee shop, pharmacy, or tourist site.
Getting directions: All navigations apps use geocoding to get the coordinates of the destination and display it on the map. Then, the best route is computed by the navigation engine.
Package delivery: Addresses are sent to the delivery driver to help them find your address and drop off your package.

For businesses:

Address validation: Online stores and delivery services geocode addresses to check and standardize them at checkout.
Route optimization: Companies geocode address lists to plan deliveries efficiently and save resources.
Customer analytics: Businesses geocode customer addresses to spot trends and improve marketing or logistics.
Store locators: Retailers use geocoding so customers can easily find the nearest shop from their address.

And this list is not exhaustive. Yes, geocoding is everywhere! 😀

Reverse geocoding: turning coordinates into addresses

Reverse geocoding does the opposite: you start with a GPS point (latitude and longitude) and get back the nearest address or place name.

That's what happens when you pin a place on the map in Google Maps or Apple Maps:

In Google Maps, pinpointing a location and getting a suggestion for the address is a reverse geocoding process.

Again, here are some real world examples:

When you drop a pin on a map to show a friend where you are, the app reverse geocodes that point to display 57 Rue de Varenne, Paris, France instead of 48.8589, 2.3514.
Photos taken with your smartphone often store GPS coordinates in their metadata. Apps reverse geocode those coordinates to label your photos with Central Park, New York or Eiffel Tower, Paris.
A delivery driver scans a package at your door. The handheld device logs the GPS coordinates at that moment, and the system reverse geocodes it to confirm delivery at the correct address.

Good to know: In most cases, when people mention "geocoding", they’re talking about forward geocoding. If reverse geocoding is meant, it’s usually specified directly.

How geocoding works (simplified version)

Now let's walk through what happens when you provide an address to a geocoding system. Understanding these steps will help you recognize why some addresses work perfectly and others struggle.

Basically, geocoding involves matching an input address to the most similar entry in a large address database. In other words, it's a process of looking up an address in a database:

Address lookup: the geocoding system checks your input against a massive database of known addresses and places to find the best match.

When I type 57 ru de varenne Paris in Google Maps (yes, with the typo), the system will compare this input with Google's database of addresses and POIs (Points of Interest) and will return the closest match.

This simple address lookup is made of 4 steps:

Address normalization
Parsing
Database lookup
Scoring and ranking

Let's go through each step in detail.

Step 1: Address normalization

Addresses can be entered in many different ways: with typos, all uppercase, extra or missing information (like country or postal code), or with unnecessary details.

The normalization process aims to standardize addresses so they can be easily compared to those in the database. Here are some typical normalization steps:

Standardization: Convert to lowercase, remove extra spaces and symbols, etc. Example: 57 , AV des Champs-élysées (paris) becomes 57 avenue des champs elysees Paris.
Expanding abbreviations: 57 R de Varenne may be expanded to 57 Rue de Varenne.
Correcting small typos: Obvious small errors can be fixed, e.g., 57 Reu de Varenne becomes 57 Rue de Varenne.
Removing filler words: We can remove words like "de", "la" (in french) or "of", "the", "in", e.g. 57 Rue de la Varenne in Paris could become 57 Rue Varenne Paris.

Note: The amount and type of normalization and cleaning depends on the geocoding provider. Google Maps will have different rules than HERE, and Mapbox, and so on. This is part of each provider's "secret sauce", and that's why a provider can fail where another succeeds.

Step 2: Parsing components

Once the address is normalized, we can try to parse it, i.e., split it into recognized component parts: house number, street name, unit/apartment number, city, postal code, region/state, and country.

Address parsing: the geocoding system splits the address into recognizable components.

This is needed in order to specify the search. When I type 57 rue de Varenne paris, should I check all addresses in the World? Probably not!

Because Paris strongly suggests that we are in France (or at least, it's highly probable... we could, for example, also be in Paris, Texas, United States 😅).

Parsing works by identifying patterns. For example:

Countries are usually placed at the end of the address (like in 57 Rue de Varenne, Paris, France)
Postal codes are usually codes between 3 to 10 digits (or characters), depending on the country
Housenumbers are usually the first numbers encountered

But all these rules can be unreliable, and the geocoding system must deal with a lot of inconsistencies.

Missing components: Sometimes components are missing (I didn't type the country and the postal code for my search)
Abbreviations: People write St (street? saint?), Av (avenue? aviation?), Dr (drive? doctor?). The system must use context to decide.
Different country formats: In the U.S., postal codes come at the end. In the UK, they're often in the middle. In Japan, the structure is completely different (country, postal code, prefecture, city, district, block, building).
Multiple languages: Rue (French), Calle (Spanish), Rua (Portuguese), Ulica (Polish) — they all mean "street," and the system needs to recognize them.

As an example, Google Maps still works well if I type 75015 Paris - Rue de Varenne 57 even if it does not respect the usual format.

Why parsing is powerful: Once the address is parsed, the geocoding engine can use the country or state or city to filter out billions of irrelevant addresses. A postal code narrows it even further often to just a few hundred possibilities. This is how geocoding systems stay fast and accurate even when dealing with enormous datasets.

Step 3: Database lookup - finding the match

Now that we have clean, parsed components, it's time to look them up in a reference database. This is an example of process:

Take only addresses within the same country or state or city (if available, let's say France for our example)
Find addresses that match the most of our components: house number, street name, city, postal code.

Illustration of the address lookup by components.

In this above example, we find 4 possible matches (that have at least one component in common with our input):

57 Rue de Varenne, Riom, France
57 Rue de Varenne, Paris, France
58 Rue de Varenne, Paris, France
57 Av. des Champs-Elysées, Paris, France

For the sake of simplicity, we used a strict matching, i.e. we only match if the input is exactly the same as the database. However, in reality, geocoding systems often use distance functions, like the Levenshtein distance, which helps match addresses even when they contain typos or abbreviations (e.g. 57 Rue de Varene with a missing letter n).

Tokenization: Some geocoding systems use a process called tokenization, which means splitting an address into smaller pieces (tokens), usually words. Instead of trying to match the entire street name as one string, the system can match individual tokens. For example, champs elysées might be split into tokens like champs, elysées, champs elysées, and champs-elysées. This approach increases the chances of finding a match even if the address format varies or contains minor errors. Geocoding engines use different strategies to generate and compare tokens: some rely on phonetic similarity, others use techniques like stemming (reducing words to their base form) or lemmatization. The exact methods may vary between systems.

You also now understand that the goal is to have the most complete list of addresses possible but also to include street names, administrative boundaries, cities, neighborhoods, POIs, and more. This is also why some providers can give much different results than others. Commercial providers like Google or Apple have their own private data, whereas some well-known open source initiatives like OpenStreetMap and OpenAddresses.io can give you good coverage of the world.

Google Maps, for instance, excels with commercial data like restaurant names or shop names. The US Census geocoder will never be able to match a restaurant name with a location; it's simply not in their database.

Step 4: Scoring and ranking - choosing the best match

As we saw, the database lookup often returns multiple candidates. Maybe there are two 57 Rue de Varenne addresses in neighboring towns. Or the postal code matches perfectly, but the street name is slightly off. How does the system decide which one to return?

If you look at the example above, it's clear that not all matches are equal. Some are more likely to be the correct one than others. If our input is 57 Rue de Varenne, Paris, France, we have:

57 Rue de Varenne, Riom, France: same housenumber & street name but different city
57 Rue de Varenne, Paris, France: same housenumber & street name & city
58 Rue de Varenne, Paris, France: same street name & city
57 Av. des Champs-Elysées, Paris, France: same housenumber & city

It becomes obvious that some components are more important than others, i.e. matching the right city is probably more important than matching the right housenumber. For our example, let's attribute a score with ponderationnal weighting:

1 point for the housenumber
2 points for the street name
3 points for the city

The result would be:

57 Rue de Varenne, Riom, France: 1 + 2 = 3 points
57 Rue de Varenne, Paris, France: 1 + 2 + 3 = 6 points 🏆
58 Rue de Varenne, Paris, France: 2 + 3 = 5 points
57 Av. des Champs-Elysées, Paris, France: 1 + 3 = 4 points

The database lookup with 57 Rue de Varenne, Paris, France has 6 points, being the highest score, so that's the one that will be returned ! 🎉

Good to know: It's a way for geocoding providers to score their results and return confidence scores. Some may use different weighting, some may use different distance functions, etc. But you get the idea. Again, it's a way for some geocoding providers to achieve better performance than others.

Coming up with a good scoring system isn't easy, and there's no single right answer. Is the city name always worth 3 points, or should that change if the name's a bit ambiguous? What about situations where parts of the address are missing or not very reliable? Tweaking the weights for each component can have a big effect on your results, and it often depends on where your data is from and the types of addresses you get.

In practice, building these ranking rules usually involves a lot of testing, tweaking, and sometimes even a dash of machine learning to get the best possible matches.

What could go wrong? Understanding geocoding failures

Now that you understand how geocoding works, let's talk about what could go wrong. You will be surprised to see how often geocoding fails, and how often it's not obviously stated by the geocoding provider 😅.

Problem #1: Database issues (missing, incorrect, ...)

Geocoding systems are only as good as the data they use. If the underlying database has missing information or is out of date, even perfect input won't produce accurate results.

Missing data:

Rural areas: A farmhouse on a county road might not have a specific street address in the database. The geocoder might place it at the road centerline or at the entrance to the property close, but not exact.
New construction: A brand-new apartment building might not yet appear in the address database. It could take weeks or months for mapping providers to update their data after construction is complete.
Private roads and gated communities: These are often excluded from public datasets. If you're trying to geocode an address inside a private community, the system might only get you to the main entrance.

Ambiguous data:

Street renaming: A city renames Washington Avenue to Martin Luther King Jr. Boulevard. For months, the old name still appears in the database, and geocoding requests using the new name fail or return low-confidence results.
Multiple languages: Some addresses must exist in multiple languages, e.g. 9 Rue des pensées, 1030 Schaerbeek should as well exist as Penseestraat 9, 1030 Schaarbeek (street name and even city name are different). They both represent the exact same address, but with different languages (French and Dutch).

How to deal with this issue? You must not just trust the geocoding provider's result. You must always check the result and if it's not correct, you must try to correct it manually. Coordable automatically detects these issues for you.

Example 1: Google Maps

At the time of writing (2025, October), Google Maps does not have the address 12 rue sur le rang, Bourogne in France. Instead, it would insist in returning the address 12 Rue Vivaldi, 90140 Bourogne, France.

Google Maps wrong example: the address 12 rue sur le rang, Bourogne is not located correctly.
Mapbox is correct because it probably uses the open source French database for this example.

This example is not that bad in the sense that the result is pretty close to the correct location. However, that's still a false positive: a result that is returned and is confident about it, but it's not the correct one.

Example 2: HERE wrong example

To be fair, all geocoding providers have their flaws. Here is another example with HERE, where Google actually works better.

In this example, we geocode the address 38 b faubourg de montbéliard, Delle. It's still unsure if there are two addresses with the same housenumber there (38 and 38B), but HERE returns something completely wrong with a high score (1.0).

HERE wrong example: the address 38 b faubourg de montbéliard, Delle is not located correctly.
Google Maps is correct in this case.

The problem here seems a lack of update in the open source French database. As HERE uses it, it also inherits its errors.

Problem #2: Parsing failures when the system can't make sense of the input

Most of the time, addresses are messy. They contain extra noise, typos, mixed languages, and other formatting issues.

But sometimes, the parser can't understand the input at all:

CALL JOHN AT 555-239-4829 120 MAIN STREET APT 5B, BROOKLYN, NY, USA: too many noise, phone number, instructions, etc.
1234ElmStreetLosAngelesCA90001: no spaces or wrong order, no city or postal code.
ru Saint cathrine West, Montreal QC H3B 1B5 Canda: typo, mixed languages, etc.
RUE DES F?TES, 75019 PARIS: encoding issue, special character (should be Rue des Fêtes)

Try these examples with your favorite maps application. You would be surprised to see how often they fail.

Parsing errors are a real problem: businesses processing thousands of global addresses using poorly designed parsers often see failed deliveries or mismatched addresses, all due to small parsing errors that could have been avoided with better cleaning and normalization.

How to deal with this issue? Cleaning the input is a good way to improve the results. E.g. if you know that your addresses have encoding issues, fix it before sending it to the geocoding provider. Coordable has automated AI cleaning that deals with all the above issues and more.

Example 1: basic encoding issue

In this example, the address RUE DES F?TES, 75019 PARIS cannot be geocoded correctly in both Mapbox and Nominatim (the OpenStreetMap geocoder).

Illustration of an encoding issue: the address RUE DES F?TES, 75019 PARIS is not properly geocoded.

In both cases, they will return the correct location if f?tes is replaced by fêtes.

Example 2: noise issue

In this example, we consecutively try CALL JOHN AT 555-239-4829 120 MAIN STREET APT 5B, BROOKLYN, NY, USA and MAIN STREET APT 5B, BROOKLYN, NY, USA in Google Maps.

Example of noise: extra phone numbers and instructions prevent the geocoder from finding the correct address.

The result is that noise is not being filtered by Google Maps (which has, to be honest, one of the best parsers out there). Is it Google Maps fault? No, probably not. At this point, we should have cleaned the input ourselves.

You may think it's a silly example, but it's not 🫠. It happens a lot to see mixed fields because of human errors.

Example 3: typos

In this example, we try to geocode the address ru Saint cathrine West, Montreal QC H3B 1B5 Canda in HERE and Mapbox. It's a mix of French and English with many typos. A correct address could be Rue Sainte-Catherine Ouest, Montreal QC H3B 1B5 Canada or St-Catherine West, Montreal QC H3B 1B5 Canada.

Example of typos and mixed languages that can cause geocoding failures.

HERE returns the correct address, but Mapbox can't find it and returns Montreal, QC, Canada. It's interesting to play around with the suggestions in the HERE dropdown. It shows that both English and French versions are available, and it's not affected by the typo ru instead of Rue.

Best practices: how to get reliable geocoding results

Now that you understand how geocoding works and what can go wrong, let's talk about how to improve your results 😎. Whether you're a consumer troubleshooting a single address or a business processing thousands, these practices will help.

1. Pick the right geocoding provider

You can get better results by picking the right geocoding provider.

Why: All providers rely on different data, different parsing rules, different scoring systems, etc. This makes many ways to differentiate them.

How: You should try different geocoding providers and see which one works best for you. You can also try to use the geocoding provider's API to get the best results.

Good to know: on Coordable, you can select the geocoding provider from a dropdown in the address input field.

2. Always add context (country, region, postal code)

Geocoding accuracy improves dramatically when you provide strong context: country, state/region, and especially postal code.

Why: Cities, streets, and even building names can be duplicated across the world (or even within a single country). "Paris" could mean Paris, France or Paris, Texas. "There are thousands of streets named Main Street in the United States alone."

How: At least, always concatenate the country to the address. It's a quick win. And if possible, a postal code is a strong hint of the correct location.

3. Clean your addresses before you geocode

Messy, incomplete, or inconsistent addresses are the #1 cause of poor geocoding results. Cleaning (a.k.a. "address normalization") means fixing typos, filling in missing parts, converting to a canonical format, and removing extraneous noise.

Why: Geocoding engines often struggle with extra info ("Attn: John", "call before delivery", phone numbers), bad capitalization, spelling/formatting variations, or misplaced address parts. Clean inputs = far fewer errors.

How: You can implement some of the rules we presented earlier in this article: normalization, replacement of abbreviations, encoding issues, etc.

Tools: Basic cleaning can be handled with spreadsheet formulas, or specialized software/APIs like Coordable, libpostal, or your geocoding provider's normalization endpoint.

4. Help the parser if possible

If possible, provide the information of your address components to the geocoding provider. This can help the parser to understand the address better.

Why: Parsing is one of the most important steps in geocoding. If it's failing, you will get poor results.

How: Some geocoding providers can accept a structured address input like a JSON object with the address components: {house_number: "57", street: "Rue de Varenne", city: "Paris", state: "Île-de-France", country: "France", postal_code: "75015"}.

5. Understand what you are geocoding

Are you sending residential addresses or POIs? Do you have mostly street names alone or do you have house numbers?

Why: Understanding what you are sending can help you to understand the quality of your results. It's obvious, but if only 50% of your addresses are residential addresses, you should expect less than 50% of results with housenumbers.

How: You can implement your own rules to classify addresses. For instance, you could write a regex rule to parse postal codes and housenumbers.

Good to know: when uploading a dataset or starting a geocoding job on Coordable, we automatically classify the addresses for you.

6. Don't trust results blindly

Geocoding systems return results even when they're not confident. If you blindly accept the first result, you might get the wrong location. Even the confidence score is not a guarantee of the correctness of the result.

Why: The confidence score is not a guarantee of the correctness of the result. It's a score given by the geocoding provider to indicate the confidence in the result. It's not a guarantee of the correctness of the result.

How to avoid it: Implement your own rules to measure accuracy and correctness of the result, based on the information the provider gives you, as well as your own manual verification.

Good to know: the Coordable platform embeds a powerful verification engine that can help you quickly identify false positives and incorrect results.

Conclusion

I hope you enjoyed this guide. I tried to explain how geocoding works in a simple way, with examples and practical tips to improve your results.

A lot of technical details are omitted, such as tokenization, distance functions, or scoring rules. I will probably write a follow-up article to cover these topics. But at least it presents the big picture of a geocoding process.

If you are a business and want to improve your geocoding results, please contact us at contact@coordable.co.

After that, if you want to learn more, here are some resources that I found interesting:

Happy geocoding! ⭐