Assigned
Status Update
Comments
ma...@google.com <ma...@google.com>
ma...@google.com <ma...@google.com> #2
Thanks for the post!
Geocoding API works best when handling full, unambiguous addresses in the standard format used by the postal service in your country. For much better result, we suggest that you use the complete address for Liverpool, UK. For example:
ia...@addedlovely.com <ia...@addedlovely.com> #3
Believe the integration we are using ( is 3rd party code ) is setting the region parameter to GB.
Would that not negate the requirement for 'UK' to be stipulated in the address string?
Also seems strange that other address searches return a result, regardless of country being in the address e.g. Birmingham - still returns a result.
A search for Birmingham with no region - returns Birmingham Alabama. With the region parameter set, returns Birmingham UK.
Literally seems that just 'Liverpool' returns no result, regardless of the region parameter being set.
Would that not negate the requirement for 'UK' to be stipulated in the address string?
Also seems strange that other address searches return a result, regardless of country being in the address e.g. Birmingham - still returns a result.
A search for Birmingham with no region - returns Birmingham Alabama. With the region parameter set, returns Birmingham UK.
Literally seems that just 'Liverpool' returns no result, regardless of the region parameter being set.
ti...@heliosx.co <ti...@heliosx.co> #4
This is quite clearly not the intended behaviour. "Liverpool" is a UK postal city, i.e., it is already an "unambiguous address in the standard format used by the postal service in your country." Furthermore, searches which are partial matches, e.g. "Liverpo" (without UK) returns the result for the Liverpool locality.
da...@cancer.org.uk <da...@cancer.org.uk> #5
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.
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.
ja...@james-sparling.com <ja...@james-sparling.com> #6
And I third or fourth this. Please don't fob us off with intended behavior nonsense. It is a clear glitch. I am using it it for find a place near a place within a range and it works fine for every other part of the country (and the search is limited to the UK/GB). This was reported in April of last year (2022) and no-one seems to have decided it's worth looking into.
Please help us!
Thanks
Please help us!
Thanks
ja...@james-sparling.com <ja...@james-sparling.com> #7
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.
ad...@webboxdigital.co.uk <ad...@webboxdigital.co.uk> #8
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.
zu...@google.com <zu...@google.com> #9
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.
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.
pa...@google.com <pa...@google.com> #10
For the information of the engineers: 281807863
This issue seems to be reporting something similar with the region parameter.
region 'US' and returning Birmingham UK as top result instead of Birmingham Alabama.
The customer mentions that it was working a few months ago
This issue seems to be reporting something similar with the region parameter.
region 'US' and returning Birmingham UK as top result instead of Birmingham Alabama.
The customer mentions that it was working a few months ago
ed...@gmail.com <ed...@gmail.com> #11
Ok.
edmilsonpereira990@gmail.com
Em sex, 26 de mai de 2023 05:39, <buganizer-system@google.com> escreveu:
edmilsonpereira990@gmail.com
Em sex, 26 de mai de 2023 05:39, <buganizer-system@google.com> escreveu:
da...@yunojuno.com <da...@yunojuno.com> #12
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.
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:
This will list the JSON response, of which item .predictions[1].description is "Liverpool".
So we do a lookup to the GeocodeService for "Liverpool":
and recieve:
```
{
"results" : [],
"status" : "ZERO_RESULTS"
} ```
We'd love a fix for this.
Description
----------------
When searching for liverpool, we get ZERO_RESULTS returned.
URL:
Can also replicate this on your documentation page:
And possibly on Google Maps itself, where only retail stores with Liverpool in the name are returned, not cities.