U-turn editing?

Coordinator: ottonomy & ARC: tonestertm | jemay
------------------------------------------------------------

Moderators: tonestertm, ottonomy

Re: U-turn editing?

Postby PesachZ » Sun Oct 18, 2015 11:41 pm

taco909 wrote:
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.


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.

Sent from Android using Tapatalk
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2375 times

Re: U-turn editing?

Postby PesachZ » Sat Oct 24, 2015 11:30 pm

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.

Sent from Android using Tapatalk
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2375 times

Re: U-turn editing?

Postby PesachZ » Sun Oct 25, 2015 5:04 am

taco909 wrote:
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.

Every single one of these medians is being penalized, and since they are all penalized equally, it chooses the closest one, if it has no other choice. If you use Route Speeds to test (which I find to more accurately mimic actual client and livemap routing), it will always use the bow-tie U-turn regardless of settings. If you use Route Checker it blocks the bow-tie route, and therefore uses the closest median since all are equally penalized (unless you allow U-turns which then uses the bow-tie U-turn). This is all working as designed in accordance with the current wiki guidelines as far as I can see.
Since you have one way segment at either end of each street, you are preventing any around the block routes instead, forcing the uturns to be used.

The issue here is that when the algorithm checks for parallelity it is looking at the two main segments (C St), not the median at all. The extra geometry you added to the median has no effect at all unless it makes the median be longer than 15m. The only way you can use a median (or tool) segment to measure the parallelity of the roads is if the median (or tool) segment has no geometry.

As explained in the wiki, all of these median uturns have a 180 ° parralel angle. To properly test this you will have to use straight medians, and apply the geometry changes to the segments of C st to affect the parallelity of the first and last segment on the U-turn.
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2375 times

Re: U-turn editing?

Postby PesachZ » Sun Oct 25, 2015 6:06 am

taco909 wrote:
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.

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.

As I explained before you are modifying the wrong angles, you are changing the angles of the median, which are of no consequence. Let's look at 186th for example.
Currently the geometry affecting the angles of the median are on the median. This is resulting in a summed angle for the u-turn of 174 °.
Screenshot 2015-10-25 at 01.55.55.png
Streets are parallel, median is bent
(19.94 KiB) Downloaded 338 times


BUT if I measure with a straight median to determine if the two main streets are parallel to each other. I find that there is a perfect 180° between them. Remember the algorithm doesn't care at all what shape the median is, it only cares if the two streets are parallel. Since there is no bend in the two streets, they are still considered perfectly parallel to each-other, regardless of how much you bend the median. So the U-turn is still prevented.
Screenshot 2015-10-25 at 01.56.29.png
Streets are perfectly parallel shown with a straight (tool) segment
(19.47 KiB) Downloaded 341 times


If I wanted to manipulate the geometry at this intersection to allow a U-turn I would have to bend the actual street to bring it out of parallel, by adding a geometry node to C st segment itself, and adjusting it so the summed angle was outside of 180°+/- 5°.
Screenshot 2015-10-25 at 01.58.05.png
streets are NOT parallel shown with straight median
(15.14 KiB) Downloaded 344 times


----

Am I making sense? If not I can try to explain it differently.
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2375 times

Re: U-turn editing?

Postby PesachZ » Sun Oct 25, 2015 6:11 am

taco909 wrote: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.

This was clearly explained for months and has been in this thread and the wiki, it measure the begining and end segment for parallelity relative to north. It's not really a super hard concept, and has proven very reliable. Have you read the updated wiki page which I linked above, there's a section with pictures explaining exactly how it works.

We can use a straight median as a tool to measure it, but the medians' geometry doesnt affect.
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2375 times

Re: U-turn editing?

Postby PesachZ » Fri Oct 30, 2015 1:05 pm

unlimited1808 wrote:I experienced a double left u-turn this morning that appears set up correctly to prevent the double left u-turn. The intersection is signed no u-turns.

https://www.waze.com/editor/?env=usa&lo ... st=4831791

1. Composed of 3 segments, with the 2 legs in opposite travel directions. Does the A-B direction of the segment affect this? Because both are one way A->B?

2. Composed with a short median. It is currently 42.65 ft.

3. In/out parallelism is within +/- 5 degrees of parallel. In segment to median is 86 degrees. Median to out segment is 95 degrees. 86 + 95 = 181


This was a reroute this morning. I was getting some really odd routes. I don't believe this was the first segment in a route/reroute as noted in the Wiki article. https://wiki.waze.com/wiki/Junction_Sty ... ersections

Any ideas?

How many segments after the reroute was this? Was the reroute trying to get you back into your previous route and using the U-turn to do that?

Sent from Android using Tapatalk
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2375 times

Re: U-turn editing?

Postby PesachZ » Fri Oct 30, 2015 8:06 pm

taco909 wrote:Update,
Test grid is now working as expected. First u-turn routed is at 186th St with doglegs only on the departing (northbound) segment.

So I understand then that you are confirming the wiki is currently accurate as is at 180° ±5° = allowed range of 175-185°?

Great work, thanks for putting in the effort, and my apologies if my previous explanations were subpar leading to your confusion, misunderstanding, and frustration. If you think the current updated text may still lead to such confusion please try to suggest some better wording to eliminate any confusion.

Sent from Android using Tapatalk
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2375 times

Re: U-turn editing?

Postby PesachZ » Mon Nov 02, 2015 4:35 am

qwaletee wrote:Unlimited,

Waze is known to ignore the U-turn penalty when encouraging you to return to a route.

To expand on this a bit further. When you miss a turn or deviate from your route, the app will try to get you back on route as quick as possible.
This is first attempted through client-side (with offline routing, where there are no closures, or special penalties applied).
Only if the client cant find a route back to your original route in a set time frame, will it then pass the recalc to the routing server (with full penalties and closures).
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2375 times

Re: U-turn editing?

Postby PesachZ » Mon Nov 02, 2015 9:32 pm

CBenson wrote:
PesachZ wrote:This is first attempted through client-side (with offline routing, where there are no closures, or special penalties applied).

So is there a definition or list of special penalties anywhere?

Not a published one that I know of. Pretty much any penalty not built into the tiles, applied directly by the server based on some algorithm. I'm not sure a full list would not be considered proprietary.
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2375 times

Re: U-turn editing?

Postby PesachZ » Wed Nov 04, 2015 2:39 am

DwarfLord wrote:Inspired by this thread, I created a test rig similar to taco909's except with 9-m (straight, no geometry nodes!) cross-segments.

I can confirm that behavior expected for 10 to 15-m separation also appears to apply at 9-m separation. That is, Waze routed over a 9-m cross-segment U with inside angles adding up to 205°, but bypassed a 9-m cross-segment U with inside angles adding to 180° in favor of continuing to a compliant U further on.

To me this says that the old 9-m thinking from many months ago was a red herring. Or maybe it wasn't, but the routing behavior has changed since then. In any event the 10-m separation threshold once discussed here appears to have no meaning for present U-turn routing.

I never believed there was a 9-10m threshold, and it was never proven empirically to my knowledge.
Thank you for taking the time, and effort to finally put it to rest, once-and-for-all.
PesachZ
Wiki Master
Wiki Master
 
Posts: 4512
Joined: Mon Jul 01, 2013 12:51 am
Location: NY, USA (also NJ sometimes) {GC}
Has thanked: 1998 times
Been thanked: 2375 times

PreviousNext

Return to US Southwest

Who is online

Users browsing this forum: No registered users