Turn Instruction Override: Exit versus Keep for On-ramps

Map Editors Community United States US Wiki Discussion
1

MODS: I’m not sure if I should discuss this in the original TIO thread or not, please move as appropriate.

Currently:
After FC upgrades, all of our local arterials now inherited instructions originally designs for freeways and expressways, and we accepted that it is nonsensical to make every freeway interchange contain stubs segments to force a “keep”, rather than “exit”.

Now that we have turn instruction overrides, we should revisit this and come to a conclusion what we should (or should not do).

Right now:
Any S, PS to ramp at a less than 45 degree angle: “Keep right”
Any mH, MH, and F to ramp at a less than 45 degree angle: “Exit right”

Question:
With respect to freeway interchanges, what is a keep, and what is an exit? How should we handle this going forward, with TIO?

My interpretation–please share yours:
An exit is only for when an expressway or freeway leaves for a equal or lower type of road via a ramp.
A keep is for all other situations, including when entering an expressway or freeway from a lower road type via a ramp (i.e., an “entrance”).

Proposal:
Option 1: Ask Waze staff to change the rule, and never issue “Exit” unless an F (which by definition, always is an exit). All other instances should be TIOed when appropriate (an MH-class expressway). At this point, we could ask Waze staff to also only issue “Exit” for left exits on F. This simplifies our guide, as S-MH, as well as left and right, all behave the same with regards to instruction.

Option 2: Suggest in the TIO page that nothing should be done to enforce the distinction between “exit” and “keep” and one should leave as “Waze selected” if there is no other reason to override. (Status quo).

Option 3: Suggest in the TIO page that all freeway and expressway entrances via a ramp should be overwritten to “keep”.

2

This probably belongs in the TIO thread since it involves new option due to the new feature. It’s not so simple as higher road type to equal or lower. For example, this is a signed exit from a highway to a freeway. I don’t know if there’s a perfect general rule and I’ve always dealt with interchanges on a case-by-case basis.

I’m fine with mH/MH/Fwy to Ramp being ‘Exit’ by default, though I’m not a fan of it also being ‘Exit’ when the out is PS/S. However, I’m not in favor of any mass behavior changes by Staff as it would probably create more work than it would save.

3

I am fine with the status quo here. I do not think it is ambiguous or confusing.

4

Sketch, can you verify what the status quo is supposed to be? Are freeway on-ramps keeps or exit, or whatever Waze defaults to?

5

Status quo == what we’ve been doing == leave the Waze default alone.

TIO at every onramp is excessive, and Waze default is not confusing. Being told to “Exit” from an arterial road or numbered highway is hardly absurd. The app experience is fine as-is.

Now, for streets departing at shallow angles from mH/MH, that’s a different story… in those cases, “exit right” is confusing and “stay to the right” is the correct instruction (better than “turn right” from the dogleg days). If there is any generalized usage for TIO, I think that is a good one.

6

I agree with Sketch, as of right now I think we are good with what we have.

7

The CA team recently started talking about this same subject. In general I think most of us are fine to allow Waze default “Exit” to on ramps from uncontrolled roadways and not change with TIO.

I noticed in the wiki page it does not mention this combination and I think we should. It would be easy enough to just recommend no change to the instruction from an uncontrolled roadway to a freeway ramp and use the default “exit” instruction.

8

I think it’s certainly circumstantial, I have seen a few examples (Don’t have them off hand, if I remember later I will try to grab some).

But overall, I don’t think a mass change should be made. I don’t see tons of UR’s popping about it, so users are mostly unconcerned by the TTS.

EDIT: Here was one in San Diego that needs to be updated. But hearing “Exit to…” here didn’t feel right. And a few years ago was generating UR’s. There were a few freeway entrances like that around here in SD. This is a good place for the TIO. (IMO)

https://www.waze.com/editor/?env=usa&lon=-117.15616&lat=32.80134&zoom=7

