Live data from Hacker News

How We reduced our Google Maps API cost

blog.cityflo.com

71–80 of 172 posts

Re: How We reduced our Google Maps API cost

#71

Well, that's more clever than a company I did due diligence for. Their strategy was to have a pool of API keys attached to new accounts that would take advantage of the Google Maps API free tier, and monitor its usage. As the free tier usage would run out, the system would roll over to a new API key automatically. Wrote that one up in big red marker in my report...

I worked at a company where they did the same thing, for a different Google API.

It didn't work out, and it still baffles me how anyone thought it could.

Re: How We reduced our Google Maps API cost

#72
post #65

Earlier quoted context omitted.

My understanding is that Google's does real time traffic reporting so well because it's constantly pinging the location of android devices. There have been several write ups on how to spoof it, but historical data is never going to be a match for a feed like that.

It sounds like you could use Google's live traffic info to augment your own predictions. You should be fine with just a few API calls. This would be pretty cheap - perhaps even within the free tier.

It would violate the ToS.

Re: How We reduced our Google Maps API cost

#73

Earlier quoted context omitted.

It's not clever, it's just much more simpler. Using linear interpolation for the time between 2 stops will have low accuracy because for the particular situation time might not be linear with position and distance. Also traffic incidents might happen. Going with a pool of free keys will be much more dependable, even if somehow more complicated to manage and easier to break.

> So, we ensure a maximum of 20 meters between two location coordinates to improve accuracy of information. Hardly "low accuracy". The key change is modelling the problem as one of routes rather than journeys. Since a route can be "polled" at a certain resolution & used regardless of the number of journeys on it. > This approach made the API calls independent of the number of vehicles and dependent only on our stops,…

> Since a route can be "polled" at a certain resolution

Unless I'm misunderstanding, they aren't polling these inter-stop coordinates

Re: How We reduced our Google Maps API cost

#74
post #65

Earlier quoted context omitted.

It sounds like you could use Google's live traffic info to augment your own predictions. You should be fine with just a few API calls. This would be pretty cheap - perhaps even within the free tier.

It would violate the ToS.

Which part of the ToS (that isn't getting violated already)?

The real problem with this approach is that you will never know when real time is conflicting with historical unless you're calling the API constantly anyway

Re: How We reduced our Google Maps API cost

#75
We at nb.ai help companies with similar get off of Google solutions, and are able to achieve similar reductions in API calls, along with typically, an IMPROVEMENT in accuracy. We find building good machine learning, traffic and routing models, along with OSRM and GraphHopper goes really far

Re: How We reduced our Google Maps API cost

#76

If you track the vehicles every day and collect the location data, you can easily augment the Open Source Routing Machine to give you traffic accounted estimates.[0] Combined with some Kalman filters you'd get almost perfect estimates when live. Of course, this is for a use case where you have similar routes every day, this allows you to really tune the Kalman filters. 0: https://github.com/Project-OSRM/osrm-backend/…

Where is the best place to get/purchase traffic data for use with OSRM?

Re: How We reduced our Google Maps API cost

#77
We at NB.ai help companies with similar get off of google solutions, and are typically able to get an uplift over google API accuracy. For a very similar company, achieved similar reduction in calls, along with an increase in accuracy of 7%

Re: How We reduced our Google Maps API cost

#78
As others suggest, switching to OpenStreetMap is something to consider.

However - it is also important to _contribute_ funds to OpenStreetMaps - for cityflo and for us.

Donations: https://wiki.osmfoundation.org/wiki/Donate

Individual membership: https://wiki.osmfoundation.org/wiki/Membership

For organizations: https://welcome.openstreetmap.org/how-to-give-back/

The OSM Foundation in general: https://wiki.osmfoundation.org/wiki/Main_Page

Re: How We reduced our Google Maps API cost

#79

Earlier quoted context omitted.

This company was shockingly deep into their lifecycle to still be using this approach. And yeah, they'd cycle IPs as needed too. I think the thought was that Google isn't doing a ton of fraud analysis for this particular modality of fraud. Still though...

You don't have many options if you need high accuracy: you have to pay a lot or try to trick Google which might be both immoral and against the law and for sure is tricky, hard to maintain and you can't count on it in the long run. Let's hope there will be alternatives to Google provided traffic data. For now they seemed to monopolized it by offering it for free while losing money to discourage competition.

> You don't have many options if you need high accuracy: you have to pay a lot

What happened to actually trying to solve problems with programming?

Interpolation is one solution. Caching is another. Temporal analysis. Put everything together.

You don't need to query the magic Google box for every small update you make (and they might get that info from the transit providers, which given my experience are not that great sometimes).

Re: How We reduced our Google Maps API cost

#80

Well, that's more clever than a company I did due diligence for. Their strategy was to have a pool of API keys attached to new accounts that would take advantage of the Google Maps API free tier, and monitor its usage. As the free tier usage would run out, the system would roll over to a new API key automatically. Wrote that one up in big red marker in my report...

Fraud.
Post reply on HN