How we cut geocoding costs by 79% across Europe

Julien Crétin — Mon, 15 Jun 2026 09:00:00 GMT

A benchmark of OSM, HERE, and Google across 12 countries and 6,000 residential addresses.

Geocoding 500,000 European residential addresses per month with Google Maps as the sole provider costs $30,000 per year. We ran a benchmark across 12 European countries and 6,000 addresses using a cascade strategy that calls free OSM first, then HERE, then Google. In our test the cascade resolved 86.3% of addresses correctly (within 100m of the national reference coordinate), against 73.7% for Google alone, at a cost of about $6,300 per year at the same volume. That is a 79% cost reduction with a 12.6 percentage point quality gain.

That average hides large per-country variation. At the same 500,000 addresses per month, the cascade saves between $15,000 and $30,000 per year per country against Google alone, with quality gains ranging from +3 to +34 percentage points depending on the country. We give the full per-country breakdown below so you can read off your own situation.

The cascade dominates Google on both axes in every single country we tested. There is no country where defaulting to Google is the better choice. But the optimal cascade configuration varies dramatically across Europe: in the Netherlands, free OSM data alone resolves nearly every address, while in Finland and Italy even the full three-provider cascade leaves a quarter of addresses unresolved. The orchestration logic matters more than the choice of providers.

This article walks through the dataset, the protocol, what we found, and what it means for any team running geocoding at scale in Europe.

The headline, at 500,000 EU residential addresses a month: better coverage, 79% cheaper.

Table of contents:

Why this matters

Most engineering teams default to Google Maps for geocoding. The reasoning is reasonable on paper: Google has the largest map data footprint in the world, the API is well documented, and "nobody got fired for buying Google". Then the bill arrives.

At $5 per thousand requests, Google geocoding is the most expensive of the three major options by a factor of six against HERE and by an infinite factor against OSM. Teams notice this when their geocoding spend hits the financial dashboards, usually around the time logistics, e-commerce, or fleet operations scale into hundreds of thousands of monthly addresses.

Number of addresses:

Costs use each provider's per-1,000 rate; free tiers are not deducted (marginal at this scale, e.g. 10,000 free requests for Google, 30,000 for HERE).

Most teams just absorb the cost, or swap Google for a single cheaper provider and brace for a quality drop. The better response is to question the default. Geocoding is not a problem where one provider is uniformly superior. It is a problem where data sources, coverage, and pricing vary by country, and where a smart routing layer outperforms any single provider on both cost and quality.

We wanted to put numbers on that claim. So we built a benchmark.

The dataset

We constructed a 6,000-address sample stratified across 12 European countries: France, Spain, Italy, the Netherlands, Denmark, Norway, Portugal, Finland, the Czech Republic, Lithuania, Slovakia, and Slovenia. 500 addresses per country, all residential.

The 12 benchmarked countries, 500 residential addresses each. The UK is hatched: no open national address dataset.

The address sources are national authoritative registries, aggregated through OpenAddresses for 11 countries and through CartoCiudad (the Spanish national mapping agency) for Spain. We deliberately chose residential rather than business addresses, because residential is where geocoding actually breaks: business addresses tend to cluster on well-named commercial streets, while residential includes the long tail of suburban subdivisions, rural hamlets, and post-2010 developments that geocoders struggle with.

The United Kingdom is missing from the benchmark, and that absence is itself worth noting: Ordnance Survey AddressBase, the only complete UK address registry, remains paywalled. There is no open national address dataset for the UK comparable to France's BAN or Spain's CartoCiudad. This is a structural blind spot in European open data that affects every open-source geocoding effort.

Each address in the sample carries a reference coordinate from the national registry: a postal code, a city, a street name, a house number, and a (lat, lng) pair. We treat the (lat, lng) as a reference coordinate, not as ground truth. Ground truth would require a field GPS reading, which we do not have. National registries have their own errors: parcel centroids that differ from the actual building entrance, projection drift, missing recent constructions. The cleanest way to phrase what we measure is "divergence from the national reference", not "provider error". That distinction matters for the methodology and we return to it.

The protocol

A note on terms first. Google and HERE are commercial providers that bundle their own data, engine, and hosting. OpenStreetMap is an open referential that we query through a separate engine, and the engine choice matters, which is why we use Photon rather than Nominatim (more below). We geocoded the 6,000 addresses three times independently, once with each of the three: OpenStreetMap, HERE, and Google. We kept the raw output for every provider on every address, with no quality filtering at geocoding time. This is the critical choice. By geocoding all 6,000 addresses with all 3 providers, we can reconstruct the cascade afterward with whatever logic we want, and measure the marginal contribution of each step.

