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

bgodette wrote:

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

Isn't that F#?

Should be, yes.

AlanOfTheBerg wrote:

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

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...)

jasonh300 wrote:

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

AndyPoms wrote: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.)

Upon arrival, TTS announces, "arriving at [name], at [address]", where [name] is the name of the favorite and [address] is the street address. For example, if my "Home" favorite is set to 23 Main St, Boston MA, it will announce, "arriving at home, at twenty-three main street." So far, so good.

For destinations that are not named favorites, [name] is the street address followed by the city. So if 23 Main St, Boston MA is not a favorite and I just navigate to it by address or via a History entry, it announces, "arriving at twenty-three main saint boston, at twenty-three main street". Oops!

I said over and over, and others said over and over, that the TTS rendering of abbreviations should not be positional. This is why.

AlanOfTheBerg wrote:I think it would still be worth it to verify things like 41st St, 141st St, and other combinations that combine "rd" and "Rd" like 33rd Rd, 63rd Rd, etc. I would figure if one or two pass, others will too.

I'm willing to bet that "33rd Rd" and "33 rd Rd" will be pronounced differently.

Finally, no post of mine to this thread would be complete without an appeal, yet again, to make all TTS pattern-matching non-positional. When navigating by address to (for example) 52 Main St in Boston, upon arrival, TTS says "Arriving at fifty-two main saint boston, at fifty-two main street." Note that the same "St" that is pronounced as "street" when it is the last word in the text, is pronounced "saint" when another word is appended to the string.

AndyPoms wrote:

AlanOfTheBerg wrote:I don't think we should have Waze relying on positional pronunciation. It's just bound to fail. If we make it a standard that "St" is "street" and "St." is "saint" then we know exactly how it will be pronounced regardless of where it is in the street name.

+1 for ease of use...

Been recommending that all along.

GizmoGuy411 wrote:This sounds like another one of those positional issues. I think I recall jasonh300 saying something before about a similar situation.

I'm not even sure how show in the list that "Br" is sometimes "Bridge" and sometimes "Branch" for the very same road segment, depending on how Samatha feels at the moment. I'll have to think on it.

Whether in the middle or the end of the ramp name, "Tobin Br" (as it appears on the signs) went from "Tobin Bridge" to "Tobin Branch" within the past year. Never mind that it also pronounces it "Tobbin" rather than "Toe-bin"... :-p