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