[OSM-talk] Transcription and "internationalization" in place names

[Peter Wendorff]

Am 16.04.2012 17:58, schrieb Janko Mihelic':
> Hello, this is a great topic!
>
> There is one more issue with internalization and names. Users tend to 
> add more than just names in "name=*" tags.
> For example "Lago di Garda" 
> <http://www.openstreetmap.org/browse/relation/8569>. If a machine 
> tried to turn that into English, it would be "Lake Lago di Garda", 
> which is not right because lago already means lake. Fortunately, 
> mappers put international tags, and the english one "name:en" says 
> Lake Garda. But now, if a machine isn't carefull it could say "lake 
> Lake Garda".
> Also it doesn't feel right to put "Lake" in front of all the lakes in 
> the World. A machine should do that.
If "Lake" is part of the name, it should be part of the name-tag, too.
Some examples, why it's necessary (and doesn't harm):
- Loch Ness is not called "Lake Loch Ness", but only "Loch Ness" - 
automatic addition of a "lake" prefix is wrong (here)
- In German we there are "See Genezareth" (the one in Israel) and 
"Bodensee", where See means lake.

=> software will always make errors with these additions, if it does not 
interpret the content of the name tag in the given language.
=> therefore the complete name should go into the name-tag - if the name 
contains "lake", it is part of the tag, too.
> Also lots of mappers put "School" in school names, "Airport" in 
> airport names, "Bay" in bay names, and so on..
Again:
- It's the "bay of Mexico" - omitting bay is wrong and useless - "of 
Mexico" is no name.
- The "Rocky Mountains" are called "rockies" in slang language perhaps, 
but "Rocky" is not the name of these mountains.
> My question is, should the renderer join "lake", "school" and 
> "airport" with their names? I think that would make users put in 
> cleaner data.
no, the render should not join that IMHO. But applications which want to 
identify the "type" of a POI may (!) add it - always or depending on the 
context.

regards
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20120416/5b59f1ab/attachment.html>