Alternate street names for TTS, zip codes, abbreviations etc

Moderators: Unholy, orit_y

Alternate street names for TTS, zip codes, abbreviations etc

Postby berestovskyy » Mon May 13, 2013 11:40 pm

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) [color=#aaa]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? ;)
[/color]
Last edited by berestovskyy on Mon May 20, 2013 6:58 pm, edited 3 times in total.
berestovskyy
 
Posts: 925
Joined: Fri Jul 15, 2011 1:50 pm
Has thanked: 254 times
Been thanked: 695 times

Re: Alternate street names for TTS, zip codes, abbreviations

Postby davipt » Tue May 14, 2013 9:58 am

Fully +1.

I'd add yet another tag for the "shields" to allow setting up the letter+number street number independently of the possible proper name when a street crosses a locality.

I'm sure it's pretty similar in most countries, but as an example in Portugal we have (N)ational roads and (M)unicipal roads called N-123 (or even N-123-3), but usually when it crosses a locality there's also a "Street xyz" or "Avenue zyx". Right now I'm using "Street xyz / N123", but it would be nice to put the "Street xyz" into the street field and the N123 into the "shield" tag and then have the shields (a simple square with a specific color per letter in most european countries) appear automatically.

Update: didn't read carefully the OP. I'm +1 for Waze supported tags and proper behavior of alt names for dedicated things, but I would never suggest starting right now abusing the current alt feature with those hashtags on the city name.
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: 2740
Joined: Tue Nov 02, 2010 8:51 am
Location: Oeiras, Portugal
Has thanked: 271 times
Been thanked: 561 times

Re: Alternate street names for TTS, zip codes, abbreviations

Postby berestovskyy » Tue May 14, 2013 2:22 pm

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: 925
Joined: Fri Jul 15, 2011 1:50 pm
Has thanked: 254 times
Been thanked: 695 times

Re: Alternate street names for TTS, zip codes, abbreviations

Postby Dekis » Wed May 15, 2013 8:41 am

davipt wrote:[...] but I would never suggest starting right now abusing the current alt feature with those hashtags on the city name.


It's just a way to introduce a new feature with existing attributes. Ideally, there shall be a separate way to indicate the type of an alternative name.
Image
Dekis
Experts
Experts
 
Posts: 1140
Joined: Tue Jul 20, 2010 4:49 pm
Location: Kyiv, Ukraine
Has thanked: 23 times
Been thanked: 351 times

Re: Alternate street names for TTS, zip codes, abbreviations

Postby petervdveen » Wed May 15, 2013 11:35 am

Maybe wait for waze to start supporting such features before entering nonsense into WME ;-)

Verstuurd van mijn HTC Sensation Z710e met Tapatalk
petervdveen
Coordinators
Coordinators
 
Posts: 9814
Joined: Wed Mar 03, 2010 4:43 pm
Location: Netherlands
Has thanked: 485 times
Been thanked: 1352 times

Re: Alternate street names for TTS, zip codes, abbreviations

Postby berestovskyy » Wed May 15, 2013 1:24 pm

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: 925
Joined: Fri Jul 15, 2011 1:50 pm
Has thanked: 254 times
Been thanked: 695 times

Re: Alternate street names for TTS, zip codes, abbreviations

Postby davipt » Wed May 15, 2013 1:57 pm

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


My point is just about either start using the current state and use the alt-city to put the hash vs. ask for a minimum development to add a new freeform field to enable alt-street = value + optional hash and, while at it, alt-city = value + optional hash.

