I've been using geofield on a number of high traffic projects for a number of different purposes, usually for geocoding addressfield addresses and plotting on an openlayers map.

BUT, I've just had someone (sadly, a client) point out the Google geocoding use restrictions, outlined here: http://code.google.com/apis/maps/documentation/geocoding/

According to this, there's a 2500 geocodes a day limit, and geocoded data is supposed to only be used on a Google Map.

What does that mean for this module? Is this module actually outside of the google geocode api terms of use? Or is there special dispensation for open source uses like this?

Also, does this mean that sites using this module for purposes which would cause more that 2500 hits to the geocoding api a day need to sign up for Google business services?

Comments

phayes’s picture

phayes commented
Project: Geofield » Geocoder
Version: 7.x-2.x-dev » 7.x-1.x-dev

Moving to geocoder project

phayes’s picture

phayes commented

Essentially you are correct - for high traffic sites you should get an enterprise account if you want to use google's geocoding services. We've also recently introduced a yahoo handler, I think the terms with yahoo are better. Longer term, we're planning integration with the Geocoder PHP library (https://github.com/willdurand/Geocoder), which should make even more providers available.

Brandonian’s picture

Brandonian commented
Version: 7.x-1.x-dev » 7.x-1.0-beta1

Nice to know we're getting used in some higher-traffic sites. I'd like to hear more about your experience with the module in general.

It's my understanding that Google's geocoding service will stop processing requests after hitting the rate limit. We don't do anything to explicitly keep track of how many calls to the service on any specific day, but it should fail gracefully if/when the service stops responding.

Keep in mind that the limit is only on the # of times you actually ping their server, so depending on the type/scale of your project, you might not be hitting the server up as much as you might think, since Geofield stores the results after initial call.

You might also be interested in Yahoo's geocoder service, which a) is supported by Geocoder and b) I believe has a significantly higher limit. Also, keep tabs on #1334838: Geocoder Library Integration, which, if implemented, would provide access to quite a few different services.

Moving to the Geocoder module's issue queue for further discussion.

Brandonian’s picture

Brandonian commented

And, we answer at the same time, @phayes. :-)

phayes’s picture

phayes commented

Hilarious. Glad we're on the same page!

elly’s picture

elly commented

Thanks for speedy response, guys! This is a little convoluted so bear with me:

On the site I'm most concerned about at the moment, we're actually using Geofield 7.x-1.0-rc1, which doesn't seem to involved Geocoder API module at all - I may have confused matters by choosing the wrong version on the original issue. So, if we use Geofield 7.x-2.x , will we have the option to switch to the Yahoo API for a geocode service? How's the upgrade path on that switch? Do we need to remake our fields?

For the Google API geocode stuff, the limit doesn't concern me as much, because you're right it would be pretty hard to hit the geocode service upwards of 2500 times a day consistently. We're creating and updating about a thousand nodes with addressfield/geofield on them via feeds API a few times a day. Does geofield re-geocode and hit the service on node save if the geo data is already place?

My real concern with Google geocode API is this line in the docs: "the Geocoding API may only be used in conjunction with a Google map" - which seems pretty rigid and basically at odds with what we've been using geofield/geocoding for!

Incidentally, we're also using openlayers proximity in a very dev state, and still trying to research whether that thing hits the google geocode api and how often.

In general would LOVE to chat about our various use cases for all of this stuff, we've been doing a LOT of mapping, currently for a very high traffic global non-profit org.

phayes’s picture

phayes commented

Hi elly,

Just a point of clarification: You are using the Geocoder module correct? Geofield doesn't actually do any geocoding.

elly’s picture

elly commented

I'm so confused right now. We are using geofield 7.x-1.0-rc1 and your geoPHP library (which I thought did the geocoding here?) - no geocoder module.

phayes’s picture

phayes commented

Really??? And you're using it with address-field? Did you do some custom development to make that happen?

phayes’s picture

phayes commented

So geoPHP *does* do geocoding, but it's not really what it's for. I'm actually considering removing geoPHP's geocoding capabilities. Despite the fact that geoPHP can do geocoding, geofield doesn't use that particular geoPHP functionality. Geocoder module is where all the cool kids get their geocoding fix. If you're doing it different you're doing it wrong. ;-)

phayes’s picture

phayes commented

Just to be *absolutely* clear - other than a general API, geocoder provides a WIDGET for geofield. That's how these two modules work together.

elly’s picture

elly commented

Okay, I think I got it. Just digging around, it looks like we have maybe a very old version of your initial fork of geocode that we've customized? I need to do some detective work on that but hopefully we can upgrade it. (We have a couple of other sites which are using recent geocoder properly, no problem, for those sounds like we can upgrade and switch to Yahoo no worries.)

In any case, sounds like our real problem might be the openlayers proximity d7 port I mentioned before, which isn't y'alls prob. I guess this is a larger question/problem of getting these other modules to use geocoder for consistency instead of randomly using the gmaps API.

I'm still curious about this "use our geocoded data on a google map only" clause in the google geocoder terms of service - it kind of makes me think google shouldn't even be offered as a service for geocoder?

phayes’s picture

phayes commented

I think what we should do is really just be clear about the terms that might apply on to different geocoder handlers with links to the relevant terms of service. I can't imagine removing google from our supported handlers would go over well at all. I think this is mainly just a case of better documentation and communication.

phayes’s picture

phayes commented

We could even make the plugins have a standard way to define terms of service links, so when you select the handler you get a message saying "This handler has terms of service. Click the following link to learn more. "

phayes’s picture

phayes commented
Status: Active » Fixed

Okay, I've added in the ability for handlers to define terms of service links. I've added them in for Google and Yahoo. They show up when you select the handler in the widget settings.

elly’s picture

elly commented

that is awesome. thanks!!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.