1

Controlling Google Geocoding API Costs

Topic: Controlling Google Geocoding API Costs

We have a few international customers in areas where Gurtam maps geodata is not as strong as Google maps geodata (geodata is used for street address lookups.)  In these cases we can switch the user's "Geodata source" from the default Gurtam to Google in User Settings (https://docs.wialon.com/en/hosting/user/set/maps?s[]=geocoding), and address lookups will be done via Google API instead of Gurtam.

This works great, but user settings can be changed by any user, so curious users who play with their Wialon settings can also switch this setting to Google, even if they don't need it.  This incurs unnecessary cost for Google Geocoding API calls, which is much more expensive than Google Maps API calls.  A single user can cause several dollars per day of such usage simply by leaving the Wialon Monitoring panel open for their units.

We propose that an option be added to allow these settings (particularly Geodata source, but possibly also Map source) to be settable for users by Gurtam Partners, but not by the end users themselves.  Partners like us could use this option to set this selection on a per-user basis without giving users the option to change these settings.

We realize there is an option in Services to turn off "Google (custom)" at the end customer account level, but I understand this disables Google as an option for both Map source and Geodata Source.  Most of our customers prefer Google Maps with Gurtam Geodata.  Perhaps another alternative is to split the Google service into maps and Geodata so they can be controlled separately for availability in the User Settings.

2

Controlling Google Geocoding API Costs

Re: Controlling Google Geocoding API Costs

Hello dear MarcW,

At the moment, the "Map Source" and "Geodatabase Source" settings are indeed custom settings and if the user can edit their own settings, no restrictions can be set on editing these settings. It is possible that these and some other settings are not really user settings. So the idea of restricting access to them in some way is logical and understandable, especially for cases where it is possible to connect paid cards.

Your suggestion to restrict access to end-users only is not practicable, because there are different hierarchies and we probably won't always be able to understand where which account is which. We can only bind to some specific account parameters. For example, we could leave access only for TOP user or for accounts with dealer rights. But these are not the right implementation options in this case. 

However, there are other suggestions:
1) Add a separate right to access map settings. But this is not a good way, since logically there should be access to user settings.
2) Take some of the settings out of User Settings and divide the rights, i.e:
    - for really user settings (e.g. language, colour scheme, date and time formats, etc.) leave the ability to lock/unlock edit access using the "Can change its settings" option in User Settings;
    - other settings (e.g. map source, geodata source, additional information) should be moved to a separate settings block and access to them regulated by a separate right.

However, the likelihood of implementing any changes in the near future is very low. Due to lack of support from other partners (we have received only 1 restriction request so far), the priority of the task will not be the highest. It is possible that someone will additionally share their cases and support the idea, then we will be able to increase the task priority in the backlog.

At the moment there are several ways to limit this:
1) close the ability to edit settings to particularly curious users;
2) disable Google Maps for users for whom there is no pressing need to use it.
3) warn users who don't need to get geodata specifically from Google that they can't use those maps as a geodata source.

I realise that all methods are not very good and effective, but for now there are only such options.


I'll put the task on the list of product development suggestions. As soon as I have news on your request, I will immediately let you know in this thread.

Nastassia Maslovskaya
Business Analyst, Gurtam
3

Controlling Google Geocoding API Costs

Re: Controlling Google Geocoding API Costs

Thank you for thinking this through and explaining the difficulties.  Also thank you for the suggestions.  To share our feedback on the suggestions:

1) close the ability to edit settings to particularly curious users. - This blocks all settings for the user which becomes a support issue because we need to change settings for the user on request.
2) disable Google Maps for users for whom there is no pressing need to use it - Most of our users prefer Google Maps, and the maps API is not a cost concern since it is much less costly to use in Wialon.  Disabling Google Maps blocks all Google Maps functionality, and users that still have Google Maps can still inadvertently change the setting and unknowingly cause a large expense to us from Google.
3) warn users who don't need to get geodata specifically from Google that they can't use those maps as a geodata source.

And for all the suggestions above, any remaining users that retain access to select Google as their Geodata source can still inadvertently change the setting and unknowingly cause a large expense to us from Google.

Our current plan is to:
Short Term - Change the Geodata source setting for all users who don't need Google for address lookups.
Long Term - Switch to using a Google API key from an Enterprise account to allow setting limitations on usage of the Google Geocoding API, which will allow Google Maps to continue working for everyone, but will cause the address lookups to sometimes fail in Wialon when the Google API key usage quotas are exceeded.

4

Controlling Google Geocoding API Costs

Re: Controlling Google Geocoding API Costs

MarcW,

Thanks for the feedback!
Switching to a different plan where the restrictions are set is also an option. But I hope that in the future we will be able to optimise things on our end.

Nastassia Maslovskaya
Business Analyst, Gurtam