Route timing accuracy tradeoffs could possibly a better name. Routing performance would mean time Waze takes to select a route, not so much how accurate the the time Waze gives.

As I like in general, I would consider adding a few additions of things for editors to note in WME:
- symptoms of things to look out for--AGC, PLRs, railroad crossings, 'seagull'/'true elevation' near intersections and #-shaped,H-shaped intersections
- verification of symptoms--Route Speeds add-on

Also, as written, JBs sound like a method of last resort. But really--it's really the correct feature to use to solve this problem. There's no harm in using it roads that editors have fully completed or are already highly locked.

---

EDIT: there is this that's already linked from in the JB article: https://wazeopedia.waze.com/wiki/USA/Ro ... urn_delays ... Makes me question the value of a separate article, or perhaps the opportunity to merge these two.

(I'd almost go and say any node on an R5 freeway that is 300m from another node should be junction boxed!)

As you'll read in the article introduction, it's the explicit hope that the article will provide a home to discuss not only tradeoffs in the generation of optimal routes but also tradeoffs in the optimal generation of routes.

We'll need to do some refactoring of this article then: https://wazeopedia.waze.com/wiki/USA/Ro ... oad_speeds, which seems to duplicate many of the concepts your article does/will want to discuss.

Last I checked they were still only available to R5 editors, which is quite a bottleneck on their application. For this reason alone it seems awkward to recommend their use to the broad editorship as a primary tool.

Staff has stated that they've left it as-is because there's no requirement from the community. We should use it as a tool, not as if it's some hack-up workaround, if this problem/location is important enough to notice and acknowledge these performance trade-offs.

I'm really sorry that this page proposal seems to have fizzled. I think this is important information, and keeping it as a standalone article linked from other locations was a good idea, because there are so many places where the content is applicable and valuable, but would interrupt the flow if placed in-line.

While the Junction Box is an ideal solution for many of the cases where junction nodes interfere with the accuracy of routing data, the current 16-connection limit makes JBs impossible to save in a lot of the situations where they would otherwise be most desirable. Unless or until we persuade Waze to allow at least double the number of allowed connections in a JB, we must consider the understanding of routing tradeoffs mentioned in this article to be just as important as if the JB solution did not exist.

Junction Boxes do have their cons. The most obvious is the editing limitations on included segments, but there are other downsides. A TTS prompt generated by a junction box TIO is executed when the user enters the JB. While this may be appropriate in some situations, it's confusing in others. JBs cannot be overlapped, but often the places we would like to use them are immediately adjacent. The buggy behaviors of JBs can eventually be worked out, so I won't go into those here.

ottonomy wrote:Junction Boxes do have their cons. The most obvious is the editing limitations on included segments, but there are other downsides. A TTS prompt generated by a junction box TIO is executed when the user enters the JB. While this may be appropriate in some situations, it's confusing in others.

I do not think it is appropriate to consider this a "downside". It is a limitation, yes, but it does not remove any functionality that would otherwise be there. "Downside" implies that it makes something at least a little bit worse. You can still set TIOs under the JB.

Besides the segment timing Waze also takes into consideration the direction that is taken at the end of the segment (right/left/ straight etc). Your article does not discuss this at all.
The situation where the back up for a left turn or a delayed straight through which involves several segments is already discussed in the Junction Box page
Also there is no guidance on either the length for editor to consider of a segment ( I think this is because it varies) or discussion on how to figure out when this comes into play. Is it worth having a discussion on how to use Route Speeds script and show some examples of where the routing is changed?
Right now this is a consideration for editors to consider but really doesn’t provide much criteria for people to use when making a decision.

An example to consider is a Gas station on a corner that is accessible from two streets. The left turns into or out of one or both accesses are prohibited. Should the person put the PLR in?

Some of this information is easy enough for newer editors to understand, and some will be difficult to understand unless the editor has spent some time on these topics already, but certainly the problem of the "H" and "#" or "box" intersections can be presented simply enough to be used in a discussion with a newer editor who wants to divide a highway.

And it can certainly enter into the discussion about when to create a separate left-turn lane vs a junction box when side roads or parking lot roads interfere with Waze being able to detect who is turning and who is not.

So I think this is a valuable topic.

I'd like to see a very clear separation between "Routing performance" and "routing server performance". I think the proposed title could be confusing, but is a reasonable working title until the community comes up with an alternative.