CBenson wrote:Your conclusion doesn't seem to address your premises.

PesachZ wrote:Based on my under standing of the turn delay recordings, and how it is affected by these small segments it would not cause the right-u-right vs. straight.

Here you say right-u-right vs. straight.

PesachZ wrote:This will not cause a Right-Uturn-Right though instead of a left unless the time it takes to complete that maneuver is less than the time it would take to pass through the intersection from the beginning of that short segment and turn left (a very short time). If the situation is such that a right-u turn-right is faster than a left, it would be suggested even without the short segment in the mix.

Here you say Right-Uturn-Right instead of a left.

I think I agree with your facts and logic, but you haven't actually addressed right-u-right vs. straight routes.

The theory is that the short segment between the split segments causes waze to fail to distinguish between traffic turning left and traffic going straight. Say there is a long red for the left turn when the straight through is green, but not the opposite, a fairly common configuration. Then as waze doesn't distinguish between the left turn traffic and the straight traffic, waze thinks the left turn is a faster than reality and that the straight traffic is slower than reality. We do see the occasional right-u-right route. Anything that causes waze to underestimate the time of the straight route, should in theory contribute to more right-u-right routes.

The question is simply whether the cross-segment causes waze to fail to distinguish between left turn traffic and straight traffic. If the bowtie and the box with diagonals configurations enable waze to distinguish between left turn traffic and straight traffic, then that would be an advantage to those configurations.

qwaletee wrote:PZ,

Are you sure? At a dual-dual intersection, the right turn will not have the short segment, so there will be two speed record: right, and combined straight+left. There are lot of combinations now (straight predominates or not, left turn signal or not, long queue for left or not, equal queueing on all directions or lopsided).

In the case of a lopsided queue, I can see a problem. Say N/S has a long red light and E/W has a short red, and right turn is permitted on red. Northbound traffic is going to look like this, The main lead-in road has two exits, right and straight/left Due to the long light, right looks very attractive, even if it has to wait for pauses in traffic. Westbound traffic overall looks better than northbound, and particularly the westbound right turn, which is also less affected by traffic light. The R-U-R from N-(W-U-E)-N might look like the best choice. In fact, in the real world, this may also be true, discounting problems making U-turns.

Even if right turns are not permitted on red or effectively unlikely due to traffic, the same might play out. Due to the long traffic light, the straight exit speed (even discounting left turn effects due to the box) is going to be diminished, as, say, only one-third of traffic actually continues through at speed, and two-thirds simply has to wait. So right-exit speed for the segment will be very close to the straight-exit speed for the segment. On the westbound run, traffic will appear to be much faster due to the shorter light. If the northbound incoming "long" segment is itself particularly slow (say, due to badly timed previous traffic lights or overall congestion), then the backup form the left turn may be enough to put the right turn at parity or better, with the speed for the westbound segment contributing marginal additional time. Since Waze is still "dumb" enough to be fixated on speed to the sacrifice of complex routes, it will sometimes give R-U-R in this case, too.

CBenson wrote: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.

TimeCross.png

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.

CBenson wrote:

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.

CBenson wrote:

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.

CBenson wrote:

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.

dbraughlr wrote:Does this mean that segment length less than 15 m is not a way to prevent a U-turn?

sketch wrote:

PesachZ wrote:Even then it's a penalty not an absolute restriction, so in the right circumstances it may still be used.

Sent using Tapatalk for Android 4.4.2

I will say for the record that a lot of things we thought to be "absolute restrictions" are actually just very large penalties -- for instance, dirt roads, when set to avoid, have something of an hour penalty.

qwaletee wrote:

sketch wrote:Diagonal(s) in the box and AGCs. The page is under construction.

Consider not calling them diagonals. They don't have to be. In fact, I prefer in many cases to "declutter" the appearance by having the AGC follow the path of the standard road, sometimes with rounded corner.

In my head, I hear "turn-bypass segments."

kentsmith9 wrote:

qwaletee wrote:

PesachZ wrote: I agree that while the utility might be necessary, the appearance of diagonals are unsightly IMHO.

Exactly, If you give it 2-3 geonodes and have it parallel the "bypassed" roads, very closely, you can hardly see them on the map.

The whole reason we draw them in it to prevent automated errors from the server when the vehicle GPS is too far from the intersection point. Having the road close to the intersection may defeat the purpose if it is not close enough to the actual road turning the corner.

These situations are part of the reason Bgodette came up with the Junction Box recommendation. Therefore we are going to replace all of them with junction boxes soon.

kentsmith9 wrote:In the new subsection on Interchanges in the Wayfinder section I am finding it very hard to discern the instructions in that section without images or a pictorial of what to put where. We could even set up some mock roadways with only streets visible on a plain background. That way we can help people visualize what is happening. To be honest I am not 100% certain how to make the roadway name for a freeway continuation not say the same thing as the segments before and after (if after is necessary). Since we are not supposed to use "to I-xxx" any more I tried "for I-xxx" and it capitalized the "For", so I reverted it back to "to" until I hear what we are proposing to use instead. Current instructions just say don't use "to". Then we should give examples of alternate proposals to fix it.

dbraughlr wrote:

PesachZ wrote:The TTS engine (I can confirm at least for Samantha) suppresses the leading "to". The verbal instruction for a wayfinder segment named "to I-87" will be "Stay to the <right/left> at eye eighty seven". This instruction would still be correct, since it's not telling you to go to somewhere, you already are.

I don't consider it to be "correct". When entering I-80 Business W from I-5 S, the big green sign says "TO I-80 W". The TTS should announce what the sign says including the "to" because it is the exit onto I-80 Business W which is the second chance connector to I-80 W.

I think we should use "to" when that is what is on the sign and the "to" should not be suppressed.