To fall in line with the preferred ramp departure angles of 10-15 degrees, point number 4 of this passage, Exit Geometry, will need to be edited.
https://wiki.waze.com/wiki/Junction_Sty ... t_geometry
It currently says "The Ramp exiting segment must have a departure angle of between 20 and 30 degrees from the entering segment"

sketch wrote:Oh, also, I'm not crazy about the "2 dropped lanes on the expected side" rule, exactly—what of the situations with 1 continuing lane, 1 option lane, and 1 dropped lane? The "only 1 lane continues" rule doesn't really apply unless we explicitly exclude option lanes from that count.

Obviously, we do need to have some sort of objective rules for this spelled out in the wiki, but this is a subject where any number of factors could make exceptions to the rules seem reasonable.

There are places where only one existing travel lane peels off to another route, but there's little advance signage, poor road striping, and/or maybe a blind curve, which combine to make the exit sneak up on drivers.

There are other places, where five lanes split into 3 and 3 (option lane in middle), but the BGS have been warning of the split every half mile for 5 miles or so, and giant Y arrows loom above, ominously, sign after sign.

The former situation begs for a wayfinder. The latter should obviously have one, but almost doesn't need it.

Some editor discretion will have to come into play from time to time.

DwarfLord wrote:

qwaletee wrote:I've also experimented with "sharp angle geonode" bowties. They look much better on the map/app. For segments not on the route, they're almost invisible.

Are these documented anywhere? I am trying to visualize what you are referring to and not succeeding.

Take a look at the intersection of Tillary st and the Brooklyn Bridge in Brooklyn, NY. Jay st and Tillary st to the east of that. Sorry no PL right now on my phone, but a quick search in WME should pull it up.

Sent using Tapatalk for Android 4.4.2

Based on the testing and comments in this thread it seems we need to mention that 3 way diverging road splits should be avoided. Supposedly it's in the best practices to instead use a series of 2 way splits, but I haven't seen that. If that verbiage is already here somewhere, maybe it can be made more obvious. I would expect to find it in the JSG probably under the diverging roads section.

