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