9

My question back is, what is the difference between an “exit” and “keep”? If there are circumstances where we should prefer one or the other, it would be good document that actual differences.

10

I don’t know if we really can though. It could even be regional as to how people respond to each.

Unfortunately I am not as eloquently worded as some others here, but I am not sure this is something we will ever get a good consensus on, as it comes down to the actual intersection and how the people in that area respond.

Like in Michigan we add a “S” to many things that don’t have one at the end. Others notice it immediately, and we notice when others don’t use it. This may be a bad example, but I think it plays an important part.

11

I think the idea is to see if we can define under what conditions you would change from Exit to Keep since doing that will create a unique situation for that waypoint.

I would think that maybe in a more unique waypoint situation where you may have two lanes splitting to two directions and you must decide to keep left or keep right, then the default for an unspoken continue and exit right may not be the best solution.

The San Diego example you showed is like all the other uncontrolled roads with ramps to highways/freeways. Generally speaking I would not say that should have an alternate TIO. Based on the creation date of the stub, it appears to have been done back when the FC changes first took place and it was then strange to hear Exit instead of the prior Keep. Now that Exit is the standard, we should probably reconsider these early hacks. Maybe we set them back to default and find out if we receive any new URs.

12

The principle governing TIOs, I would think, is first and foremost that it really is an override for rare situations, and is not for casual use.

I sense that I’m preaching to the choir, but if the main problem is simply that we dislike Waze’s default behavior, the best-practice solution is not to make a mass campaign of overriding it one junction at a time. Doing so causes multiple problems:

  1. Drivers experience inconsistent app behavior, which could well be more frustrating than having to get used to idiosyncratic but at least consistent behavior.

  2. Verifying the map in WME becomes exponentially more difficult as “override” alerts (from Toolbox or other scripts) pop up like mushrooms after the rain, with each one requiring several clicks to fully understand the override configuration.

  3. If we ever decide to change our interface decision, there will be heck to pay trying to find and adjust every individual existing override.

  4. Editors who are not completely in the loop as to what is going on will be baffled as to best practice.

With that off my chest… :slight_smile:

This is my feeling as well. Basically, if a travel lane is lost to the onramp (our wiki already defines travel lane in the context of wayfinders, although some tweaks for surface streets may be necessary) then “keep” may be a better instruction. Otherwise no override.

13

Definitely agreed - I don’t want to see these at every intersection either, but used as rarely as possible.

Ditto this. I get the idea that the general consensus (from earlier in the thread and from other discussion I’ve seen on this) is that most editors and users are fine with the current behavior. With that in mind, I would propose that any guidance on this state that we use junction angles to choose between exit/turn instruction by default and that TIO for a keep instruction only be used in specific, exceptional cases that are defined (like we do for the guidance on wayfinders).

There is so much regional and local variation in the way that surface streets are constructed that it will likely be impossible to cover every case, so there probably needs to be some room for editor discretion. That being said, how about these cases as a starting point? I know there are more:

A TIO to give a keep instruction at an on-ramp is warranted if:

  • a travel lane is lost to the on-ramp
  • the roadway splits in two or more directions at the on-ramp with no clear continuation path
  • the on-ramp appears to travel in a straight direction for some distance after the split but is separated from the non-ramp lanes by a physical barrier or painted gore.

A TIO to give a keep instruction at an on-ramp is not to be used if any of the following are true:

  • the ramp entrance is signed with “exit” signage or an exit number
  • signage at the ramp entrance indicates a hard right or left turn using a horizontal arrow :arrow_right:
14

I don’t really agree with the idea that a ‘keep’ instruction is warranted when a travel lane is lost to an onramp. This is an argument for forcing a ‘keep’ instruction in the other direction—a wayfinder. But the need for a wayfinder in one direction doesn’t make ‘keep’ any more proper than ‘exit’ on the other side, and in fact, I would argue ‘exit’ is better in this case.

