Live data from Hacker News

How We reduced our Google Maps API cost

blog.cityflo.com

121–130 of 172 posts

Re: How We reduced our Google Maps API cost

#122
post #2

For what it's worth, I found OpenStreetMaps and the Open Source Routing Machine to be sufficient for our purposes. If you don't want features like real-time traffic awareness, it's worth investigating the open source tooling. It can save a LOT of money.

I'm a big fan of OpenTripPlanner [0]. I mainly use it for accurate isochrones of public transit networks (super handy for figuring out where to live) but it has support for foot, bike and car routes as well. There was some PoC code to support traffic data [1] but it was removed [2], I believe because nobody was interested in maintaining it. If someone wants to add it back and maintain it I doubt they'd object.

[0]: https://github.com/opentripplanner/OpenTripPlanner

[1]: https://github.com/opentripplanner/OpenTripPlanner/pull/2077

[2]: https://github.com/opentripplanner/OpenTripPlanner/pull/2698

Re: How We reduced our Google Maps API cost

#123

I wonder if they simply tried calling Google and negotiating a volume based discount. I realize Google is notoriously impersonal, but I always prefer if you can solve a problem without code.

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 a different mapping provider.

Re: How We reduced our Google Maps API cost

#124
post #2

For what it's worth, I found OpenStreetMaps and the Open Source Routing Machine to be sufficient for our purposes. If you don't want features like real-time traffic awareness, it's worth investigating the open source tooling. It can save a LOT of money.

+1, I've made my own geocoding/geodecoding on openstreetmap data, it worked 10x faster than google and with our level of usage, server essentially pays for itself just for 20% of resources. With our level of usage, we would burn through free tier in several hours.

Nice! Is this open source or based on an open source project? I’m interested in doing something similar for one of my projects.

Re: How We reduced our Google Maps API cost

#125
post #98

Earlier quoted context omitted.

Genuine question: wouldn't this be considered write fraud? Last time I asked this question [0] on a different story [1], the responses I got were that it definitely is wire fraud, but this is so mind-blowing that I would like to ask again to confirm. [0] https://news.ycombinator.com/item?id=22362682 [1] https://news.ycombinator.com/item?id=22354357

It's violation of terms of service, and possibly a violation of contract, but it's clearly a civil matter, not a criminal one.

hmm, not sure, some DA might want to prosecute it as theft of service.

Re: How We reduced our Google Maps API cost

#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 placenames with >500 people it's ~10MB of data and that covers the entire planet (surprisingly small). I then wrote a KD-Tree based library to look it up the nearest point in this table extremely efficiently (log(N) time).

I'll admit i haven't updated or maintained it. The server running it has been chugging along well though >5years later. https://github.com/AReallyGoodName/OfflineReverseGeocode

Re: How We reduced our Google Maps API cost

#127
post #96

Earlier quoted context omitted.

Google's ToS says you're not allowed to do any computation on your own? I mean, I'm not disputing it, I just hadn't realized we were already there.

Section 3.2.3 of the Google Maps ToS > (c) No Creating Content From Google Maps Content. Customer will not create content based on Google Maps Content. > (d) No Re-Creating Google Products or Features. Customer will not use the Services to create a product or service with features that are substantially similar to or that re-create the features of another Google product or service. https://cloud.google.com/maps-platf…

For the use case described in the article it sounds just fine. The content part is a big vague. If read very broadly it would be super prohibitive. Perhaps it is?

Re: How We reduced our Google Maps API cost

#128
post #98

Earlier quoted context omitted.

It's violation of terms of service, and possibly a violation of contract, but it's clearly a civil matter, not a criminal one.

hmm, not sure, some DA might want to prosecute it as theft of service.

https://arstechnica.com/tech-policy/2020/03/court-violating-...

A snippet from the article: A federal court in Washington, DC, has ruled that violating a website's terms of service isn't a crime under the Computer Fraud and Abuse Act, America's primary anti-hacking law. The lawsuit was initiated by a group of academics and journalists with the support of the American Civil Liberties Union.

Re: How We reduced our Google Maps API cost

#129

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…

We were going to not display suburb data because of cost. In the end I found a creative commons placename database (geonames.org). For placenames with >500 people it's ~10MB of data and that covers the entire planet (surprisingly small). I then wrote a KD-Tree based library to look it up the nearest point in this table extremely efficiently (log(N) time).

At a previous employer I tried to convince my managers to let me do this for months. They always balked. Their loss.

Re: How We reduced our Google Maps API cost

#130
post #124

Earlier quoted context omitted.

+1, I've made my own geocoding/geodecoding on openstreetmap data, it worked 10x faster than google and with our level of usage, server essentially pays for itself just for 20% of resources. With our level of usage, we would burn through free tier in several hours.

Nice! Is this open source or based on an open source project? I’m interested in doing something similar for one of my projects.

Unfortunately no, this was entirely custom closed source code and customized for one specific use. But you can try making your own map server, when you have data in postgis and search a little, geodecoding is rather easy. Just find geometry with specific tags near your point, then select nearest street number, street name, administrative zone names. I've tested first on one country (low space requirements), importing whole europe can take several days even for multicore servers with ssd.
Post reply on HN