Hello,

I used this morning the search proximity field. This afternoon if I use the search field it does not work: "location not found". In Drupal logs I get these errors: "Exception : Google API returned bad status.\nStatus: OVER_QUERY_LIMIT dans geocoder_google() (line 52 dans /srv/data/web/vhosts/www.mydomain.com/htdocs/sites/all/modules/geocoder/plugins/geocoder_hand...)."

Do you have this problem? What can I do to make the search work?

Thanks.

CommentFileSizeAuthor
#5 staticcache-1954308-8132722.patch1.22 KBjide
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jpstrikesback’s picture

Alas, this means you have reached the daily limit of 2500 queries, there is some talk in #1462098: Google Maps Geocode Limit? of allowing client side queries which would sidestep this issue nicely.

Sansui’s picture

I see today the same error: Exception: Google API returned bad status.\nStatus: OVER_QUERY_LIMIT in geocoder_google()

The thing is, this is on a private development site, with a small handful of content with geocoded locations, and a view that only I have been accessing (and very little, at that). There's no way I've reached the limit....

urlM’s picture

I've been running into this issue as well and know we haven't been hitting the 2,500 limit by human traffic. Could spam bots be constantly submitting the form which pings Google's Geocoder each time? Is there a way to implement zip code / address validation before submitting the views exposed form (search proximity)? I've tried adding a Honeypot field (http://drupal.org/project/honeypot) to prevent the spam, but am still running into the same issue. It seems that the form still hits Google's Geocoder even with Honeypot disallowing the form submission. I've been using the Openlayers Locator feature here: http://drupal.org/project/ol_locator

urlM’s picture

Issue summary: View changes

rev2

jide’s picture

After investigating the issue, I finally found out what is causing this.

Each form submission of a views exposed form with a proximity filter hit the API 4 times :

  • The form itself hits the API 2 times, one for the validation, one for the actual submission. IMO, it's insane to hit the API for the validation. To avoid that, you can comment what is after // Validate location in openlayers_proximity_handler_filter.inc, line 300.
  • When building a view, we create 2 displays, one for the Openlayers data overlay, and one for the page itself. So we add the proximity filter 2 times, one for each display. This is more problematic, because from what I saw, it is not possible to do otherwise... But if you remove the exposed filter from the view, and keep it in the Openlayers data overlay, and pass the arguments thru the URL e.g. ?circle_op=<&circle%5Bvalue%5D=100&circle%5Blocation%5D=toulouse, it works.

A temporary solution would be to manually create a from to submit the values and build the URL. A real solution would be to differentiate how the exposed form part is built for the page display and the Openlayers data display.

And voilà how I divided # of hits by 4.

jide’s picture

Issue summary: View changes
Status: Active » Needs review
FileSize
1.22 KB

TO fix this, we can use a static cache. Here is a patch.

SeppeD’s picture

Hi,

I had the same problem of the Google api limit. This is because my sites are hosted on a shared server (one.com and versio.nl).
I solved it by using a proxy.

change line 35 of /sites/all/modules/geocoder/plugins/geocoder_handler/google.inc :

    $url = url('http://proxybay.nl/browse.php?u='.urlencode('http://maps.googleapis.com/maps/api/geocode/json?'), array('query' => $query));
    $url = str_replace('&', '%26', $url);
    $result = drupal_http_request($url);

When using a different proxy, I encountered the problem that we need to save cookies.

jide’s picture

Priority: Normal » Critical

Bumping to critical, since the module isn't usable once the limit is reached, and to give attention.

jpstrikesback’s picture

If someone else can RTBC that patch I'll commit it (with a whitespace fix).

spy70’s picture

@SeppeD #6

Soooooooooooooooooooooooooooooo much thank you!!!
You are my hero :)

I try your workaround and it works perfectly.

I was searching a solution for several weeks.

As for the others and for you, my site is hosted on shared server (OVH)

I wish you a greaaaaat day!
Many thanks again.