>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.
Agreed, but if we improve the rendering at osm.org, 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 osm.org tiles will be able to. Once the rendering is tweaked to give the results people want, the data would be presumably cleaned up quite quickly. Joseph On 16 April 2012 13:26, Claudius <claudiu...@gmx.de> 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/<http://toolserver.org/%7Eosm/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 > > Claudius > > > > ______________________________**_________________ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.**org/listinfo/talk<http://lists.openstreetmap.org/listinfo/talk> >
_______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
