Is it supported by the current renderers?
Mapnik? Osmarender? Mkgmap?
Even the “[short_name]” isn’t supported by Mkgmap, which makes navigating with a Garmin pretty challenging.
Using prefix and suffix as suggested earlier would make the db complete, and not interfere with the current renderers.
And this only one solution that would solve this issue to everyone’s satisfaction.
I’m sure we could come up with more solutions if we would put our minds to it.
Currently usability is quite limited in several aspects. Many of those problems (examples: multiple languages, correct rendering of multi-line rtl text, very high entry threshold before you can contribute) are either only software related, or require the support of both software tools and mappers to achieve a satisfactory solution. But with the correct tool support we will not sacrifice usability.
Can you please explain what do you mean by that sentence?
If you meant that is it ok to assume that every residential/unclassified street that does not start with “sderot”, “derech” etc. is a “rechov” - that is false.
For example, “Razif Herbert Samuel” in Tel Aviv has no “rechov” in its full name. But it would probably be too dangerous to assume that any street that starts with “Razif” has no “rechov” in the beginning of its full name.
If that was not your intention, then excuse me, and please explain.
I mean:
“Rehov” (or “Sdera”, or "Derech, for that matter) is not part of the name of the way.
You can see it as some feature (or “type”) of the way.
That means, that in a normalized DB, we will have a table of all way name features (rehov, derech, simta, etc.) and in the ways table, there will be a column that points to that table.
To bump this thread and see if we can agree on something specific I’ll try to summarize our reasons along with what seems to me a good compromise:
1. Always write in the ‘name’ tag the short Hebrew name, without Street, St. etc. This will give us clean & usable maps in the default renderers and make it easy for new users to get such maps.
2. Write the in the ‘name:he’ and ‘name:en’ tags the what is written on the street sign (full name including St, Blvd etc). This will allow us to have all the info in the DB for searches and other uses. It is also an easy guideline for new mappers to follow.
2.1. In case there are several signs with different versions write the fullest and best transliterated one according to the guidelines of the Hebrew Academy. Optionally just transliterate according to the guidelines assuming that the sign will also be corrected to follow them.
Note A: I don’t see a point to have the ‘name’ and ‘name:he’ tags carry exactly the same information.
Note B: I am more inclined to not use [] to mark the short version of the name. A good side of this idea for me is that it is a compact way of marking the short version. The negatives are that if we have a short Hebrew version in the ‘name’ tag there is no need to do that for ‘name:he’ and it looks to me as an additional complexity for new mappers to handle. I think it is better handled in a separate tag and left as optional.
3. Let’s write names for any other use in special tags which define the use clearly. I personally like the following tags:
name:en:short - for short English version
name:latinfont:pronunciation:en, name:latinfont:pronunciation:de, etc - for transcription of the ‘name’ tag in the respective language. The idea is to help English or German tourists pronounce the name correctly in the local language if they want to ask for directions.
Can you please comment / vote for each point and note separately - I hope we can agree at least on point 1. and 2.
I can live with point 1 and 2.
As long that we will have some kind of rule for everybody.
Point 3.
We have to think about more languages like for example Russian.
So “latinfont” will be a bit misleading. We have to have a better solution.
(Shouldnt we discuss this in another thread?)
Agree.
Ok.
Although we could make name:en have the shorter English name,
and name:en1 be the long english name.
Or maybe we could use loc_name:en for the short English name?
Agree.
Agree.
I stopped duplicating the name to name:he
I don’t like as it doesn’t work in all renderers, and is cumbersome.
I suggest we use loc_name.
e.g. loc_name:en loc_name:de loc_name:ru
Yeah, that’s a good point… now that you say it - if we are writhing transcriptions, may be they should be directly in the native writing and the tags should simply not contain latinfont:
name: הרצליה
name:pronunciation:en: Hertselia
name:pronunciation:bg: Херцелия
Russian is interesting here… it is probably:
loc_name:ru: Герцелия
name:pronunciation:ru: Херцелия
but I am digressing…
I am also not sure whether those shouldn’t be loc_name:pronunciation:[lang] because we are transcribing the local name. I like name:pronunciation better because you won’t start writing transcriptions for something else, but loc_name:pronunciation is more clear.
I agree
I find it strange. Why tanslate/transcribe ‘name’ tag, as ‘loc_name’?
Had we tagged Hebrew street names as ‘loc_name’, loc_name:xx would have been perfectly acceptable, but we are using ‘name’. and we might even use both ‘name’ and ‘loc_name’ for different names of the same object.
what a about:
name:trans:de ← name transliterated to german
or if we need more details:
By the way, I think only one transliteration to Latin script (mainly English-friendly) is sufficient per object.
We don’t need both name:trans:en=Binyamin and name:trans:de=Binjamin.
Multiple languages will be nicer where there is a different name per language.
name:en=Dead Sea name:de=Totes Meer
See the wiki: http://wiki.openstreetmap.org/wiki/Map_Features#Name
name = The common default name. (Note: For disputed areas, please use the name as displayed on e.g. street signs for the name tag. Put all alternatives into either localized name tags (e.g. name:tr/name:el) or the variants (e.g. loc_name/old_name/alt_name). Thank you.)
loc_name = Local name
Why invent this trans tag?
The existing standard tags cover all options.
I don’t believe there’s a need to transliterate e.g. the Arabic name, only the “name”, by definition should be transliterated, if anything.
I agree.
P.S.
When we reach a conclusion, we should add it to the wiki here: http://wiki.openstreetmap.org/wiki/Bilingual_street_names
The wiki here gives an example where name <> loc_name:
name=Channel Tunnel - Default name
int_name=Eurotunnel - Internationally known as
nat_name=That debt ridden hole in the ground - Nationally known As
reg_name=Gateway to France - Regionally known As
loc_name=The way to Carrefour - Locally known As
old_name=A long swim - Historically or previously known As
loc_name:xx should be loc_name in language xx, not name in language xx.
This is an alternative proposal for a new tag proposal: name:latinfont:pronunciation:en.
I only propose to use it if we plan to use a construct such as name:latinfont:pronunciation:en
Otherwise, forget it.
I beg to differ. Consider Brussels, where they tag everything as French and Dutch, the local languages. If I wanted that translated/transliterated into Hebrew, I’d want ONLY one of the two local languages on my map, I’d like to know from WHICH language my transliteration has originated from, and I should be able to choose, in case both languages were transliterated into Hebrew. Or consider Arab names, which may be different from the Hebrew names, and are no less “local”, especially in an Arab village. The tagging scheme should allow for the above, although we’d never use it…
I see the ‘name’ tag as the one which is rendered by default and not as the tag that should carry the standard name. If we decide that we put in the ‘name’ tag what we would generally put in the loc_name:he tag (see point 1 of the first post) we should consider that translating the ‘name’ tag is the same as translating the loc_name:he tag.
Yeah, but think about a real-life situation - you are in Brussels, you have both transliterations, and if you need them you obviously don’t know French or Dutch. You are asking a local in English about a street - which transliteration are you going to pick? How would you know if you are speaking to a French or Dutch, or what is the more commonly accepted name.
It is best if the person who is mapping the area makes that choice for the user. If we are mapping an Arab village, then most likely the Hebrew name is already a transliteration of the Arabic name, so we should just transliterate the Arabic name.
Otherwise name:trans:xx seems like the best choice so far - better than name:latinfont…
I don’t think we need to break hour heads over this though - most of the time, loc_name:xx tags would be quite sufficient. We need transliteration only when the translated name is very different from the local name - e.g. Dead Sea, Capernaum. Even then those are usually famous tourist places which would be know also by their English name.