From Wazeopedia

Revision as of 10:10, 2 April 2016 by RonRover (talk | contribs)


Sample Editor Outreach Message:

I see you are editing around the ________ area. Thanks for helping. I would like to welcome you to editing and offer you to join other editors in Ohio. We communicate in Google Hang Outs (GHO)s and share tips, news and tools that make editing and asking for down-locks easier.
In the meantime please read these two pages:
(You will have to add the closing parenthesis the the above link)

If you would like to pursue joining with us, just read this and request to be added.

Hope to see you editing,

Your Name/Editor Name



How to remove locations from the Waze App

How to set or change Home and Work

How to collect logs from the App. (see next item also)

Form to fill out for Waze reporting to accompany the logs. (see above item also)

Waze Help Center

Big Detour Prevention (BDP) Explained by Bill473

The following was presented by Bill473 as a training aid to satisfy the BDP requirement to attain R4 rank for both he and myself. Bill had experienced it first hand and dug into it and was very qualified to instruct.

This is an introduction to how Waze does detour prevention, how it can go wrong and how to fix it.

First, detour prevention is a good thing. You don't want Waze to recommend getting off an interstate, following some ramps and getting back on even if it saves a few minutes. That is an unneeded detour and Waze has mechanisms to prevent it.

When Waze editors discuss BDP, what they are focusing on is Big Detour Prevention errors – where the attempt to prevent detours goes wrong and actually takes you on a detour.

When checking BDP errors, you need to look at primary and alternate names on segments.

A very useful user script is WME Show Alt Names. It shows the names of all selected segments in a table on the edit page. And it can be turned off and on as needed. You can use it to select the segments for a LiveMap route or you can select them yourself.

I list this now in case you don't have it and want to install it while I continue. I don't have an "exercise" planned where you need it, but it will make diagnosing BDP errors easier in the future.

Here's a real-life example of a BDP error (fixed now, of course):

And here's the LiveMap link to the area so you can see where the segments are.

The "obvious" way to get to the destination is possible. Going NB, take the exit and drive down to the bow-tie on US-36 W. Turn left and drive to the destination.

So why didn't Waze recommend that? Because it thought that would be a detour!

Let me try to explain the "detour" before getting into all the details. US-127 N has an alternate name of US-36 E (because both highways share the road before the exit.) Our destination is on US-36 E. Once we leave the freeway, we are taking 2 ramp segments to get to US-36 E. Neither (at the time) have the (primary or alternate) name US-36 E.

