Fixed
Status Update
Comments
en...@google.com <en...@google.com> #2
Affecting me too, on linux python 2.7, VERSION file in sdk is:
release: "1.9.10"
timestamp: 1407785464
api_versions: ['1']
Thanks.
release: "1.9.10"
timestamp: 1407785464
api_versions: ['1']
Thanks.
[Deleted User] <[Deleted User]> #3
Affecting me as well. It'd be nice to get this fixed so that we can properly test client errors in endpoints.
ph...@gmail.com <ph...@gmail.com> #4
Thank you for bringing this to our attention. I have forwarded your report to the engineering team and any questions they have will be posted here. Further status updates will be posted here as well.
Best regards,
pvoutsinas
Best regards,
pvoutsinas
ph...@gmail.com <ph...@gmail.com> #5
Affecting me too:
OS:
OS X Yosemite 10.10.3 (14D131)
Google App Engine:
release: "1.9.19"
timestamp: 1424415497
api_versions: ['1']
python virtual env:
beautifulsoup4==4.3.2
ez-setup==0.9
Ferris==3.0.0a8
FerrisNose==2.3.1
google-api-python-client==1.3.1
httplib2==0.9
nose==1.3.4
oauth2client==1.4.2
PIL==1.1.7
protopigeon==2.0.1
protorpc==0.9.1
pyasn1==0.1.7
pyasn1-modules==0.0.5
pyotp==1.4.1
rsa==3.1.4
simplejson==3.6.5
six==1.8.0
suds==0.4
uritemplate==0.6
waitress==0.8.9
WebOb==1.4
WebTest==2.0.16
xmltodict==0.9.0
Thanks.
OS:
OS X Yosemite 10.10.3 (14D131)
Google App Engine:
release: "1.9.19"
timestamp: 1424415497
api_versions: ['1']
python virtual env:
beautifulsoup4==4.3.2
ez-setup==0.9
Ferris==3.0.0a8
FerrisNose==2.3.1
google-api-python-client==1.3.1
httplib2==0.9
nose==1.3.4
oauth2client==1.4.2
PIL==1.1.7
protopigeon==2.0.1
protorpc==0.9.1
pyasn1==0.1.7
pyasn1-modules==0.0.5
pyotp==1.4.1
rsa==3.1.4
simplejson==3.6.5
six==1.8.0
suds==0.4
uritemplate==0.6
waitress==0.8.9
WebOb==1.4
WebTest==2.0.16
xmltodict==0.9.0
Thanks.
sp...@gmail.com <sp...@gmail.com> #6
Any update on this? Is it a bug or a change?
lu...@google.com <lu...@google.com>
co...@maptive.com <co...@maptive.com> #8
Hurmm...next time dont make EDDIT OR HACK SYSTEM
ra...@gmail.com <ra...@gmail.com> #9
Sent me link
ju...@gmail.com <ju...@gmail.com> #10
Stream labs obs
ju...@gmail.com <ju...@gmail.com> #12
app
ju...@gmail.com <ju...@gmail.com> #13
This is wrong fix
jo...@gmail.com <jo...@gmail.com> #14
Fix this is wrong
zw...@google.com <zw...@google.com> #15
This fix was done almost 8 years ago, on a version of Endpoints that has also been EOL'd for several years. If you're still experiencing issues with Endpoints, you should file a new bug with more information.
ch...@gmail.com <ch...@gmail.com> #16
[Comment deleted]
ch...@gmail.com <ch...@gmail.com> #17
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?
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?
en...@google.com <en...@google.com>
ml...@gmail.com <ml...@gmail.com> #18
Hii.
I have one question for you about google map api.
I am getting this message:
"You have exceeded your daily request quota for this API. If you did not set a custom daily request quota, verify your project has an active billing account:http://g.co/dev/maps-no-account "
I got this error yesterday at 13PM. At 00:00 it should be restarted but I can not access to this service yet? Have anyone known what can be a problem or when will access be enabled?
Thanks a lot. Mladen
I have one question for you about google map api.
I am getting this message:
"You have exceeded your daily request quota for this API. If you did not set a custom daily request quota, verify your project has an active billing account:
I got this error yesterday at 13PM. At 00:00 it should be restarted but I can not access to this service yet? Have anyone known what can be a problem or when will access be enabled?
Thanks a lot. Mladen
ka...@google.com <ka...@google.com> #19
Hi Mladen,
re#18 This error is not related to the same issue
It looks like you are having issues because you did not set up a billing account. Please follow instructions fromhttp://g.co/dev/maps-no-account "
If this does not work please create a support case viahttps://console.cloud.google.com/google/maps-apis/support in order to open personalized communication channel. Public issue tracker is not supposed to be used for issues like this one. It is aimed to report API bugs and feature requests.
re#18 This error is not related to the same issue
It looks like you are having issues because you did not set up a billing account. Please follow instructions from
If this does not work please create a support case via
ka...@google.com <ka...@google.com> #20
An update from our Engineering team is that Maps APIs is working as expected with the quota rate limiting functionality, but they are ok to consider this as a FR for the product.
I will update it to FR for our PM team to look at.
I will update it to FR for our PM team to look at.
st...@google.com <st...@google.com>
bm...@gmail.com <bm...@gmail.com> #21
+1 any updates on this FR?
When I call the Places API from my web server I can use it very fast, but when I call it from the JavaScript API I can only call it 10 times a second. This forces me to either write more server-side code (boo) or write a javascript rate limiting function.
When I call the Places API from my web server I can use it very fast, but when I call it from the JavaScript API I can only call it 10 times a second. This forces me to either write more server-side code (boo) or write a javascript rate limiting function.
ra...@google.com <ra...@google.com>
nu...@gmail.com <nu...@gmail.com> #22
I want set unlimit quota Maps JavaScript API. What should I do to set unlimit.
jh...@google.com <jh...@google.com> #23
Thank you all for your messages. This is being fixed and will be live in early 2023.
jo...@gmail.com <jo...@gmail.com> #24
Better late than never I suppose.
Description
///////////////////////////////
console.log(google.maps.version);
var counter = 0;
var service = new google.maps.DirectionsService();
var interval = setInterval(do_request, 1000);
function do_request() {
service.route({
origin: new google.maps.LatLng(48 + Math.random(), 9 + Math.random()),
destination: new google.maps.LatLng(48 + Math.random(), 9 + Math.random()),
travelMode: google.maps.DirectionsTravelMode.DRIVING
}, show_result);
}
function show_result() {
console.log(arguments, ++counter);
}
///////////////////////////////
For your convenience, here is a very simple map on jsFiddle where you can reproduce the problem by adjusting the API version parameter, entering the above code in the JavaScript box and hitting "Run" at the top:
Don't forget to open the Developer Tools.
Versions 3.8 and 3.9 will happily print "[Object, "OK"] xxx" for many hundred lines.
Versions 3.10 and 3.11 will start printing OVER_QUERY_LIMIT errors sometime after line 150 and before line 200. Also, the frequency of the error goes up with continuing API calls up to a point where the API becomes almost unusable. Here's a screenshot:
While I think