Kои гласови навигации ползват OSM? Аз съм ползвал само тази на OSMAnd+.
Как се справя гласовата навигация(и) с name:sr=Цара Николаја II ? На български трябва да е “втори”, а не “две”.
Искам да отбележа, че OSMAnd ползва данните на OSM индиректно. От OSM се създават файлове/карти по държави или области. При този процес съответното приложение може да се погрижи да подготви и съответните текстове за гласова навигация. Например да разгъне съкращенията “Акад.”, “Ген.”, “Полк.” или да махне първите/вторите имена, така както хората казват на улиците разговорно - “Булевард Левски”. Нямаме таг voice=* но и нищо не пречи да се направи подобен
I wouldn’t worry too much about the effect of street naming on voice navigation. I’ve been using Organic Maps in Dutch for navigation in Turkey, which resulted in plenty of pronunciation mistakes (kadesi instead of zhaddesi for caddesi, etc.). That didn’t bother me though; as long as what is pronounced is recognisable in comparison with the street sign, it’s good enough. The length of the name to be pronounced is more important so providing an abbreviated version for long names (and encourage navigation apps to use it) is more important.
Regarding car navigation, I can now choose from 3 or 4 apps, and I actually prefer those with less annoying pronunciation. (Google Maps replaced the professional voice of Gergana Stoyanova with AI at the beginning of this year, causing nationwide discontent) As we map street names, we can map what we would like to hear too.
I don’t use voice navigation, so I’m not sure. This argument was brought up by others (not that it should be dismissed).
It should be Cara Nikolaja drugog (втори in genitive case) indeed. Roman numerals are customarily used even in Cyrillic text and it would be a stretch to expand them in name. A voice navigation should know some common language-specific pronunciation conventions; but things like “Акад.”, “Ген.”, “Полк.” is too much in my opinion.
I’m wondering if there is any point in keeping int_name since there are rules for it. It is trivial to implement and there is almost no way to make it wrong. Except for the case when the street is named after some French person. But in those rare cases, we can manually add int_name=Frederic Joliot-Curie. On the other hand int_name=Ivan Vazov seems like a waste of bytes.
The latest street signs with perfect styling for a graveyard, include only Bulgarian and English street names but not transliterations (i.e. no “ul. Priroda” unlike the older signs). See this sign for an example. I haven’t seen them on boulevards yet but I assume it is the same there.
Navigation applications would likely have to parse and patch any “obvious” abbreviations themselves, since most text-to-speech engines aren’t narrowly tailored to a navigation use case. For example, the Mapbox Navigation SDK uses Amazon Polly, which was originally designed for reading audiobooks. The TTS engines built into mobile operating systems also need to handle a variety of use cases, so no good set of abbreviations is provided out of the box.
To some extent, developers can request more navigation-centric text processing in SSML, but the available options usually require the application to know whether the input text is already abbreviated or not (and which language it’s in). By default, any abbreviation will be read verbatim, so “Акад.” would sound like “Акад”. I used to think the address interpretation mode would be ideal for any part of an instruction that names a street, but unfortunately it expands abbreviations too aggressively. For example, some OSM-based apps are known to mispronounce routes numbered “30A”, “9L”, and “35W” as “thirty amperes”, “nine liters”, and “thirty-five watts”, respectively. Disabling address interpretation fixes the issue but also means the app is less resilient to unexpected abbreviations in OSM data.
Although we wouldn’t want third-party TTS engines’ quirks to overly influence our data, it is part of the reality of developing navigation software. If we choose to abbreviate these words in the data, then we’re also creating an expectation that applications need to guess when to undo these abbreviations, and mappers will have no opportunity to override the guess – undoing the undoing – for any exceptional cases.
I admit that the abbreviation “бул..” is mainly for our convenience and to reduce clutter on rendered maps. So we have one approach focused on renders. On the other hand, we have voice navigation, which is becoming more and more popular. I’m not sure to what degree name:pronunciation could be appropriate in this case. We can add name:pronunciation="булевард левски" or we can add something new, like name:voice="булевард левски" hoping for support from developers.
Това е ако гледаме дубликати в рамките на едно населено място. Ако гледаме дубликати в цялата община, става по-страшно. Но, държа да отбележа че това е по-скоро местен проблем. Не мисля че съществува в такива мащаби извън София
name:pronunciation=* is for a transcription of name=* in IPA, without hiding additional words. In hindsight, it should’ve been the more standardized name:bg-fonipa=* etc. to clarify the purpose and leave room for other phonetic alphabets.
People have occasionally mused about use case–specific keys like name:geocoding=* and name:navigation=*. The idea hasn’t gotten much traction, maybe because both mappers and software developers are already having to deal with so many name keys as it is. By the way, many editors and data consumers already understand short_name=* and a few also understand full_name=*.
If it’s visual clutter you’re worried about, you could start tagging short_name=* everywhere and Mapbox will actually completely ignore name=* in favor of short_name=*, even when there’s enough room for the full name. More generally, automatic abbreviation has been the norm in OSM-based software. There could be good reasons to buck this trend, but you’ll have to weigh the convenience against the effort to get your special cases supported well.
И аз гласувам за “нещо трето”. Гледайки Елин Пелин не ми харесва да виждам “булевард” на единствения булевард в града. Също не бих искал да виждам "площад Пенчо Р. Славейков“. Компромиса от двете крайности е name:prefix. Бонуса от това нещо е че ще ни спести доста ръчни корекции на имена в бъдеще време.
I assumed it would be possible to add answer options but it isn’t
I don’t think it’s a good idea to create a new definition of a sparingly used key (name:prefix) to solve this mostly aesthetic issue. It’s unlikely to be supported by data users if it is only used in Bulgaria with this new meaning.
I prefer to follow the internationally accepted good practice of not having abbreviations in name for which there is no good reason for Bulgaria to be an exception, and to use the already widely supported short_name key to solve the aesthetic issue.
It is, but on a community by community basis, I believe. The “help and support” areas support the “solution” tick box, and also allow a form of stackoverflow-style answer ranking (which is still there despite being turned off by default).
Навремето, в стария форум, беше до някъде моя инициатива да има единна номенклатура за изписването на улици и булеварди. Ситуацията тогава беше, че буквално улица с три пресечки предлагаше четири различни начина на изписване (кавички, без кавички, ул., улица, без нищо, ул без точка и т.н.). След взетото решение тогава, изчистихме с една голяма баданарка (скриптче) тоя хаос.
Продължавам да поддържам мнението, че е по-важно да има един установен начин, отколкото кой точно. И затова смятам, че е добре да не се променя. А ако се промени, да се промени супер консеквентно, навсякъде. Но перфектно решение няма.
More generally, 