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

[Joseph Reeves]

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" <phil at trigpoint.me.uk> 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
> talk at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20120416/65098e6a/attachment.html>