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: krankyd, Unholy

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
kentsmith9
Waze Global Champs
Waze Global Champs
 
Posts: 3129
Joined: Mon Apr 23, 2012 3:33 pm
Location: SF/SJ Bay Area of Northern California
Has thanked: 528 times
Been thanked: 594 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
Using HTC One, Stock ROM, Android 4.2.2
Image
South African Wiki Waze Wiki Map Editing
Kuhlkatz
Beta tester
Beta tester
 
Posts: 846
Joined: Fri Jul 20, 2012 6:11 pm
Location: Centurion, Pretoria, South Africa
Has thanked: 25 times
Been thanked: 130 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
Using HTC One, Stock ROM, Android 4.2.2
Image
South African Wiki Waze Wiki Map Editing
Kuhlkatz
Beta tester
Beta tester
 
Posts: 846
Joined: Fri Jul 20, 2012 6:11 pm
Location: Centurion, Pretoria, South Africa
Has thanked: 25 times
Been thanked: 130 times

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
Using HTC One, Stock ROM, Android 4.2.2
Image
South African Wiki Waze Wiki Map Editing
Kuhlkatz
Beta tester
Beta tester
 
Posts: 846
Joined: Fri Jul 20, 2012 6:11 pm
Location: Centurion, Pretoria, South Africa
Has thanked: 25 times
Been thanked: 130 times

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

Postby Kuhlkatz » Wed May 15, 2013 12:20 am

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'.
Carel Cornelius
AM : Centurion & Sandton, ZA
CM & Coordinator, South Africa
Using HTC One, Stock ROM, Android 4.2.2
Image
South African Wiki Waze Wiki Map Editing
Kuhlkatz
Beta tester
Beta tester
 
Posts: 846
Joined: Fri Jul 20, 2012 6:11 pm
Location: Centurion, Pretoria, South Africa
Has thanked: 25 times
Been thanked: 130 times

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

Postby Kuhlkatz » Wed May 15, 2013 11:56 am

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.
Carel Cornelius
AM : Centurion & Sandton, ZA
CM & Coordinator, South Africa
Using HTC One, Stock ROM, Android 4.2.2
Image
South African Wiki Waze Wiki Map Editing
Kuhlkatz
Beta tester
Beta tester
 
Posts: 846
Joined: Fri Jul 20, 2012 6:11 pm
Location: Centurion, Pretoria, South Africa
Has thanked: 25 times
Been thanked: 130 times

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

Postby Kuhlkatz » Wed May 15, 2013 1:44 pm

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.
Binary 00000000 ( or null ) = No shield. NULL values, contrary to where was elsewhere stated does NOT necessarily occupy additional space for storage, it simply has zero length indicated or is not present, which is why nullable columns are traditionally stored at the END of the data row.
Binary 00000001 (1) = shield type 1, eg. National routes, with a predetermined population method, and specific graphic associated for the generation. ( Nnn ) in my case.
Binary 00000010 (2) = Shield type 2, eg. Metroplitan routes, with it's own style & graphic ( Mnn ) in my case
Binary 00000100 (4) = Shield type 3, Primary routes (Rnn) etc. etc.

In older processors bitwise operations was far faster than comparing two register values or register vs memory value or memory vs memory. Not predominantly the case any more with current processors, but still faster in general if you redo the same thing millions times over. How stuff is represented in a DB does ultimately affect CPU usage when dealing with comparisons from selecting data, and comparing freeform text vs enumerated fields are far more expensive in CPU cycle costs. Freeform tags, if allowed in input data, will likely ultimately be saved as 'dedicated' data anyway where the metadata matches the relevant 'freeform' tags in terms of columnar representation.

Something we do agree on is we have no idea how it's represented in the back-end or what is used for the storage engine(s) and where the various data bits are, so all of this is just speculation.
we also have no idea what Waze has in mind for 'fixing' this.

Please note that we are all entitled to our opinions and views, and can freely air them without having to resort to character attacks on other people just because they don't agree with your viewpoint.

You say it's an easy win to use the Alt Name for Alt tags. I say it's not a good idea to allow freeform tags here as data has to be further disseminated and syntactically checked AFTER entry to add the additional tags in the background, some for the TTS engine, some for the search engines, and some more for shield data. A good design does not need data to be reworked after entry - it uses it optimally in the way it's captured.
Carel Cornelius
AM : Centurion & Sandton, ZA
CM & Coordinator, South Africa
Using HTC One, Stock ROM, Android 4.2.2
Image
South African Wiki Waze Wiki Map Editing
Kuhlkatz
Beta tester
Beta tester
 
Posts: 846
Joined: Fri Jul 20, 2012 6:11 pm
Location: Centurion, Pretoria, South Africa
Has thanked: 25 times
Been thanked: 130 times

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

Postby Nacron » Tue May 14, 2013 6:09 pm

This segment

https://www.waze.com/editor/?zoom=5&lat ... s=12940266

was once misspelled as pealridge and not pearlridge. It was corrected on map but the TTS continues to say peel-ridge. The subsequent segment that contains pearlridge is correctly pronounced.
2010 Subaru Legacy 2.5i | Sprint Samsung Galaxy Note 3 | 4.3 MJ4 | Waze 3.7.7.0 Official
[Oahu, Kauai, Maui, Lanai, Hawaii Island, Molokai] Hawaii Area Manager
Image
Nacron
Beta tester
Beta tester
 
Posts: 277
Joined: Fri Sep 25, 2009 9:08 pm
Location: Waipahu, HI
Has thanked: 3 times
Been thanked: 3 times

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

Postby Rdawg1 » Sat May 18, 2013 7:32 pm

I live near a highway named Dawsonville Highway and Waze always pronounces it Doranville Highway. It is spelled correctly on the screen.
Rdawg1
 
Posts: 2
Joined: Sat May 18, 2013 6:06 pm
Has thanked: 0 time
Been thanked: 0 time

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

Postby russblau » Sat Apr 27, 2013 11:39 am

I had to chuckle yesterday when Samantha told me to turn on Fre-DEH-Rick Street.
ImageImage
AM Northern Virginia/Washington, D.C./Sussex County, DE
russblau
Beta tester
Beta tester
 
Posts: 595
Joined: Fri Oct 19, 2012 11:36 pm
Has thanked: 90 times
Been thanked: 158 times

PreviousNext

Return to Waze Map Editor

Who is online

Users browsing this forum: No registered users