How We reduced our Google Maps API cost • Hacker News Board

Re: How We reduced our Google Maps API cost

#161

Post by hinkley » Sun, Apr 05, 2020, 1:26 AM UTC

disillusioned wrote: post #13

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 discovered that our preproduction servers use the free tier while trying to work on some CI/CD issues. Normally we never get anywhere near the limit, unless someone (say, me) is trying to work on the test suite during a time of day when a lot of pushes are happening. Had a few enforced breaks there for a little while.

Re: How We reduced our Google Maps API cost

#162

Post by mdorazio » Sun, Apr 05, 2020, 1:48 AM UTC

lucb1e wrote: post #156

mdorazio wrote: post #123

Earlier quoted context omitted.

I worked with a major automotive company that was upgrading its head units to be more user friendly. Their #1 customer request at the time was to have it use Google Maps, so they tried to negotiate a discount with Google. I can't share the discount amount, but it was laughably small and the company would have been shelling out millions of dollars a month to Google for the integration. Needless to say, they stuck with…

I was actually kind of surprised that my spouse's new company car did not come with either Google Maps or OpenStreetMap but instead credits the map data to some mapping company from eastern Europe if I remember correctly -- the data looks like whitelabeled TomTom or HERE data. I just wish they would either augment their data with OSM or augment OSM with their data: now, with proprietary data, the data was already old…

For what it's worth, traditional (i.e. not Tesla) OEMs generally had a "no open source anything" policy for a long time, for a variety of reasons I don't really agree with. That's changing a little bit these days, but not a whole lot.

Re: How We reduced our Google Maps API cost

#163

Post by samcheng » Sun, Apr 05, 2020, 2:41 AM UTC

karussell wrote: post #39

samcheng wrote: post #4

Earlier quoted context omitted.

Yeah, unfortunately I'm not aware of any open/free sources of real-time traffic data.

Here is a collection I started some time ago: https://github.com/graphhopper/open-traffic-collection

These seem to be average / historical data sets, not "is there an accident / traffic jam on my route right now."

Thanks for the excellent work, though!

Re: How We reduced our Google Maps API cost

#164

Post by BubRoss » Sun, Apr 05, 2020, 4:42 AM UTC

AnotherGoodName wrote: post #126

I did the same years ago. We were providing realtime suburb data for a fleet of trains. Each train received a GPS coordinate once per minute, we took this and displayed the suburb. So 1440 updates per day per train. For the fleet it was going to be over $100 a day in API costs. We were going to not display suburb data because of cost. In the end I found a creative commons placename database (geonames.org). For placen…

Why wouldn't you cache the results instead of making 1440 queries per day?

Re: How We reduced our Google Maps API cost

#165

Post by tomjuggler » Sun, Apr 05, 2020, 8:53 AM UTC

I used to use Google's geocoding API when it was free, really hate it when they make stuff and then when it gets popular start charging $$$

I still haven't found a viable free replacement, unfortunately. I'm just doing this for personal projects, so no big budget.

Re: How We reduced our Google Maps API cost

#166

Post by AnotherGoodName » Sun, Apr 05, 2020, 3:42 PM UTC

BubRoss wrote: post #164

AnotherGoodName wrote: post #126

I did the same years ago. We were providing realtime suburb data for a fleet of trains. Each train received a GPS coordinate once per minute, we took this and displayed the suburb. So 1440 updates per day per train. For the fleet it was going to be over $100 a day in API costs. We were going to not display suburb data because of cost. In the end I found a creative commons placename database (geonames.org). For placen…

Why wouldn't you cache the results instead of making 1440 queries per day?

You still have the same problem. The input is a GPS coordinate. You can just return the same value as the last X minutes but that obviously sucks since you could be X minutes off in the real time suburb of a fast moving train. You could find the nearest to the cache but then you might as well just have a list of places you're finding the nearest again. Which is what i did.

Re: How We reduced our Google Maps API cost

#167

Post by BubRoss » Sun, Apr 05, 2020, 8:24 PM UTC

AnotherGoodName wrote: post #166

BubRoss wrote: post #164

Earlier quoted context omitted.

Why wouldn't you cache the results instead of making 1440 queries per day?

You still have the same problem. The input is a GPS coordinate. You can just return the same value as the last X minutes but that obviously sucks since you could be X minutes off in the real time suburb of a fast moving train. You could find the nearest to the cache but then you might as well just have a list of places you're finding the nearest again. Which is what i did.

I didn't realize the train coordinates were what the API was for. Were these public trains? How does google have their gps coordinates and no one else does?

Re: How We reduced our Google Maps API cost

#168

Post by NetToolKit » Mon, Apr 06, 2020, 2:19 AM UTC

tomjuggler wrote: post #165

I used to use Google's geocoding API when it was free, really hate it when they make stuff and then when it gets popular start charging $$$ I still haven't found a viable free replacement, unfortunately. I'm just doing this for personal projects, so no big budget.

FYI, we at NetToolKit offer 1,000 free queries per day via our development key, and the cost beyond that is very affordable at $10 for 100,000 queries.

Re: How We reduced our Google Maps API cost

#169

Post by AnotherGoodName » Mon, Apr 06, 2020, 5:42 PM UTC

BubRoss wrote: post #167

AnotherGoodName wrote: post #166

Earlier quoted context omitted.

You still have the same problem. The input is a GPS coordinate. You can just return the same value as the last X minutes but that obviously sucks since you could be X minutes off in the real time suburb of a fast moving train. You could find the nearest to the cache but then you might as well just have a list of places you're finding the nearest again. Which is what i did.

I didn't realize the train coordinates were what the API was for. Were these public trains? How does google have their gps coordinates and no one else does?

We installed hardware on each train to monitor them. So from each moving train we received a coordinate every minute to our servers.

Re: How We reduced our Google Maps API cost

#170

Post by BubRoss » Tue, Apr 07, 2020, 2:35 PM UTC

AnotherGoodName wrote: post #169

BubRoss wrote: post #167

Earlier quoted context omitted.

I didn't realize the train coordinates were what the API was for. Were these public trains? How does google have their gps coordinates and no one else does?

We installed hardware on each train to monitor them. So from each moving train we received a coordinate every minute to our servers.

Are you saying that you did that to switch off of google's API?