I have a python script that uses distance_matrix from the Google Maps API (yes I know this is now legacy and replaced by routes, but I'm updating an older piece of code and don't really want to change over yet).
My script sends a list of zip codes in Massachusetts as the origin point to get the distance to a destination.
gmaps.distance_matrix(zips, destination, mode='driving', region='us', traffic_model='best_guess')
90% of the time it works just fine, but occasionally it returns VERY wrong results. For example, for zip code 01033, which is Granby, MA it returns a result for Kyiv, Ukraine. If I search for 01033 in maps.google.com it correctly shows Granby. I added region='us' hoping it would try to restrain the results to the US, but no luck.
Any idea why it does this and how to fix it?
The behavior you're observing with the Distance Matrix API when using postal codes is expected. While it may occasionally yield accurate results, this isn't guaranteed because the Distance Matrix API first uses Geocoding to convert the postal code into a place_id before calculating the distance.
This process is outlined in the Distance Matrix documentation, which states:
"If you pass an address, the service geocodes the string and converts it to a latitude/longitude coordinate to calculate distance."
Furthermore, the Geocoding FAQs corroborate this, noting:
"When the Directions API (Legacy) or Distance Matrix API (Legacy) is queried with an address string rather than a place ID or latlng, they use the same backend as the Geocoding API to convert that address into a place ID prior to calculating directions."
Therefore, using postal codes as input is not recommended as it doesn't assure correct results. Geocoding is most effective when used with properly formatted addresses.
For more details regarding handling ambiguous requests using Geocoding API, kindly refer to this documentation as it will also provide the recommended alternative API for ambiguous inputs.