>We should really not follow the approach of making the map at <a href="http://www.openstreetmap.org" target="_blank">www.openstreetmap.org</a> perfect but instead the data >behind it because that's where we're better than Google and Co.<br>
<br>Agreed, but if we improve the rendering at <a href="http://osm.org">osm.org</a>, we should be able to highlight the issue that some users are filling the database with nonsense names. At the same time, the people that want to see "name= (name:en=)" on their <a href="http://osm.org">osm.org</a> tiles will be able to.<br>
<br>Once the rendering is tweaked to give the results people want, the data would be presumably cleaned up quite quickly.<br><br>Joseph<br><br><br><br><br><div class="gmail_quote">On 16 April 2012 13:26, Claudius <span dir="ltr"><<a href="mailto:claudius.h@gmx.de">claudius.h@gmx.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Am 16.04.2012 11:36, Andrew Errington:<div><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, April 16, 2012 16:54, Maarten Deen wrote:<br>
<snip><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Wouldn't it be an idea to tag the name in the characterset of the<br>
country and have the renderer decide whether or not to render a name:en tag<br>
with the name tag? I don't know if the renderingrules allow such a<br>
decision to make. After all, the renderingrules decide how the map looks<br>
like, and I can understand if countries that do not use latin script want<br>
to render a "latin-clean" map. And: do not tag for the renderer. Entering<br>
names twice is tagging for the renderer.<br>
<br>
</blockquote>
<br>
I'm glad this topic has come up.  I map heavily in Korea, and here the<br>
convention has been adopted to have name=* as "Local name (English name)".<br>
  This is the same as Japan, but I don't know which came first.  In<br>
addition we have name:en=* (Latin script) and name:ko=* (Hangul script)<br>
and name:ko_rm=* (Hangul spelled phonetically, in Latin script).  Not all<br>
tags are present for all objects.<br>
<br>
I have gone along with this for a while, but it has always bothered me.<br>
On one hand, it's great as it actually makes the map useful (for me).  You<br>
can even justify it by saying that the roadsigns are all printed in Hangul<br>
and English (they are) so maybe the name=* tag should have both.  On the<br>
other hand, it's a chore to enter things twice, it increases the<br>
opportunity for error, and really, it could be done programmatically.<br>
<br>
I think the root of the problem is that Mapnik didn't make a bilingual map<br>
at the start, so it was easier to get an army of humans to enter the data<br>
twice.  Now we have better renderers, with a good example from MapQuest,<br>
and this experiment here: <a href="http://toolserver.org/%7Eosm/locale/" target="_blank">http://toolserver.org/~osm/<u></u>locale/</a><br>
<br>
I think the only problem is how does software determine which language<br>
name=* is in.  This should be the 'fallback' label that is rendered if no<br>
language is selected, or the selected language tag is missing.  Actually,<br>
if you describe it in those terms then it doesn't matter.  If my selected<br>
language is Korean, then name:ko=* will be displayed, thus overriding<br>
name=*.  If name:ko=* is missing, then name=* will (or should) contain<br>
something useful.<br>
<br>
In Korea it is most useful (to Koreans and visitors) if we carry on as we<br>
do, but I would like a tool that automatically constructs<br>
name="name:ko+<space>+(+name:<u></u>en+)"<br>
</blockquote>
<br></div></div>
You raised some very good points here, Andrew, but again you came back to the argument, that "Mapnik" (I guess you are referring to the map rendering at <a href="http://www.openstreetmap.org" target="_blank">www.openstreetmap.org</a> because MapQuest is also using Mapnik to render their open map ;) ) should be made a bilingual map. Still in the code OSM is not about the map at <a href="http://www.openstreetmap.org" target="_blank">www.openstreetmap.org</a>, but about the database behind it that hundreds of other projects use. e.g. if you create a Garmin map file out of the korean (or even japanese) data it seems to be rather harmful to have the Romanization in brackets behind the name. If you would want to create a Korean/Japanese only map you would have to programmatically remove the brackets if name:ko/name:jp is not present.<br>

<br>
It should actually be the other way around:<br>
In the ideal world we could (should?) strive for the location node for Seoul would contain this data:<br>
name=서울특별시<br>
name:el=Σεούλ<br>
name:en=Seoul<br>
name:ko_rm=Seoulteukbyeolsi<br>
name:ru=Сеул<br>
<br>
So a map renderer could easily recreate the current map by using "<name> (<name:en>)" as location name, or "<name> (<name:ko_rm>)" to highlight romanization to be helpful for korean users.<br>

<br>
We should really not follow the approach of making the map at <a href="http://www.openstreetmap.org" target="_blank">www.openstreetmap.org</a> perfect but instead the data behind it because that's where we're better than Google and Co.<br>

<br>
And btw. Google Maps sometimes even has nur the Japanese location names and no problem with that either. See the airport and surroundings here: <a href="http://g.co/maps/4vu3e" target="_blank">http://g.co/maps/4vu3e</a><br>

<br>
Just take another look at the Mapquest rendering. For me it was an eye opener to emphasize on the data quality aspect and away from tagging for a nice <a href="http://www.openstreetmap.org" target="_blank">www.openstreetmap.org</a><span class="HOEnZb"><font color="#888888"><br>

<br>
Claudius</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
talk mailing list<br>
<a href="mailto:talk@openstreetmap.org" target="_blank">talk@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk" target="_blank">http://lists.openstreetmap.<u></u>org/listinfo/talk</a><br>
</div></div></blockquote></div><br>