Got it. Have increased the spacing out a bit more, to two seconds. WIll add in logic to retry queries at longer intervals if they fail.
Thanks again, Paul On Jul 4, 1:33 pm, Barry Hunter <[email protected]> wrote: > Well its not just that you get 2500 lookups every 24 hour window, its > that you get to make that many requests over the span of 24 hours. > Can't zip though all in a few minutes, then sleep for 23.9 hours. Its > not a daily quota. It just amounts to the same. > > This is the rate limit Chris mentions. BUt the exact rate is not > published, think of it as 104 an hour if you like. But its likly to be > different. > > So you need to aim on spread the results out. For a small amount your > 0.5 second might be enough. But to be able to use the full amount > would be about 35 seconds delay between calls. > > Perhaps better, is start with a low delay and then increase it when > you get errors. (but I think that was already mentioned in the thread) > > > > > > > > On Mon, Jul 4, 2011 at 6:03 PM, Paul <[email protected]> wrote: > > I am indeed doing this, but still getting the error. Essentially, I am > > making the calls from a loop, and in the loop using cURL to send the > > request, only proceeding if the response was successful. Adding in a > > half a second sleep seemed to fix this issue. > > > I have added in the check for changed data, and the half-second sleep > > and all seems to be well. Would be great if I could figure out why > > limits are being hit when I am sending data one at a time, but this > > seems to work for now. > > > Thanks for the suggestions, > > > Paul > > > On Jun 28, 9:02 am, Andrew Leach <[email protected]> wrote: > >> On 28 June 2011 13:55, [email protected] <[email protected]> wrote: > > >> > Only geocode the ones that have changed. > > >> > Or geocode them as part of the "change" allowing the user to adjust > >> > the result as required. > > >> I think that last suggestion is to be preferred; but if you do all of > >> them or just the changed ones, send the next request only when the > >> previous result has been received. That way you are guaranteed not to > >> break the ratelimit, and it may run slightly faster than your > >> pre-defined rate. Or slower, if the server needs that. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google Maps JavaScript API v3" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/google-maps-js-api-v3?hl=en. -- You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.
