Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I believe this is the answer you are looking for (from google developer section):</p> <p><a href="https://developers.google.com/maps/articles/geocodestrat" rel="nofollow">https://developers.google.com/maps/articles/geocodestrat</a> </p> <p>Quota Considerations</p> <p>Server-side geocoding through the Geocoding Web Service has a quota of 2,500 requests per IP per day, so all requests in one day count against the quota. In addition, the Web Service is rate-limited, so that requests that come in too quickly result in blocking. Client-side geocoding through the browser is rate limited per map session, so the geocoding is distributed across all your users and scales with your userbase. Geocoding quotas and rate limits drive the strategies outlined in this article.</p> <p>.....</p> <p>When to Use Client-Side Geocoding</p> <p>The basic answer is "almost always." As geocoding limits are per user session, there is no risk that your application will reach a global limit as your userbase grows. Client-side geocoding will not face a quota limit unless you perform a batch of geocoding requests within a user session. Therefore, running client-side geocoding, you generally don't have to worry about your quota.</p> <p>Two basic architectures for client-side geocoding exist. •Run the geocoding and display entirely in the browser. For instance, the user enters an address on your page. Your application geocodes it. Then your page uses the geocode to create a marker on the map. Or your app does some simple analysis using the geocode. No data is sent to your server. This reduces load on your server, but doesn't give you any sense of what your users are doing.</p> <p>•Run the geocode in the browser and then send it to the server. For instance, the user enters an address. Your application geocodes it in the browser. The app then sends the data to your server. The server responds with some data, such as nearby points of interest. This allows you to customize a response based on your own data, and also to cache the geocode if you want. This cache allows you to optimize even more. You can even query the server with the address, see if you have a recently cached geocode for it, and if you do, use that. If you don't, then return no result to the browser, and let it geocode the result and send it back to the server to for caching.</p> <p><strong>UPDATE 03/23/2015: per request by a poster</strong></p> <p>Here is the excerpt from the Google documentation on quota limits for the direction API:</p> <p>Usage Limits</p> <p>The Directions API has the following limits in place: Users of the free API:•2,500 directions requests per 24 hour period. <br/> •Up to 8 waypoints allowed in each request. Waypoints are not available for transit directions. <br/> •2 requests per second. Google Maps API for Work customers:•100,000 directions requests per 24 hour period. <br/> •23 waypoints allowed in each request. Waypoints are not available for transit directions. <br/> •10 requests per second. </p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload