Thortok2000 wrote:You must be confusing me with someone else about the Irvine thing.

Oops, yes, for some reason I thought I was responding to someone else. Sorry about that! I don't know why I didn't see your name in the quote when I was replying.

Thortok2000 wrote:That is a conundrum. Does it think the 'weird' route is faster or does it think the simple route is slower? How is the user supposed to know which way to go to 'teach' Waze better?

It must think the simple route is slower, because as soon as I don't take the first turn to deviate from my current road, it recalculates and the new ETA is 2 minutes earlier! This is what suggests to me that Waze is lagging behind on its view of what was happening on the street that I'm driving down, and as I'm going down it, it's finally catching up (but won't spontaneously reroute just to save 2 minutes).

This has happened twice on different streets that I drive down regularly, but hasn't happened before or since (routing around a block for no apparent reason).

One thing that it will frequently incorrectly suggest is where I want to take a left turn, it suggests going past the left turn, making a U-turn, then making a right turn at the original intersection. Because the road is a divided road, the U-turn is actually seen in Waze as two left turns, which causes URs at this intersection because the verbal directions are confusing to drivers ("turn left on San Marino, then turn left on Alton" when you are driving down Alton). Once in a blue moon due to traffic patterns, you can save a few seconds with this maneuver, but there are lights at both intersections and in heavy traffic you will generally lose a lot of time doing it. And yes, I have taken the Waze suggestion a few times, which is why I know that it's almost always a terrible choice. And when I ignore the "drive past and take a U-turn" directions, the ETA always improves by at least a minute from what it was before I approached the intersection, so clearly my turning left was substantially faster than what Waze thought it would take to drive past and take the U-turn.

Thortok2000 wrote:There's two possibilities for it to route a block out of your way like that. Either the speed data for those additional unnecessary segments is ridiculously high, or the speed data for the segment in front of you is slow.

I would think, if you see an actual traffic report on your map indicating high traffic in front of you, and there isn't any, then simply drive through it and that should tell Waze the traffic is gone. However, if you don't see a traffic report, go the recommended way, to teach Waze that way isn't super-fast.

What I think would be best, however, is if there's not a case of restricted turns or unconnected roads on the path the user DOES take, that if a user avoids a route that reconnects with the path the user takes, that the speed data of the route they didn't take should automatically be reduced, and it shouldn't throw up a "most users don't follow the route" error for WME.

Basically, a "is the route they took a possible route to take" check before throwing this error. If they took a route that doesn't cross restricted turns or oneway traffic or something, then the "most users don't follow the route" error shouldn't pop up in WME and instead the route recommended should be devalued.

It takes time for Waze to notice congestion or lack thereof, and near where I live and drive, congestion appears rapidly, and when it dissipates, it can vanish rapidly. It's extremely variable from day-to-day, so historical data is not always applicable (Monday one week the backups will start at 7:15, next week they'll start at 7:45, and occasionally not at all). There are also cascade effects and mini-gridlocks and by the time Waze recognizes them, the situation has already changed.

Another very similar issue, but with a twist:

https://www.waze.com/editor/?zoom=6&lat ... 46&env=usa

The suggested route leads directly into a gas station, and is the only entrance to said gas station. If the user wanted to go to the gas station, then why wouldn't they follow that route, and if not, why would they?

Why on earth would Waze route someone through a gas station instead of straight through on Route 97 is beyond my ken.

This can't be fixed by setting a No U-Turn restriction because the road segment goes into a looped parking lot road.

In general, I find that this most often happens when the short dead-end in question has the U-Turn at the end marked green. I disable it and mark the problem solved. However, I often see this problem also when the U-Turn is already disabled.

I'm not sure if this is a bug in the code or the road data.

Amen to that. I can't tell you how many times I see "wrong route" URs with no destination address and no way to figure it out from the green and/or purple lines.

My understanding is that the Waze app currently ignores the house numbers we put into the editor and uses Google Maps' data; so when correcting a house number we should also submit an error with Google. Annoying, particularly knowing that Waze is now effectively a Google product.