berestovskyy wrote: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 :(


Here you have a huge point. There are already so many cases of half-backed features that one more can't hurt. And if we, the community, stick to a format and start populating the data massively, waze can only see it as a strong push to get the feature completed and start consuming that data.
PS: house numbers and U-turns you are right, but gas prices it's all into your hands to get it enabled ;)

I'd rather like this approach than the ones I'm seeing at the moment, or in the past, where the community is asked for the opinion of a feature, in general, then waze goes back to the basement, implements something half-backed, launches it, and when we try to use it things don't work as expected.

There are plenty of cases on your examples that I think it's a big stretch and may even be abusing - closures, time based roads, etc, but all other cases about literal alternative-street-names I'm fully on board, namely the TTS override per voice/language, the street name per locale, the long/short alternative and the road shields name, including multiple shields and free form names - recall some of my streets are named N249-3, this can't fit a byte.
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: 2740
Joined: Tue Nov 02, 2010 8:51 am
Location: Oeiras, Portugal
Has thanked: 271 times
Been thanked: 561 times

Re: Alternate street names for TTS, zip codes, abbreviations

Postby edsonajj » Wed May 15, 2013 2:42 pm

I will comment on several of your examples

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

In general I like it; it would be better if the nuance voices worked correctly or Waze's adaptations considered cases where this is needed. As a stopgap, it's good.

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

At least in México our rule for street naming is to use primarily whatever is on signs and I've never seen one as long as your example... I don't know if it is common in Poland. Still, assuming you have a similar situation I think the current system could handle it correctly with the Short/Common street name on the main field and the full one in the alternate.

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

I think that all of these should be handled through separate fields.

Examples 5-10: This would be stretching the role of the alt name quite far... There is nothing to suggest that waze would start using this info, and in general when a new feature has been implemented previous data has not been migrated over (such as house numbers). And at least for road closures it can be handled by disconnecting the segments while they should not be used for navigation.
Image Edson Jiménez

Image
edsonajj
Global Champ Mentor
Global Champ Mentor
 
Posts: 2504
Joined: Wed Feb 01, 2012 6:32 pm
Location: México
Has thanked: 133 times
Been thanked: 923 times

Re: Alternate street names for TTS, zip codes, abbreviations

Postby petervdveen » Wed May 15, 2013 2:56 pm

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

Okey, but adding things like this to the waze DB is a very bad idea.

Ofcourse it would be nice if there was a possibility to add some data but not like this.

About the features not working in Poland.
The U-turns function should work.
The Housenumbers should work.
The gas stations function can be enabled when there is enough data inserted.

The state function is being worked on, but for a lot of european countries that's not necessary.

EDIT:
And if you want to contact Waze about this, contact your champs or comunity manager.
They can forward it.
petervdveen
Coordinators
Coordinators
 
Posts: 9814
Joined: Wed Mar 03, 2010 4:43 pm
Location: Netherlands
Has thanked: 485 times
Been thanked: 1352 times

Re: Alternate street names for TTS, zip codes, abbreviations

Postby davipt » Wed May 15, 2013 3:06 pm

petervdveen wrote:About the features not working in Poland.
The U-turns function should work.


Don't work at all in Portugal.

petervdveen wrote:The Housenumbers should work.


Not working in Portugal. Search doesn't even use the internal street names, much less the house numbers.

petervdveen wrote:The gas stations function can be enabled when there is enough data inserted.

Correct :D

petervdveen wrote:The state function is being worked on, but for a lot of european countries that's not necessary.


The state is gonna be yet another feature that will be designed for a set of countries and have no meaning for the rest of the world. What is a state in most countries? Usually the country has administrative regions and sub-regions and sub-sub-regions, whatever they are called locally, but in the end are they even relevant? Poland has no states, has 16 Voivodeships, like Germany has 16 Länder, Portugal has 18 distritos, all of each sub-divided into municipalities or similar, and those sub-sub-divided into smaller things. All of them are irrelevant for Waze, all of them have different names, and where one draws the line, at one division, or 4 like Portugal? Maybe one day there will be the country of Europe and the states of Poland, Portugal and Germany.
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: 2740
Joined: Tue Nov 02, 2010 8:51 am
Location: Oeiras, Portugal
Has thanked: 271 times
Been thanked: 561 times

Next

Return to Localization

Who is online

Users browsing this forum: No registered users