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'.