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
Claudius
_______________________________________________
talk mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk
