If you have a specific example I can try to help.Olestas wrote:Algorythm does not help in difficult situations.
Sent using Tapatalk for Android 4.4.2
If you have a specific example I can try to help.Olestas wrote:Algorythm does not help in difficult situations.
What you need is a variation of a wayfinder. Since the right branch of the fork has the same Primary name, Alt name, and Road type, and the left side has none of the above, the right side is considered the best continuation. To change this you must fool the server, we do that with wayfinders. But we'll modify the way finder to give you the continuation on the left.Olestas wrote:Hmm.. I have tried different configurations, but failed all the time.PesachZ wrote:If you have a specific example I can try to help.Olestas wrote:Algorythm does not help in difficult situations.
Sent using Tapatalk for Android 4.4.2
Needs to be:
1. Keep right, major.
https://www.waze.com/editor/?env=row&lo ... 5,79495519
2. Continue straight (best continuation)
https://www.waze.com/editor/?env=row&lo ... ,271798926
If I understood correctly he was asking for the angles to be drawn on the segments they apply to like this.milkboy wrote:Something like this?milkboy wrote:Very much doableqwaletee wrote: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.
The screenshot looks great. Can't wait to try it.milkboy wrote:I uploaded a new version (1.8.2) on GH with the latest fixes by FZ69617 included, and a new option for angle display mode (absolute, which is default and the previous behaviour, and departure). If nobody complains about critical bugs, I'll upload FF and Chrome extensions during the day tomorrow (UTC+3 time zone)
Pulling from livemap means only being able to give routing on live segments in their live state, and not reflecting any changes since the tile build. That is the true benefit of this script, its immediacy.qwaletee wrote: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.
Re: your U-turn note. The rules are:milkboy wrote: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.
Olestas wrote:Why <=15m? U-turns only work if over or equal to 16m. 100%.
I meant >=15james890526 wrote:Yeah, unless you use the Toolbox ruler to measure the exact length in with decimals. Numbers will be rounded up
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 junctionqwaletee wrote: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:
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.
- 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
milkboy wrote: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 itqwaletee 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 >
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...
I would suggest not using the ↑↓ arrows for continue (BC), and instead use waiter nothing (no instruction), or a smaller icon (•∅).qwaletee wrote:OK, a sample. I used this: https://www.waze.com/editor/?env=usa&lo ... s=82045410
Here's what JAI looks like now, and what it could look like, roughly:
In each case, the upper arrow closer to the junction indicates the instruction (left/right) when heading from the JAI markup segment toward the junction and then onto the selected segment. The arrow farther away from the junction indicates the direction to get from the selected segment onto the segment displaying JAI. Add three arrows for keep/exit, and done. Everything fits easily within the circle (which is the same size as the current JAI instructions circle
milkboy wrote:Hmm.. Not entirely sure I'm able to visualize this correctly in my headqwaletee wrote: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
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.
Re: [script] WME Junction Angle Info