codgerd wrote:As a test, the central median was shortened to 9 m, and the angles were adjusted to exactly 90 degrees, as per the voodoo sometimes recommended on the forums - and contrary to official guidance which says that 14 m and 175 to 185 degrees total angle of incoming to outgoing segment should be sufficient to prevent u-turns.

We've found that 175-185 is too wide of a range and WILL route.
The official guidance of 180 +/-5 is a bit foggy and it seems that it's more a total span of 5 degrees around 180 (180 +/-2.5). It's definitely not 180 +/-5% (+/-9 degrees) that was originally indicated.

I have not encountered any issues in the 178-182 range, but I personally do my best to get the sum to between 178.5 and 181.5 (same as I'll shoot for 174 on permitted u-turns on bowties)
Likewise, we've not encountered issues at skewed intersections where the angles might be 60/120 rather than 90/90, though it is absolutely acceptable to dogleg to 90, and it helps prevent confusion on angles that could lead to a "stay/exit" rather than a "turn"... or worst case (we had this) where segment type and name changes result in the "stay right" capturing Best Continuation, which ends up with all kinds of oddball instructions.

If I've got an oddball that is difficult to get the permissives outside of 175-185 while keeping the restricted legs at 180, rather than mess with the angles I'll just make it a clean 16m box and add AGCs for the prohibited legs, same as if the median is too wide to cleanly use a 14m box.

That's what I'd do.
I keep JAF set to 2 decimal places, not that it really matters.

I generally try to avoid the cusp of anything.
I try to avoid angles from 41 to 49 degrees, segment lengths of 15m on crossovers, 170 degrees for u-turns on bowties....

In part to be sure that there's no rounding error issues, but also because every now and then, Waze changes things.

PesachZ wrote:I wrote the official guidance, and in no iteration that I can think of was the threshold ever suggested to be ±5%, it was ±5° as soon as it was introduced.

I didn't mean to infer that this was in the Wiki... I was referring to various comments from people who had heard it from someone on Waze staff.
At the time, a few numbers were being thrown around ranging from +/- 5 degrees to +/- 5%.

I remember a number of us had done some pretty exhaustive testing with varying results.
Much of my testing was done prior to the revelation that the angles were compared to each other and not the median, so in one of my test cases, I was trying to push away from 90 and varying the length of the median, but I would go + on one side and - on the other, so I was getting a total that was close to 180 and wondering why I was unable to get a u-turn to route.

It doesn't help that it can be difficult to pin the start/end one side of the street or another on Livemap

PesachZ wrote: This data (±2.5°) was not incorporated into the guidance for two reasons;
A) it was never mentioned in the forum thread for updating that content, and
B) it was never tested and reproducible with public peer review that I or the other authors were aware of.

And I wouldn't suggest putting 2.5 into the Wiki without further testing.
Real-world experience is that 178-182 won't route, and 176 and 184 will.
It's a simple matter to avoid the angles in question and not use 175-177.9 and 182.1-185, just as we avoid angles within a couple of degrees of 45...
But documented guidance should be verified to get something more exact.

It may very well be that 177 and 183 may penalize the u-turn as well, at which point we can say that the cusp is "an angle between 176-177 and 183-184, it is best to avoid these 4 numbers"

Personally, just as I try to set median lengths to 14m- or 16m+ and avoid turn angles between 30 and 40, I try to get "H" and "Box" angles to between 179 and 181, and on Bowties I pull the permitted u-turns in to 174 or so.

codgerd wrote:It's possible that either a 9-m (or less) cross section or a total inside angle < 182.5° will do the trick. If you don't mind a tiny bit more testing, it would be great to to know if a 9-m segment with the 183° total angle also prohibits the U.

We had an 8m segment with angles outside of 176-184 route a u-turn a while back, and we were able to duplicate it on Livemap so it doesn't seem that it was traffic or other penalty related issues.