About the OSM provider choice: we initially ran Nominatim and got 6.4% completeness on the Czech sample. This was not a fair measurement of OSM coverage. The public Nominatim instance enforces a 1 request per second rate limit and treats timeouts as no-result, which crushes the apparent hit rate. The same addresses fed to Photon, which uses the same OSM data behind an Elasticsearch index, returned 74.4%. We switched to Photon for all subsequent runs. The Photon numbers reflect what OSM data can actually do; the Nominatim numbers reflected operational throttling, not data coverage.

For each provider, we then needed a decision rule: "did this provider produce a usable result?" In production, a cascade has to decide whether to accept a result and stop, or fall through to the next provider. It has to do this without access to a reference coordinate, since if you had a reference coordinate you would not need to geocode.

We started with a simple rule: trust the provider's own classification. HERE returns a confidence score that can be thresholded at 0.8. Google and Photon do not return useful confidence scores, so we used their classification labels (HOUSENUMBER versus LOCALITY versus UNRESOLVED).

This failed in interesting ways. For Slovakia, Google was returning 1.2% HOUSENUMBER, which is implausible. The actual Google results for Slovak addresses were correct: the right street, the right number, coordinates within meters of the reference. But the off-the-shelf classification we started with was misreading the Slovak address format ("village name + number" without a separate street) and labeling correct rooftop results as LOCALITY or POI. A label-based decision rule was throwing away correct answers because the labels were wrong.

We replaced the label-based rule with a textual one: a result is accepted if the formatted_address returned by the provider contains the street name, the house number, and either the city or the postal code from the input. This is what a human reviewer would do to validate a match. It is provider-agnostic, language-agnostic to a useful degree, and it makes no use of the reference coordinate, so it is something that could run in production.

This rule is not perfect, and we want to be transparent about that. We applied it manually for this benchmark as a way to evaluate cascade behavior more honestly than the provider labels allowed. At production scale, validating thousands of geocoded results requires more sophisticated approaches: cross-provider consistency checks, semantic matching with language models, learned rejection thresholds. We are working on a follow-up article on exactly that question, comparing an LLM-based result validator against the manual rule we used here. The takeaway for now is that this kind of validation logic, not the provider choice, is what unlocks cascade performance.

The headline results

Here are the two strategies side by side, evaluated on the full 6,000-address sample, with cost shown as annual spend at a 500,000 addresses per month workload (Google $5/1k, HERE $0.83/1k, OpenStreetMap $0).

Strategy	Acceptance	Confirmed hits (<100m from reference)	Cost / year	Cost per 1,000 confirmed hits
Google alone	77.9%	73.7%	$30,000	$6.79
Cascade (OSM → HERE → Google)	89.9%	86.3%	$6,336	$1.22

Two things stand out.

First, the cascade beats Google alone on every metric. It accepts more addresses, it lands more of them within 100m of the reference, it has a lower rate of false positives, and it costs roughly a fifth of what Google alone would.

Second, the free tier does the bulk of the work. OpenStreetMap alone resolves about 60% of addresses at zero cost. Only the roughly 40% it cannot handle fall through to HERE, and only the roughly 13% that HERE cannot handle ever reach Google. By the time an address reaches the most expensive provider, it is one of a small minority. This is the entire economic logic of a cascade.

OpenStreetMap clears most addresses for free; only a small share ever reaches a paid provider.

Whether you should drop a provider from this cascade, and whether Google's last few points are worth their cost, is something we return to in What this means for your stack. But the headline is simple: the expensive provider should be the last resort, not the default.

The country-by-country picture

The headline numbers hide the most important finding: country-by-country variance is enormous. Here are Google alone and the full cascade broken down per country, with the cascade's gain over Google, sorted from the easiest country to the hardest.

Country	Google alone	Cascade	Gain
Netherlands	90.4%	100.0%	+9.6
Slovenia	94.6%	98.4%	+3.8
Spain	89.8%	95.0%	+5.2
Lithuania	60.2%	94.4%	+34.2
France	85.0%	91.2%	+6.2
Czech Republic	84.6%	88.0%	+3.4
Slovakia	73.0%	87.0%	+14.0
Portugal	69.8%	85.4%	+15.6
Denmark	69.6%	82.0%	+12.4
Norway	67.2%	80.0%	+12.8
Italy	65.0%	74.0%	+9.0
Finland	34.6%	60.2%	+25.6

Google alone versus the full cascade, country by country. The gain runs from +3.4 to +34.2 points.

The variance is the story.

Netherlands is the easy case: OSM alone resolves nearly every Dutch residential address correctly, because the Dutch community has done extraordinary work mapping their country into OSM, much of it imported directly from the BAG (Basisregistratie Adressen en Gebouwen), the national registry of addresses and buildings, which the government publishes under an open licence. The full cascade reaches 100% completeness at zero geocoding cost. If your business operates only in the Netherlands, you do not need a commercial geocoding provider at all. In practice a Dutch team might not reach for OSM here at all: the government runs its own free geocoder, PDOK Locatieserver, on the same BAG data, and open-source tooling such as NLExtract turns that official open data into a geocoder you can run yourself. The flip side of this shared lineage is a measurement caveat we cover in Honest limitations.

Lithuania is the surprise: Google alone resolves only 60.2% of Lithuanian residential addresses correctly, but Photon brings that to 94.4%. We expected the Nordic and Baltic countries to be a weak spot for OSM, and instead Lithuania is one of the strongest performers. The +34.2 point gain over Google alone is the largest in the dataset.

Spain, France, Czech Republic, Slovenia are the steady middle: Google alone gets you to the mid-to-high 80s, the cascade adds a few points at low marginal cost, and the value of HERE is small in these countries. A two-provider cascade is sufficient.

Denmark, Norway, Slovakia, Portugal are the structural gain zone: the cascade adds 12 to 16 points over Google alone. HERE and Google together cover what neither could alone. The cascade costs more here, but the quality lift is large.

Italy and Finland are the hard countries: even the full cascade leaves a quarter to forty percent of addresses unresolved within 100m. There is no clever orchestration that fixes this with the providers we tested. Italy has notoriously inconsistent residential addressing (the same Via Roma appears in thousands of municipalities, civic numbers come with suffixes, parenthetical disambiguators, and saint names that geocoders confuse). Finland is harder still because the OpenAddresses source for Finland does not include a city field, only street + postcode + country. That kind of partial input is closer to what a real-world delivery dataset looks like, and it punishes every provider equally.

What this means: there is no single optimal cascade for Europe. The Netherlands cascade is "Photon only, stop". The Lithuanian cascade is "Photon, then occasionally HERE". The Finnish cascade is "all three, and accept that 40% will need manual review". A geocoding strategy that does not adjust by country is leaving money or quality on the table.

Annual savings at scale

The headline showed the blended average. The country-level numbers are where the real money is, and where the variance becomes impossible to ignore. We use the same 500,000 addresses per month workload, broken down country by country, so you can read off your own situation: if you operate at this volume in France, your numbers are the France row; if you run 200k per month across two countries, take 40% of the relevant rows and add them.

One number is identical everywhere: geocoding 6 million addresses a year with Google alone costs $30,000, since Google charges $5 per thousand requests in every country. What varies, dramatically, is what the cascade costs. And that variance is the whole point of this article.

Country	Quality gain	Cascade cost / year	Savings / year	Reduction
Netherlands	+9.6	$20	$29,980	100%
Slovenia	+3.8	$1,694	$28,306	94%
Lithuania	+34.2	$2,058	$27,942	93%
Spain	+5.2	$2,952	$27,048	90%
Slovakia	+14.0	$2,957	$27,043	90%
France	+6.2	$5,328	$24,672	82%
Czech Republic	+3.4	$5,961	$24,039	80%
Denmark	+12.4	$7,794	$22,206	74%
Norway	+12.8	$8,244	$21,756	73%
Italy	+9.0	$11,732	$18,268	61%
Portugal	+15.6	$12,543	$17,457	58%
Finland	+25.6	$14,744	$15,256	51%
AVERAGE	+12.6	$6,336	$23,664	79%

What you pay versus what you save, per country, against Google's flat $30,000 a year.

A few observations on this table.

First, the cascade beats Google alone in every single country. The smallest annual saving is $15,256 in Finland, the largest is $29,980 in the Netherlands. There is no scenario in our benchmark where defaulting to Google is the right call at this volume.

Second, the variance in savings tracks the variance in cascade cost, not Google cost. Google is $30,000 everywhere. The cascade costs $20 in the Netherlands (essentially free, Photon resolves nearly everything) and $14,744 in Finland (Photon struggles with Finnish addressing, the cascade falls through to the paid providers far more often). So the question "how much does the cascade save me in country X" boils down to "how good is OSM coverage in country X". That is the same country variation we saw in the quality breakdown above.

