# \[Page Update\] Detour Prevention Mechanisms

**URL:** https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108
**Category:** US Wiki Discussion
**Created:** [May 2, 2017, 11:34pm UTC](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108 "2017-05-02T23:34:16Z")
**Posts on this page:** 20
**Page:** 1

<div class="post-metadata">

### Author: ![DwarfLord](https://www.waze.com/discuss/user_avatar/www.waze.com/dwarflord/32/84523_2.png) [@DwarfLord](https://www.waze.com/discuss/u/DwarfLord)
#### Post date: [May 2, 2017, 11:34pm UTC](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108/1 "2017-05-02T23:34:16Z")

</div>

Is there a minor error in the current [Wazeopedia USA page on Detour Prevention Mechanisms](https://wazeopedia.waze.com/wiki/USA/Detour_Prevention_Mechanisms)?

It lists (5) items, all of which must be satisfied for a route to be considered a detour. The fifth item says:

> [@](#):
>
> 5. Maximum Length - The possible detour must be shorter than the threshold length as defined in the chart below.

Is that correct? Does it not mean to say the possible direct route?

Specifically, the table only provides threshold distances for Freeway/Major Highway (5 km) and Minor Highway (500 m) types. If Item 5 really is intended to note a distance threshold for the detour, not the direct route, then what are the distance thresholds if the detour consists of Primary Street or Street type?

[EDIT: Perhaps what is meant is: the possible detour must be shorter than the distance threshold set by the road type group of the possible direct route. This would come with its own interesting quirks. One could imagine a 1-km-long convoluted Primary-Street detour that leaves and returns to a Minor Highway only 300 m apart. But because the length prohibition applies (does it?) to the detour, not the direct route, Waze would try it. This seems counterintuitive…am I missing something?]

---

<div class="post-metadata">

### Author: ![FzNk](https://www.waze.com/discuss/letter_avatar_proxy/v4/letter/f/FFC400/32.png) [@FzNk](https://www.waze.com/discuss/u/FzNk)
#### Post date: [May 2, 2017, 11:57pm UTC](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108/2 "2017-05-02T23:57:55Z")

</div>

It’s definitely lacking clarity. The Road Type Group is that of the direct route and the Threshold is the length of the detour with any road type(s).

Editing to reply to your edit: The long route would be possible in that situation, but normal routing behavior would usually prevent it. Where this would become a problem is if there’s a 2 or greater segment name discontinuity in that 300m of mH. In that case, the 1km detour would be heavily preferred.

---

<div class="post-metadata">

### Author: ![PesachZ](https://www.waze.com/discuss/user_avatar/www.waze.com/pesachz/32/21281_2.png) [@PesachZ](https://www.waze.com/discuss/u/PesachZ)
#### Post date: [May 3, 2017, 11:17am UTC](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108/3 "2017-05-03T11:17:41Z")

</div>

I can give more detail later, but your edit is basically correct dwarflord. In that the threshold is set by the road you are leaving from/returning to. But if the detour itself is longer than the threshold it will not be penalized. However the actual ETA for such a convoluted route is usually longer than the direct+penalty eta meaning it isn’t usually offered as an option to users.

---

<div class="post-metadata">

### Author: ![DwarfLord](https://www.waze.com/discuss/user_avatar/www.waze.com/dwarflord/32/84523_2.png) [@DwarfLord](https://www.waze.com/discuss/u/DwarfLord)
#### Post date: [May 3, 2017, 2:15pm UTC](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108/4 "2017-05-03T14:15:43Z")

</div>

This is wonderfully helpful, thanks.

But another quirk would seem to lurk…

Extending the example, let’s say a lightly traveled Minor Highway is completely blocked by a washout, but there is relatively little traffic backup. Let’s say further that Waze finds two routes to bypass the washout that leave the mH and then return to it. One alternate route is 350 m long, the other is 4 km long, but both depart the mH and return to the mH at the same junctions.

Because the penalty is applied to the length of the detour, not the length of the direct route, the 350-m detour will be slapped with a ~4-min penalty. The 4-km detour will not.

If the speed on the 4-km route is 45 mph – 1.2 km per minute – then the 4-km detour will take 3.3 minutes, which would not be enough to overcome the penalty on the shorter route.

Waze will therefore offer the 4-km detour but not the 350-m detour, unnecessarily adding about 3 minutes to the bypass route. Right?

[EDIT: I originally concluded by admitting this to be a contrived example. However on reflection, we had something similar in the Santa Cruz Mountains last winter. The principle highway linking Santa Cruz and San Jose was covered with a mudslide several times; in one event the slide was considered too unstable to clear safely and the road was closed for days. Waze tried desperately to route people around the slide. Nearly all such bypass routes would have been subject to the detour-length penalty issue. For a indication of what washouts in our mountains can look like, see [https://www.youtube.com/watch?v=jhLYaCOiK1M](https://www.youtube.com/watch?v=jhLYaCOiK1M) .]

---

<div class="post-metadata">

### Author: ![PesachZ](https://www.waze.com/discuss/user_avatar/www.waze.com/pesachz/32/21281_2.png) [@PesachZ](https://www.waze.com/discuss/u/PesachZ)
#### Post date: [May 4, 2017, 5:26pm UTC](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108/5 "2017-05-04T17:26:53Z")

</div>

> [@DwarfLord](#):
>
> This is wonderfully helpful, thanks.
> 
> But another quirk would seem to lurk…
> 
> Extending the example, let’s say a lightly traveled Minor Highway is completely blocked by a washout, but there is relatively little traffic backup. Let’s say further that Waze finds two routes to bypass the washout that leave the mH and then return to it. One alternate route is 350 m long, the other is 4 km long, but both depart the mH and return to the mH at the same junctions.
> 
> Because the penalty is applied to the length of the detour, not the length of the direct route, the 350-m detour will be slapped with a ~4-min penalty. The 4-km detour will not.
> 
> If the speed on the 4-km route is 45 mph – 1.2 km per minute – then the 4-km detour will take 3.3 minutes, which would not be enough to overcome the penalty on the shorter route.
> 
> Waze will therefore offer the 4-km detour but not the 350-m detour, unnecessarily adding about 3 minutes to the bypass route. Right?
> 
> [EDIT: I originally concluded by admitting this to be a contrived example. However on reflection, we had something similar in the Santa Cruz Mountains last winter. The principle highway linking Santa Cruz and San Jose was covered with a mudslide several times; in one event the slide was considered too unstable to clear safely and the road was closed for days. Waze tried desperately to route people around the slide. Nearly all such bypass routes would have been subject to the detour-length penalty issue. For a indication of what washouts in our mountains can look like, see [https://www.youtube.com/watch?v=jhLYaCOiK1M](https://www.youtube.com/watch?v=jhLYaCOiK1M) .]

If the direct route is blocked, restricted or marked with an RTC then it will not be considered a direct route since it will not directly connect both sides when the routing iterates through it. This will therefore cancel BDP entirely for this section. This is newish and went I to effect after the issue you quote due to several reports of bad implementation. It is not yet documented since we don’t have all the parameters yet.

---

<div class="post-metadata">

### Author: ![DwarfLord](https://www.waze.com/discuss/user_avatar/www.waze.com/dwarflord/32/84523_2.png) [@DwarfLord](https://www.waze.com/discuss/u/DwarfLord)
#### Post date: [May 5, 2017, 4:50pm UTC](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108/6 "2017-05-05T16:50:57Z")

</div>

> [@PesachZ](#):
>
> If the direct route is blocked, restricted or marked with an RTC then it will not be considered a direct route since it will not directly connect both sides when the routing iterates through it. This will therefore cancel BDP entirely for this section.

This makes sense. I look forward to hearing more.

For the sake of my understanding, can you confirm that – absent any BDP cancellation feature – the detour behavior I detailed above is correct? That, in the example, Waze would offer the 4-km detour but not the 350-m detour?

I’m just trying to understand the detour distance threshold for sure.

---

<div class="post-metadata">

### Author: ![voludu21](https://www.waze.com/discuss/letter_avatar_proxy/v4/letter/v/0099FF/32.png) [@voludu21](https://www.waze.com/discuss/u/voludu21)
#### Post date: [October 6, 2017, 12:29pm UTC](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108/7 "2017-10-06T12:29:09Z")

</div>

I am seeking to clarify the Big Detour Criteria a bit, and incorporate the latest information we have about all criteria which are or can be public knowledge.

Please help me improve this draft:  
[https://wazeopedia.waze.com/wiki/USA/User:Voludu2/Detour\_Prevention\_Mechanisms#Big\_Detours](https://wazeopedia.waze.com/wiki/USA/User:Voludu2/Detour_Prevention_Mechanisms#Big_Detours)  
Because I reordered the list to put all the criteria having to do with the possible detour path together, the new numbering is entirely different than the numbering referenced below, and found in the current version [https://wazeopedia.waze.com/wiki/USA/Detour\_Prevention\_Mechanisms#Big\_Detours](https://wazeopedia.waze.com/wiki/USA/Detour_Prevention_Mechanisms#Big_Detours)

Here is information I have gleaned recently:

> [@PesachZ](#):
>
> If the direct route is blocked, restricted or marked with an RTC then it will not be considered a direct route since it will not directly connect both sides when the routing iterates through it. This will therefore cancel BDP entirely for this section. This is newish and went I to effect after the issue you quote due to several reports of bad implementation. It is not yet documented since we don’t have all the parameters yet.

> [@PesachZ](#):
>
> Discord, Waze USA, #routing, 09/28/2017  
> 3.1 means that there are two completely distinct ways of getting from the before segment to the after segment. 3.2 means that the first segment after the divergent paths merge must be accessible from another segment of the Sam road type group. This other segment can be part of the direct path, or part of a different path or even a stub. Essentially it is checking that the first merged segment is not the terminus of a fwy. @voludu2 (5) CM(edited)  
> …  
> just to be clear rule 3 (3.1 & 3.2) are referring to the direct path (which is an alternate path to the possible detour) and not to to the possible detour itself  
> …  
> However I’m pretty certain there’s been a change made since this was written which i don’t have the hard facts on 100% which revokes The BDP mechanism does not determine that there is actually a direct route with name and type continuity, but rather only uses the above two criteria… i believe we now need a 3.1.1 this direct path must not be itself a detour (it must match name and road type group for all segments with the segments before and after the possible detour).

> [@](#):
>
> Discord, Waze USA, #routing, 09/28/2017  
> voludu2 (5) CM - 09/29/2017 @PesachZ (6) Thanks for the clarification. I would like to work on rewriting 3.1 to make clear that it specifies another path that has no segments in common with the possible detour under consideration, as well as the change to the update. I’ll post something on the forum. After that, I will return to clarifying 3.2 to make clear that it can be satisfied by a segment that is not part of the “direct path” being tested in 3.1  
> PesachZ (6) - 09/29/2017 One caveat although that used to be true for 3.2, with the update to 3.1 requiring a type match for the direct path, it by default will satisfy 3.2 with the direct path as well. @voludu2 (5) CM

---

<div class="post-metadata">

### Author: ![anon33958190](https://www.waze.com/discuss/letter_avatar_proxy/v4/letter/a/0099FF/32.png) [@anon33958190](https://www.waze.com/discuss/u/anon33958190)
#### Post date: [October 12, 2017, 1:22pm UTC](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108/8 "2017-10-12T13:22:39Z")

</div>

I think that apart from some minor stylistic stuff the draft looks good. The requirement that the direct route have full name and type continuity seems to be most likely, based on some things I have seen. I also have seen where a detour is not penalized if its last segment shares any name with the first segment after the detour, even if that name is not on the last segment before the detour. I am about to test more of this.

Are we waiting for info from staff to confirm one of the options in your draft or just trying to figure it out by testing?

---

<div class="post-metadata">

### Author: ![voludu21](https://www.waze.com/discuss/letter_avatar_proxy/v4/letter/v/0099FF/32.png) [@voludu21](https://www.waze.com/discuss/u/voludu21)
#### Post date: [October 12, 2017, 3:50pm UTC](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108/9 "2017-10-12T15:50:38Z")

</div>

I think it is always useful to know what the current status of these checks is.  
But it is probably impossible to keep the wiki page up-to-date with these changes.

Would it be a good idea to change the approach a little bit:

1. List the checks that we are almost certain are not going to change frequently -  
Like if the continuity check for a Detour is actually “there must not be name continuity between the last segment of the possible detour and the first segment after”. Even if the check becomes temporarily more stringent, this test is still satisfied. If the waze team says the test is going to become permanently more stringent, then this could be updated

2. A Note that additional / more stringent checks that may be implemented and removed from time to time - and where interested editors can go for more current information and discussion about BDP. If there is an active BDP testing team, then this team might be willing to share the current and past results of their testing somewhere, whether it be a supplementary wiki page or a google doc. In a sense, results of testing are more reliable because we don’t have to be concerned about whether waze team confirms them or whether waze team wants to share information about how they implement their tests. The only thing that matters in supplementary information about BDP testing is the information about the experimental design and the results of the tests.

---

<div class="post-metadata">

### Author: ![voludu21](https://www.waze.com/discuss/letter_avatar_proxy/v4/letter/v/0099FF/32.png) [@voludu21](https://www.waze.com/discuss/u/voludu21)
#### Post date: [November 16, 2017, 8:40pm UTC](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108/10 "2017-11-16T20:40:55Z")

</div>

Please try this on for size

[https://wazeopedia.waze.com/wiki/USA/User:Voludu2/Detour\_Prevention\_Mechanisms](https://wazeopedia.waze.com/wiki/USA/User:Voludu2/Detour_Prevention_Mechanisms)

A) I moved the requirement for last segment before and first segment after the possible detour to match OUT OF the definition of a detour - the list item Segments before and after the possible detour might need a new title. Suggestions welcome.  
B) Under Alsternate route, I stated that there is a continuity check, but made clear that we are never sure which continuity check is being used. I list all 3 continuity checks that our champs have suggested might have been in effect at one time or another, and make clear we never know which one is in effect at any given time.

---

<div class="post-metadata">

### Author: ![anon33958190](https://www.waze.com/discuss/letter_avatar_proxy/v4/letter/a/0099FF/32.png) [@anon33958190](https://www.waze.com/discuss/u/anon33958190)
#### Post date: [November 16, 2017, 8:51pm UTC](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108/11 "2017-11-16T20:51:51Z")

</div>

Looks good, but according to our style guide, things that aren’t proper nouns (possible detour, alternate route, etc) should not be capitalized. It was probably written that way before though. Bold will do enough to draw attention to the terms.

I thought staff did clarify that at least as of a couple weeks ago full continuity on the alternate route is required… If so, we should drop the “reportedly” in that section. I also corrected a typo

---

<div class="post-metadata">

### Author: ![voludu21](https://www.waze.com/discuss/letter_avatar_proxy/v4/letter/v/0099FF/32.png) [@voludu21](https://www.waze.com/discuss/u/voludu21)
#### Post date: [November 16, 2017, 9:53pm UTC](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108/12 "2017-11-16T21:53:57Z")

</div>

Thanks for fixing typos.  
Thanks for fixing the typo. Switching from caps to bold makes sense to me.

I guess I missed the part where staff confirmed that the BDP algorithm is currently doing the most strenuous continuity check. If that is the case, and if that is expected to be the case going forward, then it will make sense to drop the references to the other two less-strenuous checks.

Other than that, do you think the three list headings make sense? The second and third are “definition of” but the first one does not follow that pattern. I’m not sure what term I ought to be defining there!

---

<div class="post-metadata">

### Author: ![voludu21](https://www.waze.com/discuss/letter_avatar_proxy/v4/letter/v/0099FF/32.png) [@voludu21](https://www.waze.com/discuss/u/voludu21)
#### Post date: [November 21, 2017, 5:10pm UTC](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108/13 "2017-11-21T17:10:40Z")

</div>

Any more comments on this proposed change?  
Any reason NOT TO take this live now?

---

<div class="post-metadata">

### Author: ![voludu21](https://www.waze.com/discuss/letter_avatar_proxy/v4/letter/v/0099FF/32.png) [@voludu21](https://www.waze.com/discuss/u/voludu21)
#### Post date: [November 27, 2017, 9:05pm UTC](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108/14 "2017-11-27T21:05:11Z")

</div>

Based on the information above, I have made a major change to the proposed page:  
It now says that a Full Continuity Check is performed for the direct route.

This means that even a single-segment discontinuity will break BDP - which means that many wayfinders which have been on the map for a long time and never used to break BDP will now break BDP by introducing a discontinuity (name and/or type) on the direct path.

Please look this over and let me know if it still seems correct.

---

<div class="post-metadata">

### Author: ![anon33958190](https://www.waze.com/discuss/letter_avatar_proxy/v4/letter/a/0099FF/32.png) [@anon33958190](https://www.waze.com/discuss/u/anon33958190)
#### Post date: [November 27, 2017, 9:12pm UTC](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108/15 "2017-11-27T21:12:46Z")

</div>

I agree with the content but still think that terms like alternate route, continuity check, possible detour, etc. should not be capitalized.

---

<div class="post-metadata">

### Author: ![voludu21](https://www.waze.com/discuss/letter_avatar_proxy/v4/letter/v/0099FF/32.png) [@voludu21](https://www.waze.com/discuss/u/voludu21)
#### Post date: [November 27, 2017, 9:18pm UTC](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108/16 "2017-11-27T21:18:32Z")

</div>

If you would like to fix capitalization, please go right ahead. Thanks.

---

<div class="post-metadata">

### Author: ![anon33958190](https://www.waze.com/discuss/letter_avatar_proxy/v4/letter/a/0099FF/32.png) [@anon33958190](https://www.waze.com/discuss/u/anon33958190)
#### Post date: [November 28, 2017, 1:45pm UTC](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108/17 "2017-11-28T13:45:24Z")

</div>

> [@voludu2](#):
>
> If you would like to fix capitalization, please go right ahead. Thanks.

Done! I added an anchor in the Big detour heading to make sure the multitude of deep links to it still work.

---

<div class="post-metadata">

### Author: ![anon33958190](https://www.waze.com/discuss/letter_avatar_proxy/v4/letter/a/0099FF/32.png) [@anon33958190](https://www.waze.com/discuss/u/anon33958190)
#### Post date: [November 28, 2017, 4:53pm UTC](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108/18 "2017-11-28T16:53:41Z")

</div>

I’d like to suggest two parenthetical additions: I think there’s good evidence that the road type discontinuity requirement for a detour applies only to the last segment of the detour, and also that the last segment of the detour can’t share any name with the first segment after the detour. Some of the evidence comes from testing [this](https://www.waze.com/en-US/editor/?env=usa&lon=-152.87094&lat=69.62884&s=221773299&zoom=4&segments=509502037,509501842,509501843) and [this](https://www.waze.com/en-US/editor/?env=usa&lon=-152.88716&lat=69.55578&s=221773299&zoom=4&segments=509491844,509491843,509516500) in the app and Live Map. Each of these routes should be given due to meeting BDP criteria, but they don’t, while similar nearby setups do give the longer, evidently penalized route. Furthermore with the name thing, I could get BDP to fail and route through the collector/distributor ramps if I added a fake alt name to [these two segments](https://www.waze.com/en-US/editor/?env=usa&lon=-83.11824&lat=39.98347&s=221773299&zoom=5&segments=37496351,61833235), but when I took the name off those, BDP worked again. Adding and removing the alt name was the only change I made.

It would be nice to get staff clarification on this, but at least we could put something in parentheses like:

> [@](#):
>
> Name discontinuity
> 
> ```
> The possible detour must include at least one segment (including the last segment of the possible detour) that is missing this shared street name (as both a primary name and alternate names).
> No other continuous name - The possible detour segments must not all share any other street name with the both the freeway/highway segments immediately before and immediately after the possible detour [i](and probably, the last segment of the detour must not share any name with the first highway segment after the detour)[/i].
> 
> ```
> 
> Road type discontinuity - The freeway/highway segments immediately before and immediately after the possible detour must be from the same road type group as shown in the table below. The possible detour must include at least one segment not in that same road type group (probably including the last segment of the possible detour).

---

<div class="post-metadata">

### Author: ![ojlaw](https://www.waze.com/discuss/user_avatar/www.waze.com/ojlaw/32/4874_2.png) [@ojlaw](https://www.waze.com/discuss/u/ojlaw)
#### Post date: [November 28, 2017, 7:24pm UTC](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108/19 "2017-11-28T19:24:51Z")

</div>

hey there, i’m having difficulty with some of the grammar/ punctuation.

> [@](#):
>
> Full continuity - All segments of the Alternate route must have both name and type continuity with the segment immediately before and the segment immediately after the possible detour - the most resource-intensive continuity check. Reportedly, has been implemented from time to time.

the sentence “Reportedly, has been implemented from time to time.” has no subject(unless you intended reportedly to be the subject). is full continuity implemented time to time or is the most resource-intensive continuity check implemented time to time?

also that statement is very vague. words like “reportedly” and “time to time” makes it seem like the importance of full continuity is unknown. i don’t know about other editors but i look to the wazeopedia for clarification and absolute guidance. this kind of muddies the water.

> [@](#):
>
> If the first segment after the possible detour is the beginning of a freeway or highway then the first segment and, thus, can only be accessed from ramps or segments of a different road type group, then there can be no direct route according to the criteria above.

i’m having a real hard time with extra commas and possibly extra words(and/ thus). is “and” or “thus” necessary here? “…then the first segment and, thus, can only be” maybe this is what is trying to be conveyed?-  
“If the first segment after the possible detour is the beginning of a freeway or highway and this first segment can only be accessed from ramps or segments of a different road type group, then there can be no direct route according to the criteria above.”

thanks so much for working on this and bringing clarity to a difficult topic!

---

<div class="post-metadata">

### Author: ![voludu21](https://www.waze.com/discuss/letter_avatar_proxy/v4/letter/v/0099FF/32.png) [@voludu21](https://www.waze.com/discuss/u/voludu21)
#### Post date: [November 28, 2017, 7:40pm UTC](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108/20 "2017-11-28T19:40:32Z")

</div>

Karetographer -

I vaguely remember having heard at one time that “only the last segment of the possible detour was checked fo rcontinuity”, and that this was supposedly changed later.  
We should ask for confirmation that this applies to road type continuity as well as to name continuity.

ojlaw -  
I have already rearranged a lot of words in the criteria section, and taken out the “reportedly” phrase, which does not belong there now that the description of other possible chacks.

My goal with this rewrite was to make the criteria / checks up-to-date and easier to understand.  
I think the notes cold also use some work. But I’d like to get the criteria / checks finished and handle the notes as a separate task. Does that seem like a viable way to attack this page?

Meanwhile, I have rearranged a lot of words. Please have a look.

thanks!

[Next page](https://www.waze.com/discuss/t/page-update-detour-prevention-mechanisms/147108.md?page=2)
