Live data from Hacker News

How We reduced our Google Maps API cost

blog.cityflo.com

61–70 of 172 posts

Re: How We reduced our Google Maps API cost

#61
I believe there's another way to look at it. More from the consumer's POV and less as pure technology per se.

First, is the fuild ETA absolutely necessary? Surely the bus has a schedule. Is it on time, or not. If not how late might it be? That's not the same as ETA. Certainly, they've collected and keep collecting enough data to infer such things. That is, 2 mins late to Stop B translates to what at Stop F and stop N.

The consumer doesn't need ETA per se. They need to know if they're going to be on time to their destination or not.

Like putting mirror next to an elevator to shorten the perceived wait; there might be other opportunities to solve this problem.

If you're interested in such things, this book from a year or so ago was intriguing.

Rory Sutherland

Alchemy: The Dark Art and Curious Science of Creating Magic in Brands, Business, and Life

4.6 out of 5 stars

https://www.amazon.com/Alchemy-Curious-Science-Creating-Busi...

Re: How We reduced our Google Maps API cost

#62

The conclusion I get from this is not plan anything on "free" features promoted by SaaS providers because that can hit you hard in the future. Either plan based on something payd and covered by a contract or try to come up with another solution, maybe an in-house solution, maybe a free solution with a failover based on another provider.

At a cloud storage company i worked for we had the most cost-intensive part of our infrastructure, the object storage ready to be switched over from Azure to AWS, just in case.

Re: How We reduced our Google Maps API cost

#63

Like in all of Google's "free" apps, the consumer is the product. They gather your data through Waze and Google maps and sell it for nice money to paying customers. Maybe they can expand on the model a bit and let the paying customers query the API to find out what you were talking while driving. I'm sure that they can find a justification for it. I was trained to think that companies like Google was all about doing…

These comments are so boring and predictable. Of course, Google makes their traffic data available to end-users too, in the Maps app and website. Yes, quite likely they're deriving it by aggregating driving data, but it's rather transparent as far as it goes. It's harder to say that about other Google services.

Re: How We reduced our Google Maps API cost

#64

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/…

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.

Re: How We reduced our Google Maps API cost

#65

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/…

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.

Re: How We reduced our Google Maps API cost

#66
post #11

This seems to be violating the Maps API terms of service? https://cloud.google.com/maps-platform/terms (a) No Scraping. Customer will not export, extract, or otherwise scrape Google Maps Content for use outside the Services. For example, Customer will not: (i) pre-fetch, index, store, reshare, or rehost Google Maps Content outside the services; (ii) bulk download Google Maps tiles, Street View images, geocodes, direc…

Caching is allowed (for up to 30 days). Here are the specific terms for the API in the article: https://cloud.google.com/maps-platform/terms/maps-service-te... "Customer can temporarily cache latitude (lat) and longitude (lng) values from the Directions API for up to 30 consecutive calendar days, after which Customer must delete the cached latitude and longitude values."

But lat/lng pairs are pretty useless on their own, particularly with a travel times app

Re: How We reduced our Google Maps API cost

#67

Like in all of Google's "free" apps, the consumer is the product. They gather your data through Waze and Google maps and sell it for nice money to paying customers. Maybe they can expand on the model a bit and let the paying customers query the API to find out what you were talking while driving. I'm sure that they can find a justification for it. I was trained to think that companies like Google was all about doing…

> Like in all of Google's "free" apps, the consumer is the product. They gather your data through Waze and Google maps and sell it for nice money to paying customers.

Huh? This article is talking about a Google PAID product and how to avoid paying for such product.

Why are you complaining over Google here? Shouldn't you be complaining about the company who's looking for workarounds on how not to pay for a product and essentially breed the culture where selling consumers is the only viable business model?

Re: How We reduced our Google Maps API cost

#68
post #43

Earlier quoted context omitted.

Is that okay in terms of the ToS? How frequently did someone have to create new accounts? Won't Google just ban the server's IP?

Needless to say, that's very much against the TOS and it's a matter of time until they get blocked. Surely at some point it'd be easier and cheaper just to pony up for a license?

... obviously not? :)

Re: How We reduced our Google Maps API cost

#69

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...

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, which helped us in scaling up our fleet with no additional cost.

Re: How We reduced our Google Maps API cost

#70

It is a proof of that Google API is overpriced. Google apparently sells something, that can be computed as well.

If the quality of every dataset was equal this argument might be more compelling but we know it's not so this rings a little untrue.

Besides, I suspect that Google knows exactly what their data is worth and keep a very close eye on the price/demand model.

Just because something is subjectively expensive doesn't make it objectively overpriced.

Post reply on HN