Test of Text-to-Speech (TTS) Abbreviations in Waze Clients

[Wajo357]

I'm waiting for:
Sp
A.T.&T.
Alt
St. Middle St

Those were added last night, so in a couple of days, they'll hit the client and I can test them out. I'm going to try out some combos of "S 1st St W" to see what I get.

Are we getting mix messages?
Wajo357 tested with Avenue S. that yield South.
Someone else tested that it worked.
Perhaps, the reason for this is that we were testing a single letter. More concern with the directional letters. Not combinations of letters like A.T.T.

Correct.

[jasonh300]

I'd have to disagree. How many street signs or exit ramps do you see that have a "" or '' in them? I understand that we're trying to get Waze to say the actual letter instead of a direction, so I would advocate more of the period.

The problem with the period is that when someone reads it on the screen and sees the period, they're going to think it's an abbreviation.

[txemt]

The problem with the period is that when someone reads it on the screen and sees the period, they're going to think it's an abbreviation.

Then the person who's looking at the period needs to be paying attention road, not if the period is after or before a letter.

As far as the other things, I'm going through the list at the very beginning of thread and finding out what works and what doesn't work. I also need to know how "AT&T Center Pkwy" is going to read because I have exit signs and a road called that, so that's a local issue.

[GizmoGuy411]

Regarding roads named as letters, I agree that surrounding the capitalized letter with single quotes will look the best as Alan said. I have yet to retest for the various test from the list for the letters, N, E, S, and W, however multiple Wazers have indicated recently that the result are now different that what is shown in the list.

Using a period after a letter may lead to confusion, as it looks like a standard cardinal direction abbreviation, as Jason said.

However using periods with multiple letters, such as A.T.T. or N.Y.C. to get the abbreviation pronounced as individual letters should be fine, if it really is working that way universally now.

One problem is that we have found in the past that many factors affect the TTS results.

The position of the abbreviation relative to other words, punctuation around it, capitalization, and the various combinations of those factors.

When list here was created, I used a space a forward slash and a space around every abbreviation, with multiple abbreviations per test segment. We expected a forward slash to produce a pause, as Waze said it would be any easy change. Since it did not happen as soon as we hoped, the TTS results were very hard to understand without any pauses. Another editor, jenncard, was helping at the time with the project, and created a test rig of her own with each abbreviation with a comma and a space. The results were much easier to understand.

Last spring I started to use her method for testing. Since that time however there has been suspicion that the comma may even cause a change in the results. Furthermore, it may be possible that ANY other words on a segment besides the abbreviation to be tested may create a different result.

If you look at the most recent entries in the list, you may notice that several test segments have created TWO TTS audio files which are actually different from each other. (On Android, one file is created with just the words in the segment name, and another file is created with the segment name prefixed with the word "at".)

A few examples:
- The abbreviation "RR" for "Rural Route", says the letters "ar ar" in one file and "Rural Route" in the other.
- The abbreviation "Cent" for "Center", say "Cent" in one file and "Center" for the other.
- Several abbreviations for "Parkway", say the letters for one file if the abbreviation is capitalized , and say "Parkway" for the other file.
- While testing "SH-123" as am abbreviation for "State Highway 123", one file said the letters and the numbers "one hundred twenty-three", where the other file said the letters and "one two three".

And in one case were I was testing the abbreviations "boro, par, ph" for Borough, Parade, and Parish, I had TTS results that said "borough par pea-aitch", and the other file said "borough parade phone".
When "ph" was tested again by itself, the results were the letters "pea-aight" for both files.

Testing for every possibility is a bit overwhelming at this point.

[orbitc]

Thanks a lot for these extensive tests GizmoGuy411.

As you may know, we've tested couple of options as well. I believe, -if that's OK to proceed- we should go ahead and change those roads with single letter like Avenue S to Avenue 'S'. It seems that's the general consensus at this point.

Also, one might argue, while we are fixing Avenue 'S', why not change it to Ave 'S'

[DaveHolzmann]

I agree with Alan. Few of us tested these with few different combination. The Best option, IMO, should be either with single quotes or double quotes.

I like single. Because they are thinner.

I'd prefer single for an additional reason: only requires one keystroke instead of two-simultaneous (as is required for the double. (At least, that's the way it is on every full sized keyboard I've ever used.)

[xteejx]

There are only so many combinations you can use before it affects other combinations. If single quotes work, just use that. Double quotes are bigger text wise.
Still waiting on Street and Saint working over here.

Sent from my GT-I9100 using Tapatalk 2

[orbitc]

Like I said, that's the general consensus at this point. More people seem to prefer single quotes as well.

In order to address the local issue here, we should start naming just those 4 letters using single quote without shortening the name.
Like this:

Avenue S will be: Ave 'S'

[CBenson]

Oddly, when I route to a destination on "'E' St NW" my phone then has a sound file "ee street en double you Washington."

OK, I can confirm that the sound file is used as the destination location if you select your destination by press and holding the location on the map. If you search for a destination, the announced destination location appears to be the search result you select. However, if you press and hold to give the destination, waze creates the destination location announcement. However, as waze gives the street name anyway this is redundant.
So if I press and hold to route to a location on F St NW, when I get there waze says: "You have reached your destination eff street en double you Washington at eff street northwest." Sometimes if waze determines the street number it seems to include the number: "You have reached your destination 601 eff street en double you Washington at eff street northwest."

[sketch]

This exit has been named "Exits 13A-B-C: US-301 / MD-3 Richmond / Crofton" to match the BGS for quite some time. I drive through it regularly. TTS says: "Exits thirteen ayybeesea...youess threeohone...emdee three Richmond...Crofton." It sounds fine to me. I've never seen or heard a complaint.

That's how it should be done (more or less — it should be "Exit" rather than "Exits", if that's what the big green sign says). Read the fifth bullet point in this section of the road naming wiki: http://www.waze.com/wiki/index.php/Road ... n-ramps.29