[Page Update] How Waze determines turn/keep/exit maneuvers

Moderator: Unholy

Re: [Page Update] How Waze determines turn/keep/exit maneuve

Postby PesachZ » Sun Jun 22, 2014 5:43 am

PesachZ wrote:This ramp split junction was brought to my attention. It is ramp to ramp, 22 degrees left, and 44 degrees right. It is giving a "Turn right" for the right branch, and nothing for the left branch (treating it as Best Continuation). All connecting segments have different names.

I'm wondering if one of these might be the cause, I'm leaning toward the first option. These are my own theories.

A) There is discrepancy between the precise angle displayed by the Junction Angle script, and the angle the server uses to determine instructions. I believe after looking around a bit (HT:dbraughlr in WME chat) that this is a function of the script and server employing different methods determining the turn angle and therefore rounding in opposite directions. So a 44.5 degree turn in JAI script shown as 44 degrees
Code: Select all
JAI
180-(135.5 rounded)136=44
may be seen by the router as 45 degrees.
Code: Select all
SERVER
starting from 0+(44.5 rounded)45=45
To support this theory there are junctions in which all the angles sum to 359 degrees or 361 degrees, showing that the rounding is not precise.


B) The threshold for keep vs. turn has become more narrow, and is now less than 45.5 degrees.

If anyone can take a look, and/or has any information on this, please chime in.

EDIT: Added theory to A)
Adjusted geometry of ramp to be a smaller angle but still displaying as 45 degrees so theoretically if it was 44.5 deg, it should now be less, and work properly. Will test after a tile update to prove theory A. 5/25/14 23:38 UTC


--------------------------------------------------------------

After adjusting the geometry if the right branch to be ever so slightly smaller, closer to 43° while JAI still displaying 44°, the fork now gives keep left/right instructions for both sides. This lend credence to the theory that there are different calculations being employed by the JAI script and by the server. Therefore an angle of exactly 44.5° will be treated by the server as 45°, and displayed by JAI as 44° (as described in my original post on this subject).

The easy solution here is when editing a junction avoid saying a turn angle of 44°, and to be safe stick to either 0-43°, or 45-90° in either direction.

Sent using Tapatalk for Android 4.4.2

-------------------------------------------------------------

I did some more testing with a tweaked version of the JAI script showing 2 decimal places. The angle described above giving a KEEP instruction ["closer to 43° while JAI still displaying 44°"] was actually 43.68°.

I then tested at exactly 44.00° and got a TURN instruction without editing anything else in the junction.

I am now testing at 43.96° to determine if the actual exact threshold used by the server is not 44.5° as previously believed but 44°.

I will hopefully have an answer to this after the next time update. It can then be confirmed by testing on other junctions. I am now leading towards theory B and don't believe this to be a rounding issue. I believe the issue is caused by the fact that any angle between 43.5 and 44.5 well display in JAI as 44, making that angle carry two possible instructions. If this is true we should update the geometry wiki to avoid using 44° angles, as it would be impossible to know what instruction they will provide without a tweaked JAI script.

Sent using Tapatalk for Android 4.4.2

-------------------------------------------------------------

After more testing this junction is giving a turn right at 43.69°
and this one is stay right at 43.59°.

We can safely say the threshold is as far as I can tell somewhere between 43.59° and 43.69°. At these angles its hard to narrow further, but the average editor will not have access to decimal points anyway.

I think we can edit the wiki to say
  • 45° or higher = turn
  • 43° and lower = stay
  • 44° is a gray area which usually will be turn, but can be stay in very few cases (the first 1/5th°).

Sent using Tapatalk for Android 4.4.2


Based on these previous results, and confirmation from another set of segments in the last tile update, I can now confirm: The threshold between keep and turn instructions is between 43.68°-43.69°, as displayed by the Junction Angle Information script (by: Milkboy).
an angle of 43.68° produces a keep instruction, and an angle of 43.69° produces a turn instruction.
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: 2374 times

Re: [Page Update] How Waze determines turn/keep/exit maneuve

Postby PesachZ » Sun Jun 22, 2014 6:26 pm

I have moved the pages and subpages to the main space wiki.
https://wiki.waze.com/wiki/How_Waze_determines_turn_/_keep_/_exit_maneuvers
https://wiki.waze.com/wiki/How_Waze_determines_turn_/_keep_/_exit_maneuvers/Stay_threshold
https://wiki.waze.com/wiki/How_Waze_determines_turn_/_keep_/_exit_maneuvers/Turn_threshold

https://wiki.waze.com/wiki/Interactive_junction_instruction_algorithm

If any of the links need to be fixed, or there are double redirects, please let me know. I think I got them all, but I am new to this thing.

Thank you everyone for all the help.

I will remove the construction box once Waze staff comment on the accuracy of the info.
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: 2374 times

Re: [Page Update] How Waze determines turn/keep/exit maneuve

Postby PesachZ » Thu Jun 26, 2014 3:01 pm

