PZ,
Look at the discussion page setup.
So, if that’s actually the “desried outcome,” then yes, it is supported. (And if you break it, you can actually fix it without deleting the page, just reload the content form another page!)
This is deciding m referencing the optional (selectable) content, not the generic common content standard to all states (hard coded)
Sent using Tapatalk for Android 4.4.2
I made a bad assumption. When I read that blanking the “unique content” article would remove the optional material, I misunderstood that to mean “all the boilerplate for the section, which is optional as you can remove it using this very method.” WHat it actually meant was that the default boilerplate includes some required (fixed, unremovable content) and may also include some optional (removable) content. You can only remove the optional content where it exists. I have opened discussion in the wiki thread for the templates, to discuss the specific cam text mismatch we have now, and the larger issue of the scope of the boilerplate.
FYI, this is the setup of the templates per Kent-
Just something to consider if/when proposing new templates.
I just don’t understand why we even bothered with the template for the state wiki if we’re just going to hack up any part any one person decides is philosophically wrong.
Last I heard, we’re trying to move toward a national standard with any subject possible. Wasn’t that the purpose of making a template-based state page? Sure there will be things that states do differently that we’ll have to explain in the state wikis, but we want to minimize that as much as we possibly can.
All that said, even though it doesn’t bother me and I might even think it useful as background information, maybe we can adjust the template for the camera to omit any boilerplate text that doesn’t apply for any given state. For example, based on just setting the speed camera flags and red light camera flags and breaking out the boilerplate text into 3 groups, representing speed-camera-specific text, red-light-camera-specific text, and text that applies to either/both, we could omit the speed camera sections of the boilerplate text in states where the speed camera flag is set to prohibited or illegal, omit the red light camera boilerplate text where the red light camera flag is set to prohibited or illegal, or omit all the boilerplate text if both flags are set to prohibited or illegal.
I somewhat think the camera descriptions should be in there even if you don’t have that type camera in the state, just so new editors know what a particular camera is, OR more emphasized textleading to the camera descriptions page.
I put a more detailed thing on the related wiki-change topic, but what if we could start the state page section with a 1-sentence link to all the general text in the USA cameras page and then just proceed with custom NJ-specific text?
I am good with that - Taking into consideration PesachZ’s previous comment
I concur that editors should have the knowledge of all camera types, as anyone serious about editing eventually will cross over State lines. So I would take the second approach here and emphasize that “editors familiarize themselves with various camera types {{LINK to main USA page}}” .
In short, Main USA page: KISS. NJ specific guidance: Elaborate as appropriate.
Yes. There are thousands. If not for FC there would be hundred of thousands. Here a few:
Street name & POI name LINK 
Street name & CDP name LINK 1LINK 2
Streetname x2 LINK 
Thank you Phantom for bringing the long overdue Jughandle discussion to the table.
First thing first, based on the above conversation and proposed guidance, combined with my own logic/reserach, I have updated the NJ wiki page with a DRAFT for Jughandle guidance (also copied below). The wording is rough and images are needed. Comments are welcome.
How I got here:
Using Phantoms original proposal, together with qwaletee’s additions, PesachZ’s questions and corner cases, this solution seems the most simple, consistent and easy to follow for new editors (especially once we get some pictures up).
One comment, as mentioned in the AGC thread; if the agc connects to more that just 2 segments, which most jughandles do, you don’t want the type of the simple AGC to be “lowest connected segment”. The AGC type needs to be “the same as the second highest type which can be routed to or from the AGC”.
Sent using Tapatalk for Android 4.4.2
Sounds good to me. Thanks for the initial write-up! 
The only thing I noticed is that, as written now, type A and C jughandles can still be prone to tentacles at intersections with S, PR, or PLR if there is a BGS present. What if, in those cases, we were to fill out the remainder of the loop route back to the highway, where the ramp type would not be appropriate for whatever reason, with Primary Streets that don’t disappear at wide zoom levels? In other words, for Type A and C jughandles where the intersecting road is S, PR, or PLR, the segment between where the jughandle ends and the actual highway itself would be upgraded to Primary Street.
As an example th jug handle here (bottom green) needs to me MH even though the lowest connected segment is mH (assuming the turn from jug handle to the mH is allowed).
Sent using Tapatalk for Android 4.4.2
Good point and Nice drawing! However, after viewing countless jughandle examples, I dont believe the one you created exists in NJ. In practice, the intersection would have one of the 3 Types to enable left/U-turns (at any/each possible left). The other “ramp” would be an exit to local streets and doesnt fall under “jughandle guidance”. Hypothetically, were it to exist - and to cover edge cases - the top loop would be made MH at the short segment connecting the mH to the MH on grounds of continuity.
The same logic would apply to your aforementioned point
Here is an example: https://www.waze.com/editor/?env=usa&lon=-74.13068&lat=40.07079&layers=2021&zoom=5&segments=32270119,80571605,80571606.
The one scenario I am struggling with is when there is BGS at an exit (signage not to just the local connecting rd), but it doesn’t follow the jughandle guidelines per the NJDOT. Most of the scenarios I came across would follow the Continuity guidance or no “Ramp (waze)” is necessary, but there may be some exceptions. I will post findings as I come across them.
This is a classic example of an exit ramp, which may very easily get confused with a jughangle, but as mentioned above, is not. https://www.waze.com/editor/?env=usa&lon=-74.17520&lat=39.96026&layers=2021&zoom=5&segments=32206891 .
Nice drawing! (Except I don’t think freeways have jughandles…) 
I’ll illustrate my points from before better later today when I have better tools available (unless someone beats me to it…)
I didnt touch upon the “tentacles” or "“ramps to nowhere” as they personally dont bother me. (I actually like the majestic disappearing act as I accelerate 
) I believe it was qwaletee who stated earlier in this thread, that there are differing opinions here. My only concern is drivers getting the correct instruction while obscuring long oblong names and as to my understanding that is why jughandles were initially made to be ramps. I may be wrong here.
In response to your point, this would most likely follow continuity guidance in most cases. (ie. Fredo-Ps scenario and here: https://www.waze.com/editor/?env=usa&lon=-74.05643&lat=40.29066&layers=2021&zoom=5&segments=63623160.) In the % of oddball scenarios (like some I posted above :? ), If possible make the ramp directly touch back to the mH or MH. Otherwise, I would say the importance of navigation/TTS correct instructions, would have to trump the “tentacles”. Further, whether a driver has Waze set to zoom out based on distance or speed, neither would be an issue here as s/he is slowing down/approaching their turn at the NJJI. Is it annoying for those panning the map? Maybe. But not for the driver en route. Additionally, This only applies to Street segments. One thing for sure, making a PLR/PR a PS (in a handful of cases) and thereby bypassing the penalty and/or guiding drivers through possibly illegal turns, for the sake of map appearance is appropriate procedure and I cant see myself ever supporting it.
Does this seem reasonable?
Based on yours and PZ’s comments, I believe a sentence & link to #continuity on the page is appropriate.
Disregard the top ramp, I wasn’t talking about it. The jug handle connects to three roads, Fwy, MH, and mH. (If it wasn’t a freeway the same could apply for MH, mH, and PS our even street) the point is if there are two different type options at the end of the jug handle we don’t want to set the jug handle for the lowest connected type, as that becomes a continuity problem.
Sent using Tapatalk for Android 4.4.2
Gotchu. If thats the case, I think we may have to update the AGC page to accommodate this rule.
Since we want as much state specific guidance here as possible, I modified the guidance to read
“Type: Lowest connecting routable segment” . Key word being “routable”. If I understood your earlier comment, the wording is simpler with the same desired effect.
Re the drawing, Thanks for clarifying. Looks like you are referring to either a Type A (forward) or Type B (U-Turn) j-handle. I altered it slightly to reflect the discussion:
On the bottom ramp (type B) , the maneuver from jug to the mH is illegal. The updated guidance now reflects that.
I added a ramp on the top left which would be Type A and used for either right or left turns at the end of it. That is more common and yes for continuity you are correct the small section between the jug and the Blue rd (not Fwy) will be matching whatever is the lowest segment it connects to assuming there is no continuity to consider.
I also added this sentence regarding Continuity as mentioned above.
“Always refer to FC #Continuity when configuring Jughandles.”
(Just need to add the continuity guidance link)
Let’s assume for whatever reason the right turn in my image from the jug handle to the mH is legal, or better yet conjure up a new example where the jug handle is connected to three different routable type segments. Let’s say the new ramp you drew with the right and left turn going south connected to a MH going east, and a mH going west.
The point is in those cases the Jug handle itself would have to be a ramp, or an MH.
When more than 2 types are involved, for continuity, we want the jug handle type to match the second highest routable type.
See the end of this thread on AGCs for more details.
Sent using Tapatalk for Android 4.4.2
Ok, so what I meant here is that when we have jughandles along highways at intersections where the intersecting road type is Street or less, and there is a GS present at the jughandle calling for announcement of more than just the directly-connected street, there is a potential for creating the “tentacle” effect when we use the ramp type for the jughandle itself, but do not complete a loop at least back to the highway with a non-disappearing road type.
The state defines 3 types of jughandles:
- TYPE A (Forward): All turning traffic (Right, Left, U) exits the highway to the right ahead of the actual intersection
- TYPE B (Dedicated Loop): Used at dedicated U-turns or T-intersections where there is no road to the right at the intersection. The ramp part of a Type B jughandle always loops completely back to the highway intersection.
- TYPE C (Reverse): U- and Left-turning traffic exit the highway to the right after the actual intersection in a cloverleaf style loop that merges into the intersecting road, while right-turning traffic typically either just turns at the actual intersection or there is a separate AGC provided for such a turn
With Type B jughandles, this point is a non-issue, since they, by their own definition, always loop completely back to the highway. As a result, when we set them as Ramp type, they will never cause the “tentacle effect”.
With both Type A and Type C jughandles, we can avoid the “tentacle effect” and accommodate suppressing from the map any necessary GS announcements by upgrading the segments of the cross road between the jughandle and the highway, which would otherwise be Street (or lower), to Primary Street, which does not disappear with Auto Zoom at higher speeds.
I don’t see any reason this would mess with continuity, since the only connections that can ultimately be made are either to the Street the upgraded segments would otherwise be anyway, or a U-Turn on the highway. Further, wouldn’t continuity concerns for U-Turns be trivial since Waze would only consider a U-Turn at the very beginning or very end of your trip? But even if continuity was a concern, then the upgraded segments would be the same type as the highway to maintain that.