You should not have been reprimanded, at most gently corrected. A BDP failure would occur where there was circumstances should have led to the penalty disfavoring the route.

Personally I don't care if it is called a failure or anything else. The only reason to possibly care is that you want to avoid confusion between a BDP bug (the failure I described in the previous paragraph), and a BDP that has been overcome (i.e., BDP applied, but penalized route was still the best route after penalization).

Finally, to me, prevention and penalty are not contradiction. The penalty is intended to prevent these detours where they don't provide a much faster route. Nowhere does it say it ABSOLUTELY prevents this type of route. And that's more pedantics, I guess. I don't see the current language as problematic. I'm OK with changing the language, but not with changing the nomenclature, since that would be disruptive. If you can propose an article change that leaves the nomenclature intact, that's fine. The problem is, inherently, you're asking for a nomenclature change.

WHat I'm hearing is that we still don't know precisely how BDP works, and there are cases where there is BDP that we would think aren't and/or where we would think there is BDP but it does not actually kick in.

I consider this a serious issue. It makes it impossible for us to explain clearly.

Given that, we may as well go with a very simplified explanation that works 80%-90% of the time, insert a qualifier that there are other rules that may affect whether BDP is applied, and call it a day. It will be much more comprehensible to the uninitiated reader than the complete, very technical and detailed description of all we know, without deviating much more from the (unknown) BDP reality than that more complete description would provide.

Also, some of the back and forth above seems limiting in how the information will be used. Reader want to know:

* What BDP is
* How it works (as simply as possible)
* When BDP will kick in and when it won't
* When it is beneficial to force Waze to apply or not apply BDP (contrary to Waze's norm)
* How to force it to happen or not to happen in those situations
* Example, examples, examples, examples, examples, examples, examples, examples, examples, examples
* More examples. Seriously. There should be at least one example at every rule showing how it applies and where it fails.
* A more detailed technical reference with all teh caveats that we know about

In my running on and on, I still left out a major point.

Editors will also come here to help them do analysis of odd routing. That generally must be based on current behavior, not future behavior. At the same time, it will require information that is complete as possible.

The lack of final segment name criteria permanence is speculative. We can go on endlessly about what Waze might do. I'm confortable leaving it as-is.

The global page inaccuracy is due to objections from a few global champs, who, some of our US experts believe, simply have an incorrect understanding of BDP. Repeated dialog has not resolved the conflict in opinions, so we'll just have to accept the situation as it is for now. I believe we can at least make a case for a callout on the global page to see your revised page for differing US guidance.

Do ramp segments have a higher threshold to have Street Name Discontinuity? The last two sub-points of point 3 - Be careful of false positives, imply that one segment without an appropriate alt-name will NOT set the discontinuity flag, but a second instance will.

From the WazeO:
If the ramp does not also carry a simple alternate name of "I-1234", then there is a discontinuity of the highway name between the concurrency and the continuation highway. If there are two ramp segments like this, it will trigger Big Detour Prevention unexpectedly, and Waze will create an unneeded penalty for continuing on I-1234.

To prevent this, just assign I-1234 as an alternate street name to all ramps between the two sections (concurrency and continuation). Note that if there is only a single ramp segment connecting the highways, there will not be a "false positive." Nevertheless, it is a good practice to do this even for a single ramp segment, in case the ramp is cut into two segments later, either by accident or because later construction or map improvements connect another feeder ramp in the middle.


If there is a difference in the way ramp segments are handled, whether within a concurrency or not it should be called out explicitly.

Do ramp segments have a higher threshold to have Street Name Discontinuity? The last two sub-points of point 3 - Be careful of false positives, imply that one segment without an appropriate alt-name will NOT set the discontinuity flag, but a second instance will.

From the WazeO:
If the ramp does not also carry a simple alternate name of "I-1234", then there is a discontinuity of the highway name between the concurrency and the continuation highway. If there are two ramp segments like this, it will trigger Big Detour Prevention unexpectedly, and Waze will create an unneeded penalty for continuing on I-1234.

To prevent this, just assign I-1234 as an alternate street name to all ramps between the two sections (concurrency and continuation). Note that if there is only a single ramp segment connecting the highways, there will not be a "false positive." Nevertheless, it is a good practice to do this even for a single ramp segment, in case the ramp is cut into two segments later, either by accident or because later construction or map improvements connect another feeder ramp in the middle.


If there is a difference in the way ramp segments are handled, whether within a concurrency or not it should be called out explicitly.

I'll say what I said in another thread – it's called detour prevention, not detour prohibition. Like "crime prevention," it doesn't always work.

"Detour Prevention" is in the context of "Detour Prevention Mechanism" which is a mechanism designed to prevent detours—not to stop them from ever happening, but to do so within reason.

It prevents detours in cases where such prevention is warranted. Nothing about "detour prevention mechanism" means "this mechanism will ensure that you never get a detour". It says "this mechanism is designed to prevent detours," which is true.

Further, "detour penalty mechanism" will be harder to explain to people who don't know what a "penalty" is in the context of the Waze routing engine, which is to say, anyone who isn't a map editor with some sort of experience. We can say to someone who reported a UR, "Normally, Waze's detour prevention mechanism would not send you off and right back onto a highway, but in special circumstances, such as extremely heavy traffic, the mechanism is designed to allow a detour if it would save you a significant amount of time." You'd have less questions than if you said "Detour penalty" – then you have to include some explanation of what "penalty" means in the context of a route.

"Detour prevention mechanism" is an accurate and understandable name for what it is.

Clearly that needs to be better stated, but it is best practice to use cardinals on every divided numbered highway, and every divided freeway however numbered or named, in the US.

PesachZ wrote: The developers are aware of the issues presented by divided highways such as the example provided by edsonajj, and perhaps a fix for that behaviour may included in some future update. But at the very least I can assure you they have acknowledged that it presents an issue which could be handled better.

Sent from Android using Tapatalk

And they can't really fix it if they don't have examples to work with.

But, regardless, at the very least, cardinals should be used on every freeway and expressway, and those are going to be responsible for 99.9% of every multi-segment U turn.