Would you be able to describe your use case of why you need to do on the order of hundreds of directions requests please?

Sure. This is my application: http://lstsim.de/

It is in German, so here's a short description: It's a simulation of an emergency services dispatch center. The user is in charge of sending ambulances to different places all over the area. I'm using the Directions Service, so the ambulances on the map use the actual roads (and even respect the speed limits). Every trip from one location to another takes a single request. This allows me to achieve a pretty realistic replication of the reality.

This also means I don't actually need a routing request every second, but it rather depends on how busy things are in the game. My users were reporting routing errors usually after 300 routings and about an hour or so of playing, so you get an idea of the average request rate.

This problem sounds similar to behavior I am seeing with versions 3.10+ ... my application allows users to create maps of their addresses. After 200 or so rows the geocoder becomes very very slow, even if I delay geocodes 5-10 seconds in-between.

Since the limit is 2500 per day, does it not seem reasonable that you would be able to send a geocode 1 per second as you have in the past until you reach 2500? If this is a change to the quota and limits of the free google maps API please let us know.

(No comment was entered for this change.)

Google is forcing 3.10 now so there is no using 3.9 to get around this bug.

I need to know if this is a permanent change on geocoding quotas or if this is truly a bug. If it is a permanent change I will need to make big changes to our app so users can only create maps of 200 or less points, whereas before it was possible to create 2500 marker maps.

Any update on this? Is it a bug or a change?

(No comment was entered for this change.)

 Issue 4241  has been merged into this issue.

An update on this would be greatly appreciated by our users.  Thank you.

Any updates on this issue? When will this bug be fixed.

Any updates about this defect?

 Issue 5230  has been merged into this issue.

So, it's about one year after my last question about the actual status of this defect. Are there any updates? 

So, it's about one year after my last question about the actual status of this defect. Are there any updates? 

The problem is more widespread than just the DirectionService, as I have the same experience with the Geocoder service. If I attempt much more than 250 calls to the service it becomes impossibly slow, no matter how far out I stagger the calls.

Getting the information with webservice is a good alternative to do this via the API, as unlike the API, the developer is pretty much in control of the qps, and can acquire/purchase more qps if needed.

Webservice also has a free set, which you can use if you have high qps, but but low page loads. For a high qps and high page load application, unfortunately that can not be offered free of charge.

Webservices are accounted for by developer rather than by page load, and offers more flexibility in terms of QPS, but that also means that the entire quota bucket can be used within one application, however we assume the developer to be in control to hand this out as they please.

See:
https://developers.google.com/maps/web-services/overview

I feel the actual problem is lack of transparency on the limits being imposed, particularly for the Javascript API. For the Directions API, it is well written in the documentation that 2,500 free directions requests are allowed per day, at a rate of 10 requests per second. The Javascript API documentation, on the contrary, does not mention the limits on individual service. The only limit I can see from the documentation is "Free until exceeding 25,000 map loads per 24 hours for 90 consecutive days".

As a consequence, developers either assume the limits of the JavaScript API Directions Service is the same as that of the Directions API, or they do a stress test on the API themselves to guess how much requests Google will allow. For developers doing the latter, they apparently observed a change in behavior compare to the previous version, and for over 3 years there is no confirmation officially given.

Your suggestion in using the Directions API may or may not resolve our problem eventually, but it is certain that the lack of transparency now causes extra development and testing effort for each developer experiencing this problem.

In addition, it is clearly written in your documentation the following:

> This service is generally designed for calculating directions for static (known in advance) addresses for placement of application content on a map; this service is not designed to respond in real time to user input, for example. For dynamic directions calculations (for example, within a user interface element), consult the documentation for the Google Maps JavaScript API Directions Service.

As you have seen in this thread, at least a few developers are doing exactly what is described. They have a user interface for users to add multiple places (could be over hundred), and then the routes for each pair of places are computed. I don't see a reason why we have to switch over to the Directions API then - given that the JavaScript API is designed to entertain client side user interaction.

At the very least, could you please disclose the limits in the documentation, such that developers can take into consideration when designing their application?

(No comment was entered for this change.)