Third, the percentage reductions are remarkably high even in countries where the cascade adds little quality. Czech Republic gains only +3.4 quality points, but still saves 80% on cost because Photon resolves 87% of Czech addresses for free. The cascade does not need a quality breakthrough to be massively cheaper. Even where it ties Google on quality, it beats Google on cost.

Fourth, the Netherlands is the limit case worth its own mention. Free OSM data resolves nearly every address that the cascade is called on, leaving essentially zero paid calls. Annual cost: $20. If your geocoding workload is mostly Dutch, you do not need a paid geocoding provider at all. We would not have predicted this five years ago, but the Dutch OSM community has done that good a job.

To extrapolate to your own volume, the numbers scale linearly. At 1 million addresses per month per country, the savings double; below that, they shrink in proportion. The percentage reductions are constant, the absolute numbers scale with traffic.

Honest limitations

A few caveats matter and we want to name them.

HERE and OpenAddresses share data sources in some countries. HERE is upfront in their documentation that "HERE Map Content" incorporates public national datasets where available. In France, this includes the BAN, which is also a source for OpenAddresses. This creates a partial overlap on our reference coordinate metric: when HERE answers from BAN-derived data and we compare it to a BAN-derived reference, the match is mechanical. To quantify this, 41% of HERE results sit within 1 meter of the reference coordinate, against 31% for Photon and 10% for Google. The other 59% of HERE results diverge meaningfully from the reference, so HERE is not a copy of OpenAddresses, but the comparison metric does favor providers that source from the same national registries. We return to the cascade with HERE removed entirely in What this means for your stack, so readers who want to discount this effect can see those numbers.

The same shared-source effect applies to OSM, most visibly in the Netherlands. Dutch OSM addresses are largely a BAG import, and our Dutch reference, sourced through OpenAddresses, traces back to the BAG as well, so the near-perfect Dutch result partly reflects a common origin rather than two independent systems agreeing. This does not change the practical takeaway, free OSM data resolves Dutch addresses whatever its provenance, and the government's own PDOK service runs on the very same data, but the 100% figure should be read as completeness against the national registry, not as proof that OSM is independently more accurate than a paid provider. Where no such open registry feeds OSM, the cascade leans much harder on the paid providers, which is exactly what the per-country cost spread shows.

The robust validation rule was applied manually. As discussed in the methodology section, deciding whether a geocoded result matches the input is the hard problem. Simple confidence thresholds fail because Google and Photon do not return useful scores. Simple label thresholds fail because the upstream classification can be unreliable on certain address formats. The textual rule we used (street + number + city/postcode in formatted_address) works for a benchmark, but it required country-by-country sanity checking and tolerance for synonyms (Calle and Carrer, Via and Strada, postal code formats with or without separators). A production cascade running at scale needs a more robust validation layer. This is the topic of our next benchmark.

Address completeness varies by source. OpenAddresses data for Denmark, Norway, and Finland does not include a city field. The geocoding inputs for these countries are therefore more impoverished than for the others (just street + postcode + country). This degrades all providers symmetrically, but it does inflate the apparent difficulty of these countries. Real-world delivery data often has similar gaps, so the measurement reflects production conditions more than ideal conditions.

6,000 addresses is not the entire population. Statistical noise is real at this sample size, especially at the country level (500 addresses per country). The directional findings are robust, the second decimal place is not.

What this means for your stack

If you are running geocoding at any meaningful European volume, four things follow from this benchmark.

The two cascades sit top-left: more confirmed hits at a fraction of the cost. Cutting HERE moves you right and down.

First, stop defaulting to Google. The full cascade beats Google alone in every country we tested, on both cost and quality. There is no defensive argument for "we use Google because it is the best". On this dataset, Google alone is dominated: 73.7% confirmed at $30,000 a year, against 86.3% at $6,336 for the cascade.

Second, if you trim the stack, cut Google before HERE, never the reverse. The instinct when simplifying a cascade is to keep the famous provider and drop the unfamiliar one. On these numbers that is exactly backwards (our Google vs HERE comparison goes deeper on the two). A cascade with HERE removed entirely, OSM then Google, resolves only 81.8% of addresses and costs $12,720 a year, because every address OSM misses falls straight onto Google at $5 per thousand. The full cascade, with HERE absorbing the middle tier at $0.83 per thousand, lands more addresses (86.3%) for half that cost. HERE is the cheap workhorse, not the expendable one. If you want a genuinely lean stack, the right cut runs the other way: OSM then HERE, no Google at all, returns 83.2% confirmed at $2,116 a year. That is 96% of the full cascade's quality for a third of its cost.

