Google Maps is always right… right?

For developers dealing with geographic information systems, Google Maps represents the industry standard. When you're working on crafting a competing solution, benchmarking against this giant is a logical and necessary step.

We recently integrated a new country-state boundary functionality into our PlaceKit API. To estimate performance, we tested our system against the Google Maps API and encountered unexpected anomalies. A manual review of each discrepancy led to an interesting discovery: we traced all anomalies back to Google Maps, offering a glimpse into its occasionally flawed calculations.

tl;dr: Google Maps showed a 0.006% error rate over 1,000,000 tests, with errors spanning thousands of miles.

Table Of Contents

• A bit of context
• Navigating state boundaries
• Not so close to a state boundary
• The Wild Turkey Run
• Off-course: far beyond state boundaries
• An interstate flight is cheaper than Google Maps API pricing ✈️
• Lost in address translation

A bit of context

A customer required precise geolocation capabilities to determine their users' current country and state at a centimeter/inch precision. This process, known as reverse geocoding, involves submitting geographic coordinates (e.g. 37.768991,-122.475353) to an API, which then returns the corresponding location data:

{ state: "California", country: "USA" }

To ensure accuracy and scalability for our new API, we conducted a comparative analysis against Google Maps API as our validation metric. We compared the state and country data returned by both APIs for the same latitude and longitude coordinates.

Out of 1,000,000 tests conducted, we encountered 60 failures, instances where Google Maps and our API diverged on the state or country returned.

In most cases, this error rate is totally acceptable and insignificant compared to the quality of the overall Google Maps products. Yet, in certain industries like online gambling or specific e-commerce items, the legislation is very strict making data accuracy crucial for business viability (e.g. get the user geolocation for an online casino app).

Legality of gambling types per US states (wikipedia)

For each of these failed tests, we manually investigated which API was wrong and why.
In all 60 tests, it was discovered that Google Maps was incorrect.

To perform those tests, we used Google Maps and PlaceKit reverse-geocoding endpoints, comparing administrative_area_level_1 / administrative and country attributes. For clarity, red pins on screenshots mark the coordinates used for the tests.

👉 Checkout Google Maps API responses using the links provided under each screenshot.

Let's dive in a few examples.

Navigating state boundaries

👉 Google Maps API response & Google Maps UI

Coordinates   📍 39.719947,-77.505964
Google        ❌ Maryland
PlaceKit      ✅ Pennsylvania
Error dist.   ⚠️ 5m - 16ft

The map clearly illustrates the demarcation of state lines with our coordinates pinpointed accurately. The Google Maps interface displays the correct location —yet, the Google Maps API returns a mismatched state only meters away.

Because the house is spanning over two states, the first result of type street_address from the API is pointing to the closest street, placing it inaccurately in Maryland. We also notice that Google Maps UI uses this erroneous record.

Adding a filter result_types=administrative_area_level_1 to the request yields the correct state. However, as a developper using a reverse-geocoding API, results are misleading as you are expecting the first result to be on the exact coordinates and not snapping to the nearest street. The goal is to identify the state associated with the coordinates provided, not a postal address to send them Black Friday gifts.

Enough nitpicking, let’s see how far this can go.

Not so close to a state boundary

👉 Google Maps API response & Google Maps UI

Coordinates   📍 30.30439,-93.74216
Google        ❌ Texas
PlaceKit      ✅ Louisiana
Error dist.   ⚠️ 167m - 548ft

In this scenario, the coordinates fall within Louisiana's borders, yet the Google Maps API erroneously identifies the location as Texas.

In reverse geocoding queries, the first result might be an interpolation, potentially deviating from the developers' expectations.

While not directly Google's fault, it can be misleading for developers assuming the first result is the most accurate and should directly match the coordinates provided. This could be considered a user experience issue with the API. Developers who don’t take this into consideration could introduce errors into their applications.

