The hidden costs of implementing geocoding services: retention limits, field mapping, and TERYT compliance - comparing 10 services

Once a service standardizes and geocodes addresses well, the implementation question remains: how do you integrate it with your own systems? At that point, several things matter - whether it offers a batch mode for large volumes, whether the licensing terms let you persist the results in your company's systems, and whether it returns TERYT-compliant identifiers and a stable point identifier. Two things hinge on this: whether the corrected address can be stored and reused at all, and how good a key it turns out to be for linking data.

In this article, we look at how 10 different standardization and geocoding services compare on integration, and what to watch for before you choose a provider.

Why an address key's durability depends on integration, not just quality

In most processes, the address acts as an identifier - it's what we use to link a customer to their order history, a complaint, or a risk assessment. But for it to play that role, the standardized address and its location have to reach the company's systems and stay there (in the data warehouse, the CRM, the operational record). A geocoding result you aren't allowed to store, or one that can't be mapped unambiguously onto the Polish address model, won't be a durable key - no matter how precisely it's pinpointed.

That's why the report ranks the services not only by geocoding and standardization quality, but also by five characteristics that translate directly into integration architecture:

• Integration model - whether access is via REST API, a web app, or an enterprise platform (often on-premise);
• Batch processing - whether the service handles many addresses at once, which is critical at high volumes;
• Result retention - whether the license terms let you persist the result in your company's systems;
• TERYT compliance - whether the service returns names and identifiers consistent with the Polish register;
• Point identifier - whether the service returns a stable identifier you can base data linking on.

Service	Integration	Batch processing	Result retention	TERYT compliance	Point identifier
Data Quality	Web app + REST API (online)	Yes - batch and online	Result caching allowed	Names and IDs consistent with TERYT	Yes - time-stable address point ID
Google	REST API	Client-side	Lat/lng caching capped at 30 days	No ID; partial name match	Yes - Place ID within the Google ecosystem
HERE	REST API	Yes - Batch API v7 (job)	Depends on plan	No ID; partial name match	Yes - object ID
Azure Maps	REST API	Yes - batch search	Depends on Azure terms	No ID; partial name match	Yes - address ID
TomTom	REST API	Yes - Batch Search API	Depends on TomTom terms	No ID; partial name match	Yes - address ID
Mapbox	REST API	Client-side	Temporary: no / Permanent: indefinitely	No ID; partial name match	Yes - address ID
Esri	REST API	Yes - batch geocoding	Depends on license / credits	No ID; partial name match	Yes - address ID
Precisely	Enterprise platform (often on-prem) + services	Yes - enterprise / bulk	Depends on deployment model	No ID; partial name match	Yes - address ID
Emapa	API	Yes - on the integration side	Depends on license	No ID; partial name match	No
Locit	API	Yes - batches (as stated)	Depends on license	Names and IDs consistent with TERYT	Yes - building ID

A comparison of 10 services on integration - based on the report “Address as the primary key for linking data.”

Are you allowed to store what you paid for?

Not every provider lets you store the coordinates and the standardized address permanently - and without that, an address can't become a durable key.

Google is the most restrictive here. The Google Maps Platform terms explicitly cap latitude and longitude caching at 30 days. Mapbox distinguishes between “Temporary” and “Permanent” results - only the latter can be stored and used long-term. With HERE, Azure, TomTom, Esri, Precisely, Emapa, and Locit, whether you can store the results depends on the plan, license, or deployment model. Our Data Quality service allows result caching.

If the license doesn't allow you to persist the result, every reuse of the address means another call to the service. That adds query costs and ties your process to the provider and its availability. An address you have to geocode from scratch every time is, by definition, not a stable key.

TERYT compliance and a stable point identifier - why they matter and how the services perform

If an address is going to link records across systems, you need a stable point of reference. It rests on two elements.

The first is compliance with the TERYT register - the official register of Poland's territorial division. It covers the components of an address: localities, streets, and administrative units (municipality, county, voivodeship). TERYT codes are unique nationwide and provider-independent, so they let you normalize an address and join and aggregate data at the street or municipality level. Only Data Quality and Locit return them. The other services - Google, HERE, Azure, TomTom, Mapbox, Esri, Precisely, and Emapa - don't return TERYT identifiers and preserve only partial name matching.

