MGODLEW wrote:This might be something helpful for reference. viewtopic.php?f=276&t=89548

We could also start a bit simpler, since the "keep/turn/exit" logic seems to be a quite complex based on inputs, outputs, etc

Perhaps start with 2 or 3 colors: purple for one range, green for another range, and red for angles to avoid (45 +/- 1*, etc). colors and ranges tbd

jondrush wrote:Please read posts later in this thread for work-arounds until the author updates it or it gets adopted by others.
(per GizmoGuy411)

Can someone summarize the steps needed to work around this problem for GreaseMonkey, TamperMonkey, and/or native Chrome?

SuperDave1426 wrote:This was working for me yesterday (or the day before), and today it's not. It actually disappeared from my Tampermonkey listing. userscripts.org only shows the old version and not the new one that someone (I forget the username now) provided as a fix. I tried copy-and-pasting from the version on the Wiki page listing extensions, but that's not working, either.

Anyone have any ideas what's going on regarding this extension?

Mine usually works, and then sometimes just mysteriously stops. Possibly a load-order issue.

tkr85 wrote:Try AlanOfTheBerg 1.5.7.3 version. If still problems try one of this (CRX for Chrome):
http://pyrczak.pl/j-A_160864.user.js (Tampermonkey/Greasemoneky) -- strongly prefered !!!
http://pyrczak.pl/j-A.crx (Save on disk, then drag&drop to Chrome/Chromium Extensions Tab)
If there are still problems, please specify witch browser you using, and do you use greasemonkey/tempermonkey.

Actually, the first fix should be to look at the layers choices and make sure "Junction Angles" is ticked!

Why not just use TM? I prefer TM to Chrome Extension anyway, much easier to enable/disable/upgrade.

Hmm, I posted this before, but it seems to have disappeared.

There are two types of angle displays in JAI, each using a different formula.

1a) When a junction is selected, it uses small orange circles to display angles of all adjacent segments in the junction. The calculation uses normative angles, calculated counterclockwise. All the angles together will add up to 360 degrees (barring aggregated rounding).

1b) When a single segment is selected, it is treated the same as 1a above, except that junctions at each of its ends (A and B) will display the set of adjacent segment angles. The formula is the same as 1a, and the totals will be 720 altogether (260 at each end) in the orange circles.

1c) When two or more segments are connected, then for the most part, the same rules as for 1b apply, but more junctions are active and therefore more junctions have angle information displayed. Each "selected junction" will have all adjacent segment angles displayed using teh same formula. However, there is an exception:

2) Where there are multiple segments selected per 1c above, each "active junction" is checked to see how many of its segments are selected. For any junction with exactly two segments selected, the display and calculations are modified, to focus on the single turn pair designated by the selected segments, and using a different angle calculation. In this case, the normal orange circle display is bypassed. Instead, it displays a somewhat larger circle containing the TURN ANGLE between the two segments, along with formatting to indicate turn type (different colors, and less/greater signs). The turn angle calculation is different than the orange circle calculation. It is 180 minus the value the orange circle would have displayed. This is sometimes called the departure angle, supplementary angle, or angle of deflection.

We rarely use the regular angles (with one exception). We almost always use the departure angle, because it is more intuitive for us, matches common driving directions, matches Waze's definitions to us, and is used in PesachZ's article on how prompts work.

Here are three requests:

Request #1: Can we have the 1a/1b/1c orange circles display the angle of departure in addition to or instead of the standard angle? I often find myself selecting multiple segments just to be able to get this number without having to subtract from 180 in my head.

Request #2: When a single segment is selected, instead of displaying the standard angles between each pair of adjacent segments, can we have a circle placed on each one of the connected segments, and have it display the angle from/to the selected segment, along with an indication of the instruction from/to it?

These two together would save an enormous amount of manual selection/deselection and manual calculations when dealing with complex junctions.

*The one exception where we use real angles instead of turn angles is when measuring for U-turn prevention (parallel roads, single segment <15m connecting them).

Request #3: In this situation, if you could detect it, a third type of display would be ideal - one that actually showed the number of degrees off parallel of the two roads.

Thanks for a great tool and for considering these requests.

This is good.

For your concern that the instruction depends on which direction you are going, my intent was to include both. you can only color for one unless you use two circles. 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 >, but f you are pressed for time, the following might work:

| ## = continue
{ ## = keep left
## } = keep right
< ## = turn left
## > = turn right
## % = Exit right (for right-drive)

If you want to get fancy, you can use Livemap integration to get the instructions, same as Route Checker and Route Speeds. This would take the (changeable) algorithm out of your code, future-proofing it against instruction algorithm changes, but not against API changes. Note that Livemap does not support Exit (it would always come in as KEEP), and this would add a slew of network transactions in place of a local calculation.

Good point

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

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

Already covered this in the design using callouts.

PesachZ wrote: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