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.

Moderator: Unholy

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: 904
Joined: Fri Jul 20, 2012 6:11 pm
Location: Centurion, Pretoria, South Africa
Has thanked: 36 times
Been thanked: 148 times

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

Postby davipt » Tue May 14, 2013 9:40 pm

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


There are multiple topics here:
- localization of city and street names. This would be nice to have and has nothing to do with the localization of the editor. It would be nice to show Lisbon to English users or Lissabon to Deutsch and the same for some street names.
- differentiation of the literal string shown on screen and what is read by tts. Sometimes it's about abbreviations, sometimes yes it would be a hack to avoid some nuance nuisances. For example in Portugal we have a lot of streets with king names and I'd like to display the correct roman name "Luís XV" but have tts read "Luis, the fifteenth". Examples of phonetic variations are quite easy to obtain by adding accents "at the wrong place" or even commas or dots for pauses
- then there's the case of the abbreviations. Today we abbreviate on the street value and have tts expand it. By splitting full name, short name and tts, it would simplify some cases where the abbreviation is well known in the area but we (editors) can't be asking waze for dozens of rules.
- and finally there is the shields information, that every other map has besides waze (manually hard coded shields doesn't count). Just let me tell Adrian "A" is blue "IP" is red "E" is green and others are white and let me put the names (multiple) on the segments.

For me these are all alternate names of a street. It would be nice to extend what exists today and get that information being used.

Ps. Also alternates for search of course :)
ImageBruno D. Rodrigues | Global Champ
Coordinator for Portugal | Expert iPhone and others
Forum PT | Wiki PT | Facebook PT | Twitter PT
davipt
Waze Global Champs
Waze Global Champs
 
Posts: 2736
Joined: Tue Nov 02, 2010 8:51 am
Location: Oeiras, Portugal
Has thanked: 271 times
Been thanked: 556 times

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

Postby berestovskyy » Tue May 14, 2013 10:15 pm

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

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.

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

You mean 11 fields, right? Because there are some countries with 11 official languages ;)

We suggest to use alt names because it's already there. 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. Wouldn't it be cool instead of waiting for implementation of a new feature (like shields, for instance), Waze could just provide us with such info:

Hey guys, we are about to implement shields, so please use this new property as follows:
Key: #shield Value: <color><shape>:<text> -- if present, Waze display <text> on a shield shaped/coloured as <color><shape>

Example:
Key: #shield Value: GR:E40 <- green rectangular shield with E40 text


And that's it! While they implement shields we prepare the map. And sure, internally, they could store our properties wherever they like: in a database fields or a text file :lol:
berestovskyy
 
Posts: 924
Joined: Fri Jul 15, 2011 1:50 pm
Has thanked: 248 times
Been thanked: 690 times

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

Postby davipt » Tue May 14, 2013 10:38 pm

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


Simple, hash the voice you are trying to enhance. #tts:raquel foo and #tts:samantha bar. There's only as much TTS fields as voice packs on your device and country.
ImageBruno D. Rodrigues | Global Champ
Coordinator for Portugal | Expert iPhone and others
Forum PT | Wiki PT | Facebook PT | Twitter PT
davipt
Waze Global Champs
Waze Global Champs
 
Posts: 2736
Joined: Tue Nov 02, 2010 8:51 am
Location: Oeiras, Portugal
Has thanked: 271 times
Been thanked: 556 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
(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: 904
Joined: Fri Jul 20, 2012 6:11 pm
Location: Centurion, Pretoria, South Africa
Has thanked: 36 times
Been thanked: 148 times

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

Postby berestovskyy » Wed May 15, 2013 8:19 am

Kuhlkatz wrote:Populating 4 / 5 different attributes in a single free-form field is a bad idea from a design perspective.

Tell it to Google, Microsoft, OpenStreetMaps... And don't forget the Wikipedia! :lol:

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

I keep saying that we shouldn't speculate about internals of Waze databases. Most probably, everything about segment's address in Waze is already designed as "properties" attached to segments IDs, because it consumes much less space.

Adding one empty (NULL) field to a database with millions of records leads to gigabytes of wasted (NULLed) space. Adding a property to a segment ID consumes just what it is. Google for Database Normalization ;)

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?

Kuhlkatz wrote:Summary of the stuff above = 'Not a good idea'.

Then we should probably keep waiting for "magic fields" which will solve our problems with abbreviations, shields, TTS, time-restricted segments/turns etc? I hope those "magic fields" will take into account your (11 languages) country specificity ;)
berestovskyy
 
Posts: 924
Joined: Fri Jul 15, 2011 1:50 pm
Has thanked: 248 times
Been thanked: 690 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.
ImageBruno D. Rodrigues | Global Champ
Coordinator for Portugal | Expert iPhone and others
Forum PT | Wiki PT | Facebook PT | Twitter PT
davipt
Waze Global Champs
Waze Global Champs
 
Posts: 2736
Joined: Tue Nov 02, 2010 8:51 am
Location: Oeiras, Portugal
Has thanked: 271 times
Been thanked: 556 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!
ImageBruno D. Rodrigues | Global Champ
Coordinator for Portugal | Expert iPhone and others
Forum PT | Wiki PT | Facebook PT | Twitter PT
davipt
Waze Global Champs
Waze Global Champs
 
Posts: 2736
Joined: Tue Nov 02, 2010 8:51 am
Location: Oeiras, Portugal
Has thanked: 271 times
Been thanked: 556 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
(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: 904
Joined: Fri Jul 20, 2012 6:11 pm
Location: Centurion, Pretoria, South Africa
Has thanked: 36 times
Been thanked: 148 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.
ImageBruno D. Rodrigues | Global Champ
Coordinator for Portugal | Expert iPhone and others
Forum PT | Wiki PT | Facebook PT | Twitter PT
davipt
Waze Global Champs
Waze Global Champs
 
Posts: 2736
Joined: Tue Nov 02, 2010 8:51 am
Location: Oeiras, Portugal
Has thanked: 271 times
Been thanked: 556 times

PreviousNext

Return to Waze Map Editor

Who is online

Users browsing this forum: AquaZR1, F1981D, Google Feedfetcher