[Page Updates Proposal] U-turns

I have a few proposals related to U-turns. I will create a proposal page for all my examples, but before I started it, I wanted to get any other inputs. Feedback here will only be used in my proposal page, so you are not committing to a final approval either way.

1. Multiple locations with details - reduce to one

We currently have u-turns covered in various degrees in a couple of places.

Wiki guidance suggests that we minimize any large repeated content when possible to prevent sync error and maintenance headaches. In cases that cannot be avoided, templates are used to at least eliminate the sync and update issues.

The current Junction Style Guide/Intersections#Avoiding_U-turns_in_box_and_partial_box_intersections is including the entire template of Routing_penalties/Controlling_U-turn_penalties excluding the Additional Examples at the bottom of the page.

Typical Wikipedia style for a section this big would suggest we keep the large subpage on Controlling U-turn penalties as is, and then on the JSG/Intersection page we reduce that section to a small summary of the issue with a link to the more detailed page.

The advantage is that any reader of the JSG page will clearly see this is a summary with a link to the details page where we cover…the details. This is the path we have been trying to head down on some of our VERY large pages (like JSG/Intersections) that are overwhelming in size and hard to navigate.

2. New summary table for U-turn prevention and enabling

I built this table to be placed at the beginning of the detailed page to help clarify the items that must be set to achieve one or the other outcome.
https://wazeopedia.waze.com/wiki/USA/User:Kentsmith9/u-turn
ScreenShotTable.PNG

The table would have wiki links to the specific section covering each of the three categories. It could be used in both the detailed page and the JSG/Intersections page since it is a good summary of what is needed. If you are already familiar with the details, this reminder of the conditions would be all that is necessary for a summary section.

3. Reformat the sub-sections of the u-turn details page

In the Controlling u-turn penalties detail page we have:

  • Preventing median U-turns
  • Allowing median U-turns
  • Checking for parallel incoming and outgoing segments
  • Straight median segments
  • Curved median segments* Additional examples

I propose we change it to:

  • Controlling medial U-turns (include table above)
  • Preventing median U-turns
  • Allowing median U-turns
  • Segment count
  • Median length
  • In/out parallelism (previously “Checking for parallel incoming and outgoing segments”)
  • Straight median segments
  • Curved median segments
  • Additional examples

I really like the table idea. It looks great and is a very quick reference tool to remind an editor of the requirements.
Is the table a template that can be used on multiple pages? I am just thinking that it may be something we may want to consider on our regions WoP page as a quick reference guide. (Just spit balling ideas)

Nice and clean!

Sent from my iPhone using Tapatalk

I guess I would have to see this to get a better feel, but quick glance at your thought looks like it would be good.

Absolutely. Even if it wasn’t a template, that is exactly the type of thing that should be in a template to permit it being used in other places. The table’s contents will be hyperlinked to each explanation of the rows, which makes it even better for independent use because questions are answered by the links.

Agreed. I will propose a user page first with that layout in case in reality it doesn’t flow as expected.

I would suggest “Must be less than 175° or greater than 185°” in that last part. “Outside” is a bit of a head-scratcher at first.

Good point. Outside fit nicely in the formatting. :slight_smile:

Fixed.

Any thoughts from on using the degree symbol (°) vs. spelling it out (degrees) in the Wiki?

Not really from this peanut gallery.

I am good with either myself.

Looks good! I would just use the degree symbol, because that’s what it’s for and everyone knows what it means

Sent from my LG-H811 using Tapatalk

The distance of 14 meters was because of the rounding from and to metric would sometimes display the wrong distance for what the algorithm used to determine whether to permit a u-turn. Since there are now different (more accurate) ways to display the distance of a segment SM an emerging specify which one to use and make it simpler with just 15?
Maybe have a statement if don’t use the distance that is accurate then need 14/16?

There is no guarantee that 100% of all editors will use a script to tell you the exact value, so this is the only way to guarantee the outcome is as desired.

Absolutely not. An editor that isn’t running that script might see “15 m” and think “it will be fine as long as it is still 15 m after whatever edit I’m going to do”. And one should not have to use the script to (1) set it up or (2) verify it, either. There is literally no reason not to use 14 and 16 m.

What if everyone had to use metric for measuring for u-turns?

Why? There is no point that I can see to get 1 meter closer to the threshold. Also, metric measurements are not standard for the US, so there is no reason to force US editors to use it.

And again, switching can cause more issues than is worth it. I have had many speed limits entered while the editor’s setting was in metric by mistake which ended up showing as 120 mph in the app.

Why force them to possibly mess other things up when there is a table that is pretty self explanatory for both.