Key Takeaway: When extracting state or other attributes for a given set of coordinates, don't blindly use the first result as it might not be what you expect. Instead, add a search param political or administrative_area_level_1 to get the exact state the coordinates are in, and avoid the trap of street interpolation.

Did you notice the conflicting information in the screenshots above? The formatted address mentions "Orange, Texas 77632, USA" while Plus Code indicates "8735+Q54 Starks, Louisiana, USA".

Could Plus Codes offer a better accuracy? Let's explore this possibility.

The Wild Turkey Run

Fort Campbell is a military base located across Kentucky and Tennessee. According to Wikipedia:

While the headquarters and a great majority of the base's acreage was in Tennessee, the base's post office was in Kentucky. After many months of mail delivery problems, Colonel Guy W. Chipman requested that the address be changed to Camp Campbell, Kentucky. The War Department officially changed the address on September 23, 1942.

Alright fair enough, but we still want to know in which state are the coordinates, no matter what the postal address is. Gimme gimme the state!

👉 Google Maps API response & Google Maps UI

Coordinates   📍 36.60434,-87.46664
Google        ❌ Kentucky
PlaceKit      ✅ Tennessee
Error dist.   ⚠️ 4km - 2.5mi

The query returns an address on "Wild Turkey Run, Fort Campbell, TN 42223, United States," situated in Tennessee. However, Plus Code "JG3M+M8 Fort Campbell, Kentucky, USA" points to Kentucky.

This is confusing. Technically, the coordinates are in Tennessee, but the Plus Code introduces confusion by indicating Kentucky while the street_address provides the wrong postal state according to the military chief. Earlier in this post we assumed that since Plus Codes are founded on pure geographic coordinates without reliance on street data it would would help us avoid such errors. Here it misleads by several miles… Is there any accurate way to get the correct geographic state?

Interacting with the map, random locations around the base yield different states, snip-snap, snip-snap.

Is this example just odd because of the military base scenario? Let’s check out on civil grounds.

Off-course: far beyond state boundaries

👉 Google Maps API response & Google Maps UI

Coordinates   📍 35.07361,-85.24068
Google        ❌ Georgia
PlaceKit      ✅ Tennessee
Error dist.   ⚠️ 10km - 6mi

This one is just wrong. The API returns the address "3307 Alabama Hwy, Chattanooga, GA 30165, USA" whereas there is no Alabama Highway in Chattanooga and anyway, Chattanooga is in Tennessee. The closest Georgia boundary point is 10km / 6 miles away!

Digging on this odd result, we found that "3306 Alabama Hwy" is at the very end of the highway, which is set in Tennessee state, 20km - 13 miles away from the given coordinates.

Google Maps UI

This anomaly looks like an interpolation error by Google’s geocoder, suggesting that their system could extend a road improperly into another state.

• Note: what is street number interpolation?

  It's a method used to guess the location when a precise match is not available in the database. Let's say we have the data for 3305 and 3309 but a user searches for 3307. We can either return a no result (strict address validation) or estimate that 3307 is probably equidistant between 3305 and 3309 and compute the coordinates based of these two data points. Seems simple at first, but you have to consider the physical geometry of the road (not always a straight highway), terrain elevation, varying street number conventions across countries, etc.

Let’s be clear: in this scenario, we didn’t perform a forward geocoding query — give me the coordinates for "3307 Alabama Hwy, Chattanooga, GA 30165, USA". We performed a reverse geocoding query — give me the street name for coordinates 35.07361,-85.24068. Street number interpolation should not have kicked in, and should not have returned a result miles away.

We would expect a reverse geocoding request to accurately pinpoint the state corresponding to specific coordinates, rather than approximating it based on nearby street numbers.

Key Insights:

• Our initial assumption about snapping to the closest known street for given coordinates is incorrect.
• Our second assumption about Google Maps using the first result of the API is also inaccurate.
• Google Maps does not directly use the reverse API or might apply additional post-processing to the data obtained.

