[Page Update] Junction Style Guide

Moderator: Unholy

Re: [Page Update] Junction Style Guide

Postby DwarfLord » Sat Feb 06, 2016 3:48 pm

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.
DwarfLord
Wiki Master
Wiki Master
 
Posts: 2452
Joined: Sat Dec 07, 2013 4:01 pm
Location: Santa Cruz Mountains, California USA
Has thanked: 1066 times
Been thanked: 1432 times

Re: [Page Update] Junction Style Guide

Postby sketch » Sat Feb 06, 2016 4:26 pm

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

You're absolutely right about car audio configuration making a difference. The time required between decision to instruct and audio playback is extended considerably when the interim must contain a handoff to a Bluetooth handsfree like that.

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. Perhaps part of the reason for this is that audio routing is typically handled by the OS, not the app itself, and sometimes other apps can sort of inadvertently force Waze to use Bluetooth even if you don't want it to. I would think that Waze could at least see where its audio was being output, but whether or not they've actually programmed to account for that is a different question.
ALL US EDITORS READ: New USA road type guidance
assistant regional coordinator • south central region • usa
waze global champ • usa country manager • new orleans
2017 chevrolet ss sedan 6mt • slipstream blue metallic
[ img ] [ img ]
sketch
Waze Global Champs
Waze Global Champs
 
Posts: 6404
Joined: Sat Aug 08, 2009 6:13 pm
Location: Nouvelle-Orléans, Louisiane, États-Unis
Has thanked: 1987 times
Been thanked: 2491 times

Re: [Page Update] Junction Style Guide

Postby DwarfLord » Sat Feb 06, 2016 10:59 pm

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.
DwarfLord
Wiki Master
Wiki Master
 
Posts: 2452
Joined: Sat Dec 07, 2013 4:01 pm
Location: Santa Cruz Mountains, California USA
Has thanked: 1066 times
Been thanked: 1432 times

Re: [Page Update] Junction Style Guide

Postby Timbones » Sun Feb 07, 2016 12:48 pm

If there is latency in the TTS instructions, then this should be fixed by Waze in the app, NOT by changing how we map the facts.

Sent from my Wileyfox Swift using Tapatalk
Timbones(6) • UK Coordinator • Forum Moderator • Global Wiki Moderator • Routing Expert
Extensions: WME Colour HighlightsWME Route TesterWME Geometries
Timbones
Coordinators
Coordinators
 
Posts: 6894
Joined: Wed Feb 09, 2011 10:33 am
Location: York, UK
Has thanked: 1015 times
Been thanked: 2881 times

Re: [Page Update] Junction Style Guide

Postby herrchin » Wed Jun 22, 2016 5:04 pm

This is in reference to the At-grade connectors page, but the Exceptions section there links to this thread. The Exceptions content has been in draft status for a long time, and since the page is nominated for the global Wazeopedia, some updates may be prudent.

As best I understand, all the AGC exceptions where the Ramp type is recommended are based on needing to name the segment with a longer name for TTS instructions, and we want the name display suppressed in the app. Buried in the Road_types/USA#Ramps section is text that supports that, but that page is currently tagged as USA, not global (and is also problematically referenced for guidance in the global Junction Style Guide).

Road_types/USA#Ramps wrote:Ramp names do not appear on the client application map, but do appear in the text for routing directions. Entrance and exit ramps often contain a lot of text which is duplicative of roads already in the area, so this text is suppressed until the user actually needs it. This is also the reason for using the ramp type for named MUTI and jughandle segments—the text is needed for effective navigation instructions but would needlessly clutter the ramp.


I propose that the Exceptions section of the AGC page include a version of that same text (so it can be global), and also new guidance to clarify when not to use the Ramp type for those intersections.

proposal wrote:Certain at-grade intersections have special layouts that may require naming the connecting segments in a manner similar to interchange ramps in order to generate effective TTS navigation instructions. In those exceptions, use of the Ramp type will properly suppress the display of the special name. If no special naming is necessary (i.e. road name inheritance will give proper instructions), then the normal road-typing rules for AGCs shall apply.


Question 1: Is the concern about a 3-road-type path (such as MH->Ramp->PS) still a current one?

Question 1a: If so, would using the AGC road-typing rules (or more specifically, the Roundabout typing rules, to cover when an AGC connects up 3 or more types) in all cases, and using 5m stubs for TTS instruction segments be a better proposal?

Question 2: Is this wiki section the appropriate place to cover additional nuance that special intersections have, such as NJ's coverage of Jughandle unintentional detour prevention, or is it time to break out special intersection design examples into its own area?
USA Country Manager / UT and IA SM
[ img ][ img ][ img ][ img ][ img ][ img ]
herrchin
Country Manager
Country Manager
 
Posts: 323
Joined: Mon Jun 22, 2015 6:05 pm
Location: Lincoln, NE, USA
Has thanked: 291 times
Been thanked: 210 times

Re: [Page Update] Junction Style Guide

Postby qwaletee » Tue Jun 28, 2016 2:12 am

Agreed about unfolding the USA ref.

The three road type is still a problem as far as I know. I believe it is in the BDP code.
US Champ / Country Manager | State Manager NY, NJ, PA, CT, MA, RI, VT, ME, NH | Northeast ARC | Mentor | Responding to Map Issues
qwaletee
US Waze Champs
US Waze Champs
 
Posts: 2936
Joined: Wed Feb 13, 2013 1:42 am
Location: NYC Metro - Active throughout NE^2 (Northeast & New England)
Has thanked: 235 times
Been thanked: 1134 times

Previous

Return to Wiki Updates and Discussion

Who is online

Users browsing this forum: No registered users