Geocoding Limit

[Paul]

Last week I was testing a geocoding script that would run nightly via
CRON and make ~600 calls/night. During testing, I inadvertently went
over my daily limit one day, and now almost a week later, when the
script runs nightly, I am still getting the OVER_QUERY_LIMIT
response... I have triple checked that I am not making any other
calls, and I own the IP address, there is nobody else using it. Has
anyone seen this before, and if so anything you can recommend? The
script is tested and ready to go into a production environment, but we
are stuck.

Thanks for any info/advice.

PS> is it possible that the speed of the calls are at issue here,
rather than the number? I am way under the 2500 limit, but the calls
get fired off from a for loop in quick succession.

[Chris Broadfoot]

Yes, geocoding is rate limited. Why are you batch geocoding?

--

http://twitter.com/broady

--
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 google-map...@googlegroups.com.
To unsubscribe from this group, send email to google-maps-js-a...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.

[Paul]

I have a table of contacts with street addresses that get updated
nightly, so I was then re-geocoding them to ensure that any address
changes were reflected in the map the next day. Any other suggestions?
I don't need the update to be fast - maybe I put a one second delay in
and the geocoding takes place over an hour or so?

On Jun 27, 11:30 pm, Chris Broadfoot <c...@google.com> wrote:
> Yes, geocoding is rate limited. Why are you batch geocoding?
>

> --http://twitter.com/broady

[Paul]

Ok, have added a sleep call, spacing the requests out to every half-
second and things are back running. Would welcome any suggestions on a
better solution if this is the wrong approach to using the geocoding
service.

Thanks

[geoco...@gmail.com]

On Jun 28, 4:30 am, Paul <pmmen...@gmail.com> wrote:
> I have a table of contacts with street addresses that get updated
> nightly, so I was then re-geocoding them to ensure that any address
> changes were reflected in the map the next day. Any other suggestions?

Only geocode the ones that have changed.

Or geocode them as part of the "change" allowing the user to adjust
the result as required.

-- Larry

[Andrew Leach]

On 28 June 2011 13:55, geoco...@gmail.com <geoco...@gmail.com> 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 rate limit, and it may run slightly faster than your
pre-defined rate. Or slower, if the server needs that.

[Paul]

Will incorporate both of these suggestions, thank you!

On Jun 28, 9:02 am, Andrew Leach <andrew.leac...@gmail.com> wrote:

[Chris Broadfoot]

On Tue, Jun 28, 2011 at 11:02 PM, Andrew Leach <andrew....@gmail.com> wrote:

That way you are guaranteed not to
break the rate limit

I'm not sure this is true, actually, but it's a fine suggestion.

The recommended strategy is to keep a queue of "tasks". Re-queue the task if the result comes back with an "over limit" response, and perhaps slow down the rate that you're geocoding.

--

http://twitter.com/broady

[Paul]

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 <andrew.leac...@gmail.com> wrote:

> On 28 June 2011 13:55, geocode...@gmail.com <geocode...@gmail.com> 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

[Barry Hunter]

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)

[Paul]

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