IssueTracker

Yes please :) Along with a more specific definition of how the Popular Times are determined (how much history? done by mobile device activity? check ins?)

Making popular times available by day of the week would be awesome

It already is Jeffrey, you can toggle by day on mobile or desktop

I've also run into this issue on sites that use this Geocoding API. As comment #4 says, 'Liverpool' is a unambiguous address in the UK. We are running the query with the region parameter set to 'uk' (I've also tried 'gb', neither works).

We are using this service as part of a stack to inform one of our search utilities - the search input we are using is a free-text field so we can't reasonably expect every single user to input 'Liverpool, UK' when 'Liverpool' should suffice.

This is clearly not intended behaviour - please review.

@r22, I think Jeff is referring to the ability to split popular times by day of week in the information released by the API, not the currently existing web GUI.

Maybe the info appears as a nested object? e.g. "popular times" > "day of week" > "hour of day" > traffic count

In case this helps, I did a bit more checking after reading #4's mention of putting in "Liverpoo". Liverpo, and Liverpoole also work. I think there is just an incorrect city entry somewhere in the database it's using.

Just chipping in another penny, same issue for us too. Like the rest of you we too do include "UK" in the address component so I too would agree this is a glitch on Google's part.

Chipping another penny on this issue, while I do understand "Geocoding API works best when handling full, unambiguous addresses in the standard format used by the postal service in your country.", the behavior Geocoding API has with the city of Liverpool in particular is peculiar when compared to other cities like London, Leeds or even Paris which could very well be confused with Paris, Texas.

I understand this could be due to the fact that there are far more locations and retail stores with the same name (leaning more into the retail stores), and that for cases where there are more than one possible results the expected result is ZERO_RESULTS, but wouldn't it be great if for ambiguous cases like this we took into account popularity of each location and limit to cities and not business places? I am assuming a mechanism of those sorts is already in place, as there most be a reason why Merida geocodes to the state in Mexico and not in Spain where the name originally came from.

Would be extremely helpful to have access to this data directly via the API.  Is it maybe available via another API?  

No update on here for a while now... Any news on making this available ?

Hi, just to add we are also suffering from this.

I definitely don't think it is intended behaviour, unless we're using the Autocompletion API and GeocodeService API incorrectly.

A user types, we use the Autocompletion API to return results we display in a dropdown, and then we use the GeocodeService to get the final response based on what option they clicked.

When you do this with "liverpool" you get:

https://maps.googleapis.com/maps/api/place/js/AutocompletionService.GetPredictionsJson?1sliverpool&4sen&5sGB&7scountry%3Agb&15e3&21m1&2e1&callback=_xdc_._fahsef&key=<API_KEY>&token=125288

This will list the JSON response, of which item .predictions[1].description is "Liverpool".

So we do a lookup to the GeocodeService for "Liverpool":

https://maps.googleapis.com/maps/api/js/GeocodeService.Search?4sliverpool&7sGB&9sen&callback=_xdc_._10pnpk&key=<API_KEY>&token=87473

and recieve:

```
{
   "results" : [],
   "status" : "ZERO_RESULTS"
} ```

We'd love a fix for this.