Another routing issue I see is that users in my immediate area (rural north-central Maryland and south-central Pennsylvania) tend to ignore Waze routing if it takes them down very narrow roads (such as this one -- where a "wrong routing" report was actually filed; Waze told the user to turn left from Keysville Rd onto Reifsnider Rd and the user stayed on Keysville) or gravel roads (such as this one -- haven't seen a UR here yet but it's a road in my area that I try to avoid if it's raining). Both of these roads, according to local area managers, still get marked as paved, so even if a user has "avoid unpaved roads" set, those roads won't be avoided for routing.

In my experience, after a little over a month of using the Waze app every workday, Waze consistently tries to route me between home and work using the Baltimore Beltway (I-695), even at times of day when I KNOW FOR A FACT that this routing involves absolutely brutal rush-hour traffic delays and that I should use MD-97 and I-70 instead. Regardless of what Waze says, I'll always use the latter route unless I'm traveling outside the hours of 6:30-9:30a or 4:00-6:30p. I've been doing this commute for two and a half years now, so I know better than the Waze app. But we've gone way off-topic now -- Here we're talking alternate routes that are several miles apart from each other versus a few city blocks.

In my case, however, though surely Waze has enough users who commute using the Baltimore Beltway to know that its use is almost always a bad idea during rush hours, my alternate route using a winding, two-lane country road may not have enough tracks; though I consistently see the same Wazers showing up on my map using the same winding, two-lane country road.

I've tried teaching Waze, but it's not a student who is exactly willing to learn.

What would really help is if the destination was included in the report. We don't know where they're being routed to, so we don't know if the route provided is a good route or not.

From a client's perspective, I've often seen really horrible routing happen when the destination address is set closer to the wrong street than to the right street. This causes the routing to loop around onto the streets behind the destination instead of directly to the destination. The only way to fix this would be to fix the destination address location, hence why knowing what that is would be beneficial. You just have to wait for UR's instead of automatic, and hope the user puts the destination in the report.

I've also seen a 'routing ignored' happen a lot when it's directing people off of the main travel areas. I assume this is to avoid traffic, and people who don't understand that Waze is trying to get them to avoid traffic just ignore the route that would get them around traffic and keep driving down the main roads. This is particularly the case when there's a potential path out of where they were routed to back towards the direction they were traveling. (Obviously doesn't apply if they're routed into a dead-end or no-outlet area.)

And of course the easiest to fix ones are when there's a turn that's restricted or isn't restricted that needs to be fixed. But when everything looks fine to me, I assume it's because people don't understand that they're being routed around traffic.

@slandrum:

If you have the time and/or gas to spare, always drive Waze's recommended route. This causes it to 'learn' that the route does indeed actually suck. If you don't have the time to spare, then just go the faster way, this too helps Waze.

More details in the FAQ: https://www.waze.com/wiki/FAQ#Why_doesn ... _routes.3F

You must be confusing me with someone else about the Irvine thing.

That is a conundrum. Does it think the 'weird' route is faster or does it think the simple route is slower? How is the user supposed to know which way to go to 'teach' Waze better?

There's two possibilities for it to route a block out of your way like that. Either the speed data for those additional unnecessary segments is ridiculously high, or the speed data for the segment in front of you is slow.

I would think, if you see an actual traffic report on your map indicating high traffic in front of you, and there isn't any, then simply drive through it and that should tell Waze the traffic is gone. However, if you don't see a traffic report, go the recommended way, to teach Waze that way isn't super-fast.

What I think would be best, however, is if there's not a case of restricted turns or unconnected roads on the path the user DOES take, that if a user avoids a route that reconnects with the path the user takes, that the speed data of the route they didn't take should automatically be reduced, and it shouldn't throw up a "most users don't follow the route" error for WME.

Basically, a "is the route they took a possible route to take" check before throwing this error. If they took a route that doesn't cross restricted turns or oneway traffic or something, then the "most users don't follow the route" error shouldn't pop up in WME and instead the route recommended should be devalued.

@tckma - My suggestion would work there too.

Basically the steps are as follows:

A) User sets a destination.
B) User travels whatever way they think is best. Assuming for this example though that they do not go the way Waze recommends.

If the following conditions are true:

- The user rejoins the original route at some point before reaching the destination.
- The point between where the user left the route and where the user rejoined the original route is a driveable route, with no errors such as restricted turns and stuff (this should always prevent the "did not take the recommended route" error anyway, since there's nothing for us editors to fix, the map's right, it's the routing that's potentially wrong)
- There is more data for the route the user took than there is data for the route the user didn't take

Then C) Waze recommends the route the user took in the future instead of the previous recommended route.

This follows the 'users are smarter than Waze' and the 'learn my route' philosophy.

Alternate suggestion:

If there is a significant difference between which route has more data, Waze always routes the user in the way that has less data. This follows the "give Waze the data it needs to make the smartest decisions possible" philosophy. The con to this is that people without the spare time to oblige Waze's weird routing requests will just ignore the route and it will never learn the data. In all honesty, I think this is most similar to the current model, which is again why I think obliging Waze's weird requests is the best route to take (literally.)

Alternate suggestion:

Client-side, offer options to the user that indicates when routing is going a particular way to avoid traffic. For instance, a purple line that goes straight ahead, and a yellow line that goes right. An example voice prompt would be "To avoid traffic, turn right ahead at Main Street. Otherwise, continue straight." Then the user can be like "there is no traffic" and ignore the prompt or "okay whatever you say Waze" and follow the prompt.

An alternate to the alternate is to simply offer both the shortest and fastest route simultaneously. The faster route being the only one that tries to avoid traffic, of course. Where the routes fork, prompts would begin with "for the faster route, <prompt>" or "for the shortest route, <prompt>" with again yellow lines reflecting shorter and purple lines reflecting faster. The route you didn't take could be recalculated on the way.

This would be an advanced form of navigation and not the default as it would be too confusing (and/or spammy) for regular users, unfortunately. =/

CBenson wrote:

tckma wrote:

tckma wrote:In my case, however, though surely Waze has enough users who commute using the Baltimore Beltway to know that its use is almost always a bad idea during rush hours.

It seems not. I don't know why.

Probably that is a common case of unintended consequence of wazers, i.e., wazer do not use the rushed route because they know that it is crowed. Those that drive to the rush route are not wazers. Waze sever compute the route without wazers as the fast route due to lack of average historical speed.
Consequence, wazers are sent to crowed trafic...

Just my thoughts, I have no data to verify it. Only the fuzzy view of the problem. Maybe the solution is to take the waze to the rush to build the data to avoid it for those that do not have knowledge about the best route.


Sent from my iPad using Tapatalk