IssueTracker

Hey Martin,

Can you please supply a sample along the lines of https://github.com/domesticmouse/MovingMarkerPosition that demonstrates the behavior you are seeing? Thanks!

Hi Brett,
Here you go,
https://github.com/farfromrefug/OverlappingMarkers

Thank you for reporting this, already 4 other reports in this issue tracker, I'm picking this one because it has most comments.

There is an issue in the Geocoding API, whereby reverse geocoding a latlng that is far away from precise results will often produce a sublocality_level_3 result in Japan. We are working on a fix.

The best solution is to never depend on the ordering of reverse geocoding results.

It is highly recommended to always inspect the "types" array of results before using them.
Each use case of reverse geocoding will generally require results of a limited set of types, e.g. ["premise", "street_address", "route"] when looking for street-level addresses.

Applications that already implement this strategy will not be affected by the current issue.

While reverse geocoding results are generally ordered from more to less precise, this ordering is not guaranteed there may be exceptions. Relying on any specific ordering of results is risky and highly discouraged.

Alternatively, restricting reverse geocoding results via the result_type or location_type paramters can also be used to workaround the current issue:

https://maps.googleapis.com/maps/api/geocode/json?&latlng=0,0&result_type=street_address&key=YOUR_API_KEY
https://maps.googleapis.com/maps/api/geocode/json?&latlng=0,0&result_type=route&key=YOUR_API_KEY

https://maps.googleapis.com/maps/api/geocode/json?&latlng=0,0&location_type=ROOFTOP&key=YOUR_API_KEY
https://maps.googleapis.com/maps/api/geocode/json?&latlng=0,0&location_type=RANGE_INTERPOLATED&key=YOUR_API_KEY
https://maps.googleapis.com/maps/api/geocode/json?&latlng=0,0&location_type=ROOFTOP|RANGE_INTERPOLATED&key=YOUR_API_KEY

This workaround may be easier to implement in some cases, but in no case replaces a proper strategy to never depend on the ordering of reverse geocoding results.

To learn more about these restricts, please see
https://developers.google.com/maps/documentation/geocoding/intro#reverse-restricted

I guess this result comes up because the bounds for this location include the whole world:

"formatted_address" : "1 Chome-11 Kamifukubara, Yonago-shi, Tottori-ken 683-0004, Japan",
         "geometry" : {
            "bounds" : {
               "northeast" : {
                  "lat" : 90,
                  "lng" : 180
               },
               "southwest" : {
                  "lat" : -90,
                  "lng" : -180
               }
            },

Maybe it should somehow be prevented that locations with bounds like this can ever be inserted...

[Comment deleted]

[Comment deleted]

[Comment deleted]

https://maps.googleapis.com/maps/api/geocode/json?latlng=12.9898450,80.2487660

I too got the same response as Japan.

now I'm getting correct location address. don't know what the issue

I got this as a result in Asus' weather widget and was pretty confused about it :-)

ETA for this defect? or fixed already? we have similar issue reported coincidentally for the same date as mentioned in issue 9683.

This should be fixed. Please comment to re-open if this is still impacting you.

We experienced this similar issue, happened 3 times since Feb 9, 2024 on random occasions and we cannot reproduce the bug to get the response from Google API. The addresses are as below, and we use Google Maps Distance Matrix API with WooCommerce Distance Rate Shipping plugin. Could someone help advise what should we do to at least reproduce the bug and identify its root cause?

Thank you!

1. 101 KINGS CT
SUMMERVILLE, SC 29485

2. 1455 West Wade Hampton Boulevard
Greer, SC 29650

3. 323 Horseshoe Road
Parents House
Moncks Corner, SC 29483