Those choices are insanely expensive for Google to provide.
Every unique configuration of options has to be hosted by hundreds of servers in each region. The cost of running the routing service is proportional to 2 ^ (the number of options). It's because everything has to be precomputed for fast lookups, and the lookup tables for one set of options aren't valid for another. See [1].
This is why Google hasn't added any more options in ~a decade. Even then, some combinations of options use various approximations and in some cases don't return the mathematically best result, or take longer to do so.
[1]: https://bib.irb.hr/datoteka/644571.MaueSandersMatijevic.pdf
That's a weak hill to die on with the money G makes. That's just the cost of doing business. People using maps need choices. If you as a map app choose not to provide an option, that's just an area a competitor can one up you. Once they do, you have to play catch up. That could be advantageous as you see what the competitor did that does/does not work allowing you to shortcut some of the R&D.
It's not "doing business" if people using maps don't provide enough revenue back to the company either directly or through advertising. The reason Google makes so much money is that they are careful to implement features that are revenue positive.
I don’t see how that can be true. With, conservatively, 50 million destinations, that would mean 25E14 different precomputed routes (edit, that’s exactly what the paper you reference argues: An extreme way to accelerate queries is to precompute all shortest path distances d(s, t). However, this is impractical for large graphs since it requires quadratic space and preprocessing time.)
Also, the average GPS without any internet connectivity can compute routes. Surely, those don’t store those precomputed routes.
What likely is true is that it may be a bit harder to do a bicycle route planner. Slightly simplifying, a planner for cars, given two places A and B relatively far apart, ‘just’ needs to find the best route from A to any on-ramp to a highway, from any highway to B, and a route only on highways between the on- and off-ramps.
On the other hand, bike routes that have to be planned typically will be a bit shorter.
Together, that means it isn’t that hard to compute routes on the fly. https://routeplanner.fietsersbond.nl/ does exactly that, giving you options such as “shortest route”, “fewest interruptions”, “racing”, “fewer cars”, or “recreational”.
It's similar to the way that we intuitively navigate by car - if you drive from (say) London to Glasgow, you don't bother weighing up the many options: rather, you take whatever local roads get you to the M1 fastest, then follow M1, M6, M74, and then whatever local roads get you to your exact destination.
Generally bicyclists have a fixed starting point so you could cache the results and improve them over time. (Obviously cross-country would require further work to support efficiently.)
I’m all for “anything can be done in the cloud” but if the cloud can’t efficiently handle this, I still have a couple of supercomputers laying around that I’d be happy to let puzzle over my bicycling needs for a few minutes (or overnight, or for a few weeks when charging) if that helped me find a more scenic route someday that isn’t much slower than the direct one.
Google Maps' offline maps also include routing information. The downloads are pretty small, which definitely excludes the more space-intensive algorithms.
No. A small area means a small download.
I would argue that updating the routing algorithm's data structure isn't the expensive part of reacting to live traffic. Getting and processing the raw data sounds a lot harder than re-running the customization phase of routing preprocessing.
So I don't think it is that expensive or insummortably difficult.
https://services.google.com/fb/forms/streetviewussuggestions...