It is a proof of that Google API is overpriced. Google apparently sells something, that can be computed as well.
Everyone of us software developers sells something that can be computed or made as well. For insane prices no less.
How We reduced our Google Maps API cost
21–30 of 172 posts
Re: How We reduced our Google Maps API cost
#22The 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.
Re: How We reduced our Google Maps API cost
#23This is a pretty nifty solution! To nitpick, I'm curious how much the ETA between successive stops fluctuates.
For example, if you have 2 buses on the route `A-B-C-D-E-F-G-H`, using the same value of T(F-H) for the bus starting off at A and another one already at D, might not be quite right?
Re: How We reduced our Google Maps API cost
#24Well, 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.
Re: How We reduced our Google Maps API cost
#25Author mentioned OSM but they could also use Mapbox's navigation APIs if they don't want to host things themselves.
Re: How We reduced our Google Maps API cost
#26This is a pretty nifty solution! To nitpick, I'm curious how much the ETA between successive stops fluctuates. For example, if you have 2 buses on the route `A-B-C-D-E-F-G-H`, using the same value of T(F-H) for the bus starting off at A and another one already at D, might not be quite right?
They said in the article they sample the time as frequently they deem necessary.
Re: How We reduced our Google Maps API cost
#27Earlier quoted context omitted.
Does it matter whether google or the consumer of the google api caches data?
Placement of the cache definitely matters, even more so if you can take advantage of the more specific data freshness requirements. Disclaimer: I work in Google. But I also worked a bit on effects of cache placement in my PhD.
Why is the fact that you work at Google and have researched caching for your PhD a disclaimer? I fail to see how it denies your previous statement
Re: How We reduced our Google Maps API cost
#28This 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."
That might be a mistake on their side which they might repair now that they started to ask for lots of money for the data.
Re: How We reduced our Google Maps API cost
#29Well, 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.
It's probably against their ToS and Google could detect it and ban all of those accounts, or the servers' IPs.
You can then keep fooling them by creating new accounts or changing IPs (assuming your usage doesn't have clear patterns they could look at).
But such events would be clearly disruptive for the business. Works for a POC, but if your business has actual customers, it's a terrible solution.
Re: How We reduced our Google Maps API cost
#30Taking this approach to its logical conclusion, one could sample Google to infer a congestion heat map for all the main routes in an area, and calculate the transit time estimates directly from the inferred heat map.
IME congestion is also often modal, there's probably reductions in sampling effort you could make by noticing the patterns in how commuters route, whether school is on break, and what the latest roadworks are.