I'm going to recycle my visual from this post. Imagine that Seg4, Seg5 and Seg6 are one-way north and there is another southbound carriageway to put this in the context of the plain box intersection.

PesachZ wrote:Regardless of how long the left turn delay is due to lights, at that short segment pretty much all directions should appear equal to Waze.

In the context of my diagram, are you saying that that the travel time to traverse Seg5 should appear equal to waze regardless of whether going to Seg6 or Seg7? If so, I agree.

PesachZ wrote:The left may be slightly slower, but the right turn, and straight should be equal in transition time.

The left may be significantly slower. We see right/u routes instead of left turns. The explanation has been that waze calculates that on average these routes are faster. This means that waze data shows the left turn is significantly slower than the right turn. So significantly slower that waze calculates that the time to leave the intersection going right, make the U-turn, and come back to the intersection is less than the average difference between making the left and making the right. This I can find conceivable where there is separate left turn signal.

The problem with the plain box is that regardless of whether you are turning left or going straight from Seg4, you wait at Jnct2 for the traffic light and proceed to Seg5. Thus, the theory is that waze averages all the traffic that waits at Jnct2 and proceeds to Seg5 together, that is both the straight through traffic and the left turn traffic is lumped together as traffic that stops at the end of Seg4 and then proceeds to Seg5. The theory with right/u/right routes is that the left turn data contaminates the straight through data enough for waze to think that the right/u/right is faster than going straight. Without the cross-segment (bowties) or with separate cross-segments for straight and left-turning traffic (box with diagonals), the left turn traffic data would be retained separately from the straight through traffic, thus eliminating the contamination.

PesachZ wrote:Therefore, a right followed by a u-turn and another right, should always be longer to Waze in time and distance, than just going straight, regardless of segment length.

But we do get routes like this. Waze does in some circumstances calculate that a right followed by u-turn and another right is faster in time (on average) than just going straight.

PesachZ wrote:If you meant to say "With the cross-segment (bowties) or with separate cross-segments for straight and left-turning traffic (box with diagonals),... I agree.

I'm refering to Seg5 as the cross-segment. So, I just meant that bowties have no cross-segments as the intersection is reduced to a simple point. In essence, to form a bowtie, shrink Seg5 to nothing so Jnct2 and Jnct3 become the same.

sketch wrote:

CBenson wrote: But we do get routes like this. Waze does in some circumstances calculate that a right followed by u-turn and another right is faster in time (on average) than just going straight.

This is an example of right-U instead of left though, not right-U-right instead of straight.

Hmm, I'm getting GTGreybeards post of Aug 17, 2013 10:54 am in the thread showing a right-U-right instead of straight. That was my intention to show that waze can route right-U-right.

sketch wrote:Right-U-right should be taken care of by existing detour prevention for all but streets and primary streets anyway.

Good point.

sketch wrote:I haven't seen an example of that in a while.

Maybe a simple box intersection could commingle the data enough to make a right-U instead of Left happen, but a dedicated left turn lane can be slow enough to make a (pass-thru-then-)U-right instead of Left happen (I have proof!). I imagine a bow tie or diagonal could have the same effect (at least, if the transition times are actually being used). I don't get that U-right anymore though, so maybe small detour is in place?

I do think this all very speculative. I don't think the potential data gathering qualities of the various configurations need to be discussed in the wiki. I just thought it worth mentioning when thinking about updating the wiki.

I haven't been routed right/U in quite some time and I haven't seen complaints right/U routes in the forums recently either. So maybe the small detour prevention is in place.

PesachZ wrote:what would you do

If only the final sign at split lacks the control city, but others approaching the exit include the control city, I go ahead and include the control city. Otherwise, I put a space after the cardinal direction ("I-50 W ") to make the name different. However, I can't find any I've done with the space that still exist on the map.

DwarfLord wrote:Except, signage preceding the exit suggests that the road splits.

I liked your logic and would have argued that the signage in your screen shot does not suggest a split. One direction is clearly marked exit, while the other is not. Thus, its quite clear which way you should go in the absence of an instruction. However, the signs on the bridge before those signs don't mention the exit and seems to suggest split much more to me.

DwarfLord wrote:This signage confused a visiting Wazer who submitted a UR asking for continuation guidance. Thus the additional language for when signage suggests a split.

I think this point is important. If we are getting URs saying that users are confused, then we should look to make changes that will provide better instructions.

For instance, I'm still not sure what the "stay to the left" instruction discussed here should say. But copying the BGS results in much confusion, so we've deviated from the signs.

kentsmith9 wrote:Is it really a problem when you get a keep to the right or left at a true split vs a true exit at an interchange?

No. That's kind of what I meant with the UR comment. If people are confused we should try to provide better instructions even if its an exit rather than a split.

