Get a sneak peek at whats next for Permanent Hazards on our April 7th Office Hours!
The place to get information and ask questions about everything to do with properly and successfully editing the Waze Map.

Use this forum for all general editing questions, and the sub-forums for specific types of Waze Map Editor features.
Post by CBenson
Sure sounds like Seminary to me too. I think Alan is correct that its just the way the TTS says Cemetery.

Is there a way to upload sound files to forum posts?
CBenson
EmeritusChamps
EmeritusChamps
Posts: 10330
Has thanked: 608 times
Been thanked: 1642 times
Send a message
Regional Coordinator: Mid-Atlantic, US
Verizon, Nexus 6, Android 6.0.1, Waze 4.7.0.902

Post by CBenson
Would you have a link to where on the nuance website you can do this?
CBenson
EmeritusChamps
EmeritusChamps
Posts: 10330
Has thanked: 608 times
Been thanked: 1642 times
Send a message
Regional Coordinator: Mid-Atlantic, US
Verizon, Nexus 6, Android 6.0.1, Waze 4.7.0.902

Post by jasonh300
I decided to go to the link above and get a correct pronunciation on a local highway (Belle Chasse Hwy). Unfortunately, the nuance Samantha voice pronounces it with the correct French pronunciation...nothing like the way the Waze Samantha voice butchers it (which adds a -AY syllable onto the end of Chasse).

What am I supposed to do about that?
jasonh300
EmeritusChamps
EmeritusChamps
Posts: 7568
Has thanked: 131 times
Been thanked: 530 times
Send a message

Post by kentsmith9
I take it from the description this procedure will change the pronunciation of the road for all mobile devices (assuming Waze adds the change to the database).

Alan is proposing we add this procedure to the Wiki. I propose that we say the following:
Proposed Wiki Addition wrote:When the TTS engine pronounces a street incorrectly, there is a process that can be used to get that pronunciation corrected.

1. Go to the following web site {insert web site URL}
2. Enter the name of the street that does not get pronounced correctly.
3. Listen to how the street is pronounced.
4. If it is not pronounced correctly you can say it correctly and get a copy of the file.
5. Send the TTS file to Waze {do we have a forum for this, or do we use the support page?}
6. Include "Street name = Modified street name" in the email {or forum post} and request that the file be added to the Waze TTS database.
7. Once it is added {how do users know when that happens?} the TTS cache in the client device must be cleared before the new street name can be heard {how is the cache cleared?} Before the cache is cleared, you will not hear the new street name.
Is there anything else we are missing or need clarified?
kentsmith9
Waze Global Champs
Waze Global Champs
Posts: 5766
Has thanked: 816 times
Been thanked: 1156 times
Send a message


Post by Kuhlkatz
http://www.nuance.com/vocalizer5/flash/index.html should do the trick.

Sent from my HTC Sensation Z710e using Tapatalk 2
Kuhlkatz
Waze Local Champs
Waze Local Champs
Posts: 917
Has thanked: 32 times
Been thanked: 146 times
Send a message
Carel Cornelius
AM : Centurion & Sandton, ZA
CM & Coordinator, South Africa
(HTC One, Android 5.0.2, v7.19.401.51)
[img]https:///DwNb3R[/img]
South African Wiki Waze Wiki Map Editing

Post by Kuhlkatz
And what do you suggest for countries with more than one primary language.
Which do you choose as an alt name, or will we need to try and stuff 10 alternate names info one field separated by a language code?
This issue with TTS needs to be tackled in a different way with some real thought behind it.

Sent from my HTC Sensation Z710e using Tapatalk 2
Kuhlkatz
Waze Local Champs
Waze Local Champs
Posts: 917
Has thanked: 32 times
Been thanked: 146 times
Send a message
Carel Cornelius
AM : Centurion & Sandton, ZA
CM & Coordinator, South Africa
(HTC One, Android 5.0.2, v7.19.401.51)
[img]https:///DwNb3R[/img]
South African Wiki Waze Wiki Map Editing

Post by Kuhlkatz
You are suggesting that editors and developers put effort into a hack for a once-off solution that is not reusable anywhere else, using a field that is already populated with valid data. Whether that data is currently of any use is another debate.

With the future WME editor supporting localization, they should rather design around using a separate tts override field based on the language that you are editing in, tying that pronunciation into that language code and storing the info in a field dedicated for that purpose.

The other thing is, Waze is using Nuance as tts engine , I'm not even sure that it does support phonetic overrides for pronunciation. Specific voices are only avaliable in specific languages, which makes me think not, or else Samanthas voice would likely have been available in all supported languages.
Kuhlkatz
Waze Local Champs
Waze Local Champs
Posts: 917
Has thanked: 32 times
Been thanked: 146 times
Send a message
Carel Cornelius
AM : Centurion & Sandton, ZA
CM & Coordinator, South Africa
(HTC One, Android 5.0.2, v7.19.401.51)
[img]https:///DwNb3R[/img]
South African Wiki Waze Wiki Map Editing

Post by Kuhlkatz
berestovskyy wrote:You can add as many alt names as you like, so already existing data would not be harmed. All suggested properties start with the hash (#), so it's easy to distinct property and alt name for server, client App and editors.
The fact that it's there doesn't mean it should be abused. Most pick-up trucks in Australia, SA and the US of A have flashy chromed bull-bars and roll-bars, but it doesn't mean that their owners can go crashing into things just because they have them fitted.
You tend to forget that it's not only your device that makes use of this data. The livemaps would use it, editors use it, devices use it, and it's probably duplicated multiple times across multiple databases and server banks. TTS is served from the back end servers and it has to get this data somehow for every segment you drive on that needs a shield or needs an announcement. Populating 4 / 5 different attributes in a single free-form field is a bad idea from a design perspective. There are a vast number of segments out there, used by millions of Wazers daily. Searching through this large string of gobbledygook to get & verify the free-form TTS for every segment used, check if a shield should be generated or not, etc. would create havoc on performance, instead of searching through dedicated fields of the smallest required storage.
If you want to try it, clean 1000 small tiles of 1x1 centimeters using your toothbrush. Now try doing the same with 1000 tiles of 4x4 or even 10x10 cm using the same toothbrush. Slighty slower now isn't it ?
Well, that is exactly what crappy design principles does to DB performance, and exactly what would happen here too.
Unfortunately, we have no insight to what the data looks like where it lives, and how much space it occupies or how many segments, nodes, landmarks etc. it all comprises at this stage.
You mean 11 fields, right? Because there are some countries with 11 official languages ;)
I should know, I live in South Africa where we have 11 of them. Waze supports one in TTS, and I helped with the localization for a second one that is not supported in TTS, and better yet, not even supported by Nuance. That is why I would prefer to see a proper implementation based on the supported locales.
In my opinion the Suffixes should also have been split from the street names, as that is a lot of free-form text being duplicated where not required. This would also have supported the localization effort where names remain the same, but suffixes change based on the language. Houston Road vs Houston Weg, to compare the English vs Afrikaans equivalent. Houston remains 'universal' across all supported languages for this specific street, irrespective how it's pronounced, mangled by or 'fixed' for TTS. The suffix is the real kicker here that makes it 'not fit for use'.
We suggest to use alt names because it's already there.
Alt names already have their 'designation', and they will not disappear overnight. They could be put to proper use in future if Waze does start using their own search mechanisms. If this data is scrubbed now for such an implementation, many editing hours would be down the drain for nothing.
It also means that every time a decision should be made on whether it's TTS data or shield data or if it's just a normal 'Alt' name, the full field has to searched and parsed to verify that it contains valid data for each of those or not. It would be like starting at one end of the library looking at each book in turn until you find the one you want, instead of just going to the indexing system and looking up the exact location to pick it out. Oh, and don't forget the extra coding to error-check the editors, just because they failed to put a # or whatever other tag in the right place.

[/quote]But ok, let's forget about alt names. Let's assume that it's another attribute-value pairs or properties that could be attached to any segment in Waze.[/quote]
As long as it's fit-for-purpose and has a valid use, then yes. It's easy to designate 4/8/12 shields per country and tie that in with flag x/y/z and images to match, or a TTS override if supported tied in with a language.
The major snag is, what is priority for Waze at this stage and what is planned for the near future ? How long have the US guys been moaning about their beloved shields ? This was manually generated I understand, hence the outcry for a 'flag'. One single flag, which can be implemented as a bit-wise selector for a flag using one extra byte per segment, and capable of supporting 8 different shield types this way, or 256 if they use the straight numeric value.

