[Page Update] Junction Style Guide

[qwaletee]

DL,

Have to try that on a true wayfinder. You're showing a bit of an unusual situation. I imagine it would be correct all the moreso for a true wayfinder, but I would like to see it tested.

[qwaletee]

I agree. Whether or not the lanes start just before the exit/split/ramp is highly relevant to the wayfinder judgment call. I have been thinking about that recently. Same thing where all the exit only lanes on the right only just started at the previous interchange, maybe less than a mile behind.

So the left exit should require at least one exit-only lane, and that the exit-only lane(s) started substantially before the exit point. The right exit should still require that at least as many lanes exit as continue, and should be qualified by saying that a wayfinder is not necessary if those exit-only lanes started at the immediately-previous interchange.

"At least as many" is overstating it. There just needs to be enough to make the exit and "non exit" have some level of parity. Do we really want to exclude a situation where left has 5 and right has 4? That just seems arbitrary.

[qwaletee]

How about :

When an exit has multiple lanes, consider whether drivers may be confused about whether it is an exit or a continuation of the main road, or may simply accidentally exit where he or she was already on the lane that approaches the exit. The same applies where there are only two lanes, and each curves away where the road forks. Streetview images can help you determine whether there will be driver confusion, or a driver in the right lane may accidentally exit

In such situations, where Waze normally treats the continuation as not requiring an instruction, you will want to override this behavior for the confusing junction. Use a wayfinder junction. It will cause the driver to be explicitly instructed to keep to the appropriate side of the road. If you are not certain, whether there is a problem, err on the side of caution.

[qwaletee]

Sketch,

We clearly can't take the editor's judgment out of it. The questions are:

* How tightly can we craft the rules be without creating the need for exceptions?

* How tightly can we craft the rules without making them too complex to follow?

* How well do at least 85% of the applicable situations conform to principle and rules simultaneously?

* How much trust do we place in the average editor (especially given that the typical use case for this particular feature is a highway, most of which are locked above newbie ranks)?

Also, don't forget, drivers have no notion of our standards. The only standards they hold us to are 1) did you know where I wanted to go, 2) did you find a good route for it, 3) did you instruct me along the way in a fashion that I could follow easily without being annoying, and 4) did you fulfil the Waze value adds that come from crowd sourcing (ephemera such as traffic reroutes, hazard warnings, etc.)

We have standards to promote the above, not for the sake of pure consistency to the driver. Drivers will not notice most inconsistencies from one route to another or one map section to another, so long as the 4 key principles (especially the first 3) are met. A corollary is that many rules promoting consistency provide more advantage to editors that to drivers. Standards help editors look for things they expect, and understand whether there is a well mapped section of the network or one that needs work. Validator is great, but think we all recognize that it sometimes elects an inappropriate standard. Nevertheless, it puts a lot of editors on the same page for expectations, making it easier to edit.

Standards can certainly benefit the three things the user is looking for (properness of destination/route/instructions). For example, FC standards for the most part do improve routing. And they can also benefit the developers, because programmers have expectations for what map data means to the concepts (algorithms) needed in navigational programming. For example, the pre-FC standards had different physical properties for highways, which when changed, caused the traffic management algorithms to behave unpredictably. The change in standard "startled" the algorithms, because they were written to a different set of assumptions, and some adaptation is now needed. Once Waze and the editing community are sync on how to deal with this, the editing standards will once again benefit the programmers on this. Standards imply immutability, and violation of that can sometimes ring alarms.

The occasional standard also manages benefits the driver in a "small" way. For example, the standard of AGC taking the lower connected segment type provides a visual benefit in that it prevents zoomed out ramps from appearing to be connected to nothing. I may personally not agree that it provides a benefit, but others do find it to be a benefit. So this standard doesn't really help editors (I don't think editors for pure editing purposes care about this), it doesn't help developers, and it doesn't help us meet the 4 key driver expectations. Nevertheless, in this case, for those who prefer this look, it is an example of a standard that benefits the driver.

OK, I'll get off the soapbox now, and explain why I think this is relevant to the discussion.

