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