keep it as simple as possible (no writing of 5 - 8 tags)
We have enough to do, by writing English AND Hebrew street names.
adding always “Street”,“St.”, “Road”,“Rd.”, etc. to the streetname, No matter if its short cutted or not.
Writing the main road name square braked makes things shown correct in all maps and the full name is still searchable.
So no reason to divide things in several tags ?!?
I suggest leaving out “street” (en) and “Rehov” (he) from the respective name tags,
and if someone wants them, then they can add it to residential streets.
Having a too long name with no (real) additional meaning makes the maps cumbersome.
I don’t believe people search with the road type.
i.e. people looking for a way named “Herzl” will not search for it using “rehov Herzl” or “derech Herzl”, or anything like that.
They would just search for “Herzl”
I hope you agree that a Herzl boulevard is not the same as a Herzl street …
So how could you find out the difference between it when searching?
I checked several streets in UK and Germany and there is ALWAYS the streetname with the postfix of the type (boulevard, gardens, way, street) in the name tag. No additional tags used.
And I don’t see a reason to keep Israel different than the countries that are mapped in a very detailed level.
Please remember that the actual renderer will change the name the following way when using squere brackets:
Name Tag => Result shown in Mapnik or Osmander
_________________________________________________________
"Theodor [Herzl] Street" => "Herzl"
"Moshe [Smilanski] St." => "Smilanski"
"David Ben [Gurion] Blv." => "Gurion"
You are asking who will ever search for “rehov Herzl” or “derech Herzl” instead of just Herzl.
I would! If I wouldn’t be so bad in Hebrew
In Israel (in contrast to the UK,) there are no 2 roads with the same name in the same city.
The only exception is “Bialik” and “Sderon Chen” in Tel Aviv, and I don’t believe people get confused by the them…
If anything, then sometimes the same name appearing in 2 different cities are actually a continuation of the same way.
e.g. Jabotinski in Ramat Gan, Bnei Brak, and Petah Tikva.
The UK have a history of multiple names in the same city, with different meaning.
In Germany, Strasse is part of the name, as this is how the language works in general.
In Israel, however, to my knowledge, there are no maps with “rehov” in them.
I would be happy to be corrected.
You know, in the UK and Germany they don’t write in Hebrew characters, so why do we write in Hebrew characters?!?..
(This was irony, but it just goes to show you that you can’t always compare.)
I believe we should compare ourselves to other Israeli maps, and not OSM maps of other countries,
if we want our map to be used by the general public.
We cannot invent our own standard, we have to use the local standard.
Recently we got some publicity (e.g. in Ynet last Sunday,) and people go in and check the map.
If the map doesn’t look like what people here are used to - They will not use it.
Here’s another example of the OSM map use in an Israeli site: http://www.shvoongmap.co.il (click on the “mapa” (he) button)
The renderer is not the only tool that needs to support the square brackets.
Mkgmap should support it as well.
If the street appears just ONE time in two city its worth it to write always Rehov in all street names.
Please don’t talk about standards when talking about Israeli maps.
The Israeli maps are normally written in Microsoft Standard for Internet Explorer. So I can’t even open them in my web- conform browser.
Once there was a searchengine website that was not created like a portal. It was just giving you a box for the search term and a “go” button.
This was not standard in those times. Today Google is THE STANDARD worldwide!
I aspect Israelies to be intelegent enough to understand the power of this project and that its a global project and not like “freemaps” a Only Israel one.
User will not avoid OSM because we are writing the streetname in a map like it is shown on the street sign.
AGAIN: The look of the map should not effect what information are saved in the street name.
We should always write down everything including the Rehov! No matter how it looks later in the map itself.
We will find a solution for this 'problem’of unneded information in a streetname later.
I suggest to have some kind of voting to finish this conversation with a official way of writing it down.
BTW: iGo, the favorit navigation software in Israel is also having all street written WITH Rehov, Derech.
If the map is cumbersome, and street names are truncated because “rehov” has to be written, then we achieve nothing,
even if the DB is complete.
To repeat my position:
I agree that the db should be as complete as possible,
but NOT on the expense of the usability of the map,
or by breaking basic IT rules, like having the data in the DB in a normalized way.
I’m not just talking about how maps are presented in the web.
I’m also talking about printed maps.
Look at (almost) any Israeli street atlas.
There is no “rehov” there, and for the time being, there are far more people using printed maps than online maps.
Again… you can ask to remove the rehov part of the name at renderer level.
So, I continue not to understand what is your problem to enter the full name in the database?
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?)
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 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:
name:trans:he_to_de <— hebrew name transliterated to german
name:trans:ar_to_de ← arabic name transliterated to german
-or-
name:he:trans:de <— name:he transliterated to german
name:ar:trans:de ← name:ar name transliterated to german
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
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.
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.