TERYT doesn't go down to the building level, though - “Kwiatowa 1” and “Kwiatowa 15” in the same locality share the same set of identifiers. Telling one specific address from another is the job of the second element: a stable point identifier. When it's stable over time, the same building always gets the same identifier, which lets you link and deduplicate records without re-geocoding. Google provides an identifier that works only within its own ecosystem (a key tied to a single service), Data Quality provides a time-stable address point identifier, Locit a building identifier, and Emapa doesn't return one at all.

The two elements complement each other. TERYT organizes the address at the street, locality, and municipality level, while the point identifier pinpoints the specific building. The strongest key comes from a service that provides both - in our comparison, that's Data Quality and Locit.

Field semantics - the hidden cost of integration

Even when a service returns a complete set of data, how useful it is depends on how well it aligns with the Polish addressing model. This is the biggest problem for global services, where Polish administrative concepts end up mapped onto different fields - forcing extra work on the client's side.

• Esri - the “City” field often behaved like a municipality name (sometimes with the word “gmina” appended), while the “District” and “Nbrhd” fields were populated inconsistently, making it hard to build a stable key.
• Azure Maps and TomTom - the municipality and municipalitySubdivision fields can mean a municipality, a locality, or a district, and are sometimes empty. Both services occasionally return several values (e.g., postal code, locality) separated by commas in a single field, which complicates building a key automatically.
• Google - no municipality in the administrative model, voivodeship and county names that don't match TERYT notation, and no parsing of the apartment number into a separate field. In some cases, the text result looked correct while the coordinates pointed to a different building.
• HERE - it's ambiguous whether the “city” field holds a locality or a municipality, and the “district” field was used in both senses. We also saw cases of altered building numbers despite a declared high match.
• Mapbox - performed weakest in areas specific to the Polish model, including the presence of a municipality in the API response and the handling of localities that aren't divided into streets.
• Precisely (Spectrum) - ambiguous field semantics and no TERYT-compliant name standardization; in localities without streets, the service wrongly duplicated the locality name in the street field, leading to redundant data.
• Emapa - closer to Polish realities in its administrative breakdown, but with no clear match-quality score; it didn't return TERYT codes or parse the apartment number.
• Locit - represents the administrative breakdown and the full address (including the apartment number) correctly, and returns TERYT identifiers. Two things caught our attention: messages about gaps in the building reference data even at the highest geocoding level, and the copying of input values into the standardized fields when there's no match - which, in an automated pipeline, risks locking in bad data as “standardized.”
• Data Quality - full TERYT compliance, returned identifiers, a time-stable address identifier, and caching support. The service currently covers Poland and selected Central European countries (including the Czech Republic, Slovakia, Romania, and Hungary), though it offers the widest range of returned data and the highest match and geocoding quality for Poland.

Any standardization that requires extra mapping and normalization logic on the client's side is a real implementation cost - rarely visible in the price list, but felt during integration and maintenance.

What to watch for when choosing a service

• Check the storage terms before you choose a provider. Establish whether the license lets you persist the result, and for how long. A restriction like “cache for 30 days,” or a split between “temporary” and “permanent” results, can rule out any plan to build a permanent address key.
• Anchor to the register if the address is meant to link data. TERYT-compliant identifiers and names give you a stable reference point that isn't tied to a single service. In our study, only Data Quality and Locit provided them.
• Factor in the cost of field mapping. With global services, the semantics of administrative fields can be ambiguous - budget time for the work of normalizing the result to the Polish addressing model.
• Verify batch mode against your volume. Most services support batch processing, but with some (e.g., Google, Mapbox) it's handled client-side, which changes the integration architecture at scale.

Accessing the report

The full report - including a comparison of the services across the remaining dimensions (standardization and geocoding quality, and how much to trust providers' own quality labels) and a spreadsheet simulating the added cost of the services for 100,000 shipments a year - is available free of charge at this link. If you have questions or would like to discuss the findings, feel free to get in touch.