PesachZ wrote:Guidance should indicate simply turns with an angle above 170° can generate a uturn prompt, to be safe and ensure the prompt is given the angle should be set with 5° buffer, above 175°. These angles should be used when junctions are made using the bow-tie style, and anywhere else they are appropriate.

It would be great to get this into the documentation!

I'm fine with 170, but reluctant to embrace 175. The latter is extremely difficult to make using micro-geometry nodes and WME's default snapping distance.

Many editors who read the wiki do not use Toolbox, and thus won't adjust their snapping distance. These editors will have to make the geometry larger to accomplish 175. But, as a result, their work may end up large enough to affect drivers' display experience.

Or it may end up undone by the simplification script. I'm aware that Toolbox's simplification script has been disabled for US editors of Rank 4 and below, but I am also well aware of Rank 5 and Rank 6 editors who have used it en masse, one even during MapRaids that nominally forbid mass editing. Even with the new restriction I still regard the simplification script as a severe danger to micro-geometry nodes unless they are created very carefully.

It is important the guidance get published. I just feel we must trust editors with 170 or greater, rather than specifying 175. If the Wiki is effectively going to require editors to use a third-party script, it would be much better to require Junction Angle Info than Toolbox.

PesachZ wrote:...based on how the TTS timing is set up in the app, that the user will have a better experience if the junction node is at the gore

I have struggled for nearly a year with the question of where junction nodes should be located.

Originally I believed it best for editors to focus on the penultimate turn instruction. That is, we adjust junction nodes to ensure that the next-to-last voice instruction arrives in time for drivers to change lanes and otherwise prepare. I wrote local provisional AGC guidelines based on this penultimate-instruction focus.

Then other editors told me that Waze is notorious for never issuing any but the final instruction. One editor said his wife refuses to use Waze because the final instruction is the only one she hears and it always comes too late. From his perspective it was a non-starter to focus on the penultimate instruction since Waze so often fails to provide it.

This has not been my experience. But if it really is common that drivers only receive a final instruction and no other, junction nodes should be placed far enough ahead of the physical decision point so that the final instruction arrives in time to change lanes/whatever. For any but the simplest exit, that means advancing the junction node well before the gore.

So "how the TTS timing is set up in the app" really is the key question here. I hear conflicting driver experience and have no idea what to recommend.

sketch wrote:This is not to mention the time it takes for the voice to actually start talking and to finish the words "Exit right ...", and while that is presumably factored into the instruction distance X, sometimes phones do lag a bit with background processes (e.g., Spotify in the car) and such.

Recently I did a test with two phones in the car. The iPhone 5 was on Jane and routed through the car's factory-installed low-quality Bluetooth audio, the iPhone 6 was on Kate (UK voice) and handheld. I was the passenger and could focus on performance.

Results:

1. The Bluetooth audio system issued instructions reliably 1-3 seconds later than the handheld system. This may have been associated with the phone's need to negotiate a "hijack" of the factory audio stream. The 3-second delay was common, not an outlier.

2. Once the first phone had been removed from Bluetooth and set to direct output, the two phones generally began the voice announcements at the same time. So far so good, except they would finish at different times because Jane and Kate do not say exactly the same things or in the same manner.

Conclusions:

1. Car audio configurations can cause a 3-s delay in issuing instructions, which seems enough to lead to URs. Attempting to fix those particular URs by becoming more aggressive with junction-node placement (beyond the wiki standard), adding AGCs, etc. is probably not the best response. Unfortunately we don't know which URs might be due to this behavior.

2. Waze is said to take into account how long it will take to issue a voice instruction and to advance voice timing to compensate. The test showed no evidence that it does so, at least not with any precision. It is possible that Waze instead uses a rough guess at how long the instruction will take that does not differ from voice to voice. If so, one wonders how that affects timing of very long versus very short street names, if at all.

sketch wrote:As for 2, Waze does account for that, but I don't think in the way you're thinking. It will start speaking sooner for particularly long phrases, but it won't account for the differences in audio playback methods (Bluetooth vs. phone speaker), I don't think.

The second test occurred after we had disconnected the first phone from Bluetooth and they were both using internal speakers. The two voices (Jane and Kate) would typically start at the same time but would finish at different times.

This suggests to me that, if Waze does start speaking earlier for things that take longer to say, any advance in timing is at best approximate -- just a rough guess, rather than a precise estimate based on a priori knowledge of how long the phrase will take to speak. Which brings up the question of how good a guess it really is.

But yes, it wouldn't surprise me at all if Waze made no allowance for latency in the audio path. In fact that's what the first test seems to indicate.

In regards to the junction style guide/intersection, I see that examples are needed. I know of a few locations here in AZ that meet the examples. Do I just update here, input the update notice in another thread already started, or start a new thread [Update] Junction Style Guide/Intersection

Well, even though the /Intersections page states to PM Kent for any changes, I've gone ahead and added some screenshots of three way and four way split road intersections. I don't know if the arrows needed to be shown or not, let me know.

https://wiki.waze.com/wiki/Junction_Sty ... ersections

Noticed my split three-way image is really a four-way. lol. Looking for another image right now.

KB_Steveo wrote:Question: On the interchanges sub-page, Is this still necessary with the detour prevention mechanism?

Note: Be sure to restrict the straight through motion from the exit ramp onto the entrance ramp on the other side of the road. This will prevent the routing server from trying to route someone off the freeway just to get back on it. Even though it may be a legal direction for a vehicle, turn restrictions are only for controlling routing directions.
https://wiki.waze.com/wiki/images/2/2c/ ... _turns.png

I would also like to know because Arizona, well Maricopa County at least, allows this.

You want waze to write in code to start monitoring CPU/RAM and battery performance and use that to alter the prompts? Won't that also cause more CPU usage resulting in more battery consumption, resulting in more heat?

We've been having a discussion in the Southwest forum about U-Turns at typical box or H intersections (double left). We've submitted two intersection where U-Turns should have been prevented per the guidelines given to us by Waze, and the app continues to route U-Turns there. The feedback from Waze is the intersection is working as intended. That "one time traffic events" or situations where the legal route to turn around is too long, will result in Waze routing over the short segment, as the penalty caused by the traffic or legal route is higher than the penalty for violating the no double lefts rule.

Based on that feedback, I feel we should add a note along the lines of
"The penalty for routing a double left across these segments is low enough that in some instances Waze will route the U-Turn due to traffic and/or distance on the legal routes. If this is a common occurrence, you will need to use a different U-Turn management technique such as a bowtie intersection."

Related posts/thread:
viewtopic.php?f=566&t=78041&start=60#p935725
viewtopic.php?f=566&t=78041&start=90#p951974

So waze states there are two reasons possible for this u-turn: 1. segments under 15 meters have high penalty but if there is a heavy traffic / irregular event - waze will use u-terns under 15 meters. 2. the alternate route (without the u-turn) will be longer and will take time, waze will prefer to take the u-turn (even with the penalty on it) because it's shorter and saves time.

PesachZ has also suggested using an At-Grade Connector for U-turn management, however I don't believe that is yet considered an approved method of handling u-turns?