Waze is a business, with their own projects and plans as well, which is not shared with us. What sounds like a quick button press or 2 for most people, actually translates to detailed project plans, man-hours for coding, testing, performance testing, regression testing etc. and most importantly this all translates to cost.
This is where the bean-counters come in and double check the direct benefit in terms of return on investment for Waze from spending time and money to add shields for everyone vs. roi for spending time and money on getting partners that pay for flashy ads, and this is where reality sets in and they decide that shields can wait.

Summary of the stuff above = 'Not a good idea'.
Kuhlkatz
Waze Local Champs
Waze Local Champs
Posts: 917
Has thanked: 32 times
Been thanked: 146 times
Send a message
Carel Cornelius
AM : Centurion & Sandton, ZA
CM & Coordinator, South Africa
(HTC One, Android 5.0.2, v7.19.401.51)
[img]https:///DwNb3R[/img]
South African Wiki Waze Wiki Map Editing

Post by Kuhlkatz
davipt wrote:I think you are overreacting, not quite aware of what the concept of key-val Map is, or how to scale DB systems, specially in terms of future feature set, and are forgetting the world is a big place.
I maybe overreacting, but no more than those suddenly jumping on the bandwagon advocating it's a great idea to use the field - it's there and has it's use and purpose OUTSIDE of what is recommended. If the average editor cannot even correctly pick a country or city field from a provided drop-down list, do you have any idea how they will fare using free-form fields ?
We can discuss how storing key-val pairs duplicates metadata and escalates costs if stored as part of the data vs traditional metadata and it's benefits, but not knowing how it's stored and even what's used in the back-end makes it sort of irrelevant.
One thing to note is that we are talking about Waze after here, not OpenStreetMaps, which is likely what you are referring back to with their sometimes overwhelming use of the various tags to describe every little aspect that is frankly out of scope for most of Waze and simplicity.
Your comment about Suffixes and a Single byte for shields shows you don't even know what is happening in other countries. That's the same mindset that brought us the "x to y continuous house numbers" and then this "numeric only house numbers", or the "tolls roads" done by developers of a country without tolls.
I'll gladly draw you some pictures so you can understand those concepts too. It's just as easy to indicate what in English is usually referred to as a street name 'suffix', could just as easily be used as a prefix by flagging it as either. Take "Rue du" Commerce (FR) vs. Commerce "Street" (EN) vs Commerce "Straat" (AF).. is that a good enough sample to indicate the 'common' portion vs what should be custom ? There are simply not 1000's of these prefixes in any language, so why are we duplicating them millions of times over ?

I also never said fixed numeric-only house numbers ever was a good idea, in fact just the opposite. I am simply saying that if it is taking this long for shields to be resurrected, it will take slightly longer for supporting custom TTS, if that is even on the map.
Hardcoded fields are prone to limitations, heavy development, hard migration downtimes, and in this case, quite prone to try to solve one country's problem without caring about others
Not if it is a well thought out design that encompasses the possibility to be flexible enough to use in most cases, and yet simple and easy enough to use for everyone that is capturing the data.
This is plainly what I am advocating.

Of course ideally should not be an abuse of the alt-city with freeform hashes
+1 for the first sensible thing said

[/quote], but a proper key-val alt-street (and even alt-city variations), but I do still hope it is a map with free values. In my and the countries nearby we don't have "suffixes", maybe have "prefixes", and dont' have a byte for street shields, but instead letters and number and dashes and much more than 8 bits.[/quote]
There are certainly no more than say, an average of 4 or 5 different shield TYPES in any country for the major/minor route types, which is what people want indicated. The representation of the route info if you want that displayed ON the shield has a few possibilites, but again it is not a very large number, top, middle, bottom and left, right, center or any combo of the 2 ?

Look up the definition of BIT vs BYTE and the definition of multi-byte character sets like Unicode, which is how the data is presented in Waze to support various devices.
Kuhlkatz
Waze Local Champs
Waze Local Champs
Posts: 917
Has thanked: 32 times
Been thanked: 146 times
Send a message
Carel Cornelius
AM : Centurion & Sandton, ZA
CM & Coordinator, South Africa
(HTC One, Android 5.0.2, v7.19.401.51)
[img]https:///DwNb3R[/img]
South African Wiki Waze Wiki Map Editing