I'm getting the same for most, if not quite all, geocode requests. The address that comes up is:  1 Chome-11 Kamifukubara, Yonago-shi, Tottori-ken 683-0004, Japan

ALso mentioned here: http://stackoverflow.com/questions/37028442/wrong-google-maps-distancematrix-behaviour

As a quick workaround I've changed Google's example code ( https://developers.google.com/maps/documentation/javascript/geocoding#reverse-geocoding-by-location ) from using results[1] to results[0] and this seems to work for now.

(No comment was entered for this change.)

 Issue 9682  has been merged into this issue.

 Issue 9684  has been merged into this issue.

 Issue 9685  has been merged into this issue.

 Issue 9688  has been merged into this issue.

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

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

 Issue 9687  has been merged into this issue.

 Issue 9693  has been merged into this issue.

 Issue 9698  has been merged into this issue.

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

 Issue 9707  has been merged into this issue.

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