It appears the turn threshold angle has increased with the latest update. More tests will be needed to confirm.

Sent using Tapatalk for Android 4.4.2
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: 2374 times

Re: [Page Update] How Waze determines turn/keep/exit maneuve

Postby PesachZ » Thu Jun 26, 2014 11:02 pm

qwaletee wrote:
PesachZ wrote:It appears the turn threshold angle has increased with the latest update. More tests will be needed to confirm.

Sent using Tapatalk for Android 4.4.2


If it turns out to have been changed, we'll have to also test older clients to see whether it affects them too. if it does, update to new standard, If it does not, we'll have to give information to cover both.

Good point, there doesn't seem to be a shortage of people who roles back or didn't update. we should be able to find a tester.

Sent using Tapatalk for Android 4.4.2
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: 2374 times

Re: [Page Update] How Waze determines turn/keep/exit maneuve

Postby PesachZ » Sun Jul 27, 2014 4:22 pm

I added an image to help describe the turn angle visually
[ img ]

I also replaced "abnormal roundabout" with "non-normal roundabout" to match the roundabout page.
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: 2374 times

Re: [Page Update] How Waze determines turn/keep/exit maneuve

Postby PesachZ » Tue Aug 05, 2014 3:24 pm

I added a note to the page that no-name agreements are treated as a unique name, and not as the name they inherit.
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: 2374 times

Re: [Page Update] How Waze determines turn/keep/exit maneuve

Postby PesachZ » Tue Aug 05, 2014 5:40 pm

sketch wrote:
PesachZ wrote:I added a note to the page that no-name agreements are treated as a unique name, and not as the name they inherit.

Excellent. That is very good information.

:D thank you for clarifying it to me.
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: 2374 times

Re: [Page Update] How Waze determines turn/keep/exit maneuve

Postby PesachZ » Thu Sep 11, 2014 4:26 pm

It was recently brought to my attention (HT: ottonomy) that there seemed to have been a recent change in the Waze routing Best Continuation algorithm to now also consider alt names. I ran a group of tests and the results we have so far, is if there is no primary name match at a fork in the road, the next check is for a alternate name match, followed by a segment type match if the alt names don't match.

The test results ↓:

[ img ]
I got results on testing alternate name effect on best continuation. √=instruction, X=Best Continuation, Green=No match, Orange=Primary match, yellow=alt match, purple= the alt of one segment match primary of the other segment.
If primary names match it's BC, if alt names match it's BC (NEW), if a primary matches one segment and an alt matches another - the primary match is BC, if a primary cross matches an alt it is not BC. So the BC algorithm should be modified to show order of preference; Primary name match, Alt name match, type match.


I propose to add this step (do alt names match?) Into the best continuation algorithm.

Any comments?

Sent using Tapatalk for Android 4.4.2
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: 2374 times

Re: [Page Update] How Waze determines turn/keep/exit maneuve

Postby PesachZ » Sun Sep 14, 2014 9:56 am

I've done some more tests and have found that the order of the alt names does not affect matching.

It is possible to have a alt <=> primary name cross match, but it requires there at least be one alt name on the s-in (even if it is no the matching alt). If s-in doesn't have an alt name, then even if the s-out alt matches s-in, it isn't used. It is yet to be tested what the results would be if only s-in has an alt name which matches the primary name of s-out.

City names don't seem to affect this algorithm as was demonstrated by an intersection in Miami Fl.

The Miami junction proved that an alt name match (even with a city mismatch in those alts), and a segment type match together on one side, trumped the primary name match on the other side.
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: 2374 times

Re: [Page Update] How Waze determines turn/keep/exit maneuve

Postby PesachZ » Sun Sep 14, 2014 11:18 am

CBenson wrote:
PesachZ wrote:City names don't seem to affect this algorithm as was demonstrated by an intersection in Miami Fl.

Thanks for reverse engineering this. Does this mean that the primary names must have the same city for the alt matches to work? Or does this mean that city matching is no longer a requirement?

As far as we (Myself, ottonomy, sketch, ...) can tell, City names were never part of this algorithm, and that hasn't changed. (If they were part of this algorithm before, I am not aware of it, please enlighten me, so I can use it for further testing.)
For example:
s-in is primary="Southern Fwy, Chicago"
s-out is primary="Southern Fwy, Other City"
s-2 is primary="to Highland Pk, Chicago"
s-out would still be the BC

What we found yesterday to prove this was:
s-in is primary="SW 3rd Ave, Miami", alt="SR-972, No city", type=mH
s-out is primary="SW 22nd St, Miami", alt="SR-972, Miami", type=mH
s-2 is primary="SW 3rd Ave, Miami", type=PS
s-2 used to be the BC, but since this change s-out is now BC even though the cities on the alts don't match.
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: 2374 times

PreviousNext

Return to Wiki Updates and Discussion

Who is online

Users browsing this forum: No registered users