DwarfLord wrote:If there were exit-only striping present as well I would say this is not a case for a wayfinder; if we cater to drivers who would miss striping and three massive signs spread over a mile of open highway then we would annoy all the others with too-frequent instructions, especially the commuters who already know the road and who make up a big part of the Waze user community.

The more I think about this, the more I think we are leaving something out here. There is no real downside to more wayfinders except the point that wayfinders can "annoy commuters with too-frequent instructions." Thus, there's really no downside to a wayfinder if there is not another one for a hundred miles in either direction. So it seems to me we are properly taking into account what drivers expect for a particular interchange, but not taking into account what long distance drivers might expect when they enter a highway. It can be disconcerting to have the next instruction be for an exit a couple of states away and 10 hours away. Although, the continue on for 10 hours instructions do help mitigate this issue.

I'm not sure what you call the opposite of splits - confluences? Part of the problem is that we don't always give instructions when you change highways if one highway simply merges with the other. Thus, you can have the next exit be on a different highway with a different numbering scheme. So for instance if this segment is freeway you get no notice that you transitioning from Route 32 to I-97. This is a problem for example if you are directed to the next exit of I-97: "Exit 5: MD-187 / Crownsville" as there is an exit 5 on Route 32 as well a few miles before the confluence. So getting a "Exit 5" instruction for the I-97 exit when you are still on Route 32 is a problem. So the final segments of Route 32 are ramp segments to trigger the keep left to I-97 instruction. In fact this instruction is unnecessary for traversing the interchange itself. But the instruction is needed for clarity in routing that you can't determine by simply looking at the lane drops. The big difference from the examples being discussed, is this is not a split, rather a confluence where the highway name is changing. You are on Route 32 and the pull-through sign is for I-97. I do think this should be raised in the wiki somewhere. For confluences where the pull through sign is for a different highway than the highway you are on, then an instruction is appropriate for the main lanes.

This shows up for example in for a route like this. I am hoping that you will see an alternate route down US-301 across the Chesapeake Bay Bridge and into Washington DC. The problem that I experienced a while ago is that I was further north on College Ave in Newark Del expecting to get instructions onto I-95, but the next instruction was to "Exit Right to L St." It took me a bit realize the instruction was in 110 miles and was for a turn in Washington DC. The issue is that you get no indication that US-301 begins at this intersection, that US-301 and US-50 begin a concurrency here which ends here. So you change from US-301 to US-50 with no notice. This is further compounded by the fact that US-50 is an eight lane interstate from the end of the 301 concurrency to the Washington Beltway and then just continues on into the city as New York Ave. There is no exit you just transition from interstate to city thoroughfare, so you get no instruction. At no intersection along this route do you need an instruction to understand which way to go through the intersection. But the lack of any instruction over the whole route can be rather confusing. So it seems to me that we should look not only at the configuration of each interchange. Seems its worthwhile to consider both whether the wayfinder would annoy communters with too-frequent instructions and whether the lack of the wayfinder would confuse visitors with too few instructions. Codifying this would be difficult. But again if you get URs from wazers that are confused that is a good sign that more instructions would be helpful. The Route 32 segment was changed to ramp in response to URs complaining about the lack of an instruction mentioning I-97.

I agree with all that is being said here. I do not think the no-name segment after the split is likely to break the detour prevention. I think the no-name segment before the split is much more likely to. However, I have no tests to confirm this.

PesachZ wrote: I think we can document the order of preference should be to name the two wayfinder segments to:
1) Match the BGS provided it is different than the lead-in segment name (s-in)
2) Be no-name.

I don't see why this isn't universally applicable. If the lead in segment is no-name, then it is by definition different from the BGS and 1) applies.

PesachZ wrote:Take a look at the CT example I posted earlier where the right OUT segment is not a stub, rather continues as one no-name segment to the next exit. Theoretically such a situation could end up configured in a way to possibly break detour prevention. I was just trying to be proactive and document to be mindful of that, and prevent it. Trying to put the theory with the rule, so others when (not) to bend them.

Agreed, all wise. But making it a stub solves the problem, so the rule should work

PesachZ wrote:

CBenson wrote:

PesachZ wrote: I think we can document the order of preference should be to name the two wayfinder segments to:
1) Match the BGS provided it is different than the lead-in segment name (s-in)
2) Be no-name.

I don't see why this isn't universally applicable. If the lead in segment is no-name, then it is by definition different from the BGS and 1) applies.

Great point, except where there is no BGS

Hmm. I guess I'd say if there is no BGS you don't need a wayfinder. But I guess I shouldn't rely on the DoT to alway provide helpful signage. I'm still trying to figure out what is a clear instruction for the "split" discussed here.

PesachZ wrote:I agree that a stub will fix it, but only if the next segment after the stub is named. If it is needed to be unnamed, we will stool have the problem and an additional issue.

Again agreed. But if the segment needs to be unnamed going into a ramp it would be for some other reason than getting the wayfinder instruction. So that other reason would break the detour prevention rather than the wayfinder guidance.