I do agree that the roadway splitting with no clear continuation path might be a good place for it, but again, the real need here is to ensure that an instruction is forced (again, wayfinder), and I don’t necessarily think that ‘exit’ is worse than ‘keep’ in all such cases as a rule.

The third example may make sense, I’d have to see an example though.

  • Please note that by “wayfinder” I do not mean the old style of configuration, obviously, unless signage calls for it. The wiki hasn’t been updated to reflect this, but “wayfinder” means a typically-forced instruction to stay on the road you’re already on, no matter the manner in which it’s achieved.
15

  1. Good point, I’ll have to mull on that and see if I can come up with any good examples. It seems like this is more a case of what the roadway looks like approaching the split but that probably means it could be merged into case #2.

  2. One possible example where a ‘keep’ could be debated due to no clear continuation is something like this. The highlighted segment is MH, causing an exit instruction to I-55 S. If it were a ramp, that would be a keep right, so really this is a question of consistency. I would not feel comfortable making the MH segment a ramp coming out of the traffic light to force a keep right. https://www.waze.com/editor/?env=usa&lon=-90.16351&lat=32.32578&zoom=7&segments=26608422

  3. The sort of setup I had in mind for the third case is something like this. We’ve been experimenting with different configurations at this interchange, since “exit right then turn right” just seemed odd. https://www.waze.com/editor/?env=usa&lon=-84.09111&lat=35.91870&zoom=7&segments=44933559,504650298,61204448

16

I agree with forcing a “keep right” for (2), and in situations like this generally, although I am not sure how to generalize it sufficiently.

I agree with the configuration in (3). It is an odd situation as the ‘keep’ instruction is really just for the painted separate lane in advance of further instructions, and I do think that is the kind of situation where ‘keep’ is justified over ‘exit’. But that is a bit more specified than the way you generalized it, as I do think ‘exit’ is fine in a situation where there is no further instruction, if perhaps a normal singular onramp has a couple hundred feet of separated lane before it actually diverges.

17

Good comments and examples. We could perhaps clarify that a wayfinder tells you how to stay on a road when it’s not clear how to do so; an exit instruction tells you how to leave a road when it is clear how to do so. So when a wayfinder is justified, that ipso facto says that the continuation is not clear, and therefore that an “exit” is probably a less obvious instruction to the driver than “keep” (probably some road geometries would be exceptions).

Meanwhile I agree with sketch’s take on grsmhiker’s examples 2 and 3. The problem, as sketch said, is codifying it.

We could back away from the lost-travel-lane language altogether and simply say that a “keep” override may be justified for onramps leading from uncontrolled highways when (a) the highway continuation path is unclear or (b) the onramp’s initial departure continues to share direction and pavement with the originating highway, either for an unexpectedly long distance, or leading to two or more subsequent offramps. These two parts (a) and (b) correspond directly to grsmhiker’s points (2) and (3).

18

From what I feel about the conversation thus far:

  • we should not be override ‘keep’ for ‘exit’ in the general case–to blanket override to keep is undesired
  • a desire to use ‘keep’ for /both/ directions when the continuation is unclear

Then could our answer just to fall back to the standard wayfinder criteria, but in an arterial road context?

19

From what I feel about the conversation thus far:

  • we should not be override ‘keep’ for ‘exit’ in the general case–to blanket override to keep is undesired
  • a desire to use ‘keep’ for /both/ directions when the continuation is unclear

Then could our answer just to fall back to the standard wayfinder criteria, but in the context of an arterial road?

If a wayfinder is not needed, then the standard Exit prompt is desired. Otherwise, use a TIO for both the ramp and the arterial?

20

I tend to agree. My concern would be that the guidance make it clear that overriding the default should be uncommon.

So, rather than “in situation x use exit”, the guidance would be better phrased as “in the rare case of situation y, the default exit instruction may be overridden to provide a keep right or left instruction instead”.