Google Maps reverse geocoding API can be a thousand miles off | Hacker News Reader

Google Maps reverse geocoding API can be a thousand miles off

placekit.io

35 pointsraphi30 comments

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

> 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.

That sounds way less dramatic as the headline makes it out to be.

Maybe this is why when people geolocate my home IP, it places me a hundred miles from where I am in a completely different city.

I love that it does that.

Right? I used to use t-mobile home internet and sometimes I'd be geolocated to Detroit or Baltimore or Wichita etc etc. It was wild haha caused problems at times too because retail sites thought I was in a different place entirely.

Depending on which IP stack you're using, this is possibly due to their CGNAT config or an inaccurate geoIP database (Maxmind, etc).

https://community.t-mobile.com/troubleshooting-38/nat-forwar...

This would probably be due to GeoIP databases being wrong/inaccurate rather than GPS coordinates mapping to invalid addresses.

You are correct. There are a few websites you can use to see what various providers have your geo-ip result as. This is one I use and a few of them are very wrong:

https://www.iplocation.net

I work for IPinfo and let me go off on a tangent here. We use our own infrastructure system to probe IP addresses and determine geolocation. This system is based on technology similar to GPS satellites (ping and check RTT from multiple servers).

Other providers mostly rely on WHOIS data and other public databases. These sources are not very accurate and often contain stale data because the IP range geolocation reporting mechanism for ISPs is mainly voluntary.

Sometimes, even though an IP address is pingable and we have evidence of the round trip time, the majority of providers will indicate one location while we indicate another. So, who is correct in this situation? Is it the majority or us?

If someone needs to verify the location of an IP, I usually recommend visiting that site first. If there are any discrepancies, I recommend pinging the IP address and checking the WHOIS records.

For a while my location would always show up as the same city as my ISP's main office, 800km away. Good times!

This has absolutely nothing to do with reverse geocoding

I work for an IP geolocation company and precision isn't the main goal of IP geolocation. Accuracy is the main goal. IP geolocation needs to be precise enough on a city or zip code level at best. If precision is the goal, IP geolocation is not a drop-in replacement for GPS geolocation.

Open Street Map FTW... (Google said Texas, Louisiana is the correct state)...

https://nominatim.openstreetmap.org/reverse?format=json&lat=...

{ "place_id": 344147672, "licence": "Data © OpenStreetMap contributors, ODbL 1.0. http://osm.org/copyright", "osm_type": "way", "osm_id": 59390991, "lat": "30.304411869782914", "lon": "-93.74218940151427", "class": "place", "type": "house", "place_rank": 30, "importance": 9.999999994736442e-8, "addresstype": "place", "name": "", "display_name": "5289, LA 12, Lunita, Starks, Calcasieu Parish, Louisiana, 70661, United States", "address": { "house_number": "5289", "road": "LA 12", "hamlet": "Lunita", "village": "Starks", "county": "Calcasieu Parish", "state": "Louisiana", "ISO3166-2-lvl4": "US-LA", "postcode": "70661", "country": "United States", "country_code": "us" }, "boundingbox": [ "30.3043619", "30.3044619", "-93.7422394", "-93.7421394" ] }

> A customer required precise geolocation capabilities to determine their users' current country and state at a centimeter/inch precision

Per-inch precision? Seems doubtful

It's hard to imagine a legitimate use case for that. Sounds like the intention is that the target will soon not be anybody's customer.

They're using this API to sell gambling services, but they're apparently required to check that it's legal for the user to gamble.

Unrelated, I hate how GIS systems built on text search are turning geometry problems which are easy to reason about into unpredictable database problems.

> 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.

The fact that the first Google autocomplete for the address "3520 S State St" happens to be the State St. in Utah, not Illinois, has absolutely nothing to do with whether the lat/lon coordinates (41.8,-87.6) are in the geographical boundary which describes Illinois and Utah.

Personally I wish I could get accurate property lines using my phone instead of hiring a surveyer.

I've heard people want such precision for proximity based services, like buying something from a vending machine in front of you by solely interfacing with your location instead of establishing a link to it.

Those already exists, but people always want it to be more precise since then you can put them more densely.

It could be that they mean "our API should accurately determine the country and state given arbitrary lat/lon coordinates with 6 decimals of precision", which sounds fair to me. With 6 digits, you are looking at centimeter/inch precision. I agree that the wording does sound off though.

That just means the question is "why do you need 6dp of precision?" which boils down to the same question.

Google Maps was never the solution for this lol

While useful, Google Places API can be really weird at times. One weird caveat that we identified at work is that this list is supposed to be a documentation of all possible place types: https://developers.google.com/maps/documentation/places/web-...

yet we have polled this endpoint and have received the place type "supermarket_or_grocery" which is not documented there. Fun!

This is just an ad for PlaceKit. A more complete and tasteful article would have also compared Mapbox, HERE Maps and ESRI, and I assume the latter two would provide slightly better results.

It's also a good reminder that folks can often do a better job by specializing on a specific problem than trying to solve the world. It's not surprising to me that a service that specializes in geocoding does a better job at geocoding than a service that does consumer-facing maps, driving/transit/walking directions, place reviews, geo-driven advertisements, etc.

I guess Google wasn't happy with this article, when clicking on the API examples...

{ "error_message": "Google has disabled use of the Maps API for this site. Learn more: http://www.google.com/help/terms_maps.html", "results": [], "status": "REQUEST_DENIED" }

Author here: indeed :/ The quota on the API key is still OK but they blocked it. You can replaced the API key in the URL directly with your own to see the response.

I used to work for a division of State Farm insurance which ran into some similar issues with addresses on or close to state lines. Insurance is also one of those businesses that's very particular about location, as we were only approved to do business in certain states.

The solution we ended up going with was to use the free Tiger shape files from the US Census (https://www.census.gov/geographies/mapping-files/time-series...), which enabled us to statically "lock" our geocordinates. Apart from filing our approach and getting it approved, the logic was that we could always point back to it being a government database if there was ever a problem.

Is it possible to search without being constrained to one country? The landing page search demo would be more impressive.

Because my typical first test for geocoding SaaS is to search for Paris and see if they get the continent right.

wow, just did this test aswell and the 5 results it showed were everything from all over the world except for the actual Paris

Author here: nope it's not possible for address search to target all countries (but there is an option to add multiple countries if necessary). It's a take on our part to provide more relevant results to the end users. By default, the end user is pre-located via IP first and can change its country if necessary, which works well in most cases. There are so many matches possible for address search that it reduces the relevance of the top 5 results. Also, there is the option of world cities available (no constraint on countries but cities only).

well, yeah. addresses change, or can share similarities with other addresses; maps change; and then all the problems related to scraping public data and maintaining databases with the latest changes: stale data, incorrect data, matching fuzzy inputs to exact addresses, regional differences in spellings & geographical representation, and more.

if you're doing this at scale, geocoded data needs to verified against multiple sources. even then, you'll probably still need a human in the loop to catch edge cases.

these kinds of edge cases would be my worst nightmare to work on

Reply on news.ycombinator.com