Get a sneak peek at whats next for Permanent Hazards on our April 7th Office Hours!

Post Reply

Alternate street names for TTS, zip codes, abbreviations etc

Post by berestovskyy
UPDATE3. Summary:
  1. To adjust some of non-common segment properties, we suggest to implement Key-Value pairs in WME. We have no intention to use these properties for the vast majority or the roads.
  2. These Key-Values available for 3+ or 5+ cones editors only.
  3. Waze devs can implement it in a way they like:
    • as a separate Key-Value system similarly to Alternate names;
    • adding a Key to existing Alternate Names, so they would become "Key, Alt City (Value 1), Alt Street (Value 2)";
    • using existing Alt City as a Key and Alt Street as a Value or vice-versa;
    • as fields on a separate tab (next to General) in WME, available for 3+ or 5+ cones editors only;
    • or any other way (it is not really important).
  4. How could we benefit from these properties? Here are the most reasonable applications at the moment IMHO:
    1. To correct TTS pronunciation, using, for instance, Nuance phoneme set (Nuance Grammar Developer's Guide (PDF), page 85). So, if the property is attached to a road segment, Waze App use it to pronounce the street name.
    2. To put shields on the map (Waze is about to implement this, so details are subject to further discussion).
    3. To handle planned road closures (i.e., closed-until) and time-restricted turns (Waze is about to implement this, so details are subject to further discussion).
We also assume that:
  1. Alt streets will be available for search, so we don't need a "short name" property.
  2. Waze (or someone else) to suggest better idea to localize map data.
  3. Waze to implement zip codes/administrative divisions in (some) countries as separate fields in address block.
Thanks for your feedback!


Hi!
Discussing with Dekis my previous suggestion Client-side Abbreviations, together we came up with the following idea.

We propose to use "Alternate street names" feature as Attribute-Value pairs to specify advanced properties of road segments. For instance, we could use Alt City as an attribute name (starting with hash #) and Alt Street as a value.

Here are some possible usage scenarios:

  1. To improve TTS pronunciation:
    Street: full street name Waze uses by default
    Alt City: #tts Alt Street: if present, a spoken form of the street name for TTS

    Example:
    Street: CeBIT Street <- a name for search and to display
    Alt City: #tts Alt Street: C. bit Street <- Waze uses this to correctly pronounce the street name
  2. To abbreviate long street names:
    Street: full street name Waze uses by default
    Alt City: #short Alt Street: if present, a short street name to display and to pronounce (if #tts is not there)

    For instance:
    Street: Estakada imienia generała brygady piłotów Mateusza Iżyckiego <- full name for search
    Alt City: #short Alt Street: Estakada Iżyckiego <- short street name to display/pronounce
  3. To complement/disambiguate an address:
    Street: full street name Waze uses by default
    Alt City: #zip Alt Street: if present, a zip code Waze uses for search
    Alt City: #province Alt Street: if present, a province name/code Waze uses for search
    Alt City: #district Alt Street: if present, a district name Waze uses for search
    etc
  4. UPDATE2: probably a bad idea (thanks to Kuhlkatz) To localize some of above (or below):
    Street: full street name Waze uses by default
    Alt City: #<attribute>:<LOCALE> Alt Street: if :<LOCALE >suffix is present, Waze use the <attribute> just for specific <LOCALE>

    For instance:
    Street: вулиця Маршала Малиновського <- default street name in Cyrillic
    Alt City: #short Alt Street: Малиновського <- short street name in Cyrillic
    Alt City: #short:en_EN Alt Street: Malynovs'koho <- short & transliterated street name
  5. UPDATE1: To handle road closures:
    Alt City: #closed Alt Street: if present, Waze temporarily does not use this road for navigation
    Alt City: #closed-until Alt Street: dd.mm.YYYY -- Waze does not use this road until date specified
    etc
  6. UPDATE1: Complicated house numbers:
    Alt City: #house Alt Street: number (i.e. 23B/2) -- if present, Waze uses this field to search complicated house numbers (small invisible segments should be placed accordingly)
  7. UPDATE1: Time-restricted segments or turns:
    Alt City: #restricted-time Alt Street: date/time range -- if present, Waze does not use the segment for navigation if date/time range match ETA
    Alt City: #restricted-AB-time Alt Street: date/time range -- if present, Waze restrict traffic one way (A->B)
    etc

    For instance:
    Alt City: #restricted-time Alt Street: Wk0705-1000,Sa,Su <- restrict traffic weekdays from 9:05 AM to 10:00 AM, Sturday and Sunday
  8. UPDATE1: Shields:
    Alt City: #shield Alt Street: <color><shape>:<text> -- if present, Waze display <text> on a shield shaped/coloured as <color><shape>

    For instance:
    Alt City: #shield Alt Street: GR:E40 <- green rectangular shield with E40 text
  9. UPDATE1: Cardinal directions:
    Alt City: #dir Alt Street: N, S, E or W -- if present, Waze uses this info to display or for TTS
  10. UPDATE1: City center:
    Alt City: #city-center Alt Street: name -- if present, Waze uses this segment as a center of the corresponding city
  11. UPDATE1: Alternate names (yes!):
    Alt City: name Alt Street: name -- if present, Waze uses this alt names for search (note Alt City name does not start with hash #)


I hope you grasp the idea.

UPDATE1: WME might show and accept those properties from editors with 5 cones up only.

UPDATE1: All we need at the moment is to discuss and agree the syntax with Waze devs. Alt City/Street fields are already there in WME so we could begin to add those properties while Waze would be implementing them.

What do you think? ;)
berestovskyy
Posts: 912
Has thanked: 321 times
Been thanked: 832 times

POSTER_ID:2630595

1

Send a message
Last edited by berestovskyy on Mon May 20, 2013 6:58 pm, edited 3 times in total.

Post by argus-cronos
Actually in Germany or Switzerland the state field in its current state is completely useless. A field which is editable is needed in Germany and it should be found via client search. In Switzerland we need nothing additional, cause naming scheme is pretty clear and functional. For Thailand it would make a lot of sense cause there are provinces - districts - subdistricts - cities - khets(quarters in BKK) - villages and very small vilages.

Waze btw gives altnames as search results.
argus-cronos
Posts: 6264
Has thanked: 439 times
Been thanked: 813 times
Send a message

Post by argus-cronos
What you have to do depends on your community, and your country guidelines. Where you from?

What i meant: i've tested this with quarter names in CH and those local quarters will be found on the search, also alt streetnames with only numbers or anything local in it.
argus-cronos
Posts: 6264
Has thanked: 439 times
Been thanked: 813 times
Send a message

Post by argus-cronos
Well in Germany it called "Bundesland" in CH it is "Kanton" but the use of these in a statefield is completely nonsense and brings us nothing. Yes Bing search is absolutely crap in Germany, cause anything will be found in english "Cologne" instead of "Köln" if you search for a road that is double in the city, you get results kilometers away, this sucks. And Bing invented names that doesn't actually exists.
The City name itself isn't the problem, but we name municipalities and if there are double streetnames in different parts of the municipality you never get a correct result.

@berestovskyy
We suffering and complaining also since years, but waze is about to improve the search. We will see.
argus-cronos
Posts: 6264
Has thanked: 439 times
Been thanked: 813 times
Send a message

Post by berestovskyy
I just added few more usage examples: to handle road closures, complicated house numbers, time-restricted segments or turns, shields, cardinal directions, city center and alternate names.

I hope it will draw more attention ;)
berestovskyy
Posts: 912
Has thanked: 321 times
Been thanked: 832 times
Send a message

Post by berestovskyy
petervdveen wrote:Maybe wait for waze to start supporting such features before entering nonsense into WME ;-)
You might missed the "we need [...] to discuss and agree the syntax with Waze" in OP.

From this topic:
davipt wrote: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.
We agreed that we're talking about "Key-Values just like Alt street names", ok?

Sure, we can wait for Waze to start supporting some feature, then wait while they fix it, then start to add it to the map, then wait for a decision to activate it in your country... For instance, neither of recent features like gas prices, house numbers, U-turns... neither is working here in Poland. We can't even use "state" fields in an address :(

The benefits of the Key-Values:
  1. It will help Waze to concentrate their limited resources on a new feature itself, implementing it in client, adjusting search and routing server, rather than web interface. And those Key-Values are already implemented in WME as Alternate names.
  2. It will allow the community to review the feature before it's implemented and propose a correction. So we don't have a situation like with house numbers.
  3. It will allow to prepare the map data (by community) and implement the feature (by Waze staff) at the same time. And as soon as the feature is ready, Waze could even convert those Key-Values into their internal representation. Or they could convert them periodically during tiles update.
I'd really like to see people discussing the idea of Key-Values itself. But sadly, people just see Alt streets here and speculate about database performance impact :(
berestovskyy
Posts: 912
Has thanked: 321 times
Been thanked: 832 times
Send a message

Post by berestovskyy
Regarding gas stations. Well, unfortunately in Poland we have gaps in Aerials, so it's not easy to map streets, not to mention gas stations and house numbers :(