Visually we can see that path makes sense, but Waze sees this as leaving US-36 E, driving on two ramp segments and getting back on US-36 E. "Clearly" a detour to be avoided. (The Waze recommendation shown in the picture goes to US-36 W so it doesn't see that as a detour.)

(As an aside, the old guidance to disable the "straight-through" at the end of interstate ramps was to prevent the type of detour where you leave a highway, travel a few ramps and return to the highway. However, BDP (working properly) should keep that from happening.)

• If we are OK with my description here, we can take a look at the Wiki to see that the exact definition is met.

The basic Wiki entry on Detour Prevention is

A more detailed version written for the US is

The last link has five criteria that must ALL be met to be considered a detour. Let's check to make sure my summary above is right:

1 Road Name Discontinuity - The freeway/highway segments immediately before and immediately after the possible detour must share at least one street name

Yes: US-36 E on both. (Primary or alternate, makes no difference)

2 Road Type Discontinuity - The freeway/highway segments immediately before and immediately after the possible detour must be from the same 'Road Type Group' as defined in the chart below. The possible detour must include at least one segment not in that same 'Road Type Group.'

(The grouping is Freeway/MH in one group, mH in another)

Yes: US-127 N is Freeway, US-36 E is MH so same group. Our ramp "detour" isn't in that group.

3 Existence Of Direct Route

The idea is there needs to be a direct route before labeling a different route as a "detour" to be avoided. I'm having a little trouble with the exact wording because I think it is slighly misstated. (Both the detour and the "direct route" share the first ramp segment.) Can we say "yes, there is a direct route, Waze is showing it in the picture?

4 Minimum Length - The possible detour must be more than one segment long.

Yes: 2 (ramp) segments.

5 Maximum Length - The possible detour must be shorter than the threshold length

Yes: Threshold for this group is 5km.

Whew! Let's take a breath. The complexity of the Waze routing algorithm and the difficulty in putting it into words is why (I think) some view BDP as very hard to understand.

Here is the basic idea that I think makes this "simple".

You have 2 highways (A and B) running together for some distance. The highways then diverge with B exiting on ramps. If the ramp segments aren't labeled to indicate they are part of highway B, Waze will see that as a detour and "penalize" the way you should be driving...which results in Waze recommending a strange detour.

There are, of course, other configurations that will result in BDP errors. But every BDP error I've seen fits the "simple" summary. (Check "Confirmation bias" on the Internet)

So what's the fix? Let Waze know that this ramp is part of US-36 E. You can't touch the first ramp segment since you need the name discontinuity to get the "to US-36 / SR-571 / Greenville / Piqua" instruction. But you can add US-36 E as an alternate name to the second ramp segment.

At one point we believed you could have a one-segment name discontinuity anywhere along a series of ramp segments. We discovered Nov 2015 that the only safe place to have a discontinuity was the first segment (to support the wayfinder function.)

Des Moines Iowa

LiveMap Link:

I-80 (E/W) and I-35 (N/S) run concurrently for a while near the center of Des Moines. Where I-35 N leaves I-80 E and heads north was connected by a single ramp segment. Everything was OK at that point because of #4 above ("detours" must be 2 or more segments). It was then cut to Seagull it. Now we have 3 segments and I-35 N was not added as an alternate to the new ramp segments. Within a few days there were numerous URs from commuters wondering why they were no longer being sent the normal way.

(Slight update: the current implementation of BDP is that to make sure something is not a detour is to have the name carried through on the last ramp segment. You can gap any segments before the last. Probably best to carry names through all segments as that implementation is likely to change)

My feeling is the checking of the last segment only is to make the process faster. But you certainly can't expect that to always be the case.

The Des Moines error was fixed by adding I-35 N as an alternate to the ramp segments.

It's very easy to cause a BDP problem in a case like this without realizing it. Think "name discontinuity" any time you are working on ramps. As more Seagulling in being done, it's likely other such errors will occur. Again, the most dangerous areas are where two major highways diverge.

That one was pretty dramatic. The tendency is to think "temporary traffic issue" when the URs start coming in. Especially since not every LiveMap route test will show an error. (If you are too close the "detour", there may not be an alternate direct route so LiveMap won't show it.)

Are we OK with the Des Moines example and fix?

Here's an example that show this is really Big Detour Penalty rather than Big Detour Prevention:


The obvious path is still listed, but listed second so it won't be chosen by default. (Again, the problem is caused by 2 ramp segments, the second one didn't have SR-5 for name continuity.) The recommended route is 6 minutes, the second (penalized) one is 3 minutes. But the penalty (not publicly revealed. changeable without notice and possibly different for different configurations) is enough to make it listed second. Also, depending on traffic conditions for the first choice, the second route with the BDP error could actually be listed first so BDP errors could (theoretically) come and go.

(This is also a "favorite" of mine because I lived it. I took the 6 minute drive since I trusted Waze that there was a problem at the SR-82/SR-5 intersection. The problem was BDP.)

I have other examples of BDP errors I've seen in the last year, but they are all the same flavor. When you see a strange detour, after checking Ctrl-Z to make sure there aren't invalid turn restrictions, take a look at name discontinuities.

If we're OK with BDP, there is also there is also Small Detour Prevention.

This is discussed much less because there doesn't seem to be the same type of associated errors. Basically this is meant to prevent doing a U-turn followed by a right turn instead of the more obvious left turn. From the Wiki "While this may save a few seconds over waiting for a long average left turn, it is undesirable. Waze will prevent such detours if there is not a measurable difference in the route times. The exact difference in time required to trigger this prevention is proprietary, and subject to change as needed. "

I do wonder if this is an example where the prevention isn't working:

It seems that at certain times of the day, the obvious left-turn takes long enough for Waze to recommend continuing and doing a U-turn.