[NEW] Guidance for turn instruction overrides

Map Editors Community United States US Wiki Discussion
1

The following is a draft started by subs5 & nzhan1. I am posting it to get a draft in front of wiki folks quickly because the feature is live in WME Prod and we’re behind.

The initial draft is simply a documentation of the feature. We need to add specific guidance on when to use them. And when they can take the place of a wayfinder and when they cannot.

There is also no formatting set in this draft.

Creating an Override Instructions

wme_turn_override_hover2.png
wme_turn_override_hover2.png161×165 7.72 KB

When in WME and you click on a segment and hover over a Green or Yellow Turn Connection/Restriction Arrow, both the Time Based Turn Restriction (TBTR) clock AND the Turn instruction Override speaker icon will appear. If the turn is Red (restricted), then the override icon will not appear.
Available Override Instructions
When you click on the ‘’'Speaker", you have the following choices:
wme_turn_override_list.png
wme_turn_override_list.png598×277 8.3 KB

  • Waze Selected (this gives the default voice prompt turn, exit, keep right/left, etc)
  • None (No verbal instruction/recommendation is given)
  • Turn Left (The instruction/recommendation “Turn Left” is given)
  • Turn Right (The instruction/recommendation “Turn Right” is given)
  • Keep Left (The instruction/recommendation “Keep Left” is given)
  • Keep Right (The instruction/recommendation “Keep Right” is given)
  • Continue (Not available as of 2016-12)
  • Exit Left (The instruction/recommendation “Exit Left” is given)
  • Exit Right (The instruction/recommendation “Exit Right” is given)
  • Uturn (The instruction/recommendation “Uturn” is given)

If there is a selection other than the default “Waze Selected” then the circle around the speaker changes color from (Cyan) to (Orange).

When to Use Override Instructions

Exit Left
When there is a the Big Green Sign (BGS) indicating an exit left.
Discuss with your Regional Coordinator(s) and/or State Manager(s) to see if they want it added to locations where a HOV or HOT/Express Lane is separated from the regular freeway, highway, etc.

U-turn
This works well for one way segments that have a u-turn only lane. You can post a “u-turn” verbal prompt on the first left turn and “None” on the second one.

Streets not meeting at right angles
When streets meet at some kind of diagonal, the default turn instruction may end up being a “stay to the left/right” even though the driver would consider it a left or right turn. In these cases, we have historically modified the angles the roads meet at a very high zoom level:

Simple Wayfinder
Simple wayfinders use an unnamed segment simply to force an instruction where one would normally be voiced. This is most often a “stay right” or “stay left.” A basic example is a roadway with a split where left lanes go left and right lanes go straight ahead. To ensure the driver is kept on the correct side of the roadway to stay on the expected route, we create a wayfinder on the “straight” segment to force a “stay to the right instruction.”

An example of this is shown below. The selected segment is unnamed, and you can see the name of the street on both sides of the wayfinder are the extact same name. For drivers heading the direction of the arrow, the unnamed segment forces the app to give the driver the instruction “stay to the right to El Cajon Blvd.”

The guidance here is to remove (or rename and join) the unnamed segment, and replace it with a “keep right” turn instruction override.

Complex Wayfinder
A complex wayfinder is one where the legs (child segments) are named differently than the subsequent segments. The wayfinder segments are named for the Big Green Sign (BGS) verbiage for clarity.

For these kinds of wayfinders, a turn instruction override does not have the required functionality and should not be used.

2

A lot of this was put together by subs5, so h/t to him as well. I’ll try to find examples of when to use exit lefts. Maybe some SV imagery of left exit signs.

3
4

I like BGS like this where they justify (left/right) the exit number based on the side of the road where you exit.

5

You may notice formatting and other updates as I am continuing to update the original post.

6

Perhaps this is a discussion for later, when “Continue” becomes available. But I figured I’d ask it now.

is there going to be national guidance on when it’s appropriate to implement a “Continue” prompt? In other words: Should every freeway entrance which is a basic continuation from a feeder street be notated with a “Continue”? Or is this going to be a state/regional preference?

7

Do we also need to consider reviewing AGC guidance? In many places we’ve been adding 90 degree mDLs to a force a turn right rather than exit right instruction. The override might be a solution to match AGCs to their real geometry. Thoughts?

8

I would like to have some standard national guidance, yes. The example you provided is good for documenting. Map-based examples would be good to have.

Yes! I believe this is also good. Though for some very long turn lanes, I don’t think a “turn right” 800+ feet before the actual turn is a good idea. Examples are welcome.

9

We may want to take care to keep departure angles around ~20° to preserve the ability to close roads from the app (due to the pitiful nature of the app’s road closure tool).

10

Just a couple of recommendations:

Current: Creating an Override Instructions
Recommended: Creating Override Instructions or Creating Instruction Overrides as the feature is being called by staff Instruction Override.

Current: If there is a selection other than the default “Waze Selected” then the circle around the speaker changes from cyan to orange.
Recommended: If the “Waze Selected” default option has been changed, the Instruction Override speaker icon changes from cyan to orange.