An interstate flight is cheaper than Google Maps API pricing ✈️

👉 Google Maps API response & Google Maps UI

Coordinates   📍 41.83021,-87.62679
Google        ❌ Utah
PlaceKit      ✅ Illinois
Error dist.   ⚠️ 2000km - 1260mi
Round trip    ✈️ 109€ - $118

How can a reverse geocoding query be thousands of miles off?

Let's zoom in 41.83021,-87.62679 and the returned corresponding address "3520 S State St, Salt Lake City, Utah 84115, USA", despite the true location being Chicago in Illinois.

Using Google Maps directly with these coordinates takes us to the correct place in Chicago, however, the API response tells a completely different story.

Chicago, via 41.83021,-87.62679

Salt Lake City via the returned address

Can you spot the pattern in the screenshots above?

41.83021,-87.62679 points to the building 3520 which closest street is "S State St". Whereas the first API result is "3520 S State St, Salt Lake City, Utah 84115, USA".

For an unknown reason, it mixes up neighborhood information from Chicago with the locality and administrative level data from Utah — an erratic merging of geographic data that disregards the actual provided coordinates:

{
  "neighborhood": "Park Boulevard",            // ❌ in Salt Lake, ✅ in Chicago
  "locality": "Salt Lake City",                // ❌ 
  "administrative_area_level_1": "Utah",       // ❌
  "administrative_area_level_2": "Cook County" // ✅
}

It appears that the API might be following this process:

1. Takes the coordinates and identifies the nearest building + street address.
2. Performs a textual best match query across its datasets.
3. Returns the first record, mixing up the fields from different locations.

Shifting the coordinates slightly away from the problematic building number yields accurate results in Chicago. Attempts to duplicate this issue with address numbers common to both cities did not reproduce the same mistake.

This case highlights a unique flaw where the API logic appears to disregard the geographic context in favor of the closest textual match in their database, causing a severe drift in expectations.

Lost in address translation

👉 Google Maps API response & Google Maps UI

Coordinates   📍 29.67213,-95.27028
Google        ❌ GA
PlaceKit      ✅ Texas
Error dist.   ⚠️ 1100km - 700mi
Flight time   ✈️ 1h50

As in the previous example, the street number and street name matches exactly in another state. The coordinates are located in Houston, Texas, but the API astonishingly returns an address in Georgia, a distance of about 1100 kilometers (700 miles) away. It seems like the mail sent to this particular Houston address might encounter some logistical issues.

We identified another inconsistency in the way Google Maps API handles state names:

{
    "long_name": "GA",
    "short_name": "GA",
    "types": [
        "administrative_area_level_1",
        "political"
    ]
}

Here, the API improperly cites GA as the long_name for the administrative area level 1—where it should be the full name, Georgia. While it's a relatively minor error and easy to resolve, it could cause complications if a system relies on the full state name for an exact match.

Developers using geocoders must be aware of potential data anomalies and plan accordingly to ensure accurate results, especially when handling critical applications like package deliveries.

Wrapping up: navigating through imperfect data

What can we learn from these tests?

Google Maps !== Google Maps API —what you see on Google Maps is not what you will get via their API. And Plus-Codes seems to be using a different dataset, sometimes contradicting itself in the same record.

Our test suite is mainly located in the US but we can extrapolate that the errors detected are also present worldwide. We’ve only tested the accuracy at a high level (state), who knows what could be found by running tests at street level?

Geographic Information System (GIS) is hard work. It’s impossible to get it 100% right. While Google Maps remains a powerful and widely-used tool, these examples serve as a reminder that all geocoders have their shortcomings. From minor inaccuracies along state boundaries to significant misdirections covering thousands of miles, these are not just theoretical errors—they can have real-world implications, potentially impacting businesses applications where location accuracy is key.

Our new country-state boundaries API is available on demand. PlaceKit offers a cost-effective geocoding API with 10k free requests per month and pay-per-request pricing.