This is my daily commute: https://www.waze.com/livemap?zoom=13&lat=37.2967&lon=-121.91322&from_lat=37.29819&from_lon=-121.86956&to_lat=37.26131&to_lon=-121.96202&at_req=630&at_text=10%3A30
Basically, the freeways form a trapezoid, and I can either take the southern route: S87→N85→S17, or the northern route: N87→N280→S17. In the linked live map, the routings all look OK. If there are no problems, time and distance differences between the routes are minimal; the southern route is usually slightly faster in estimates (and is the #1 route suggested), but if the stoplight at Curtner/87 is changing, it’s faster for me to use the northern route.
On the app, regardless of traffic conditions, when I check alternate routes, the northern routing tries to cut the corner between N280 and S17 – exiting at Southwest Exp, even though this is usually 3-5m longer. That’s a problem, because I can’t tell if that routing is just an error, or if there’s actually slowdown at the 280/17 interchange.
It depends on what time of the day you are traveling. When I look using the tools I have, for most weekdays at 7 am, using the Southwest Exp cutoff is only 45 sec longer on average because of the backup from I-280 getting onto 17 S. At 8 am, the difference extends to over 2 minutes.
I don’t know when you ask for a re-calculation. However, if you are already traveling on SR-87 N, Waze will start discarding SR-87 South route. None of us really know the criteria Waze uses to calculate routes as it is a proprietary company secret, but Waze does give you 3 alternate routes…it just may not be the ones you are expecting.
The times I normally travel – when traffic is usually clear – SW expressway will always be several minutes slower, even by Waze estimates. If I recalculate after heading north on 87, it immediately recognizes that staying on 280 to 17 is the faster route. It seems like a bug in route calculation that it doesn’t show the faster route just because it’s the second option instead of the first. It’s weird that it only happens on the app; it calculates correctly on the website.
If it was the faster route when Waze initially calculated your route, it will try to stick to that route even if it’s now slower. I see this every day when I take a cut-off from the Waze route that cuts off two minutes and Waze consistently tried to get me to make U-turns and other crazy antics to get back on the original route even though the way I’m going is faster (even by Waze’s own estimates).
This is still happening. Is there a way I can know whether the Waze dev team has acknowledged this bug?
The Waze dev team doesn’t habitually monitor these boards. And, like any developers, they are reluctant to pursue issues that can’t be reliably repeated with a series of known steps. For better or worse, they have also been known to prioritize development in ways that don’t match even the most desperate concerns of the volunteer editing community.
So I suspect we are on our own until we can isolate this behavior ourselves, and even then we may still be on our own.
One thing you can do, and that’s the next time you observe this routing, take one or more screen shots and post here.
Here is an example of a navigation problem report I posted some time ago, with screen shots demonstrating what I still think was an egregious Waze fail. If you can post detail like this it could help. Of course, my post never garnered a single response so ultimately it was unproductive! But maybe someone will see something in your screenshots that would otherwise be overlooked.
Rtorchia - Have things changed at all for you? I did some research, identified a potential trouble spot and attempted a fix. In live map, the Southwest Expressway “shortcut” now receives lower billing, and I’m interested to know if you’ve seen the same in your daily travels, or if we need to look further.