[Script] WME Junction Angle Info

[PesachZ]

@milkboy

1.8.3 being published on AMO and Chrome store (should autoupdate for Greasemonkey/Tampermonkey users)… Extension in Chrome store will probably be available soon, while the Firefox addon will be enabled once reviewed =)

Added a note-to-self-or-anyone-else-interested about the U-turns, and amended directionality issue with bidirectional support.

Re: your U-turn note. The rules are:
Parallel one way roads
within <=15m,
which are at the tip 180° ±5° relative to each other.

Sent using Tapatalk for Android 4.4.2

[Olestas]

Why <=15m? U-turns only work if over or equal to 16m. 100%.

[james890526]

Yeah, unless you use the Toolbox ruler to measure the exact length in with decimals. Numbers will be rounded up

[PesachZ]

@Olestas

Why <=15m? U-turns only work if over or equal to 16m. 100%.

@james890526

Yeah, unless you use the Toolbox ruler to measure the exact length in with decimals. Numbers will be rounded up

I meant >=15
This came direct from staff, but use 16 unless you have exact decimals as mentioned to account for rounding.

Sent using Tapatalk for Android 4.4.2

[milkboy]

@wlodek76

In this intersection we have keep left and keep right in LiveMap, but JAI shows best continuation :?
Link to this real place: https://www.waze.com/pl/editor/?env=row&lon=16.90936&lat=52.40810&layers=1412&zoom=10&segments=104888227

One route shows “gray” as in not applicable for routing, so the only one left is then considered BC. I’ll check why the left one is not correctly detected :shock:

[milkboy]

@milkboy

One route shows “gray” as in not applicable for routing, so the only one left is then considered BC. I’ll check why the left one is not correctly detected :shock:

Meh… There is a restriction from 2015-06-01 to 2016-12-31, which is incorrectly detected as a current restriction… Need to add date range checks also =)

[Olestas]

Hmm… strange.
JAI shows that this junctions all straight drives will be Keep, but they all are BC.
https://www.waze.com/editor/?env=row&lon=26.39434&lat=56.54548&layers=3553&zoom=6&segments=167182298

[qwaletee]

Sure. Former UI designer here

If you place the instruction indicator centered on a line, then you can rotate the text to be perpendicular to the line, and stack two instructions. You would end up with three “rows” within your container:

• Line closest to junction - directions from “this” segment toward the “other segment” coming out of the junction.
• Line containing the turn angle.
• Line furthest from junction - directions from the “other segment” to this segment

Bear in mind that road geometry will complicate your placement and orientation. On a segment with no geonodes, this is no big deal. Where there are geonodes, if you can place the container between the junction and the first geonode, also a no-brainer. Where you can’t that becomes problematic. I would suggest that for such cases, draw using call-out style instead, but using the same orientation you would use if drawing directly on the segment. Draw the callout line to either a spot that is a set number of pixels away from the junction (if that falls before the first geonode), or to the geonode itself otherwise.

@milkboy

@qwaletee

But even with a single circle, you can display a short version of the reverse direction in the same circle. Might be time to start adopting little arrows (like Waze does) instead of the coloring and < and >

The whole idea about supporting bidirectional information has been lurking in my mind for a longer time. Also, that would probably mean that it should be possible to select segments in any order (like a-c-b instead of a-b-c or c-b-a as you have to do now to make sure the information is displayed for the direction you wanted). The biggest issue is probably how to output the info, so it’s perfectly clear what it means. Any UI designers/experts/wannabes around to give ideas? Or even better, make the code for it

Arrows (←↑→↓ ↔↕) could possibly be used, with a marker on each side of the road ( when instructions would differ, taking into account the left/right hand traffic)…

On a side note, I’d probably need to refactor some of the code to make it both faster and easier to implement changes…

[PesachZ]

@qwaletee

Sure. Former UI designer here

If you place the instruction indicator centered on a line, then you can rotate the text to be perpendicular to the line, and stack two instructions. You would end up with three “rows” within your container:

• Line closest to junction - directions from “this” segment toward the “other segment” coming out of the junction.
• Line containing the turn angle.
• Line furthest from junction - directions from the “other segment” to this segment

Bear in mind that road geometry will complicate your placement and orientation. On a segment with no geonodes, this is no big deal. Where there are geonodes, if you can place the container between the junction and the first geonode, also a no-brainer. Where you can’t that becomes problematic. I would suggest that for such cases, draw using call-out style instead, but using the same orientation you would use if drawing directly on the segment. Draw the callout line to either a spot that is a set number of pixels away from the junction (if that falls before the first geonode), or to the geonode itself otherwise.

@milkboy

@qwaletee

But even with a single circle, you can display a short version of the reverse direction in the same circle. Might be time to start adopting little arrows (like Waze does) instead of the coloring and < and >

The whole idea about supporting bidirectional information has been lurking in my mind for a longer time. Also, that would probably mean that it should be possible to select segments in any order (like a-c-b instead of a-b-c or c-b-a as you have to do now to make sure the information is displayed for the direction you wanted). The biggest issue is probably how to output the info, so it’s perfectly clear what it means. Any UI designers/experts/wannabes around to give ideas? Or even better, make the code for it

