Oh, I thought I said that. That screenshot is from November 2012. That's a production client.

Agreed on generally limiting the use of bow-ties, but I think you are overlooking the best use-case for them, which is the ability to selectively allow U-turns in different directions at a given intersection. In your part of the country, are there few locations where U-turns are only legal in one, two, or three out of four directions? We have that sort of arrangement at every other intersection in LA, it seems, and they are often in areas where the only alternative to a U is a very long and ugly detour. I don't like bow-ties any more than anyone else does, but until we have junction boxes, they serve a purpose, and not exclusively that of disallowing U-turns.

My own dislike for bow-ties is what led me, in my earlier editing days, to make much heavier use of at-grade connectors for left turns. They can effectively allow or disallow U-turns, but don't fit every situation. I still use them occasionally, but have had so many of mine deleted by the CM clutter police, I resort more often to bow-ties, because they're more likely to stick around.

Well, times do change, and fleshing out the guidance means you'll have something to point to (which CMs should be familiar with anyway). Fortuitously, a few such intersections can be controlled adequately simply by disabling left turns which are disallowed anyway. Others can't, but there are other solutions, like AGCs and box-diagonals, all of which can be configured to give the "turn left then turn left" instruction.

While I do agree with you that "Turn left onto [the road you're on]" is potentially confusing, I don't see how "Turn left onto [something], and then turn left onto [the road you're on]" is really much less confusing. They are both bad prompts, and swinging a U hardly resembles a two-turn maneuver than it does a single turn. Yes, it's nice to hear the name that will be on the sign where you'll be making the initial turn, but that doesn't always happen. Because of issues like street name changes at intersections, we often leave the cross segments un-named. In those cases, the double prompt names the street you're on twice.

But in any of these bow-tie or regular-split intersection cases, a quick look down at the screen will show you a highlighted route with a clear turn-around point ahead. It's an understandable visual cue.

Maybe "turn left then turn left" is a "bad prompt", but at least it's accurate. "Turn left" is just plain wrong. We have to recall that not every user is always looking at the screen while using Waze – some don't have dash mounts, resorting to cupholders, and so forth. If "turn left then turn left" is odd, then at the least it might prompt the user to take a look at the phone to try and figure out what it's telling them to do.

And actually, the double prompt no longer names the street you're on twice in those situations. With the TTS changes in 3.8, it will now say "Turn left then turn left on Street-youre-on Blvd".

I'm not sure how you can say that a bow-tie prompt is "utterly confusing", but in the next breath more or less dismiss the far more baffling (lack of) instructions for an un-split road U-turn. I don't think you are considering just how confusing that can be, and how frustrating it is when it happens at a time and place where a mistake and recalculation can cost all the time savings for which you were using Waze in the first place.

Because you, as an editor, never need to choose between the two. Either the road is unsplit and your choices are "don't allow U turns" or "no instruction at all", or the road is split and your choices are "turn left" (bowtie) or "turn left then turn left" (two lefts make a U...).

I agree, and to be honest, I don't know why we don't have those arrow overlays every other GPS provider seems to have. They'd make turns etc. a lot easier to see.

voludu2 wrote:I thought the current "disable all u-turns" policy was in response to this:

DwarfLord wrote: There is the issue discussed in this thread where Waze will provide a route that requires a U-turn but will not give any instructions to do so, which is mind-bogglingly confusing to the driver.

Therefore the decision to disable u-turns everywhere to prevent this happening, and to split roads where U-turns are absolutely necessary -- in effect, the u-turn instructions problem has led to more split roads.

U turns should not be seen at all in routes. If it happens, staff wants to know. Staff wishes, last I heard, are that we leave U turns enabled as they should be, and to report them to staff if they are used despite the massive penalty that's supposed to make them not be given.

CBenson wrote:

sketch wrote:U turns should not be seen at all in routes. If it happens, staff wants to know. Staff wishes, last I heard, are that we leave U turns enabled as they should be, and to report them to staff if they are used despite the massive penalty that's supposed to make them not be given.

I am willing to agree to the change to the guidance based on this staff recommendation. However, if we do see U-turns, let waze know, and the response is - oh waze will route through U-turns to avoid heavy traffic, then I will want to change the guidance back.

Waze has stated recently that they hope to have actual U turn support in the client "really soon"—god knows what exactly that means, though.

I've heard that these bad U turns are only given after a route recalculation of some sort, maybe a traffic-based one. So maybe it's a real time vs. normal routing server problem. But it may become moot before we have time for any real findings.

We could also put it in the California wiki for now not to enable U turns in L.A. because that's where it's been a problem, maybe. It only seems to happen in places notorious for traffic, so maybe we only need to compensate in certain places.

It's a balancing act. It's kind of two different balancing acts: one concerns whether we want to allow Waze to look at and hopefully fix the penalty now; the other concerns whether we want the map to be ready for upcoming U turn support. It's impossible to answer "no" to one and "yes" to the other and apply it. So the options are "yes" to both, "no" to both, or a balancing between the priorities if your answers are "yes" for one and "no" for the other.

Or the real-time server needs to be updated in line with the normal routing server. Really, that's what should happen.

voludu2 wrote:real-time server vs normal routing server?

"normal routing server" = server that computes your route when first ask for navigation.

"real-time server" = server that (re) calculates your route due to deviations or real-time impending traffic.

It is probably actually the same server (or server farm)...but, different algorithms with different applications of the penalties.

I thought the current "disable all u-turns" policy was in response to this:

DwarfLord wrote: There is the issue discussed in this thread where Waze will provide a route that requires a U-turn but will not give any instructions to do so, which is mind-bogglingly confusing to the driver.

Therefore the decision to disable u-turns everywhere to prevent this happening, and to split roads where U-turns are absolutely necessary -- in effect, the u-turn instructions problem has led to more split roads.

that's a pretty clear response. We should definitely update the wiki.

Perhaps replacing the first paragraph and leaving the second alone:

As of November 2014, it is OK to allow the U-arrow where appropriate. Waze will not route the U-arrow. Therefore, whether u-arrows are enabled or not should make no difference to routing at this time. At some time in the future, when Waze is capable of routing the u-arrow, these will become useful to wazers. This advice replaces the advice from June 2014 -- at that time, waze used the u-arrow in routing, but did not communicate this to the driver.

Fortunately, the lack of u-arrow support can be mitigated with a workaround...

-----------------
Edited 19 Nov 2014 -- use "u-arrow" instead of "u-turn" for clarity; make clear this is a change from the June 2014 policy