I completely misunderstood you. Thank you for pointing me towards that fantastically technical and though-provoking thread. I sensed my answer was WAY too simple for the question you were posing! As there still seems to be some confusion on this rule and do not wish to continuously add/change the guidance, I prefer waiting for further clarification. Do you agree?
Draw much? 
Thank you for the clear images! Assuming that there is no continuity issue I dont see how implementing this change to the guidance for the sake of visual appearance would be detrimental. I also dont find the visuals as annoying as some, but the guidance needs to be collaborative. As I said before, its changing PLRs to PS’s that I have a problem with, S to PS, not so much.
My BIG concern here is actually based on the aforementioned thread here . In your specific examples we would be adding in unnecessary detour prevention. In fact based on sketch’s last post there (Timestamp: Thu Sep 11, 2014 11:51 pm) I would vote to make PS’s an exception to the rule and NEVER use type:ramp regardless of the BGS, so that we dont have to deal with UR’s and routing issues. Assuming this turns out to be Waze’s intent.
I like the way you listed the 3 types of jugs, eliminating almost all the usage of the words ramp and at-grade connector. The wiki should follow that theme to avoid confusion.
Looking for consensus regarding these 2 points:
1 - When the BGS says just the name of the road, we agree not to use ramp type. Would you agree that if the BGS lists the local name of the rd (our primary) , as well as the County road name (alt) , the same should apply?
2 - If ramp type is used the road name should NEVER be blank.
Opinions please!
I would agree with that because it’s still a “direct connecting segment name” (pulled from the wiki). IMHO, a ramp means exit and pay attention to the directions as you need to make a decision. Where as this is just a glorified turn onto a road so it should follow the guidance of matching the lowest connecting segment
This makes sense, as per my view of ramps. We’re asking drivers to engage in the act of exiting one roadway and looking for another. There could be a variety of configurations so naming the ramp should hopefully queue the driver with voice guidance.
Unless that ramp section connects to multiple exits. This would be one of the only cases that a ramp segment would be left nameless.
example: A ramp leads to another highway, and two different streets (Multiple BGSs)
I was literally typing this out when I saw you posted. Thank you for pointing this out.
#2- Would change as follows:
Usage of the ramp type, per the definition of the guidelines, would require an exit name on at least one segment of the jughandle.
Sound better?
Sent from another Galaxy using Tapatalk 2
George, there’s a routing problem with you r proposal for upgrading the street to “complete the loop.” The routing problem exists even without your proposal, but once we’re changing road classifications to accommodate the visuals, we should think about this, too.
There is a penalty in Waze for a highway-ramp-other-highway routing (where other is any non-highway, non-ramp, including S, PS, or anything else). This creates an exit-and-reenter penalty (similar to the highway detour penalty).
In the case of a divided highway requiring a U-turn, that’s exactly what you’d get. So for continuity, we may want to do one of the following:
-
Turn the segment of local road that “completes the loop” into a ramp, so there is no “exit,” just highway/highway via ramp. This would have to also include the segment running between the sides of the highway.
-
Turn those segments into a highway type (I don’t think which type will matter for our purposes, probably use lowest type present at the intersection; since this would generally accommodate only last mile routing, the usual FC continuity issue should not apply)
-
Use dual roadways for the affected portion, effectively turning A/C into B - probably cleanest visually, but more complex to maintain and subject to error?
EDIT: This post has been deprecated by sketch’s latter posting on this topic.
[color=lightgray]That’s a bummer about the highway-ramp-other-highway penalty. To me, the biggest threat this poses, since U-Turns are really only used by Waze to reach nearby destinations on the other side of a divided road, is if there is like an unsignaled opening in the middle of the highway where U-Turns are not banned, despite a closer, marked jughandle where a U-Turn could be made.
So, of the 3 solutions presented by qwaletee, the most simple for any non-advanced editor, who may not be familiar with all the intricacies of jughandles and how they impact Waze, is the solution where we just dump the ramp type for jughandles altogether, treating them as any other AGC in which each jughandle segment would be the lowest type that maintains continuity of all the segments it touches. The drawback, of course, is that this will litter the map with potentially long, ugly tangential text for the BGSes found at the jughandles’ entrances. One possible solution would be to use short wayfinder stubs at the jughandles’ entrances to reduce the chance of such tangential text actually being rendered on the map, but these jughandles occur a lot, all over the state, which really might be inconsistent with the highly-exception-only basis on which wayfinder stubs are intended to be used.
Option 3 is the purest solution in terms of road type selection, but also produces the threat of overlapping road errors, especially if super-detailed attention isn’t paid to junction angles at very close-up zoom levels. This is totally prone to all kinds of errors from anyone who would not completely understand why we would choose this option, so I don’t think we should do this.
The final option mentioned requires us to choose between a highway type and a ramp for any segments required to complete the loop of a type A or C jughandle back to the highway. Both will be less obvious to newer editors as to why it has to be done that way, but both also let us continue using the ramp type for the jughandle itself, both suppressing its BGS text and eliminating any possible need for wayfinder stubs at their entrances.
Personally, I think using the ramp type to complete the loop for the segments between the jughandle and the highway will look cleaner in the client display, especially at closer zoom levels. It will also render more consistently with the type B jughandles, which already form a closed, dedicated ramp-type loop back to the highway. The only potential caveat here is that if any part of that jughandle loop is shared with a 2-way road, that segment would have to be unnamed, as 2-way ramps are required to be unnamed (not sure why, actually, but it is programmed into WME validator as a blue-level error).
Do we know if it would cause problems anywhere with TTS announcements if any of those segments pointed out in my 2 illustrations as upgraded to PS were instead set to nameless and type Ramp?[/color]
Not to argue with any of your reasoning, but I just want to confirm. Perhaps a champ with a personal understanding of the penalty system could chime in.
I’m not sure the penalty is automatically invoked by going from highway>ramp>non-highway>highway. My understanding was that the penalty was invoked going from highway>minimum of 2 non- highway segments (which includes the one variation of ramp>non-highway)>highway, but it ONLY applies if the names or the alt names of the two highways are identical.
In the case of a U-turn through a jughandle, the highway names won’t be identical because of the compass cardinals at the ends. One of the reasons it was setup this way from what I understood was specifically not to prevent users who missed their exit from being routed back to the other side of a freeway.
Of course it is possible we are discussing two different penalty systems, and I’m just not aware of the one qwaletee mentioned.
There is not a penalty for going from Major to Ramp to PS. That was a misunderstanding.
The reason the jughandle was not used in that case is simply that it was slower than taking the U turn.
The reason small detour prevention didn’t kick in is that small detour prevention is designed to give a simple left instead of a straight-U-right, and so forth; it is not designed to prefer a jughandle. There was no active small detour prevention in this case, so whatever “Major-Ramp-PS” penalty that might be somehow involved in the detour prevention algorithm was not at play here. That penalty is not active under normal circumstances.
There is no penalty I’ve ever heard of for going from a highway to a ramp to something else then to a highway. Not to say there isn’t a routing issue – there’s a distinct possibility that a route, especially a long one, that uses both highways might get “pruned” (as it is said) because of that low-type road in the middle of it. But if you need to use that road to get between a freeway and a highway somewhere anyway, it should most likely be at the least mH already.
To the specific example of avoiding “tentacles”: I have long held that any road served by a freeway interchange should be at least PS, much for this reason, but also because any road that connects to a freeway is likely at least somewhat important. Because of FC, it’s likely that this will be the case almost always anyway.
To consolidate thinking from a recent NJ Forum thread and a Google Hangout discussion, I’m proposing updates to the Major Road section of the wiki. The quote below shows the current state.
New guidance and directives based on dual roadway naming and regional coordinator thoughts should make the updates as follows:
I’ve added the switch from SR-XX to NJ-XX as well as the Highway name modifiers in the last paragraph of the quote. Thoughts, suggestions or improvements?
Looks good! One thing you may have overlooked, “Spur” should be “SPUR” in the CR example.
Also, I would explain the difference between “descriptors” and “modifiers” a bit more. The (cars) and (inner) is for preferential lanes, where the one you choose doesn’t affect the exits available to you. The TRUCK and EXPRESS are for differing routes, whether entirely different or different in the exits you’re able to access.
Agreed. There should be a reference to the distinction of preferential/managed lanes vs named route variations, like SPUR, ALT, etc.
The Spur-SPUR error was something I overlooked when creating the page. I made the initial changes/corrections to the wiki -
and updated the highway naming by state page as well.
100%. Perhaps you can use the distinction of whether the descriptor is part of the road name to help explain the variance as well. Notating the correct placement of the cardinal direction letter in these instances - eg - Garden State Pkwy EXPRESS S and I-287 N (inner) - seem important.
Are we settled on the terms “descriptors” and “modifiers”? Not that I have an issue with them, just curious if there are any better or official vernacular we should consider.
Once these guidelines are written we should look at adding them to the main Road names/USA page. At least for the rules that would apply nationwide.
Agreed re: where to put the compass direction.
Not sure about “descriptors” and “modifiers” tbh, to me they sound pretty much the same. Things like ALT, EXPRESS, SPUR, etc. are often referred to as “banners”, so I’d suggest that. For the other, I dunno, “description”? I’m not sure what I’d call that.
Would the following formula be preferred to call out and define? Route type/Banner and (Vehicle Prefernce) feels clearer then my previous use of descriptor and modifier.
Vehicle preference doesn’t quite fit. “Inner” is not a vehicle type.
Sent using Tapatalk for Android 4.4.2
It’s more like {Road Name} [BANNER] [Cardinal Direction] [({Disambiguation})] where {} indicates a required value and indicates an optional/as-needed value. Also, contrary to what I initially thought, banners do actually consist of a set of specific words, according to MUTCD, and any other kind of disambiguation should follow all other name components and be enclosed in parentheses and be included only where necessary.
Thanks all. Based on feedback, here’s a revised wiki proposal update:
Thoughts on the proposed?
There’s an ongoing debate in the state GH about NJ-17 vs SR-17 for state roads, since NJ shields are basic circles/ovals anyway. Personally, I like NJ-17 because it works toward a countrywide standard and also agrees with other commonly used navigation systems, but there are a lot of counter-arguments, particularly that all numbered roads in NJ, regardless of shield types, are colloquially referred to as just routes.