Geocoding is intended to make spatial data more useful. But in many Geographic Information System (GIS) workflows, “good enough” geocoding quietly creates downstream problems that are expensive, time-consuming, and difficult to spot until something breaks.
If you work in local government, utilities, or infrastructure management, you’ve probably seen it happen. A batch geocoding job comes back with an impressive match rate, points populate the map, and everyone moves on. Later, routing fails, inspections are assigned incorrectly, or risk models start producing questionable results.
The culprit is often a Locality match.
Understanding how to identify and prevent Locality matches has become increasingly important. As geocoding workflows become more tightly connected to routing, analytics, automation, and usage-based pricing models, low-precision matches can affect operational efficiency, map accuracy, and overall geocoding costs.
Geocoding is a technical step, but it’s also a line item. With credit-based (Esri) and transaction-based (HERE) pricing models, every low-precision match carries a cost.
Whether usage is measured in credits or transactions, paying for coordinates that are technically successful matches but operationally inadequate creates economic friction for GIS workflows.
The gap between exact PointAddress matches and vague Locality matches is a silent failure when precision is the gold standard. For workflows like last-mile delivery, utility and infrastructure management, emergency response planning, and property permitting, a city-level match may technically return a result while still lacking the precision needed for reliable operations.
For example, if a utility company geocodes a work order to a generalized city-level location instead of the actual service address, the map point may appear valid while being inadequate for the workflow: the routing engine generates an inefficient or misleading route and the field crew wastes time locating the asset.
For cases like this, PointAddress or Subaddress precision is the real goal. A city-level centroid is often just a placeholder disguised as a meaningful match.
A Locality match typically happens when the geocoder cannot confidently identify the full address. Rather than returning no result, many locators “zoom out” to a broader geographic level.
That hierarchy progresses from precise to general:
SubaddressPointAddressStreetAddressStreetNamePostalLocalityFallback cases may be identified by reviewing the Addr_type field directly in your attribute table. If the field returns values like “Locality” or “Postal” instead of “PointAddress” or “Subaddress,” the locator likely fell back to a broader geographic match.
Locality matches tend to pile up at city or ZIP centroids, creating artificial “data piles” that can skew heatmaps and dashboards. In routing workflows, those same clusters can cause routing engines to build routes around generalized locations rather than actual destinations, leading to inefficient sequencing and unnecessary overlap.
In other words, the fallback ensures a result is returned, but not necessarily one that solves the operational need.
Fortunately, there are ways to reduce Locality matches before they become operational problems.
One of the most effective strategies is filtering by category during the geocoding process. In ArcGIS Pro/Online workflows, category parameters and Locator Properties settings can be configured to exclude broader Postal or Locality results and prioritize PointAddress and Subaddress matches.
Many GIS teams leave default geocoding thresholds untouched, but raising the Minimum Match Score and Minimum Candidate Score can force questionable results into an unmatched state instead of allowing low-precision coordinates through the workflow.
That may sound counterintuitive, but operationally, it’s often better to have an "Unmatched" record you can manually fix than a "Locality" match that looks correct but isn't.
In many organizations, the default geocoder works well—most of the time. But as workflows scale or precision requirements increase, relying on a single provider can become limiting.
That’s why many modern GIS workflows now use a “primary” and “failover” service. If the default geocoder doesn’t hit a PointAddress level, the workflow automatically pings a high-precision secondary geocoding service.
For organizations handling complex international addressing, HERE Geocoding & Search improves consistency across countries and address formats. Another advantage is its strong “rooftop” precision, which helps workflows resolve locations to the actual building or address point.
HERE's flat-rate transaction model can also help reduce budgeting uncertainty associated with high-volume batch geocoding. Unlike credit-based pricing structures that can make the cost of large jobs or repeated retries difficult to predict, the HERE model provides more consistent and predictable scaling as geocoding volumes grow.
Different providers may be a better fit for different operational needs.
Open-source-focused platforms like OpenCage may be practical for lightweight workflows, internal projects, or organizations looking to support lower-volume geocoding needs without enterprise-level licensing costs.
A localized provider like Geocodio can perform well for organizations focused specifically on U.S. and Canadian addressing workflows, where a narrower regional focus makes a specialized provider sufficient.
One of the most common geocoding mistakes organizations make is celebrating overall match rate without auditing match precision.
A 98% match rate sounds impressive until you discover that a meaningful percentage of those results are Locality matches rather than PointAddress matches.
A better audit framework compares:
PointAddress precision rateSubaddress precision rateLocality fallback percentageViewed together, these metrics provide a clearer measure of geocoding quality than overall match rate alone.
Input quality also plays a major role in precision outcomes. Address normalization remains one of the simplest ways to improve geocoding quality before requests ever reach the locator.
Quick fixes like standardizing “St” versus “Street” can help locators succeed on the first pass. Standardizing directional prefixes, ZIP formatting, and unit information also helps reduce the need for the locator to fall back to broader Postal or Locality matches and improves match precision.
Locality matches can appear usable at first glance, making them easy to accept as valid results. But as routing, analytics, and automated GIS workflows become more interconnected, generalized city- or ZIP-level matches can fall short of the precision needed to support reliable decision-making.
The goal is not just “getting a match.” It’s getting the right match.
Organizations that build precision auditing, appropriate performance thresholds, and flexible geocoding workflows into their location intelligence are better positioned to reduce downstream errors and improve routing accuracy while avoiding the cost of low-value geocoding results.