I made it up, so I’m gonna say it should be used with the original concept
The other thing is called a “stub”. They used to be pretty much coincident with each other (all wayfinders required at least one stub, and stubs weren’t really used in other places), but now that the concept of the wayfinder can be in some cases implemented without use of a stub, the mixing up of the two has become more confusing.
“Wayfinder” assists you in finding your way along the route you’re already on. Similar in concept to “pathfinder” or “trailblazer” or “reassurance” signs you see on the side of a highway periodically. I’m not sure if I meant to create a word similar to “pathfinder” or if I simply remembered it wrong.
I suppose there’s concept of “wayfinder stubs”; i.e., short segments created (matching BGS) to give a direction, as well as the concept of “wayfinding”, where a Wazer may be uncertain of where to continue.
A “wayfinder” is an installation that creates an instruction to stay on the road you’re already on, however it is done.
A “stub” is a short (~6 m) segment used to alter instruction behavior and/or road name.
A “wayfinder stub” is a stub used in a wayfinder.
There are wayfinders accomplished other than by stubs (TIO, yes, but also alt-name manipulation), and there are stubs used for things other than wayfinders (e.g., so a turn instruction matches a sign that is other than used in addresses for that segment).
The entire page needs some cleanup. The structure is not very conducive to understanding the individual instructions. I’m also debating whether we need information about using them in exception cases that need SM/RC input.
Here is my $.02 on adding continues where a road name changes. Here is a segment from a frequent drive where a little more instruction would be helpful to drivers:
After turning from S 500 W onto W Center St, the first instruction given is “In 6 miles stay right to Exit 271”
Where I am familiar with the route, it doesn’t confuse me, but to a driver unfamiliar with the area, it leaves them wondering where Waze thinks they are.
Can we ship at least the guidance, and then do the refactor? The purpose of this change is to include guidance for Continue, and I’ve already refactored it slightly.
I’ve added a clear statement as to what it does:
Any SM/RC input would override guidance put into the wiki anyways. I’m not seeing any value in fluffing every single guidance with “speak to your SM/RC”. A good SM/RC should be able to justify why a specific scenario requires special attention, and a national Wiki cannot possibly contain every possible scenario. Plus, we already prefaced in the Creation section to speak with an SM.
There’s a difference between “it’s great to do this, unless your local authorities tell you not to” and “don’t do this unless your local authorities have said it’s OK”. We seem to be leaning here towards the former.
The problem is that, in some regions, RCs and SMs are not very active or involved. This is not a criticism, we are all volunteers with many demands on our time. It’s just a fact that RCs and SMs can’t be everywhere saying “no” to uncomfortable constructions. So if guidance does not explain the tradeoffs – the reasons AGAINST using a tool as well as the reasons FOR – there’s a strong possibility nobody else will. This will leave editors less informed to make their own judgements.
In California we have been discussing many concerns about potential overuse and misuse of the Continue TIO. We may end up writing our own article on it, in which case the USA article should suggest that readers check state pages. If this comes to pass I’ll let folks here know.
I’m OK with holding off on the refactoring. But usable guidance is critical. Think problem solving, and how reading the article helps direct a situation - does or doesn’t get a junior/experienced editor to know what to do, or senior editors (SM+ type) to confirm the guidance they have in their heads for the situation in front of them.
To make that work, we have to know what the common positive and negative use cases are and describe them. That includes expanding on the what we briefly mention about not doing wholesale mDL and WF converts.
I have made some semi-major refactor to the article, but short of rewriting the JAI–I’m not sure what else I can do with this article.
The scope was simply to add use-cases for when and when not to add a TIO for continue, which is fairly clear. The blob about mDL and WF converts was a relic of the existing article; however I have re-written it and added links to the rest of the wiki.
I was just following up on what is the status of the Continue Straight TIO guidance. I have seen many requests regarding this. Lots of good work has been done here. Do we think it is near finalization?
Been a while but I think we should get this through.
I made a couple of small changes, removing the word “wayfinder” and substituting “named stub segment if necessary” in a couple of places (again, not the same thing). I also added some bold to make the situations themselves stand out a bit more.
I made some wording changes to “Terminus of a freeway” to make it easier to understand, and some tweaking on the wayfinder section.
Other than that, I think we’re good. These are all sensible and pretty much industry-standard stuff, and we’re still less chatty than Google Maps.
Those changes look good. Has the comment period expired now, and can you push this live? We have been applying some of the drafted principles already in NJ, and it would be good to have this seen as final.
I do want to suggest one small change, that a continue be used to supplement a ramp fork as well as a wayfinder, for all the same reasons and criteria listed in the supplement a wayfinder section. Sometimes a continue instruction makes sense on one part of a ramp fork, if it uses all the travel lanes or is part of a three-way split. So the section would be called “Supplement a wayfinder or ramp fork”, and the first sentence would read “… where a wayfinder is warranted for a particular direction or a ramp fork exists, but ‘keep’ or ‘exit’ would be misleading.”
I think more than enough time has passed for these changes to be discussed, this should go live with or without my suggestion here, and just to clarify since the links aren’t in the first post, this is Nagamasa’s draft TIO page, and this is the diff between the draft and the current version of the TIO page.
Some monday-morning quarterbacking here. I’m not super happy with this “when not to”:
=== You don't like the Waze default ===
Don't use a TIO to override the default just because you don't like it. We can't manage changing thousands and thousands of intersections like this.
We (editors) are literally responsible for managing thousands of intersections. Also what does “just because you don’t like it” mean? Do you not like a “exit right” from a mH because it doesn’t fit the nature of the road (bad, but not awful) OR do you not like a “keep/turn/exit left” because it’s actually a u-turn AGC (incorrect).
That specific section needs some help, or to be removed altogether.
