R4CLucky14 wrote:With all this conflicts, why are we doing this? Wouldn't it be better to simply ask Waze to implement a TTS field, so we can actually follow the goal of making it simple to the user: matching the BGS?
Yes we have asked for an exception field, and Waze has said here in the forums that a solution is coming. (can't find the post at the moment). It may also come along with the ability to test the results immediately.
However the issues with TTS abbreviations, and TTS for full words are not exactly the same.
There are multiple layers to how the TTS engine works. Waze uses a product from Nuance that is sold customized for mobile use. Waze also has the ability to further customize what the TTS can say.
When they provide us with an exception field, was can over-ride the delivered TTS and have it say what we want for all the special cases we encounter, such as alternate local pronunciations, non English language words, and other similar infrequent cases.
Abbreviations however are used very frequently, and need to be available without always needing to use an exception field.
The abbreviation list we are building here is intended to test what Waze currently recognizes and to test future possibilities. Everything that we test is NOT necessarily what we would like Waze to actually use for TTS.
As others have mentioned above. we hope to get Waze to change the TTS for those abbreviations that we feel are most likely to be encountered in North American that are commonly used on signs.
The exception field can then be primarily for full words and hopefully only needed for abbreviations in rare exceptions.
So the combination of a Waze customized set of abbreviations, along with our ability to further customize anything in an exception field should provide the best solution.
While this will be important for North America, the exception field will be even more important for the rest of the world. The ROTW may well need their own custom abbreviation list too. And that is best left for discussion in another forum!