And we have house numbers with letters, odd and even numbers on the same side of the street etc. Neither Bing nor Google address searches work here. Waze search does not work too.

As to administrative division. We have many villages and towns with the same name, and even two counties with the same name. So, we have issues naming and searching them. We asked about administrative division few times.

I'm glad there are countries which are happy with Waze as it is. All I'm trying here is to change Waze a bit, so we could also enjoy it as you are ;)

Thanks everyone for your feedback!
berestovskyy
Posts: 912
Has thanked: 321 times
Been thanked: 832 times
Send a message

Post by berestovskyy
Thanks for your answers and here is my summary:
  1. To adjust some of non-common segment properties, we suggest to implement Key-Value pairs. We have no intention to use these properties for the vast majority or the roads.
  2. These Key-Values available for 3+ or 5+ cones editors only.
  3. Waze can implement it in a way they like:
    • as a separate Key-Value systems, just like Alternate names;
    • adding a Key to existing Alternate Names, so they would become "Key, Alt City (Value 1), Alt Street (Value 2)";
    • using existing Alt City as a Key and Alt Street as a Value or vice-versa;
    • as separate fields in WME, available for 3+ or 5+ cones editors only;
    • or any other way (it is not really important).
  4. The most controversial part: how could we benefit from these properties? Here are the most reasonable applications at the moment IMHO:
    1. To correct TTS pronunciation, using, for instance, Nuance phoneme set (Nuance Grammar Developer's Guide (PDF), page 85). So, if the property is attached to a road segment, Waze App use it to pronounce the street name.
    2. To put shields on the map (Waze is about to implement this, so details are subject to further discussion).
    3. To handle planned road closures (i.e., closed-until) and time-restricted turns (Waze is about to implement this, so details are subject to further discussion).
We also assume that:
  1. Alt streets will be available for search, so we don't need a "short name" property.
  2. Waze (or someone else) to suggest better idea to localize map data.
  3. Waze to implement zip codes/administrative divisions in (some) countries as separate fields in address block.
berestovskyy
Posts: 912
Has thanked: 321 times
Been thanked: 832 times
Send a message

Post by berestovskyy
argus-cronos wrote:Waze btw gives altnames as search results.
Do you mean we have to put "City (province)" into city field and then just "City" into an alt. city field to get this city found?
berestovskyy
Posts: 912
Has thanked: 321 times
Been thanked: 832 times
Send a message

Post by berestovskyy
argus-cronos wrote:What you have to do depends on your community, and your country guidelines.
Here in Poland we name non-unique cities as "City (province)" or "City (county)" or "City (commune)" (just like on Wikipedia). But it's not a problem to name a city. The problem is to find a city.

When you run a search for "City" in Waze App, instead of getting a list of those "City (provice)", "City (county)" etc. you get just "City", but 650 km away in another country, for instance.

I should start a separate topic about that. We have no local champs and we suffering and complaining for years about this problem. But now it's clear to me that most of you guys don't even aware about it...

Thanks for the idea though! I'll give it a try to put just "City" in alt city field, so maybe it will help with the search ;)
berestovskyy
Posts: 912
Has thanked: 321 times
Been thanked: 832 times
Send a message