The raison d'être of wayfinders is meet driver expectation #3 - comprehensible, appropriate turn-by-turn navigation. In other words, it keeps them on the route, or at the very least, reduces uncertainty for the driver about how to stay the course. Any wayfinder that introduces difficulty violates this purpose. Any wayfinder that neither adds nor removes difficulty does not violate the purpose, but does not meet it either; further, it complicates the map, making maintenance more difficult and increasing the likelihood of error. (I don't have server load as a consideration, because that's really least important to us.)

If we create rules that are too rigid, we risk moving away from the raison d'être. I would seriously think it is loony to ask the editor to effectively fill out a questionnaire that determines yes/no wayfinder, without doing his or her own needs analysis: with guidance given, would a particular junction provide more benefit to the driver with or without a wayfinder; does an existing wayfinder provide more benefit to the driver or not.

I don't want chaos. I just want to choose an appropriate border on the spectrum between "minimal guidance" and "inflexible and/or overly complicated rule," crossed with the general benefit of human intelligence. Every map editor is an analyst by avocation. Those who aren't, never become good editors. Structures that reduce this analysis result in an overall poorer community of editors, and in some fraction of cases, large or small, in poorer mapping of exit junctions, forks in the road, and instructions matching road signs.

How to bridge that gap? We can start by defining the rules, but then also providing guidance for some known cases where the rules fall apart, and then ask the driver to look out for these or other situations where the rules of wayfinders are contrary to the philosophy of wayfinders.

And now, for the second time, I put away the soapbox. Sorry for boring you with my ramble.

TL;DR: Ideas drive rules, but rules don't always adequately express how to make an idea work. Human intelligence does that.

[qwaletee]

Sketch, I'm going to take your comment as being constructive, not dismissive. Nevertheless, I know of what I speak.

[qwaletee]

Carl, I believe the word you are looking for is "merge."

DwarfLord, a little bit of a different experience. First time i used Waze, must be 18-20 months ago? I had a longish stretch, maybe 30-45 minutes of no instructions. It was disconcerting to have no instruction. Surem the display said 50 miles, or whatever it was, but there was that nagging ffeling that maybe voice had stopped working or something.

I suppose it also helped that on the first drive after an install, the app does not show remaining trip length between the two menu bubbles on the bottom.

[qwaletee]

And now, for something completely different. I have an additional use case. We normally don't give lane guidance, but I believe the below case calls for a WF to give lane guidance. I've been reverted and received a lot of flack for doing just that, but I can testify to multiple people (including myself) getting caught flatfooted by this.

Situation: One lane of traffic, which becomes a left-only lane with little warning right after an additional lane opens up beside it. The straight ahead lane continuance form the single lane is clearly the one that becomes a left turn lane. It is a state highway, but really not much more than a semi-rural 2-lane local road, no controlled access, 40mph speed limit, average speed probably just shy of 50.

We don't normally give lane guidance, but I would think this needs it, and thus needs some variation of WF. It is bad engineering, but it happens.

https://www.waze.com/editor/?zoom=5&lat ... 7,79851480

SV of the 1 -> 2 lane "fork" https://www.google.com/maps/@41.065383, ... tdyszg!2e0

SV of the short throw for first warning that the lane is abou to become left turn only https://www.google.com/maps/@41.066311, ... jxeqMg!2e0

Closer view of the above - it is only approximately 4s warning (70m@40mph speed limit) https://www.google.com/maps/@41.067091, ... 6MJddQ!2e0

Perfect storm, yes?
* Insufficient time to maneuver without guidance
* Unclear lane split
* Geometry goes against normative driver expectations

The general case would be unexpected changes in maneuvers allowed for a lane with minimal time to react. Do we consider this common enough to require a rule? Is there a better way to state this? Is it too much of an oddball case to cover in the wiki, but should nevertheless get a WF?

[qwaletee]

Or maybe we're just grinding on this too much.

[qwaletee]

That's not what I meant. We sometimes get more specific than we need to. That doesn't mean the page is great as-is, there's definite room for improvment. But I'm uneasy with your specific guidance in this case.

[qwaletee]

OK, I misunderstood you, sketch. We're thinking along the same lines, then.