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.
Cheers, Joseph On 16 Apr 2012 20:03, "Philip Barnes" <[email protected]> wrote: > On Mon, 2012-04-16 at 14:26 +0200, Claudius wrote: > > Am 16.04.2012 11:36, Andrew Errington: > > > On Mon, April 16, 2012 16:54, Maarten Deen wrote: > > > <snip> > > >> Wouldn't it be an idea to tag the name in the characterset of the > > >> country and have the renderer decide whether or not to render a > name:en tag > > >> with the name tag? I don't know if the renderingrules allow such a > > >> decision to make. After all, the renderingrules decide how the map > looks > > >> like, and I can understand if countries that do not use latin script > want > > >> to render a "latin-clean" map. And: do not tag for the renderer. > Entering > > >> names twice is tagging for the renderer. > > >> > > > > > > I'm glad this topic has come up. I map heavily in Korea, and here the > > > convention has been adopted to have name=* as "Local name (English > name)". > > > This is the same as Japan, but I don't know which came first. In > > > addition we have name:en=* (Latin script) and name:ko=* (Hangul script) > > > and name:ko_rm=* (Hangul spelled phonetically, in Latin script). Not > all > > > tags are present for all objects. > > > > > > I have gone along with this for a while, but it has always bothered me. > > > On one hand, it's great as it actually makes the map useful (for me). > You > > > can even justify it by saying that the roadsigns are all printed in > Hangul > > > and English (they are) so maybe the name=* tag should have both. On > the > > > other hand, it's a chore to enter things twice, it increases the > > > opportunity for error, and really, it could be done programmatically. > > > > > > I think the root of the problem is that Mapnik didn't make a bilingual > map > > > at the start, so it was easier to get an army of humans to enter the > data > > > twice. Now we have better renderers, with a good example from > MapQuest, > > > and this experiment here: http://toolserver.org/~osm/locale/ > > > > > > I think the only problem is how does software determine which language > > > name=* is in. This should be the 'fallback' label that is rendered if > no > > > language is selected, or the selected language tag is missing. > Actually, > > > if you describe it in those terms then it doesn't matter. If my > selected > > > language is Korean, then name:ko=* will be displayed, thus overriding > > > name=*. If name:ko=* is missing, then name=* will (or should) contain > > > something useful. > > > > > > In Korea it is most useful (to Koreans and visitors) if we carry on as > we > > > do, but I would like a tool that automatically constructs > > > name="name:ko+<space>+(+name:en+)" > > > > 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 www.openstreetmap.org 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 www.openstreetmap.org, 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. > > > > It should actually be the other way around: > > In the ideal world we could (should?) strive for the location node for > > Seoul would contain this data: > > name=서울특별시 > > name:el=Σεούλ > > name:en=Seoul > > name:ko_rm=Seoulteukbyeolsi > > name:ru=Сеул > > > > 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. > > > > We should really not follow the approach of making the map at > > www.openstreetmap.org perfect but instead the data behind it because > > that's where we're better than Google and Co. > > > > And btw. Google Maps sometimes even has nur the Japanese location names > > and no problem with that either. See the airport and surroundings here: > > http://g.co/maps/4vu3e > > > > 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 www.openstreetmap.org > > > http://www.openstreetmap.org does seem to be rendering multiple names > for Welsh towns, separating them with a /. Hence giving the Welsh > Jubilee city of St Asaph as Llanelwy/St Asaph. Strangely the Welsh name > disappears at certain zoom levels, http://osm.org/go/eufQoa2--. > > It is using the tags name:cy and name:en. It works for a lot of places > in Wales, buy not for Cardiff. Maybe it can only cope with 2 languages. > > Phil > > > _______________________________________________ > talk mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/talk >
_______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