U-turn
Current: This works well for one way segments that have a u-turn only lane. You can post a “u-turn” verbal prompt on the first left turn and “None” on the second one.
Recommended: If you have one-way segments with a u-turn only lane, adding an Instruction Override u-turn prompt on the first left turn and setting the second left turn to ‘None’ will create a better TTS experience for the Wazer and more accurately depict what the driver needs to do.

11

Accepted.
[hide]

[/hide]
Wiki-based draft available here: https://wiki.waze.com/wiki/User:AlanOfTheBerg/WME_Turn_Instruction_Override

12

Looking for this guidance in the wiki.

FYI, I am finding many places in the wiki for turns, junctions, “how waze determines instructions” which need to have references or modifications because of the override available.

13

I think it’s a good start. After reading it, I’m beginning to wonder if we need to be more explicit that this should be replacing mDLs where possible or if the override should only be used in exceptions. Can we get clarity on which is preferred or is that another can of worms to discuss?

Sent from my iPhone using Tapatalk

14

I think we are looking at a whole retraining of editors on how to design an intersection potentially and further challenges if TIO is rank locked on how best to proceed.

15

It is great that this new feature is being documented.

I’m concerned that the tone of the article seems to suggest a campaign to update the map, which troubles me. In particular, this passage:

One example of how a campaign to change the map could cause trouble: if micro-DogLegs (mDL) at a left-left U-turn are removed as no longer necessary by an editor redoing things en masse without paying close attention, and replaced with a U-turn and no-instruction overrides, some U-turns could become prohibited because of parallelism and too short a cross-segment.

Or, an energetic editor with the perception that older constructions are deprecated could go on a campaign (or rampage depending on one’s point of view), removing, renaming, joining everywhere possible, potentially leaving new mistakes when there were no problems before.

Another potential side-effect is a surge in unlock requests so the map can be “fixed” when it is already working just fine.

It is a great new feature and I sure have no desire to deny it to those who want to take advantage of it. And I don’t want to sound alarmist, although I have seen something like the above scenarios play out before. I’m just concerned that the tone of the wiki could set off an unnecessary fixup rush that won’t actually serve drivers or the volunteer community.

I’d like to recommend (1) adjusting the language to be sure the wiki in no way recommends fixing what ain’t broke and (2) adding a “there is to be no campaign” warning box or disclaimer.

p.s. I’m puzzled that this discussion is limited to the US; in fact in one place the draft wiki devolves authority over best usage to the regional and even state level. I’m not at all sure it is in the best interest of the volunteer community for every state potentially to have a different approach towards implementation. At the same time I am well aware how hard it is to gain agreement among editors at anything above the local level, so perhaps this is the only realistic approach.

16

I don’t think people are advocating for a rush to change things. I think it is important to ensure new edits going forward are utilizing this feature over our historic alt name or road to nowhere hacks. And to think about the longer term plan.

It is also important to think how this will impact the next generation of of editors training and learning. All of the sudden we have a tool that impacts BC, junction angles, wayfinders etc. if it ain’t broke don’t fix it mentality should be taken as mass fixing things will result in mistakes as you mentioned.

Clearly this is the future of how we design intersections moving forward and finding the right balance to aid in this transition is important.

17

Yes indeed, I agree that few of us want to unleash a new campaign to fix what ain’t broke. And I agree that this is the way of the future. And heck, it beats all the crazy stuff we used to have to do!

What I’m trying to say is that the current draft of this wiki may read, to some anyway, like a change order. All it takes is one enthusiastic editor to misinterpret the wiki as a call to arms, and the rest of us could be doing damage control for months. Again, I don’t want to be an alarmist, but I have seen this very sort of thing happen. Adding some cautions and disclaimers to the wiki, and toning down the “the guidance is to replace” language, will cost very little compared with the potential benefit.

18

I am not sure I understand the concern from a high level. We now have a way to do away with a pretty large number of map hacks to use what Waze would prefer us to use. It’s not a “campaign” but it sure is ok if editors start fixing the map to be more standardized.

Also, this is a pretty big change in behavior. Most editors are familiar with the current state and guidance on forcing instructions in a variety of situation. Without including from-to examples, it’s going to be difficult to understand which guidance is being modified to what.

The page could be more specifically current state. I think lots of pages have too much “history” in them. Maybe make it all “here it is” and a separate page for “from-to” examples?

19

I have reworded much of the page which referenced previous guidance, also modified a couple of images.

For reference, compare these versions if you wish: https://wiki.waze.com/wiki/index.php?title=User%3AAlanOfTheBerg%2FWME_Turn_Instruction_Override&diff=154572&oldid=154368

20

As I said, I don’t believe those of us involved in this discussion want a “campaign”. But it doesn’t matter what we want. What matters is the message that wiki readers take home.

If readers get the impression that current map structures are “wrong” and must be “fixed”, then there will be a campaign, regardless of our intent. I have seen this happen, and it was to the detriment of the map.

Of course I understand why we’d want to use the new system going forward, and I get why it wouldn’t hurt, when a construction is already under the knife for other reasons, to update it. But why do we want to do away with innocent constructions that are doing their job and working fine? I do not understand that perspective, at least not from the standpoints of app reliability or of editor productivity and efficiency.

Granted, I’m someone who has had to learn the adage “if it ain’t broke don’t fix it” over and over again – the hard way. Maybe I’m too old for this :mrgreen: