Road name is incorrect when spoken, right on the map itself

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.

Moderators: Unholy, bextein

Re: Road name is incorrect when spoken, right on the map its

Postby Kuhlkatz » Tue May 14, 2013 9:19 pm

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.
Carel Cornelius
AM : Centurion & Sandton, ZA
CM & Coordinator, South Africa
(HTC One, Android 5.0.2, v7.19.401.51)
Image
South African Wiki Waze Wiki Map Editing
Kuhlkatz
Waze Local Champs
Waze Local Champs
 
Posts: 917
Joined: Fri Jul 20, 2012 6:11 pm
Location: Centurion, Pretoria, South Africa
Has thanked: 39 times
Been thanked: 160 times

Re: Road name is incorrect when spoken, right on the map its

Postby Kuhlkatz » Tue May 14, 2013 7:32 pm

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
Carel Cornelius
AM : Centurion & Sandton, ZA
CM & Coordinator, South Africa
(HTC One, Android 5.0.2, v7.19.401.51)
Image
South African Wiki Waze Wiki Map Editing
Kuhlkatz
Waze Local Champs
Waze Local Champs
 
Posts: 917
Joined: Fri Jul 20, 2012 6:11 pm
Location: Centurion, Pretoria, South Africa
Has thanked: 39 times
Been thanked: 160 times

Re: Road name is incorrect when spoken, right on the map its

Postby Kuhlkatz » Fri Apr 26, 2013 6:57 pm

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

Sent from my HTC Sensation Z710e using Tapatalk 2
Carel Cornelius
AM : Centurion & Sandton, ZA
CM & Coordinator, South Africa
(HTC One, Android 5.0.2, v7.19.401.51)
Image
South African Wiki Waze Wiki Map Editing
Kuhlkatz
Waze Local Champs
Waze Local Champs
 
Posts: 917
Joined: Fri Jul 20, 2012 6:11 pm
Location: Centurion, Pretoria, South Africa
Has thanked: 39 times
Been thanked: 160 times

Re: Road name is incorrect when spoken, right on the map its

Postby kentsmith9 » Tue May 14, 2013 3:39 pm

This conversation has been launched in two separate threads. This one and viewtopic.php?f=129&t=15178&start=480#p440221
USA: Now Idaho; previously California (Northern, SF/SJ)

ImageImageImageImageImageImage
PLEASE READ: Waze Map Editor (Start Here) | Editing Quick-start | Best Practices | Junctions
kentsmith9
Waze Global Champs
Waze Global Champs
 
Posts: 5578
Joined: Mon Apr 23, 2012 3:33 pm
Location: Boise ID and SF/SJ Bay Area of Northern California
Has thanked: 1507 times
Been thanked: 1711 times

Re: Road name is incorrect when spoken, right on the map its

Postby kentsmith9 » Sat Apr 27, 2013 5:33 am

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?
USA: Now Idaho; previously California (Northern, SF/SJ)

ImageImageImageImageImageImage
PLEASE READ: Waze Map Editor (Start Here) | Editing Quick-start | Best Practices | Junctions
kentsmith9
Waze Global Champs
Waze Global Champs
 
Posts: 5578
Joined: Mon Apr 23, 2012 3:33 pm
Location: Boise ID and SF/SJ Bay Area of Northern California
Has thanked: 1507 times
Been thanked: 1711 times

Re: Road name is incorrect when spoken, right on the map its

Postby jasonh300 » Sat Apr 27, 2013 2:01 pm

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
Joined: Fri Oct 28, 2011 4:26 pm
Location: New Orleans, LA, USA
Has thanked: 407 times
Been thanked: 976 times

Re: Road name is incorrect when spoken, right on the map its

Postby davipt » Wed May 15, 2013 2:11 pm

Kuhlkatz wrote:
davipt wrote:I didn't get your point here. Agreed with the shield types, but my point was about

Not wanting to hijack the thread with discussions about shields, but I'm simply saying an easy way to represent the various shield types for each country as a simple 'value'.
The segment street name would still be used as the shield 'value' as that is stored already without duplicating it, hence still free form text and not a fixed number.


Understand this point but the misunderstanding is between the shield type and the shield name.

