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

[GizmoGuy411]

I have also noted that "Mt" and "Mt." both say "mount" but "Mt." sounds ... strange. It takes longer to say "mount" and there's a longer space after the word. "Mt" should be the standard.

Periods should be generally avoided unless necessary for differentiation ("St."; "Dr.").

I agree that we should reserve the period only for cases of ambiguity.

We do have "MT" in caps that is intended to say "Montana".

So while I think that is sufficient to differentiate it from "Mt", we can still add "Mt." to say "Mount", but only list "Mt" in our recommended abbreviation list.

Similarly, Alan also questioned my submission of "BUSN" for "Business" along with his prior submission of "BUS". I replied that we could indicate in the recommended list, that "BUS" should be used if signage says "BUS" or "BUSINESS", and only use "BUSN" when signage dictates.

[harling]

Having written my share of regexps and parsers, it occurrs to me that if we are going to use the period/full-stop '.' character to differentiate 'N' ("north") from 'N.' ("enn") or 'St' ("street") from 'St.' ("saint"), we also need to decide whether it should have to be followed by a space. For example, should it recognize 'St.Louis' (no space) as "Saint Louis"?

Unless someone can think of a good reason to allow '.' mid-word, I think the '.' should double as a delimiter (i.e., a space should not be required), if only for the sake of saving screen real estate. "N Street" would be written as either 'N.St' or 'N. St'.

[harling]

And I think the period after the single letter indicating that it should be the letter is confusing. Plenty of signs out there that use N. to mean North and S. to mean South etc.

For the sake of clarity and reliability, you are right that we should try to minimize overloading (e.g., 'N' vs. 'N.'), and try to minimize positional semantics (e.g., handling "St" differently depending on where it appears). The more "common sense" we try to build into it, the more complicated the code is to implement it, and the more likely fixing one problem will break something else.

BTW, maybe we should find out how these are handled:
So. (South)
No. (North)

Those would be good options to reduce overloading in street names, but we still need to address how to write "enn street" in a way that is readable, without breaking the existing database that uses 'N' for "north".

[harling]

Basically there needs to be positional awareness for handling things like St, Dr, N/S/E/W. Can anyone think of a name where St isn't Saint unless it's at the end of the name and therefore Street? Same thing for Dr.

'Storrow Dr E' is supposed to be "storrow drive east", not "storrow doctor east" or "storrow doctor ee". And each time someone comes up with an example that we haven't anticipated, the rules (and code) become messier and harder to maintain.

All these conditions and exceptions are easy enough for a human to follow, but to a computer, context-sensitive grammars are brittle. Trust me, I have done this for a living. Better to start now with as straightforward and literal a system as possible, or it will turn into a perpetual problem, where fixing one case will break several others.

[harling]

You can find the engine being used in the preferences file. One of our users (Xteejx) located it and tried sending commands manually but it didn't even adjust for "St" as "Street". Waze is clearly intervening in the command before it is sent to the engine!

That's how I heard it explained (by Ehud IIRC). The routing engine parses the street names into phrases, and passes them to the client along with the original names. When the time comes to announce a street, the client displays the un-parsed name, but sends the parsed name to the TTS engine. So, changing how Waze "reads" street names does not require a client update, as it's all done on the server side.

[harling]

Then there is also the case where X<>number, like "F 1/2 Rd"

Isn't that F#?

Should be, yes.

[harling]

I just discovered that "Pr." is on a few BGSs around here as an abrieviation for "Prince." The TTS says "pea are."

Another one to just spell out? Though I'm not sure what "pr" would otherwise conflict with.

Puerto Rico? Pier? Pair?

I could see having TTS pronounce 'Pr.' as "Prince" in TTS... but at only six letters, and the possible interference with highway names all over Puerto Rico , it might make more sense to just spell out "Prince" where it is needed.

[harling]

Here's a TTS issue that I noticed the other day.

We have a "Summer St" in town. TTS correctly pronounces it "summer street". Off of that street is a court, named "Summer St Ct". TTS pronounces it as "summer saint court". Wait, what?

There are a lot of roads around here for which "St" and other abbreviations need to be pronounced the same regardless of position. I hadn't noticed this before because these are generally small side-streets not used for through-traffic, but people do live on them, and I can think of at least half a dozen examples off the top of my head in my own small town alone. (Smith St Ct off of Smith St, King St Ct off of King St, etc...)

[harling]

We have a "Summer St" in town. TTS correctly pronounces it "summer street". Off of that street is a court, named "Summer St Ct". TTS pronounces it as "summer saint court". Wait, what?

We have a "State Street Dr", which is an extension of State St in a different neighborhood. But the "Street" is always spelled out in "State Street Dr". I think there are other streets in that neighborhood that are the same way.

Around here, the signs never spell out the "street", just "St". (Many of them date from the '40s or earlier and are made of cast iron with raised letters, and are not likely to be replaced any time soon.) At present, the text on the display matches the signage, which I think is the best arrangement. Personally, I think it would be better for 'St.' to be "saint" anywhere, and "St" to be "street anywhere. But if the decision comes down that these abbreviations will remain positional as well as lexical, I'll start spelling them out.

[harling]

The other thing I noticed while looking at the State List (and if I'm reading this wrong, please let me know) is that you want to add "Ct" to be "Connecticut" instead of "court" which is currently does. Being from Connecticut, we have many roads named "Something Court" and the USPS abbreviation is "Ct" for "Court" (but it's also missing from the "C" section of the list...

I'm probably preaching to the choir here, but in case it isn't obvious to someone: it makes no sense for "Ct" to say "Connecticut". The state abbreviation is CT, all caps. (Ditto for "NY" vs. "Ny", and all the other standard state abbreviations.)