Useful information: Junctions
Some editors might already know all of this information, but I thought that it would be a good idea to share the outcome of a discussion on the mr-classroom-mentors section of the international discord server. The topic was about how to map intersections with AGCs and whether they could impact the collection of routing data. The topic was already discussed on the Australian server, but volundu2 was able to give the following explanation of information provided here. In particular, the response was a reply to my question about a section of the wiki:
Funwayz wrote:the wiki says " if there is a chance that traffic can go in different directions at a junction and that junction can experience different amounts of congestion, you should keep the segment before that junction long". How long do segments have to be in order to record traffic data correctly?
Abc1357 added the following:Volundu2 wrote:There are two answers to that question.
In general, guidance (available on the wiki) says that segments should be 6m or longer to do a good job recording traffic data.
But the example you are referring to do has to do with the case of adding an intervening node that "confuses" waze
Consider the example in the wiki - let's assume all segments are > 6m - long enough to accurately record data about how long it takes to pass through each one on the way to each of the segments connected to it.(edited)
In the first image
https://cdn.discordapp.com/attachments/ ... nknown.png
In the left image, Waze will probably do a good job of recording the fact that cars travelling NB on seg4 may have a much longer wait time for one of the two branches (Seg 5 or Seg6) than for the other. For example, Seg5 might back up, and the traffic waiting to "keep left for Seg5" may backup onto seg4, while traffic headed for Seg6 breezes right through at high speed.
In the right image, imagine exactly the same scenario.
Except, in this case, most of the long left-turn wait is happening on Seg7.
All traffic leaves seg7 toward seg8, so waze has no way of differentiating between traffic at a standstill waiting on seg7 to wait some more on seg8 before finally keeping left for seg9, and traffic breezing right through seg7 to get to seg 8 and seg10.
It has to average together all the traffic on segment 7, and overall, it may look like that traffic is really slow.
In reality, the route 7 > 8 > 10 might be a quick and good route, and better than the next alternative, but waze has no way to keep track of that.
At the same time, Waze might think that the route 7 > 8 > 9 is faster than it actually is, because average speed on seg7 is faster than what actually happens to traffic waiting to go left.(edited)
there may be a better route for wazers heading toward wherever segment 9 goes, but waze has no way to make that calculation correctly.
jnct3 might exist for a pretty good reason. but we might opt to leave it off the map if we know that left-turn traffic routinely backs up past jnct3.
If that's not a viable way to map this, then the other option is to use a junction box. That gives waze a place to store enough information for it to "understand" the time it actually takes a car to go up seg7 and come out seg9, and the must faster time it takes for a driver to go up seg7 and come out seg10.
Abc1357 wrote:To add to what voludu said. This is important when considering PLRs for corner businesses at major intersections. The PLRs split the main road and could possibly cause Waze to have bad timing information for left turns or right turns (in AU) at congested intersections.
Re: Useful information: Junctions