Arrows (←↑→↓ [LEFT RIGHT ARROW][UP DOWN ARROW]) could possibly be used, with a marker on each side of the road ( when instructions would differ, taking into account the left/right hand traffic)…

On a side note, I’d probably need to refactor some of the code to make it both faster and easier to implement changes…

If you tie to the first geonode you get stuck by micro doglegs. You’d have to ignore any geonodes within xx pixels of the junction

Sent using Tapatalk for Android 4.4.2

[taco909]

The comments on u-turns seemed a bit confusing to me… To clarify (as I understand the logic)

Crossover segment >=16m U-Turn will be routed
Crossover segment <=15m U-Turn will be routed if the sum of the approach and departure angles are outside of the range of 180 +/- 5 (have also heard 5%, but we confirmed consistent u-turn routing at 185)
Crossover segment <=15m U-Turn will be penalized (routed only under extreme penalty) if the sum of the approach and departure angles are inside of the range of 180 +/- 5 (have also heard 5%, but we confirmed consistent u-turn routing at 185)

So u-turns can “work” with any length crossover segment depending on the geometry.

Personally, even with the measuring tool and JAI, I treat the 15/16m issue the same as 45 degree angles.
I avoid angles between 40 and 50
I avoid crossover segments of 15m and use 14m or 16m.

[sketch]

That’s right taco. Conversely, U turns can never be prevented by a segment longer than 15 m. And I do the same, 14 or 16 (if I’m going for a particular result with a road that would otherwise physically dictate a smaller or larger distance).

[milkboy]

@milkboy

Meh… There is a restriction from 2015-06-01 to 2016-12-31, which is incorrectly detected as a current restriction… Need to add date range checks also =)

The date based restrictions should work correctly with latest version from GH/GF (1.8.3.1). Won’t be releasing new addons for only this change just yet, as it’s probably not the most frequently occurring issue

[milkboy]

@Olestas

Hmm… strange.
JAI shows that this junctions all straight drives will be Keep, but they all are BC.
https://www.waze.com/editor/?env=row&lon=26.39434&lat=56.54548&layers=3553&zoom=6&segments=167182298

Argh. Good catch. The BC logic should only take angles <=~45 into account. This filter got lost at some point.

EDIT: And yes, this is probably bad enough to actually warrant a new release.

EDIT2: And fixed packages uploaded.

[FZ69617]

Just published JAI version 1.8.4.1 including additional fixes to the turn instructions estimation atgorithm:
https://greasyfork.org/en/scripts/9192-wme-junction-angle-info

This version contains valuable additions contributed by wlodek76 - thanks!

[Olestas]

So which one should I use, GH or GF? I keep changing them with each update?

[FZ69617]

@Olestas

So which one should I use, GH or GF? I keep changing them with each update?

Depends on your expectations.

If you are an average user of the script, then you can use official releases of the script linked by @milkboy in the opening post there:
https://www.waze.com/forum/viewtopic.php?f=819&t=61926&start=50#p735439
The recent version published by the author is 1.8.4, which is available on both GH, and GF.

Version 1.8.4.1 (published by me) is say “developer version” and is currently available only on GF:
https://greasyfork.org/en/scripts/9192-wme-junction-angle-info
After acceptance by the author a version 1.8.4.1 may become a next offitial version (1.8.5?), but this is a sole decision of the original author, and this may even never happen.

Decide yourself on which version you want to use.

[milkboy]

I try to check any patches as soon as possible and add them to the GitHub repository (which then automatically pushes the changes to my Greasy Fork script), with best effort to attribute the changes to whoever made them. The most effortless way (for me at least) to get patches merged (and correctly attributed) is naturally to submit pull requests on GitHub, but I can’t and won’t require that

As for when and how a “official version” is released (well, release in this case only means updating the Chrome/Firefox addons), there is no process for it.

[milkboy]

PR merged Quite painless operation that could be done while queuing to pay for a 21mm socket (for tightening wheel bolts)

[milkboy]

Oh, and if we’d really want to utilize GitHub, I could set up a separate “development” branch that could then be used for testing new stuff, before merging into master. The dev branch could then be used by brave testers who don’t mind occasional problems or something. Master would then be considered “release quality”… just some thoughts.

[milkboy]

@qwaletee

If you place the instruction indicator centered on a line, then you can rotate the text to be perpendicular to the line, and stack two instructions. You would end up with three “rows” within your container:

• Line closest to junction - directions from “this” segment toward the “other segment” coming out of the junction.
• Line containing the turn angle.
• Line furthest from junction - directions from the “other segment” to this segment

Hmm… Not entirely sure I’m able to visualize this correctly in my head :?
3 lines inside the marker is probably going to make the markers biggish or the text really small…

I wonder if is possible to have multicolored markers =D As in, split in half with matching color code somehow matching the direction… Might need some deeper insight into how OpenLayers actually work though.