If this is posted it the wrong thread, (I haven't followed all the discussions and proposals on the JSG) please move it to the appropriate thread, or tell me where I should post it.

Sent using Tapatalk for Android 4.4.2

jondrush wrote:Dang, I though the three-way split was already in the wiki.

As I'm testing more, it appears any split with more than two options (I tested three and four way splits in both left and right configurations) will give the left most branch 'keep left' and all the rest of the branches a 'keep right'. This is regardless of the actual angle of the turn.

Hopefully someone can this information into the wiki.

Sent using Tapatalk for Android 4.4.2

CBenson wrote:I'm confused again. I thought your testing showed this to be true for a split with two options as well.

The difference in implementation when there are more than two branches, is that all the branches (including all the middle branches) besides the left-most one will say Keep right. So for example a 4-way split with two left branches and two right branches, will give the per left left branch a keep left, and the other three branches keep right.
http://img.tapatalk.com/d/14/05/21/ju2ype8y.jpg
http://img.tapatalk.com/d/14/05/21/upy5e9a6.jpg
http://img.tapatalk.com/d/14/05/21/enetevut.jpg

Sent using Tapatalk for Android 4.4.2

CBenson wrote:I see that as being true for a two way split as well. But I guess for a two branch split it is correct, while for more branches it becomes problematic.

Exactly. Since there are no middle branches in a two way split, this logic is fine. When applying it to a split with more segments it can be confusing to a driver.

Sent using Tapatalk for Android 4.4.2

qwaletee wrote:Whatever happened to the Wayfinder section of JSG? I know it needed some work, but better what we had than nothing at all.

I don't recall a discussion to remove it.

There was discussion to move some content to sub pages... maybe it got moved

Sent using Tapatalk for Android 4.4.2

tonestertm wrote:

PesachZ wrote:As I'm testing more, it appears any split with more than two options (I tested three and four way splits in both left and right configurations) will give the left most branch 'keep left' and all the rest of the branches a 'keep right'. This is regardless of the actual angle of the turn.

Does this hold true if one of the "right-keeping" roads has the same name as s-in?

It was true at a junction where the left and right branch had the same name as s-in, and the middle had a different name. otherwise I don't believe i tested this specific scenario. But if the road you are describing is the best continuation, there may not be any instruction to it, however it will still affect what instructions the other branches get. This is as far as I can tell testing with 2 way forks which had a best continuation, and 3-way splits without a best continuation.

CBenson wrote:I would just note that if the information here is correct, then a plain box intersection has the disadvantage that the timing data for a straight movement is not distinguished from the timing data for a left turn. There is some question as to how much this contributes to right/U/right routes in place of straight through routes. Theoretically, neither the bowtie nor the diagonals in the box method suffer from this problem.

I acknowledge this is highly speculative as it depends on how the data is collected and assigned to small segments is small areas.

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. Let me explain my understanding of how it works, and then you can correct me where I am wrong.

Waze keeps track of how long it takes a vehicle to traverse a segment, to move from the beginning of one segment to the beginning of the next segment and continue past the junction. Waze understands there might be a delay in transitioning to the next segment, say for a traffic control device, or waiting for passing traffic to make a turn. Waze accounts for these transition delays by including the time for the transition delay with time it takes to traverse the originating segment (s-in). So the recorded time it takes to pass over this segment includes the time you have to wait at the end of this segment before you start driving across the next segment.

When traffic leaving the originating segment has more than one destination segment (more than one option for s-out) then waze will keep a separate time record for the originating segment corresponding to each of the options leaving the junction. A simple 4-way with 2-way roads then will have travel 3 options when you arrive at the junction, and Waze will record 3 separate travel times for the originating segment, one for traffic ultimately ending ending up on each of those three connected segments. In this way, if there is a longer delay for left turning traffic, Waze can acount for that. It works because Waze knows that traffic from the originating segment which continued straight to the next segment had a traverse time of x + a delay of y, which is shorter than the left turning traffic which had a travel time of x + a delay of z.

A caveat to this system arises when there is a short segment before the junction where the turns are made, and the traffic line waiting to make that turn backs up past the short segment to the segment behind it. The transition delays are still being properly recorded for the short segment (in the intersection box) immediately prior to the turn, but not for the longer segment before it (the street approaching the intersection). The longer segment now only has one option for s-out at the junction between it and the short segment, so Waze only calculate one transition time for that long segment, even though some of the traffic on this long segment is being held up because of the turn delay after the next (short) segment, and other vehicles are moving through freely. The average speed of this longer segment for straight through traffic is now being represented as much slower than it is in reality because Waze is not maintaining separate records (since it only has one exit at the junction). This will affect routing on the long segment, and may cause an alternate route to be chosen for traffic traveling straight through the junction.

wiki wrote:To understand this problem better, consider if we add a short Seg8 between Seg7 and Jnct4. Let's say the traffic exiting Seg10 backs up all the way to Seg7 (easy enough, since Seg7 is short). Because Seg7 only has a single exiting segment (Seg8), the routing server is only able to collect a single average speed — it can no longer distinguish traffic by where it is going after Seg8. Now the through traffic going to Seg9 appears to Waze to slow down through Seg7, even though it doesn't in reality. At a minimum this causes an incorrect ETA for routing, and it might actually cause traffic to be rerouted unnecessarily, and less optimally, through another route. Hence if there is a chance that traffic that goes in different directions at a junction experiences different congestion, keep the segment before that junction long.

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.

On a side note, if this is correct that

Waze will penalize a route with two left turns in less than 15 m (50 feet) in right-hand traffic jurisdictions

which is being discussed here, being meticulous about the angles in a simple box type (90 degrees) intersection will, in itself, prevent U-turns, and allow the lefts if necessary.