New pricing changes went into effect on July 16, 2018. For more information, check out the Guide for Existing Users.

New Forward Geocoder FAQ

This FAQ covers questions specific to the new forward geocoder that was announced in the blog post Address Geocoding in the Google Maps Platform. See also Best Practices When Geocoding Addresses.

Please refer to the Google Maps Platform FAQ for questions common to all Google Maps Platform.

Troubleshooting

Troubleshooting

I’m getting more queries that return ZERO_RESULTS with the new geocoder. What’s going on?

In the new geocoder, ambiguous, incomplete and badly formatted queries, such as misspelled or nonexistent addresses, are prone to produce ZERO_RESULTS. These queries would typically produce incorrect results in the old geocoder, such as returning the suburb if the address could not be found. We believe that returning ZERO_RESULTS is actually a more correct response in such situations.

If your application deals with user input of addresses, the Place Autocomplete feature in the Places API may produce better quality results. Place Autocomplete allows users to select from a set of results based on what they’ve typed, which allows users to choose between similarly named results, and to adjust their query if they misspell an address.

If you have an application dealing with ambiguous or incomplete queries or queries that may contain errors, we recommend you use the Place Autocomplete feature in the Places API rather than the forward geocoder available in the Geocoding API. For more details, see Best Practices When Geocoding Addresses and the Address Geocoding in the Google Maps APIs blog post.

I need fast responses, and the new geocoder is too slow for my application. What can I use for faster responses?

We recommend that applications that respond to user input, and therefore are highly latency-sensitive, use the Place Autocomplete feature in the Places API (also available in JavaScript, Android, or iOS) rather than address geocoding. Place Autocomplete is optimized to be used interactively, and thus has very low latency.

Address geocoding in the Geocoding API is optimized for use with complete, unambiguous, well formatted addresses, such as delivery addresses entered into online forms, and thus has higher latency than Place Autocomplete. This is already the case with the old forward geocoder. The latency difference between Place Autocomplete and the new forward geocoder increases further, since the new geocoder has greater coverage and better result quality, but at the cost of somewhat higher latency.

How can I mitigate the latency on the Directions API and Distance Matrix API?

Instead of addresses, use place IDs to specify waypoints, origin, and destination. Place IDs are best obtained from the Place Autocomplete feature in the Places API or the Places library in the Maps JavaScript API. See also the information on the placeIdOnly option, which can be used to reduce the cost of Place Autocomplete.

When the Directions API or Distance Matrix API 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. Place Autocomplete is faster than address geocoding. For applications that use the Directions API or Distance Matrix API in highly latency-sensitive situations, such as responding to user input, we recommended you use Place Autocomplete to get the place IDs corresponding to those addresses, and pass the place IDs to the Directions API or Distance Matrix API. This approach reduces latency significantly even compared to the old address geocoder. See our documentation for an example of how to use Place Autocomplete with directions.

I’m a Premium Plan customer, and the Places API is too expensive. What can I do to reduce costs?

We recommend using the Maps JavaScript API Place autocomplete widget. To reduce the cost of using the autocomplete widget, use the new placeIdOnly option to enable direct access to place IDs from the Place Autocomplete service. The placeIdOnly option skips Places Details requests for applications that only need an address, not full business details. To get the corresponding address, pass place IDs to the geocoding service or the Geocoding API. You may also pass place IDs to the directions or distance matrix service or the Directions API or Distance Matrix API instead of an address text string or latitude/longiture pair.

The Google Maps API Geocoder Tool and the Place Autocomplete and Directions example have been updated to illustrate how to use the new placeIdOnly option.

How do I report bugs in the new geocoder?

If you have any bug reports or feature requests for the new forward geocoder service, please let us know using our public issue tracker.

The new geocoder is not producing good results for my use case. What help is available?

Please let us know using our public issue tracker, sharing a few specific queries that produce worse results with the new geocoder, so we can investigate to see if there are any bugs or systemic issues causing problems with result quality, or if there are any changes we can make to the best practices guide to help developers get better results.

Component filtering in the new geocoder does not work the same as the old geocoder. How do I get the best results with the new geocoder using component filtering?

In the new geocoder, component filtering no longer enforces restrictions other than postal_code and country. The following examples illustrate how best to use component filtering, depending on the results you need. In the sample request URLs, be sure to replace ‘YOUR_API_KEY’ with your actual API key.

  • To restrict postal codes to a specific country, be sure to specify the country restriction using an ISO 3166-2 country code. For example: components=country:CH|postal_code:8000 returns "8000 Zürich, Switzerland".
    https://maps.googleapis.com/maps/api/geocode/json?components=country:CH%7Cpostal_code:8000&key=YOUR_API_KEY
    
  • To restrict queries to a specific country, be sure to specify the country restriction using an ISO 3166-2 country code. Country names and other abbreviations are not guaranteed to produce the same results as country codes.

    Examples:

    • Geocoding for components=country:FRA|locality:gallus returns the sublocality of Gallus in Frankfurt am Main, Germany. This is because the 3-letter country code for France (FRA) is not supported, thus results in any country are allowed and the result in Frankfurt is a better fit than anything in France.
      https://maps.googleapis.com/maps/api/geocode/json?components=country:FRA%7Clocality:gallus&key=YOUR_API_KEY
      
  • Geocoding API will not necessarily return multiple results for ambiguous queries. Such queries are better answered by the Place Autocomplete.

    Examples:

    • Geocoding for components=country:US|locality:madrid returns "Madrid, NM 87010, USA" but none of the other cities in the USA named "Madrid".
      https://maps.googleapis.com/maps/api/geocode/json?components=country:US%7Clocality:madrid&key=YOUR_API_KEY
      
    • Using Place Autocomplete for input=madrid&components=country:us&types=(regions), and also specifying a viewport using location and radius to bias the location results, generates a response with several cities in the USA named "Madrid".
      https://maps.googleapis.com/maps/api/place/autocomplete/json?location=37.386052,-122.083851&radius=10000&input=madrid&components=country:us&types=(regions)&key=YOUR_API_KEY
      

Enviar comentários sobre…

Precisa de ajuda? Acesse nossa página de suporte.