We DO have to be very careful in field observations.
We had a box that kept routing u-turns no matter what we did with the geometry.
Looking at the "big" picture, it was simply a matter that there was no programmed point to make a u-turn on one leg of that intersection. (Edit to clarify, no other way to route a u-turn at other crossings between the intersection and the end of the road a number of miles away, IOTW: No penalty would have prevented the u-turn since it was the only way to get from A to B)
IIRC, we were able to find a driveway that crossed the median that provided a legal path. It too was programmed to penalize the u-turn, and we corrected that. It may have been a combination of issues (geometry plus the median segment was PLR, I honestly don't recall).

PesachZ wrote: The information you see now in the page, and its new overhaul is directly obtained from the waze Devs. We got them talking, they told us about the ±5°. They also told us that the angles are measured based on the two segments relative to each other, and not the median, allowing the penalty in skewed intersections. This information is believed to be the most current available, and was tested by several editors, myself included, and found to accurate.
This is also believed to be the intended operation, if other behaviour is found, it is assumed to be a bug we should report to staff. Rather than try to edit around the assumed bug by making AGCs, or changing guidance to be ±2.5°, we should show staff the examples and allow them to fix it.

That all said, if this is truly the behavior, and an adjustment from total angle of 183 to 182° does fix a problem we need samples to show staff and get it fixed. So please let us know if you find anything. Things can always change around here by accident or on purpose.

They said "+/- 5" specifically, or "within 5 degrees"?
If they said "within 5 degrees" is it possible that they meant "a 5 degree span" or +/- 2.5?

PesachZ wrote:What you're sounds like prudent best practice editing, and I wouldn't discourage it as a practice. As far ±5°, I went back and forth a few times to confirm that's what they meant.

Sent from Android using Tapatalk

Edit the exact quote was …180° (give or take 5°)…

I set up a test grid

https://www.waze.com/editor/?env=usa&lo ... 668&zoom=5

The cross-street names indicate the higher number of the 18x/17x pair.
Obviously couldn't nail the angles exactly, so the numbers indicate something 18x.+ / 17x.- ... IE 182.11 and 177.89, so the 17x number is close to the desired target and likely within rounding distance.

I set the end segments to one way inward to prevent dead-end u-turn routing to create a path that allows for a right, right, u-turn, left, right.
I also broke the crossing segments so we are not beginning or ending on a segment directly connected to the 2-way.

Median is 13m
All cross streets were drawn, then junctioned to "C" st so the native angles are all 180.
A junction node was added and deleted from the median to create a geometry node without disturbing the angles on the southbound to eastbound turn... all angle adjustments are on the eastern nodes.

PesachZ wrote:Just make sure there is a 'legal' alternative for the U-turn you're trying to prevent which isn't itself penalized.
I got stung by that with my first batch of u-turn test that I created. Only to be told by staff that the u-turn wasn't penalized because every possible turn was penalized. That's how I discovered that skewed u-turns can still be penalized.

Bingo.

The test grid has cross streets set to angles from 180 to 189, so we cross beyond 185, plus there's a Bowtie style U-turn enabled below that AND a dead end stub below the bowtie....
Pretty much all options are covered, so the u-turn will be routed. Kinda like a gravel separator, at some point it will cross over.
If we can confirm that on multiple test grids, then we can go through the painful process of closing in on how close to the round number we NEED to be for documentation purposes... Whether we end up setting 2 degrees or 4 degrees as "best practice" it's good to know.

I edited my original TLDR to clarify the situation that we had issues with, having no (programmed) legal u-turn on one side.

Though normally, in a situation like that, especially where heavy traffic can exceed penalties, I would gravitate more toward AGCs.

PesachZ wrote:Just make sure there is a 'legal' alternative for the U-turn you're trying to prevent which isn't itself penalized.
I got stung by that with my first batch of u-turn test that I created. Only to be told by staff that the u-turn wasn't penalized because every possible turn was penalized. That's how I discovered that skewed u-turns can still be penalized.

Okay, test grid is set up with some disturbing results.

https://www.waze.com/editor/?env=usa&lo ... 587&zoom=5

I could not make it route a u-turn at anything other than the bowtie-style u-turn at "U St", or the first crossover at 180th, which is 180 degrees.

If I have u-turns enabled, it goes to the end. If I disable them, it crosses at the first crossing.
Fastest or shortest makes no difference (which may call into question the effect of penalties on "shortest" routing)

I understand that junctions have a penalty until they are driven, but in this case, even if we assume that 185 will route a u-turn and 184 will not (expected behavior to make the turn at 185th), the path going to the bowtie at the end adds 8 additional junctions and approximately 100 seconds.

4th attachment

qwaletee wrote:So what do you think Waze is doing? (Or put another way, I didn't analyze your pictures enough to draw a conclusion myself.)

I honestly don't know.
Everything we've been told about penalties seems to be thrown out the window, and why it violates the most basic u-turn penalty when I disable "u-turns" is also baffling.

My suspicion is that rather than merely the sum of the entry and exit angles being 180 +/- 5, there is also something going on perhaps related to the 90 degree entry, of which all of my test routes are.

I'll let this sit as-is for a week to see if anything changes, then I'll adjust the geonodes so rather than an entry of 90 with all of the adjustment on the exit angle, both angles are tweaked roughly the same amount.

IF this is the case, then we need to be careful when using doglegs to adjust permitted and prohibited u-turns on different approaches.

PesachZ wrote:The first comment I'll make is that testing to be accurate must be done with client. And following that try in the actual livemap, not any route checking scripts in the editor.
Also I can't see the angles on mobile, which of these uturns would you expect to be not penalized? Your results are consistent with all U-turns being penalized.

Client is doing the same thing.

The street name matches the larger of the two angles, rounded down.
180th is 180 degrees.
181st is 181.xx on one side and 178.xx on the other side
etc...

So I would expect to see the u-turn occur at 185th or 186th based on 180 +/- 5, or 183rd based on observations from URs.

So it's not *only* the sum of the entry + exit angle?

Back to AGC until we get a working JB.
This is really frustrating.