<p>Have you checked the data and history on the actual nodes? Often you're seeing the results of an edit war - the names keep changing but low zoom level tiles aren't updated often enough to keep up. Syria, Egypt, etc, suffer the same.</p>

<p>Cheers, Joseph</p>
<div class="gmail_quote">On 16 Apr 2012 20:03, "Philip Barnes" <<a href="mailto:phil@trigpoint.me.uk">phil@trigpoint.me.uk</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, 2012-04-16 at 14:26 +0200, Claudius wrote:<br>
> Am 16.04.2012 11:36, Andrew Errington:<br>
> > On Mon, April 16, 2012 16:54, Maarten Deen wrote:<br>
> > <snip><br>
> >> 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>
> ><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/~osm/locale/" target="_blank">http://toolserver.org/~osm/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:en+)"<br>
><br>
> You raised some very good points here, Andrew, but again you came back<br>
> to the argument, that "Mapnik" (I guess you are referring to the map<br>
> rendering at <a href="http://www.openstreetmap.org" target="_blank">www.openstreetmap.org</a> because MapQuest is also using Mapnik<br>
> to render their open map ;) ) should be made a bilingual map. Still in<br>
> the code OSM is not about the map at <a href="http://www.openstreetmap.org" target="_blank">www.openstreetmap.org</a>, but about<br>
> the database behind it that hundreds of other projects use. e.g. if you<br>
> create a Garmin map file out of the korean (or even japanese) data it<br>
> seems to be rather harmful to have the Romanization in brackets behind<br>
> the name. If you would want to create a Korean/Japanese only map you<br>
> would have to programmatically remove the brackets if name:ko/name:jp is<br>
> 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<br>
> 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><br>
> (<name:en>)" as location name, or "<name> (<name:ko_rm>)" to highlight<br>
> romanization to be helpful for korean users.<br>
><br>
> We should really not follow the approach of making the map at<br>
> <a href="http://www.openstreetmap.org" target="_blank">www.openstreetmap.org</a> perfect but instead the data behind it because<br>
> that's where we're better than Google and Co.<br>
><br>
> And btw. Google Maps sometimes even has nur the Japanese location names<br>
> and no problem with that either. See the airport and surroundings here:<br>
> <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<br>
> opener to emphasize on the data quality aspect and away from tagging for<br>
> a nice <a href="http://www.openstreetmap.org" target="_blank">www.openstreetmap.org</a><br>
><br>
<a href="http://www.openstreetmap.org" target="_blank">http://www.openstreetmap.org</a> does seem to be rendering multiple names<br>
for Welsh towns, separating them with a /. Hence giving the Welsh<br>
Jubilee city of St Asaph as Llanelwy/St Asaph. Strangely the Welsh name<br>
disappears at certain zoom levels, <a href="http://osm.org/go/eufQoa2--" target="_blank">http://osm.org/go/eufQoa2--</a>.<br>
<br>
It is using the tags name:cy and name:en. It works for a lot of places<br>
in Wales, buy not for Cardiff. Maybe it can only cope with 2 languages.<br>
<br>
Phil<br>
<br>
<br>
_______________________________________________<br>
talk mailing list<br>
<a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk" target="_blank">http://lists.openstreetmap.org/listinfo/talk</a><br>
</blockquote></div>