Switch to full style
Post a reply

Re: [Page Update] Detour Prevention Mechanisms

Thu Jan 17, 2019 7:24 am

Sorry, but to me, a lowly R3 editor, prevent means prevent, and if it fails to prevent then it failed. There is no difference between "prevent" and "prevent absolutely", just as there is no difference between "stop" and "stop completely". The current nomenclature is confusing, in more ways than just this. It deserves to be revisited.

Re: [Page Update] Detour Prevention Mechanisms

Fri Jan 18, 2019 4:40 am

sketch wrote:No prevention method is 100% effective. Condoms break, crimes still happen, and automobile engines still die no matter how diligent you are about changing the oil.

Detour Prevention is what Waze staff calls this mechanism and therefore is what we shall call it as well.

Of course we will. But because the terminology confuses me, I will continue to think of it as "Big Detour Penalty" in the privacy of my mind. I promise I'll do it quietly - you'll never even notice.

Re: [Page Update] Detour Prevention Mechanisms

Mon Dec 28, 2015 3:34 pm

The other quite confusing issue at this point is that the actual mechanics of whatever you want to call this are set forth here: https://wiki.waze.com/wiki/Detour_Preve ... anisms/USA

However, we have not yet been able to reach agreement on how to present this information on the global page.

Re: [Page Update] Detour Prevention Mechanisms

Wed Jan 13, 2016 11:27 pm

Well for the record I'll state that I have no objection to Detour Penalty. I didn't really put much thought into the title which was originally "Small Detour Prevention Mechanism." Alan immediately called me out on Small, which proved prophetic when waze came up with another detour penalty for even smaller detours.


Re: [Page Update] Detour Prevention Mechanisms

Wed Jan 20, 2016 7:06 pm

What do the "name-discontinuity" and "uninterruped name" concepts add to understanding the BDP? Would this be correct?
https://wiki.waze.com/wiki/User:CBenson ... Mechanisms

Re: [Page Update] Detour Prevention Mechanisms

Wed Jan 20, 2016 10:16 pm

Regarding the Criteria section, the significant differences that I see between my draft and your proposals are:

1) I've eliminated the "to be considered as a possible detour" paragraph. Even if the routing algorithm operates with a two step process, I'm not sure it matters to us if as long as "detours" are a subset of "possible detours." My reasoning assumes they are. That is there are no "detours" that meet the criteria for "detours" but are not penalized because they weren't evaluated because they failed to qualify as a "possible detour."

2) The current wiki defines "name-discontinuity" as a series of segments that . . . . The possible detour statement refers to "a series of segment that contain a name-discontinuity." I've read this to mean that the possible detour can be comprised entirely of segments without the relevant street name or can include some segments that have the relevant street name as long as one is missing the relevant street name. This fits with my understanding of the BDP, so I'm pretty sure this is correct.

3) There has been some confusion regarding the road type limitation. The wiki states: "The possible detour is not composed of the same 'Road Type Group' as the continuation after the possible detour." The first question is does "not composed" mean does not include any segments of the same 'Road Type Group' or does it mean does not include all segments of the same 'Road Type Group.' My experience tells me this should mean "does not include all segments." In other words the detour must include at least one segment that is not in the same 'Road Type Group.' The second question is that the 'Road Type Group' limitation is also mentioned in the possible detour paragraph and seems to modify the series of that contains the "name-discontinuity" series. If this is intended to mean that a segment with the 'Road Type Group' discontinuity must also have the "name-discontinuity," then I do not believe I've included such a requirement in my draft. (It is usually the case, for example a ramp segment with the name discontinuity, but I don't know if its required or not).

4) The final difference that I see is that I have changed criteria 5 regarding the one segment rule to refer to the possible detour rather than the name continuity. I'm fairly certain that this is the basic change that needs to me made even if my other suggestions are not adopted.

Re: [Page Update] Detour Prevention Mechanisms

Thu Jan 21, 2016 7:32 pm

I don't know. I don't think its good practice to name cross streets between a divided highway with the name of the highway in order ensure compliance with a shifting BDP implementation.

Re: [Page Update] Detour Prevention Mechanisms

Thu Jan 21, 2016 9:10 pm

I don't know. I think I have to disagree.

PesachZ wrote:In the USA this would not have been an issue at all, since our guidance here is to always add a cardinal direction to end of a divided freeway name.

Where is this guidance?

It seems to me that add names to segments that are clearly for a road with a different name is bound to cause problems in the long run. To do so because the BDP may potentially be changed to penalize this route still does not seem like good practice to me.

Re: [Page Update] Detour Prevention Mechanisms

Fri Jan 22, 2016 1:11 pm

sketch wrote: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.

I think I disagree. Unless the address matching has greatly improved, putting cardinals on named highways where the cardinals are not typically used for address searches causes problems. Besides if this is not worldwide guidance, then the BDP should still be designed with the idea that there will be divided highways with the same name on both carriageways.

PesachZ wrote:I will argue that I believe with the information above we have a very solid of how and when BDP today. Like anything in the routing engine, especially penalties, they are always in a state of potential flux. Therefore when we know that a specific limitation is only implemented due to processing constraints, as opposed to intended operation, it is prudent to assume they may improve the process to more accurately meet their intent at some point in the future. We therefore when designing guidance should do so in a manner that is compatible with the operation today, as well as the intent. This will give us configurations that work 100% of the time.

But if the current operation works better than the "potential" operation, like it does for edsonajj's example, shouldn't we tell the developers that changing it is likely to cause more problems than it solves?

Re: [Page Update] Detour Prevention Mechanisms

Mon Jan 25, 2016 4:30 pm

sketch wrote: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.

I'd just state for the record that I believe that there are plenty of divided roads that are not limited access freeways and expressways and that these roads account for more than 0.1% of multi-segment U turns (particularly as there are destinations on such roads that require U-turns to get to and from).
Post a reply