[Page Update] Junction Style Guide

Moderator: Unholy

Re: [Page Update] Junction Style Guide

Postby PesachZ » Fri May 30, 2014 3:35 pm

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.


You are correct, i got distracted in middle and lost my train of thought at the end. But the logic is the same for going straight vs. right-uturn-right. 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. The left may be slightly slower, but the right turn, and straight should be equal in transition time. 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.

The only time otherwise might be a street with very heavy traffic where the right turn is actually faster than going straight. and the intersecting street has very little traffic recorded. In this case though having the short segment doesn't affect those calculations IMHO.
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: [Page Update] Junction Style Guide

Postby PesachZ » Fri May 30, 2014 4:14 pm

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.

The right on red is a big hole in theory, I admit. Where I come from it is illegal, and I didn't even consider it. With a dual-dual ( split roads in both directions) situation (the box vs, the H) the right turn may have a better affinity as well. What I said really would apply best for an H intersection with no right-on-red, or maybe doesn't really apply at all. :o
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: [Page Update] Junction Style Guide

Postby PesachZ » Fri May 30, 2014 4:49 pm

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.

Yes that is what I meant, but erroneously included the right turn in that statement as well.


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.

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. However IMO the bowtie looks better, and is less clunky then diagonal segment. Both would need (micro)doglegs to give the best instructions though.

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.

Disregard this statement, I was wrong based on the above information
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: [Page Update] Junction Style Guide

Postby PesachZ » Fri May 30, 2014 5:05 pm

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.

i agree
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: [Page Update] Junction Style Guide

Postby PesachZ » Fri Jun 06, 2014 7:07 am

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

It does work but seems finicky. Apparently the angles have to be very close to 90° for it to work. 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
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: [Page Update] Junction Style Guide

Postby PesachZ » Fri Jun 06, 2014 3:41 pm

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.

It's my understanding now that anything other than a disconnect is just a penalty. Sometimes it may be compounded penalties based in the situation, but still a penalty. The only absolute restriction seems to be a disconnect.

I only mention it to explain the occasional override may be for to the alternative routes carrying higher penalties.

Sent using Tapatalk for Android 4.4.2
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: [Page Update] Junction Style Guide

Postby PesachZ » Mon Jun 09, 2014 11:28 pm

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."

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

Sent using Tapatalk for Android 4.4.2
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: [Page Update] Junction Style Guide

Postby PesachZ » Tue Jun 10, 2014 6:31 am

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. ;)

I believe you are confusing AGCs as used for ramp like turning lanes with what is being discussed here. This is a discussion about placing 'AGCs' for lack of a better term inside the box of an intersection between two split roads. This is one of methods employed to disallow u-turns whole allowing left turns on both roads. These are not in place to prevent MPs.

This is preferred by some over the bowties for looks, and over just using the left left U-turn penalty due to reliability issues (or median width >15m).

Sent using Tapatalk for Android 4.4.2
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: [Page Update] Junction Style Guide

Postby PesachZ » Tue Jun 10, 2014 8:40 am

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.

While I don't agree with the logic for not using "to ..." at a wayfinder, I think "on ..." may be an alternative.

This problem is purely aesthetic from what I can tell, as it only applies to the instruction as it is displayed at the top of the client or in the instruction list. 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.

Production android client audio " to I-87 / Major Deegan Expy / Albany"
Production android client audio " to S Conduit Ave "

From the perspective of a driver approaching a split in the road, the fact that he is already on the road doesn't change the fact that he needs to know which side of the fork to take to continue on that same road. Looking at the fork a driver has two choices; to the freeway, or to the exit. Yes he is already on the freeway, but describing where these two branches of a fork will take him; one will go TO the freeway, and the other TO the exit. I don't believe seeing an instruction TO the freeway, at a fork in the road would confuse anyone, even if they are already on the freeway.

But I digress, that decision appears to have already been made.

I'm not sure how it will sound in TTS, but what do you think of naming the continuation stub of a freeway "on ..." instead of "to ...". I'm hoping for an instruction along the lines of "stay to the left on ...", though it may say " stay to left at on ...".

Sent using Tapatalk for Android 4.4.2
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

Re: word "to" dropped from exit name

Postby PesachZ » Tue Jun 10, 2014 6:48 pm

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.

That is not what I was referring to, I was speaking to the specific scenario being discussed of a wayfinder segment where one side is the continuation of the same freeway. For example I-676 S, 2 left lanes exit to 1-95 N, two right lanes continue as I-676 S. I was referring to the wayfinder segment between the two segments of I-676 S. whether the other segment to 1-95 N should suppress the "to" or not, wasn't part of my point. That is how it's been for a while already.

As a side note only the first "to" in the name is suppressed. A ramp for example names "to I-295 N / to I-95 N / New Haven" will be spoken as "keep right at eye 295 north, to eye 95 north, New Haven". If you need the word "to" to be spoken it can probably be accomplished (I haven't tested) by naming the segment "to to I-80 W".

Theres still the problem of the discrepancy between the displayed instruction and the verbal one.
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2374 times

PreviousNext

Return to Wiki Updates and Discussion

Who is online

Users browsing this forum: No registered users