These aren't time restricted turns. They're perfectly legal instructions, just hard to follow. My preference would be to close these as solved and not change anything, however I feel we may need to put something in the Wiki to refer new users to. I expect with this new auto-generated problem we'll find a lot of legal turns restricted in order to "solve" the problems.
You are assuming they'll get backed up there, vs saying "This won't work" and making a right turn causing this error to be generated.AlanOfTheBerg wrote: If Wazers continually get stuck in the back-ups waiting a long time to make a difficult turn, then Waze will eventually have that data and be less likely to give that turn instruction at the times of day where it finds traversing that segment-to-segment pair is very slow. I say let the data do the work.
They didn't start showing up for me until I cleared my cache.
Nah, its just that dead end segments are the only place Waze officially supports U-Turns. So if Waze wants the user to go back the other direction, and there's no "around the block" routes it can give them, it sends them to the closest dead end to turn around.Mike-1323 wrote: This routing down dead end streets has me wondering if the terminal junction on the segment is corrupt or has some connectivity issues. I've noticed that sometimes the JNF script will actually 'fix' the terminal node on a dead end even though the highlights scrip doesn't indicate anything's wrong. I think a self connected terminal node may cause, or at least allow, this type of route to come out of the server.
The problem with this system generated UR, is it will only show 2 segments of the route. The segments before and after the turn. Waze just wants us to double check that the turn is properly allowed, not to troubleshoot the entire route. So if it is allowed, and it looks like a dead end u-turn, mark as solved. If it looks like it is allowed, and its not a dead end u-turn, you might want to scan ahead to see if there's anything else wonky going on at the next few junctions to cause Waze to want to turn someone too early. But with only 2 segments of the route, and no idea where they are going its often impossible to know why Waze gave the turn direction and why drivers ignored it.
I've never had it happen to me, but I've seen many UR's where it shows more of the route, and it has the user turn into a dead end, turn around at the end, and head back out going back the way they came.CBenson wrote:I don't believe that this is true. First, its not like waze gives a U-turn instruction on dead end segments. Second, there are plenty of time that waze does not send me to the closest dead end to turn around, but rather passes up several dead end roads to turn around on another.shawndoc wrote:Nah, its just that dead end segments are the only place Waze officially supports U-Turns. So if Waze wants the user to go back the other direction, and there's no "around the block" routes it can give them, it sends them to the closest dead end to turn around.
I came across another round of these errors this morning. For at least two of them in my area the Waze suggested route went through turns that were marked as restricted. Is this an artifact of using old data, as discussed above, or is there something new afoot?
Here's an example:
https://www.waze.com/editor/?zoom=7&lat ... s=53326141
The route that users ignored was a U turn in the Y
Possibly related: I've noticed a few cases recently where Waze won't route straight through what appears to me to be a correct intersection, but instead send folks down the side street to make a U turn, then return to the route of travel and continue in the same direction. (right turn, left handed u-turn, another right turn). It's usually at the intersection of two divided roads ( # ). At first I thought that the short segments in the intersection (making up the box) might be the issue, but they appear to be of the proper road type, in the proper direction, with the proper turns allowed/restricted.
Unfortunately I don't have a handy example of that.
Thoughts?
jeff
sdg
Here's an example:
https://www.waze.com/editor/?zoom=7&lat ... s=53326141
The route that users ignored was a U turn in the Y
Possibly related: I've noticed a few cases recently where Waze won't route straight through what appears to me to be a correct intersection, but instead send folks down the side street to make a U turn, then return to the route of travel and continue in the same direction. (right turn, left handed u-turn, another right turn). It's usually at the intersection of two divided roads ( # ). At first I thought that the short segments in the intersection (making up the box) might be the issue, but they appear to be of the proper road type, in the proper direction, with the proper turns allowed/restricted.
Unfortunately I don't have a handy example of that.
Thoughts?
jeff
sdg
Area manager for Sterling, VA
OG Wazer, trying to keep up.
OG Wazer, trying to keep up.
I've thought that too. I've seen one instance where Waze tried to route me down a frontage road to get around slow traffic. The traffic was caused by a crossing guard, and the frontage road emptied at the same intersection, so the route would not only have been slower but if enough folks followed it it would really mess up traffic when school is getting out. Not much we can do in this case, but it does show Waze trying a similar tactic to get around a slow intersection.Mike-1323 wrote:The way that I've chosen to interpret that type of routing is that there is such a large delay in the junction transit time when waiting for a red light at an intersection that the routing server calculates it is faster to take a low-delay right turn, two low-delay left turns and another low-delay right turn. Of course this theory falls apart when the routing server directs somebody to make a u-turn on a dead end and then continue in the same direction on the original road when there's no light or stop sign along the original road.
jeff
sdg
Area manager for Sterling, VA
OG Wazer, trying to keep up.
OG Wazer, trying to keep up.
I'm seeing the "save button unavailable" issue as well.
Area manager for Sterling, VA
OG Wazer, trying to keep up.
OG Wazer, trying to keep up.
sweet baby jesus I have never seen so many SRP's before.
https://dl.dropbox.com/u/72242/WazeLevel3.jpg
Waze Warrior - iPhone 5 AT&T iOS 6.0.1 - Waze 3.5.1.0
Area Manager: Maryland - Central Harford County, Central Cecil County
Waze Warrior - iPhone 5 AT&T iOS 6.0.1 - Waze 3.5.1.0
Area Manager: Maryland - Central Harford County, Central Cecil County
Hehe. Didn't mean to sound like I was complaining. I've been working nonstop on this entire area and it was just funny to see so many MPs before.CBenson wrote:Well then send a note of thanks to arl16, jondrush and the other editors that have also been working in NE MD, it really doesn't take long for the MPs to clutter the map without constant vigilance. I've been leaving Baltimore for you guys and trying to make some inroads in DC, where the problems have piled up a bit.joshellis625 wrote:sweet baby jesus I have never seen so many SRP's before.
https://dl.dropbox.com/u/72242/WazeLevel3.jpg
Waze Warrior - iPhone 5 AT&T iOS 6.0.1 - Waze 3.5.1.0
Area Manager: Maryland - Central Harford County, Central Cecil County
Waze Warrior - iPhone 5 AT&T iOS 6.0.1 - Waze 3.5.1.0
Area Manager: Maryland - Central Harford County, Central Cecil County
Re: Changes to Editor - New Automatic Detected Problem