| The new Waze Wiki, aka Wazeopedia, is now live at Wazeopedia.waze.com! While this legacy wiki will remain accessible for the time being, it is no longer updated by the community. For the most up-to-date guidance, please visit your local Wazeopedia.
Please do not make any more updates to these legacy wiki pages, all future updates should be made in your country's local Wazeopedia.
- From the LA Map Raid Google Hang Out on 1/1/2015, Otto (ottonomy) jumps in and teach about why box junctions are evil! He began with a tip about Toolbox I didn't know about. How to copy PL's without layers! Just be aware that this was done in chat and hence was not a carefully edited teaching document. There was discussion as he was typing which directed some of the conversation. With that said, it's remarkable how Otto kept it focused, which is why I was inspired to create this page to record it all!
Any of you who have Toolbox installed, I would like to request that when you post PLs in the hangouts, use the layerless permalink feature, so that those who click your links don't inherit all of your layer preferences. If you hover over the regular permalink button, and press and release Shift, then use Control-C to copy the link from there, you get a PL in your clipboard which doesn't have the layer properties built in.
Which brings me to box intersections, which are, until Waze fully implements the fabled Junction Box, the scourge of good routing in my opinion. They are BAD BAD BAD in the way they deal with speed/turn data.
I shall explain. Let me preface this by saying that the addition of left turn AGCs in one form or another can partially or completely negate the badness. As much as AGCs annoy me. Forgive me if any of this is telling you what you already know. I'm saying this in the main MapRaid hangout for a reason. Others can read it here.
Ok, Waze has two kinds of speed data stored for segments. Part of it relates to the segment itself, and is portable, meaning that you could take that segment, bend it, shape it, change its road type, even relocate it to another road and rename it, and that data would, for a time, until overwritten by new data, go along for the ride.
This portable speed data has to do with the time it takes to get from one end to the other. Segment length is taken into account, and there is some correction done if the segment is stretched, merged with another, or cut in pieces. The portable data is reportedly very precise as to time of day and day of week.
Then there is the non-portable data, meaning speed/turn data, which relates to the different elapsed times between entering the segment and leaving it TO another specific segment, be that left, straight, or right.
This data is junction dependent. When you pull a segment away from a junction, it is gone. There is no how-long-to-turn-left-from-this-segment data when it's not connected to another segment to which it can turn left. And it's not a matter really of left versus right, but of this segment ID to that segment ID
If the turn angle from one to another was set as a straight continuation one day, and a left turn the next, by an editor, Waze would still see it as the elapsed time from entering the one to entering the other. (was changed)
- At this point a user asks "So If you pull away, reconnect, save, is it lost? Because that was confusing me earlier"
I believe so, though WME is a little weird about what it keeps/discards between saves. Always better, if you want to preserve segment to segment data, to move the junction, rather than even momentarily separating segments. If you save while disconnected, then it is definitely lost. That is what we call rebuilding a junction. Pull all segments away, save, reconnect. Fresh turn data must be made by Wazers, and corrupt existing data is gone.
Ok, so what about box intersections (without AGCs)... Never need to rebuild a junction unless there is something absolutely crazy going on, like Waze refusing to route an allowed turn. It's a fallback routine when nothing else has worked. Kinda like reinstalling an OS.
Ok. So box junctions...
When you are waiting to proceed at a box intersection, whether you are turning left, proceeding straight, or turning right, that waiting is done behind the first junction (with the exception of mid-intersection waiting for a left). So Waze can tell which traffic goes right, but it cannot tell straight traffic from left traffic. Both straight and left proceed straight from that first junction.
Most of the Wazers going through the second junction are not going to wait. So, at the first junction, people waiting to make lefts corrupt the straight data by not moving, and people going straight pollute the left turn data by moving fast.
At the second junction, where the turn transition happens or not, most Wazers are already going. This is one of the reasons why Waze sometimes will route you through a horribly long left turn, or avoid an intersection which moves quickly going straight. A bow tie avoids this because it allows Waze to see every possible out-route from the intersection at one junction.
If you add AGCs, then Waze uses the speed data specifically for those. AGCs that start back before an intersection can have their own speed data pollution issues.
Sometimes they are necessary for early prompts, but if there are very long lines of waiting cars, and some of them are stopped back on the main segment behind where the AGC splits, Waze can get corrupt data for the mainline there. So we try not to use the early prompt type AGCs except where the turn pockets are crazy long and need to get you over there well before the intersection.
Bow-ties look weird in the app, and can create MPs at wide intersections. They also can confuse people with their single U-turn prompts in places where the real world seems to have a double left.
There's a special kind of box intersection setup, sometimes called "cross-diagonals" which handles right/straight/left at the first junction, provides better GPS tracking of the driver's movement in comparison to the segment layout, allows complete control of allowed or disallowed lefts and U turns, and is more or less invisible in the app when higher road types are used and the intersection is not extremely large. or "box diagonals"
I used to really dislike this approach, because it looks like a tangled bunch of spaghetti in WME, but...
Here's an example, a PL to Westlake and Thousand Oaks
The box diagonals method is tricky to set up. NOT for beginners. And I'm not really comfortable with proliferating these intersections all over, as new editors tend to try to learn by example, but don't catch the nuances. It requires doglegs and an elevation difference where the segments cross. BUT, it uses only the four junctions already included in the box, so there aren't that many more data points for the routing server to deal with.
With the doglegs set properly, there is a prompt at the first junction, and none at the second. They double in function for opposing left turns. So only two are needed to cover all four lefts.
So when SHOULD this be used?
Well, that's the fun part... We are waiting for Junction Box. How long? No one knows. Do we want to create a ton of these? Do we want people out there trying to set them up and doing them wrong?
I have been saving them for specific places where a bow-tie just seems to pull everything too far to the center of a huge intersection, or where I believe that straight versus left turn data is causing major issues.
There is one more advantage to these. WHEN Junction Box finally comes, it's extremely easy to just delete the two cross segments. Much easier than opening a bow-tie.