The new Google Maps Platform environment (announced by Google in the last months) also introduces important changes to its Terms of Use and Billing Prices & Conditions.

At the moment (although extension to Leaflet JS Apis is in the actual Roadmap) Geofield Map module for Drupal 8 uniquely relies on Google Map JS API for Geofield Map Formatting and Views integration, so as for its Geocoding functionalities and Google Places library implementation.

Google Maps API/Platform important updates and Google Maps new pricing & terms of services changes that are going into effect starting July 16, 2018 will probably affect your use of this module, and probably NOT in an easier way (sorry , this is completely out of our control).

For more information, check out the Google Maps News Guide for Existing Users.

Comments

itamair created an issue. See original summary.

itamair’s picture

Issue summary: View changes
itamair’s picture

Issue summary: View changes
itamair’s picture

Issue summary: View changes
itamair’s picture

itamair’s picture

Title: Google Maps API Key: New pricing changes will go into effect starting July 16, 2018 » New Google Maps Platform Terms of Use and Billing: New pricing changes will go into effect starting July 16, 2018
Issue summary: View changes
itamair’s picture

Issue summary: View changes
benjarlett’s picture

Can anyone give some guidance on how to work out which of the sections in the maps, routes and places I'd be accessing if I were to use this module? I'm wanting at a minimum a proximity filter... and the other features of this module are looking tempting... but my client needs to know what it'll cost him,.... and I'm confused....

google maps pricing calculator

Is one call of a map with many markers on it that has zooming functions a single "Dynamic map"? or is it one call per marker? and is it one call per view of the page.. do you pay again when the user clicks zoom in? It's hard to understand/make a guess.

itamair’s picture

Priority: Major » Normal
itamair’s picture

New 8.x-2.9 version introduces Client Side Reverse Geocoding caching functionalities, that can be configured from the Geofield Map settings page. This can highly reduce the amount of payload calls against the Google Maps Geocoder and Google Places webservices used by the module.
Further more a deeper integration of Geofield Map module with the Geocoder one is on the way. This will make possible to use and properly setup other Geocoding/Reverese Geocoding web services different from Google ones ...

weseze’s picture

I was looking into using this module instead of further implementing our custom solution, but ran into a problem caused by this new pricing strategy from Google.

It effectively forces us to restrict the API keys by domainname or IP address. (you can't do both) If we don't then anyone can just copy the key out of a Javascript call and start using it on our billing...
This means you have to have 2 keys, 1 restricted on IP that will work on any PHP call made by serverside and a second one restricted on domainnames that will work in Javascript calls for rendering maps clientside.

I'm curious as to how you are solving this issue? Because you can only enter 1 key in the config for this module? What am I missing?

itamair’s picture

At the moment the module is using the same GMap Key (stored in its configuration) for every call to Google Maps objects (as Geocoder) and to initialize the Google Maps itself (this version is using just javascript/client side calls).
You might have some different mapping modules on the same Drupal project, but then you might use the same API key, and your Google Maps charging will rely on the same linked account.

May be I am missing something ... or your question real meaning,
but AFAIK, It's your choice to define the kind of GMap Key you want to define and enable.
Yes it was domain or IP kind API key: but then you would be able to add the amounts of domains and IPs addresses to each of them.
Now things are probably changed/changing on Google Maps side ... @see: https://developers.google.com/maps/documentation/javascript/get-api-key

Anyway in the same Drupal Project you should be able to use just 1 GMap API key for all of the Google Maps libraries services and functionalities implemented ...

d70rr3s’s picture

Hi, in my case I got some clients that use premium accounts and don't want to lease their API Key. I'll create a Feature request for this with a patch proposal. Any advice?

itamair’s picture

@d70rr3s sorry but it is very hard to get the sense of your question. Premium account of what? Patch for what?
Please open whatever issue and feature request you would like, but try to be clear in your requests and more exhaustive in you scenario explanation.
Here maintainers and contributors are using their free time for the community projects, and there is no one looking for help whose time is more valuable of any one supposed to provide support ...

weseze’s picture

I think this should not be a feature request but a bug that needs to be fixed.

I'll try to clarify things:

The main problem is not a technical one, purely a commercial one: Goole maps keys are no longer free. You have to pay for every single request you make with your key.
If you create a new Google Maps API key now, you will get free credit every month. I think it's something like $200/month. If you want more you have to add a credit card and you get billed for every request over your free credits. You can set a limit to your budget. Once the limit is reached, all Google Maps calls are blocked.

It is now absolutely necessary to restrict your key, either on IP address or domain name, those are the only options. If you do not restrict your key anyone can just copy your key from a JavaScript file and start using it, billing your credit card for it or just maxing out the configured budget limit.

So this is where the problem starts. If you restrict on IP address your key will only work on PHP calls. If you restrict on domain name your key will only work on JavaScript calls. So we need 2 separate keys to prevent anyone from being able to use our key and our money on their site.

itamair’s picture

thanks for the further clarification @weseze (although my last post was asking more info to @d70rr3s rather).

You scenario sounds weird and interesting though. So the possibility/need of setting two google maps api keys for the Geofield Map module to handle php calls (may be for geocoding services) and for maps processing ...
Do I understand well?
This really seems over-heading, and quite challenging for a module refactoring.

I should better investigate the matters you highlight and eventual solutions/workaround.

At the moment it seems to me that the 2.x version of the Geofield Map module is using gmap key only for client / javascript calls, isn't it?
Am I wrong?

In its roadmap though I am implementing a further integration with the Geocoder Module (almost finished) and that would really lead to a different scenario (some gmap api key are really server side for geocoding operations ...).

Would you suggest any proper and possible approach? The possibility to input and manage 2 gmap api keys (for server and client side operations do sound so complicate to me ...).

Did you inspect if and how any other Drupal 8 Geo Module (i.e.: geolocation module) is facing & solving this issue???

itamair’s picture

Ok @weseze I better investigated the issue that you arised, and your warning scenario, that perfectly makes sense.
I confirm that at the moment the 2.x version of Geofield Map uses its gmap api key just for client side operations, both for google mapping and google geocoding. So just restricting it based on domain name should keep you both safe and efficient.

In the new 3.x version of the Geofield Map module (on the way), that will geocode server side and eventually integrate with the Geocoder module (if enabled) it will be possible to specifically differentiate and use a second gmap api key just geocoding operations server side. This would be object of IP address protection ... thus, instead.

weseze’s picture

Status: Active » Needs review

Excellent!

Perhaps we could add some info on the project homepage on this? Or in the description next to the fields were keys are inputted?

itamair’s picture

Sure ... going to add some more info in the description next to the gmap api key fields

  • itamair committed f7186ec on 8.x-2.x
    Issue #2978588: Better documentation on Google Maps API Key use and...

  • itamair committed ee052d9 on 8.x-2.x
    Issue #2978588: Better documentation on Google Maps API Key use and...
d70rr3s’s picture

Hi @itamair, I appologize for my post as it wasn't clear enough and if somehow is not related to this issue discussion, as you say everyone's time is precious. I've created this #3025468 Add support for using client id ticket with the use case I was talking about.