Third, Google's last few points are cheap, but their value is concentrated in a handful of countries. Adding Google on top of an OSM-then-HERE cascade buys 3.1 percentage points of quality, from 83.2% to 86.3%, for an extra $4,220 a year, about 2.3 cents per additional correctly resolved address. In absolute terms that is inexpensive, so for a mixed European footprint the full cascade is the right default. But the gain is not evenly spread. In the Czech Republic, Slovenia, Spain, and Slovakia, Google adds under two points and barely earns its place in the cascade. In Portugal it adds fifteen points, in Italy almost six. If your traffic is concentrated in OSM-strong countries, OSM then HERE is enough. If it includes the hard ones, Google stays in.

Fourth, the orchestration logic matters more than the provider choice. A naive cascade that just chains OSM, HERE, and Google without a smart decision rule on when to accept a result will inherit the false positives of the cheaper providers and lose the cost-quality advantage. We showed in the protocol that switching from a label-based decision rule to a textual one moved cascade quality by several percentage points. The provider stack is the easy part. The accept and reject logic is the hard part.

One last point on simplicity, because it is easy to overcorrect. A simple uniform cascade already wins; country-aware routing is the next gain, not a prerequisite. Run the same three providers in the same blind cheap-to-expensive order in every country, and you still beat Google alone everywhere, on both cost and quality. You do not need clever per-country provider selection to capture the bulk of the value. Where country-awareness pays off is the bill: serving the Netherlands from OSM alone, calling OSM then HERE where Google earns nothing, and reaching for all three only where it does, trims cost further without touching quality. That refinement is what we are building. The simple uniform cascade is already the right move today.

What comes next

The biggest open question from this benchmark is the one we sidestepped: how do you decide, at production scale and without a reference coordinate, whether to accept a provider's result? The textual rule we applied here works for a benchmark of 6,000 addresses. At 500,000 a month and up, it needs to be automated, robust to language and formatting variants, and able to catch the failures the textual rule misses: the right street and number but the wrong city, or the correct address pinned a few hundred meters down the road.

Two directions follow from this. The first is the accept-or-reject decision itself. Provider confidence scores and labels are the obvious signal to lean on, and a real question is how far they can be trusted: on Slovak addresses, the providers' own labels flagged correct results as failures. So the more promising path may be external, can a language model flag a bad result from the input and output pair alone, with no reference coordinate, well enough to replace the manual rule? That layer is the missing piece that lets a country-aware cascade run unattended at scale. The second direction sits upstream: most real-world address data is far messier than a national registry, and how much of the geocoding gap closes with input cleaning rather than a better provider is still an open question. Both are what we are looking at next.

Methodology recap

For readers who want to reproduce or audit the analysis:

Dataset: 6,000 residential addresses, 500 per country, 12 European countries, sourced from OpenAddresses (11 countries) and CartoCiudad IGN (Spain). Schema: id, street_name, house_number, city, postal_code, country, country_code, full_address, lat_ref, lng_ref.
Geocoders: OSM via Photon (not Nominatim), HERE, Google. All addresses geocoded once with each, raw outputs preserved.
Validation rule: provider result accepted if (a) latitude returned, (b) house_number from input appears in formatted_address from provider, (c) at least one significant token of street_name from input appears in formatted_address from provider, (d) city or postal_code from input appears in formatted_address from provider. For HERE only, additionally requires confidence_score >= 0.8.
Confirmed hit: accepted result within 100m of the reference coordinate (haversine distance).
Cost basis: Google Geocoding API $5/1k, HERE Geocoding $0.83/1k, OSM via Photon $0 (self-hosted or platform-included).
Cascade logic: blind cascade in production order (cheaper first, expensive last). Each step calls the next only if the current one was not accepted.
Volume normalization: costs reported as annual spend at a workload of 500,000 addresses per month (6 million addresses a year).

The full per-address dataset (6,000 rows, 34 columns) is available on request.

Where to go from here

If you are choosing or trimming a geocoding stack, these pages go deeper on the pieces this benchmark touches:

Provider guides: Google Maps Geocoding API, HERE Geocoding API, Mapbox Geocoding API.
Head to head: Google vs HERE geocoding in 2026.
Country deep dives: France, Germany, Italy, Luxembourg, Portugal, Spain, United Kingdom.

Coordable (Posts about europe)