The shield value may not be into the street name. I have plenty of cases where the highway has a proper name, and on top there are one or more shield names. Besides the typical case of national roads that have proper names inside the locality, I can even pick up examples on Freeways that have a proper name (e.g. "Via do Infante") and on top are also A22 (Freeway=Auto-Estrada #22), E01 (with a zero, European Road 01) and IP1 (Principal itinerary #1). Hence why I like the idea of the alt-names+hash.

Now about the shield types in an ideal world it would be nice to pre-create a list of all possible shield types, designs and colors, and then simply reference those with a single digit, but we all know how fast waze is at managing these internal per-country lists. Hence the fast-track of having a pre-set of designs (the US shield and the EU Rhombus style) and let the free form assign the background color (which is slightly different in european countries, except the Exx which is always green).
It would be a question of early optimization. Would we rather sit and wait until waze creates all possible combinations and then start populating the data, or like we do today, just populate the data (landmarks, uturns, alt names, etc.) and let waze play around with the data and implement the feature on top of that?
Bruno D. Rodrigues | Global Champ & Coordinator for Portugal | iPhone Beta
Forum PT | Wiki PT | Facebook PT | Twitter PT
davipt
Waze Global Champs
Waze Global Champs
 
Posts: 2796
Joined: Tue Nov 02, 2010 8:51 am
Location: Oeiras, Portugal
Has thanked: 282 times
Been thanked: 609 times

Re: Road name is incorrect when spoken, right on the map its

Postby davipt » Wed May 15, 2013 12:17 pm

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


Not quite. As the name indicates, it's "alternate" values for the street (or city), the only thing missing is to tag what kind of usage is intended for the alternate value, so the suggestion fits quite well into the current architecture. The only lack is to have "alt-street"+"tag" and "alt-city"+"tag" instead of abusing "alt-city" to put the hash.


Kuhlkatz wrote: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 ?


Nope, I don't. I'd probably suggest the feature to be visible to AM and up only.

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


We are only asking for adding relevant information to waze - street localization, TTS overrides per language/voice, alternate names to help the search, all features important for waze.

Kuhlkatz wrote:
davipt wrote: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 ?


This is a completely different discussion. You are talking about possible optimizations on the waze DB without knowing its design. Sure ideally there should be a better way to declare cities and street names directly, instead of assigning those values per segment and hope the backend can de-duplicate them and understand they are the same. Or better abbreviation tables to allow abbreviating or expanding dynamically so instead of writing an abbreviated street on the editor, to save space on the client screen and probably break search, one could write the long version and have the backend abbreviate it. But then it would probably open a can of worms and people would start thinking about separate fields for the street name, with a drop down for all "Street/avenue" combinations and a freeform for the rest, and then we'd all be screwed trying to manage that list. Hence why the street name is *FREE FORM*.
This has nothing to do with the OP.


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


I'd go one step further and justify why I think freeform would be better, in Waze's context, than specific fields - the request for "user notes" per segment, which we've been asking for ages. In my opinion, the internal DB is tied to a schema and any schema change, even something as simple as a text field to be used exclusively to show on the editor, would require a downtime and schema migration. Been there, suffered that.

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


Hence what we're asking. Some data should be optimized and put into a schema, for performance reasons. I'm sure plenty of segment data needs to be fully optimized so the routing algorithm is fast enough. But the data we're asking for needs to be analyzed between the compromise of a freeform map and the client doing a couple of map lookups, vs. a complex schema change trying to cover every possible combination and tied up until the next possible schema change in six months.


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

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.


I didn't get your point here. Agreed with the shield types, but my point was about using the byte to store the shield value - again, the error committed into the house numbers. For example, maybe you are assuming the streets are like E80 and you could store a flag for E (green rectangle) and store 80 into a byte. But then there is E01 - with the zero - and in Portugal, stuff like N249-3. How do you store the 249-3 now? And what if it were 249B ? I'm pushing this with a strong voice because bing was able to screw this some months ago - the bing maps shows a shield "[3]" on the N249-3 because someone probably thought that freeform text was bad and it would be better to optimize it. BANG.
Bruno D. Rodrigues | Global Champ & Coordinator for Portugal | iPhone Beta
Forum PT | Wiki PT | Facebook PT | Twitter PT
davipt
Waze Global Champs
Waze Global Champs
 
Posts: 2796
Joined: Tue Nov 02, 2010 8:51 am
Location: Oeiras, Portugal
Has thanked: 282 times
Been thanked: 609 times

Re: Road name is incorrect when spoken, right on the map its

Postby davipt » Wed May 15, 2013 11:06 am

berestovskyy wrote:
Kuhlkatz wrote: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.

+1 Did you suggest it before?


I sincerely hope he didn't. Then waze would probably implement it and half of the world would be wondering what the heck are suffixes when what we need is prefixes. Like I said, same with idea of numeric only shields and door numbers. Worthless features that took ages to implement without looking at them with a worldwide generic feature set requirements. That's why I like so much the freeform idea - KISS!
Bruno D. Rodrigues | Global Champ & Coordinator for Portugal | iPhone Beta
Forum PT | Wiki PT | Facebook PT | Twitter PT
davipt
Waze Global Champs
Waze Global Champs
 
Posts: 2796
Joined: Tue Nov 02, 2010 8:51 am
Location: Oeiras, Portugal
Has thanked: 282 times
Been thanked: 609 times

Re: Road name is incorrect when spoken, right on the map its

Postby davipt » Wed May 15, 2013 8:39 am

Kuhlkatz wrote:You tend to forget...


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.

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.

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.

Of course ideally should not be an abuse of the alt-city with freeform hashes, 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.
Bruno D. Rodrigues | Global Champ & Coordinator for Portugal | iPhone Beta
Forum PT | Wiki PT | Facebook PT | Twitter PT
davipt
Waze Global Champs
Waze Global Champs
 
Posts: 2796
Joined: Tue Nov 02, 2010 8:51 am
Location: Oeiras, Portugal
Has thanked: 282 times
Been thanked: 609 times

PreviousNext

Return to Waze Map Editor

Who is online

Users browsing this forum: Google [Bot]