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

[Volker Schmidt]

I picked up a message from another mailing list
(http://groups.google.com/group/bikemapde/topics), which maybe someone
following this thread can follow up:

The site Bikemap.de recently switched to OSM. In their mailing list I
picked up this complaint from a user in Taiwan:

"I am very disappointed with the new maps currently being used by
Bikemap. I live in Taiwan and these new maps not only omit important
data, such as road names and numbers, but the place names are in the
Hanyu Pinyin form of romanization and do not match the common signage
used in Taiwan. This adds one extra layer of complexity and difficulty
for most users. I hope Bikemaps can consider these problems and revert
to using a mapping software that can be more accurate and reflect the
local names as they are actually spelled."


Volker

-- 

Volker SCHMIDT
35127 Padova
Italy

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Claudius]

I'd like to bring this topic on the table once more as I've recently 
worked on that in the middle east area.
The challenge is that there are some mappers that add the English name 
to place names so that they (and other international visitors) can read 
the map at www.openstreetmap.org better. Most of the time this derives 
from the misconception that with OpenStreetMap you are editing a map, 
while in fact we are editing a database of geographic features and maps 
are just one representation of the data.


The rule about place names the majority of OSM participants have agreed 
on is "Use the name that is being used on the ground". Adding English as 
an easy to get latinized transliteraion is most of the time not 
following this rule.
Usually the best way to convince those users that it's unnecessary work 
and actually degrading the data quality is by simply pointing them 
towards a different map representation of the same data. MapQuest did a 
great job of showing an "English map view" (showing name:en as place 
name) while preserving local names (shown in brackets): 
http://open.mapquest.com/


I'd like to use my mail to raise awareness of this topic:
Please talk to you fellow mappers if you see them adding English names 
in an act of goodwill to help other visitors of www.openstreetmap.org


I'd also like to get some feedback especially from east asian countries 
(especially looking towards the japanese and korean communities here) if 
they want to revise their naming strategy/guideline to only have the 
local name in the name-tag and the transliteration in name:en


Also in Algeria, Libya and some other countries of the Maghreb the 
double name tagging has recently gained momentum, probably due to some 
remote mappers that cannot read arabic script and wanted to be able to 
read the map. Still the primary langauge in all those countries remains 
Arabic written in the arabic script.


I'm also aware that there are several examples where there are multiple 
primary languages in the same region: Belgium, Chad, Cameroon, etc. - Of 
course for these areas multilangual/multi script naming in the name-tag 
is applicable.


Claudius


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[John Sturdy]

On Mon, Apr 16, 2012 at 4:58 PM, Janko Mihelić  wrote:
> 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". 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.
>
> Also lots of mappers put "School" in school names, "Airport" in airport
> names, "Bay" in bay names, and so on..
>
> My question is, should the renderer join "lake", "school" and "airport" with
> their names? I think that would make users put in cleaner data.

I think that words like "lake", "school" etc are part of the name, and
should be in the data, and the renderer should present the name just
as it is in the data.  I don't think a machine could get this right.
For example, not all named instances of "natural=water" are called
"lakes" in English (e.g. "Windermere" is a name in its own right, and
does not need "Lake" prepended to it).

__John

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Philip Barnes]

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:
> > 
> >> 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++(+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 " 
> ()" as location name, or " ()" 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@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [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"  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:
> > > 
> > >> 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++(+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 "
> > ()" as location name, or " ()" 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 na

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

[Miloš Komarčević]

Hi all,

On Mon, Apr 16, 2012 at 11:01 AM, Daniel Kastl  wrote:
> name:ja_rm is probably what will not be rendered usually, but this would be
> the name written for example on street signs as name in latin characters.
> name:ja_kana is what was mentioned in a previous email, because it helps
> Japanese people to know the reading of a name. It's also useful for
> geocoding.
>

I would also like to take this opportunity to draw your attention to
the lack of unification on how 'romanized' language tags are used and
constructed for languages not usually written in Latin script.

'ja_rm' and 'zh_pinyin' are some examples

We strongly believe OSM should get behind and use BCP 47 as
recommended by W3C, Unicode, ECMA, etc.:

http://en.wikipedia.org/wiki/IETF_language_tag

and are already committed to retagging all our data in Serbia to 'sr'
and 'sr-Latn'.

Here is good historical article describing the rationale (note that
RFC 3066 is superseded by 5646):

http://icu-project.org/repos/icu/icuhtml/trunk/design/language_code_issues.html

Regards,
M

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Stephan Knauss]

Andrew Errington writes: 


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++(+name:en+)"


It is for map rendering. So the renderer should construct this. 

Good news is that Mapnik doe not need to be modified for this. It is just a 
modified query in the database. 

For the bilingual map of Thailand (and Laos, Cambodia, Vietnam) I did add a 
view to the database. That way I did not need to modify the style-file 
which makes it a lot easier to keep in sync with upstream. 

That view will return a custom string whenever mapnik asks for a name to 
put on the map.
In this case it will construct the bilingual name (if available) including 
a fallback in case no bilingual tagging is available: 

 case when (tags ? 'name:en') then case when (name != (tags->'name:en')) 
then name || ' ' || (tags->'name:en')  else  tags->'name:en' end else  name 
end AS name, 



As the name tag already contains the name in the local language no special 
handling is needed for this. 



In case you want to implement different rules for the name based on 
geographic boundaries you could replace the simple logic above with a piece 
of pgsql whick does the construction based on bounding box checks. 

You could also construct the bilingual label at the time of database import 
and store it in a separate column. Either by a modified import or using a 
trigger on the database. 



Stephan 






Best wishes, 

Andrew 



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Stephan Knauss]

Andrew Errington writes: 

In fact, I think that if name:ko=* is present, then it doesn't actually matter 
what is in name=*.  The definition of name=* then becomes subtly altered to 
mean "The label we use if no language is specified."  Then we can argue what 
goes into that label...


IMHO the definition of the name tag is fine. It says it's the name the 
*local* people call it. If the local people want some mixed spelling in 
that tag then, -well- it's their problem when doing other things with the 
data besides rendering a map. 

So the standard rendering should be a help for the *local* mappers and thus 
display their local name. 

If for tourists or other special cases a different rendering is required 
then it should be on a specialized map. 

For Thailand we do it like this. The local people can read the names on the 
map as a lot of expats who map here can do. 

For those who want to have latin script names we have a special rendering. 

As Mapquest does already provide a fallback to English, why not adapt the 
label on the main site to read "MapQuest open (bilingual)" to make it 
easier to find? 



Stephan

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Andrew Errington]

On Tue, April 17, 2012 10:31, Stephan Knauss wrote:
> Andrew Errington writes:
>
>
>> In fact, I think that if name:ko=* is present, then it doesn't actually
>> matter what is in name=*.  The definition of name=* then becomes subtly
>> altered to mean "The label we use if no language is specified."  Then we
>> can argue what goes into that label...
>
> IMHO the definition of the name tag is fine. It says it's the name the
> *local* people call it. If the local people want some mixed spelling in
> that tag then, -well- it's their problem when doing other things with the
> data besides rendering a map.
>
> So the standard rendering should be a help for the *local* mappers and
> thus display their local name.
>
> If for tourists or other special cases a different rendering is required
> then it should be on a specialized map.
>
> For Thailand we do it like this. The local people can read the names on
> the map as a lot of expats who map here can do.
>
> For those who want to have latin script names we have a special
> rendering.
>
> As Mapquest does already provide a fallback to English, why not adapt the
>  label on the main site to read "MapQuest open (bilingual)" to make it
> easier to find?

Ok, well I think it would make sense to always include a tag with the name
in the local language even if it is redundant with the name=* tag.  And in
fact that's exactly what we do in Korea and Japan.

Alternatively, is there a mechanism to link name=* and name:xx=*?

i.e. name:ko -> name  (or name -> name:ko)?

Then we only have to enter the information once, but we can answer the
question "What is the name of Seoul in Korean?" unambiguously.

Best wishes,

Andrew


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Stephan Knauss]

Andrew Errington writes: 


Alternatively, is there a mechanism to link name=* and name:xx=*?
Then we only have to enter the information once, but we can answer the
question "What is the name of Seoul in Korean?" unambiguously.


You can get the geographic location of a feature by checking whether it's 
inside a bounding polygon. So if you use the polygon for Korea you can tell 
whether a feature is in Korea or not.
Based on this decision you can have multiple rules on how to render names. 
You could for example have a different rule to construct the displayed name 
in Korea than in Japan. 


Stephan

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Pieren]

On Tue, Apr 17, 2012 at 5:01 AM, Stephan Knauss  wrote:
> You can get the geographic location of a feature by checking whether it's
> inside a bounding polygon. So if you use the polygon for Korea you can tell
> whether a feature is in Korea or not

The language iso code(s) could be stored in this polygon (usually the
boundary relation). Btw, we already have 200+ country codes ISO3166-1
(http://taginfo.openstreetmap.org/keys/ISO3166-1#values).

Pieren

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Claudius]

Am 16.04.2012 22:17, Miloš Komarčević:

Hi all,

On Mon, Apr 16, 2012 at 11:01 AM, Daniel Kastl  wrote:

name:ja_rm is probably what will not be rendered usually, but this would be
the name written for example on street signs as name in latin characters.
name:ja_kana is what was mentioned in a previous email, because it helps
Japanese people to know the reading of a name. It's also useful for
geocoding.



I would also like to take this opportunity to draw your attention to
the lack of unification on how 'romanized' language tags are used and
constructed for languages not usually written in Latin script.

'ja_rm' and 'zh_pinyin' are some examples

We strongly believe OSM should get behind and use BCP 47 as
recommended by W3C, Unicode, ECMA, etc.:

http://en.wikipedia.org/wiki/IETF_language_tag

and are already committed to retagging all our data in Serbia to 'sr'
and 'sr-Latn'.


+1

Would be great to get the tagging guidelines accordingly.

Claudius


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Joseph Reeves]

Hi Claudius, list,

Thanks for bringing this up as it is by far my favourite OSM issue; there
can't be many examples of such widespread bad mapping practices. I've done
remote mapping in the Middle East and North Africa which is the background
I use to base my opinions on. I'm not aware of the issues in the Far East,
but I imagine that there are a number of similarities with examples from
the Arabic world.

Thanks also for pointing out the example of open.mapquest.org - that looks
like a really good way of handling this. I've previously said that more
localised maps would help, but presumably they'd consume much more
resources than simply tweaking the osm.org home page. Perhaps a bug
reported should be submitted requesting that all names are rendered as the
contents of name= whilst followed by name:en= (or int_name=) in brackets
when different.

Cheers, Joseph



On 15 April 2012 16:47, Claudius  wrote:

> I'd like to bring this topic on the table once more as I've recently
> worked on that in the middle east area.
> The challenge is that there are some mappers that add the English name to
> place names so that they (and other international visitors) can read the
> map at www.openstreetmap.org better. Most of the time this derives from
> the misconception that with OpenStreetMap you are editing a map, while in
> fact we are editing a database of geographic features and maps are just one
> representation of the data.
>
> The rule about place names the majority of OSM participants have agreed on
> is "Use the name that is being used on the ground". Adding English as an
> easy to get latinized transliteraion is most of the time not following this
> rule.
> Usually the best way to convince those users that it's unnecessary work
> and actually degrading the data quality is by simply pointing them towards
> a different map representation of the same data. MapQuest did a great job
> of showing an "English map view" (showing name:en as place name) while
> preserving local names (shown in brackets): http://open.mapquest.com/
>
> I'd like to use my mail to raise awareness of this topic:
> Please talk to you fellow mappers if you see them adding English names in
> an act of goodwill to help other visitors of www.openstreetmap.org
>
> I'd also like to get some feedback especially from east asian countries
> (especially looking towards the japanese and korean communities here) if
> they want to revise their naming strategy/guideline to only have the local
> name in the name-tag and the transliteration in name:en
>
> Also in Algeria, Libya and some other countries of the Maghreb the double
> name tagging has recently gained momentum, probably due to some remote
> mappers that cannot read arabic script and wanted to be able to read the
> map. Still the primary langauge in all those countries remains Arabic
> written in the arabic script.
>
> I'm also aware that there are several examples where there are multiple
> primary languages in the same region: Belgium, Chad, Cameroon, etc. - Of
> course for these areas multilangual/multi script naming in the name-tag is
> applicable.
>
> Claudius
>
>
> __**_
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Shu Higashi]

Hi Claudius,

We discussed on this topic several months ago in Japasnese community.
A community menber claimed not to add Romanized Japanes with blackets
just as you said.
But, our conclusion is to keep on adding Romanized Japanes with
brackets as bellow:
name=馬橋 (Mabashi)

The main reason why we decided to keep adding Romanized Japanes is
beacause most OSM viewer applications do not have the function to
switch languages.
So, we think it is better mainly for foreigners who visited Japan and
wanted to use OSM in Japan.

IMHO, It's also a matter of phonetics.
One need to pronounce a place name when he wanted to ask other people
how to go there.
Romanized Japanese is not a foreign language but a pronunciation of
the place name using latin characters.
It's also useful for us Japanese because we have several
pronunciations per one character.

For example, the character "馬" have 4 pronunciations ma, me, ba, and uma.
So sometimes we cannot pronounce a place name correctly without
phonetic expressions.

Shu Higashi


2012/4/16, Joseph Reeves :
> Hi Claudius, list,
>
> Thanks for bringing this up as it is by far my favourite OSM issue; there
> can't be many examples of such widespread bad mapping practices. I've done
> remote mapping in the Middle East and North Africa which is the background
> I use to base my opinions on. I'm not aware of the issues in the Far East,
> but I imagine that there are a number of similarities with examples from
> the Arabic world.
>
> Thanks also for pointing out the example of open.mapquest.org - that looks
> like a really good way of handling this. I've previously said that more
> localised maps would help, but presumably they'd consume much more
> resources than simply tweaking the osm.org home page. Perhaps a bug
> reported should be submitted requesting that all names are rendered as the
> contents of name= whilst followed by name:en= (or int_name=) in brackets
> when different.
>
> Cheers, Joseph
>
>
>
> On 15 April 2012 16:47, Claudius  wrote:
>
>> I'd like to bring this topic on the table once more as I've recently
>> worked on that in the middle east area.
>> The challenge is that there are some mappers that add the English name to
>> place names so that they (and other international visitors) can read the
>> map at www.openstreetmap.org better. Most of the time this derives from
>> the misconception that with OpenStreetMap you are editing a map, while in
>> fact we are editing a database of geographic features and maps are just
>> one
>> representation of the data.
>>
>> The rule about place names the majority of OSM participants have agreed on
>> is "Use the name that is being used on the ground". Adding English as an
>> easy to get latinized transliteraion is most of the time not following
>> this
>> rule.
>> Usually the best way to convince those users that it's unnecessary work
>> and actually degrading the data quality is by simply pointing them towards
>> a different map representation of the same data. MapQuest did a great job
>> of showing an "English map view" (showing name:en as place name) while
>> preserving local names (shown in brackets): http://open.mapquest.com/
>>
>> I'd like to use my mail to raise awareness of this topic:
>> Please talk to you fellow mappers if you see them adding English names in
>> an act of goodwill to help other visitors of www.openstreetmap.org
>>
>> I'd also like to get some feedback especially from east asian countries
>> (especially looking towards the japanese and korean communities here) if
>> they want to revise their naming strategy/guideline to only have the local
>> name in the name-tag and the transliteration in name:en
>>
>> Also in Algeria, Libya and some other countries of the Maghreb the double
>> name tagging has recently gained momentum, probably due to some remote
>> mappers that cannot read arabic script and wanted to be able to read the
>> map. Still the primary langauge in all those countries remains Arabic
>> written in the arabic script.
>>
>> I'm also aware that there are several examples where there are multiple
>> primary languages in the same region: Belgium, Chad, Cameroon, etc. - Of
>> course for these areas multilangual/multi script naming in the name-tag is
>> applicable.
>>
>> Claudius
>>
>>
>> __**_
>> talk mailing list
>> talk@openstreetmap.org
>> http://lists.openstreetmap.**org/listinfo/talk
>>
>

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Stephan Knauss]

Claudius writes: 

Also in Algeria, Libya and some other countries of the Maghreb the double 
name tagging has recently gained momentum, probably due to some remote 
mappers that cannot read arabic script and wanted to be able to read the 
map. Still the primary langauge in all those countries remains Arabic 
written in the arabic script.


When the crisis in Libya started to heat up I was asked if I could provide 
bilingual rendering which is still online on http://libya.osm-tools.org/ 

Is this of use for anybody? If no one cares for the bilingual rendering I 
might stop serving the map as my machine is quite small.
If now even mapquest is providing bilingual rendering then having mine 
might be obsolete by now. 



I will still continue with the thaimap.osm-tools.org for Thailand and the 
surrounding asian countries. That map required a bit more tweaking of the 
style to get readable names (the fontsize on osm.org is way too small) 


Stephan

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Claudius]

Am 16.04.2012 06:33, Stephan Knauss:

When the crisis in Libya started to heat up I was asked if I could
provide bilingual rendering which is still online on
http://libya.osm-tools.org/
Is this of use for anybody? If no one cares for the bilingual rendering
I might stop serving the map as my machine is quite small.
If now even mapquest is providing bilingual rendering then having mine
might be obsolete by now.


Your rendering is a very good example showing where the duplication 
takes place if multiple scripts are entered into the primary name-tag.
e.g. west of Tripoli you see the place node for "Surman" showing the 
English name three times.
I think with the availability of the MapQuest rendering and the recent 
decrease in interest in mapping Libya you might consider turning your's off.

I did use it quite heavily a while ago though. Thanks for that.

Claudius


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Maarten Deen]

On 2012-04-16 08:32, Claudius wrote:

Am 16.04.2012 06:33, Stephan Knauss:

When the crisis in Libya started to heat up I was asked if I could
provide bilingual rendering which is still online on
http://libya.osm-tools.org/
Is this of use for anybody? If no one cares for the bilingual 
rendering

I might stop serving the map as my machine is quite small.
If now even mapquest is providing bilingual rendering then having 
mine

might be obsolete by now.


Your rendering is a very good example showing where the duplication
takes place if multiple scripts are entered into the primary 
name-tag.

e.g. west of Tripoli you see the place node for "Surman" showing the
English name three times.
I think with the availability of the MapQuest rendering and the
recent decrease in interest in mapping Libya you might consider
turning your's off.
I did use it quite heavily a while ago though. Thanks for that.


Surman seems to be a bug. The name tag is "Surman صرمان Surman".

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.


Maarten


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Peter Wendorff]

Am 16.04.2012 09:54, schrieb Maarten Deen:
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 think it's a simple task to decide from the unicode 
representation of osm tags about the character set of the country, as 
it's not "encoded" in that way.

name:en might additionally not be what we want internationally.
Let's take Beijing as an example:
- it's something in chinese glyphs as a local name (and I'm not sure, if 
there aren't several variants even in chinese
- in Germany it's called "Peking", which originates in south china 
(according to wikipedia)

- Gaeilge language uses Béising
- Italians use Pechino

In this case English seems to use the "right" transcription "Beijing", 
but I'm sure there are other cases, where English (or at least British 
English) uses a more "customized" version, e.g. from colonialism.
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.

+10

regards
Peter

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Andrew Errington]

On Mon, April 16, 2012 16:54, Maarten Deen wrote:

> 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++(+name:en+)"

Best wishes,

Andrew


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Daniel Kastl]

I think Japanese names are a good example how complex name tags can be, see:
http://wiki.openstreetmap.org/wiki/Japan_tagging#Names

There are altogether listed 5 tags for a name: name:ja_rm or name:en are
what you can read without knowing Japanese characters.
name:ja_rm is probably what will not be rendered usually, but this would be
the name written for example on street signs as name in latin characters.
name:ja_kana is what was mentioned in a previous email, because it helps
Japanese people to know the reading of a name. It's also useful for
geocoding.

Daniel


On Mon, Apr 16, 2012 at 5:18 PM, Peter Wendorff
wrote:

> Am 16.04.2012 09:54, schrieb Maarten Deen:
>
>> 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 think it's a simple task to decide from the unicode representation
> of osm tags about the character set of the country, as it's not "encoded"
> in that way.
> name:en might additionally not be what we want internationally.
> Let's take Beijing as an example:
> - it's something in chinese glyphs as a local name (and I'm not sure, if
> there aren't several variants even in chinese
> - in Germany it's called "Peking", which originates in south china
> (according to wikipedia)
> - Gaeilge language uses Béising
> - Italians use Pechino
>
> In this case English seems to use the "right" transcription "Beijing", but
> I'm sure there are other cases, where English (or at least British English)
> uses a more "customized" version, e.g. from colonialism.
>
>> 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.
>>
> +10
>
> regards
> Peter
>
> __**_
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk
>



-- 
Georepublic UG & Georepublic Japan
eMail: daniel.ka...@georepublic.de
Web: http://georepublic.de
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Claudius]

Am 16.04.2012 11:36, Andrew Errington:

On Mon, April 16, 2012 16:54, Maarten Deen wrote:


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++(+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 " 
()" as location name, or " ()" 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

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

[Joseph Reeves]

 >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  wrote:

> Am 16.04.2012 11:36, Andrew Errington:
>
>  On Mon, April 16, 2012 16:54, Maarten Deen wrote:
>> 
>>
>>> 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++(+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 "
> ()" as location name, or " ()" 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
>

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

[Andrew Errington]

On Mon, 16 Apr 2012 21:40:40 Joseph Reeves wrote:
>  >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.

Absolutely!  And I think that this particular issue could be cleaned up 
automatically by a 'bot, with an exception report sent to the 
country-specific talk mailing list for anything that needs to be handled 
manually.

The reason that Japan and Korea have bilingual labels is because mappers want 
it that way.  Since Mapnik did not provide it, they did it themselves.  Now 
newer software is capable of doing automatically, so we should revisit the 
issue.

Should I simply open a ticket on Mapnik's issue tracker, to request that in 
Korea, labels be rendered as "name:ko (name:en)"?

On a related note, and using Claudius's example:

name=서울특별시
name:el=Σεούλ
name:en=Seoul
name:ko_rm=Seoulteukbyeolsi
name:ru=Сеул

Should we add name:ko=서울특별시?

Otherwise, how do we know the Korean name for this city?

Best wishes,

Andrew

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Joseph Reeves]

>Should I simply open a ticket on Mapnik's issue tracker, to request that in
>Korea, labels be rendered as "name:ko (name:en)"?

I think we should request for a international solution rather than Korea
specifically, but yes, I like the idea. Claudius points out that:

>I guess you are referring to the map rendering at www.openstreetmap.orgbecause 
>MapQuest is also using Mapnik to >render their open map

I don't know if MapQuest have submitted their changes upstream to Mapnik,
but regardless of this, the same functionality should be requested on the
osm.org Mapnik instance.

As for Korea:

>Should we add name:ko=서울특별시?
>Otherwise, how do we know the Korean name for this city?

It seems to me that adding name:ko is duplicating data. We should be using
the local names for the name: tag, so the Korean can go in there. I would
then have this rendered as "name= (name:en=)" on the osm.org mapnik tiles.
Such a system could presumably be used worldwide (although I'm sure there
are plenty of people that would disagree). Having said that, adding
name:ko= isn't going to hurt and may be of use to other data consumers.

All best, Joseph



On 16 April 2012 13:58, Andrew Errington wrote:

> On Mon, 16 Apr 2012 21:40:40 Joseph Reeves wrote:
> >  >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.
>
> Absolutely!  And I think that this particular issue could be cleaned up
> automatically by a 'bot, with an exception report sent to the
> country-specific talk mailing list for anything that needs to be handled
> manually.
>
> The reason that Japan and Korea have bilingual labels is because mappers
> want
> it that way.  Since Mapnik did not provide it, they did it themselves.  Now
> newer software is capable of doing automatically, so we should revisit the
> issue.
>
> Should I simply open a ticket on Mapnik's issue tracker, to request that in
> Korea, labels be rendered as "name:ko (name:en)"?
>
> On a related note, and using Claudius's example:
>
> name=서울특별시
> name:el=Σεούλ
> name:en=Seoul
> name:ko_rm=Seoulteukbyeolsi
> name:ru=Сеул
>
> Should we add name:ko=서울특별시?
>
> Otherwise, how do we know the Korean name for this city?
>
> Best wishes,
>
> Andrew
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Maarten Deen]

On 2012-04-16 14:15, Joseph Reeves wrote:


As for Korea:


Should we add name:ko=서울특별시?

 >Otherwise, how do we know the Korean name for this city?

It seems to me that adding name:ko is duplicating data. We should be
using the local names for the name: tag, so the Korean can go in
there. I would then have this rendered as "name= (name:en=)" on the
osm.org [8] mapnik tiles. Such a system could presumably be used
worldwide (although I'm sure there are plenty of people that would
disagree). Having said that, adding name:ko= isn't going to hurt and
may be of use to other data consumers.


Hopefully with worldwide you mean only the countries that do not use 
latin script. It would not be pretty to see München (Munich) or worse: 
Bruxelles - Brussel (Brussels).


Regards,
Maarten




On 16 April 2012 13:58, Andrew Errington  wrote:


On Mon, 16 Apr 2012 21:40:40 Joseph Reeves wrote:
>  >We should really not follow the approach of making the map at
>
> www.openstreetmap.org [1] 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 [2], 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 [3] 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.

Absolutely!  And I think that this particular issue could be
cleaned up
automatically by a 'bot, with an exception report sent to the
country-specific talk mailing list for anything that needs to be
handled
manually.

The reason that Japan and Korea have bilingual labels is because
mappers want
it that way.  Since Mapnik did not provide it, they did it
themselves.  Now
newer software is capable of doing automatically, so we should
revisit the
issue.

Should I simply open a ticket on Mapnik's issue tracker, to request
that in
Korea, labels be rendered as "name:ko (name:en)"?

On a related note, and using Claudius's example:

name=서울특별시
name:el=Σεούλ
name:en=Seoul
name:ko_rm=Seoulteukbyeolsi
name:ru=Сеул

Should we add name:ko=서울특별시?

Otherwise, how do we know the Korean name for this city?

Best wishes,

Andrew

___
talk mailing list
talk@openstreetmap.org [4]
http://lists.openstreetmap.org/listinfo/talk [5]




Links:
--
[1] http://www.openstreetmap.org
[2] http://osm.org
[3] http://osm.org
[4] mailto:talk@openstreetmap.org
[5] http://lists.openstreetmap.org/listinfo/talk
[6] http://www.openstreetmap.org
[7] http://osm.org
[8] http://osm.org
[9] mailto:a.erring...@lancaster.ac.uk



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Andrew Errington]

On Mon, 16 Apr 2012 22:32:14 Maarten Deen wrote:
> On 2012-04-16 14:15, Joseph Reeves wrote:
> > As for Korea:
> >>Should we add name:ko=서울특별시?
> >>
> >  >Otherwise, how do we know the Korean name for this city?
> >
> > It seems to me that adding name:ko is duplicating data. We should be
> > using the local names for the name: tag, so the Korean can go in
> > there. I would then have this rendered as "name= (name:en=)" on the
> > osm.org [8] mapnik tiles. Such a system could presumably be used
> > worldwide (although I'm sure there are plenty of people that would
> > disagree). Having said that, adding name:ko= isn't going to hurt and
> > may be of use to other data consumers.
>
> Hopefully with worldwide you mean only the countries that do not use
> latin script. It would not be pretty to see München (Munich) or worse:
> Bruxelles - Brussel (Brussels).

I would love to be able to see a map with München (Munich) on it.  I am going 
there on vacation, but I don't speak German.  It would be handy to know the 
real name for the places I only know the English name of.

I'm not advocating this for 'Standard' map tiles at osm.org, but some feature 
from some map service whereby I can get a nice map labelled with one or two 
languages of my choice.

Best wishes,

Andrew

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Andrew Errington]

On Mon, 16 Apr 2012 22:15:38 you wrote:
> >Should I simply open a ticket on Mapnik's issue tracker, to request that
> > in Korea, labels be rendered as "name:ko (name:en)"?
>
> I think we should request for a international solution rather than Korea
> specifically, but yes, I like the idea.

Well, the international solution might be to make name=* be "name:ko 
(name:en)", or "name:xx (name:yy)" which is where we started...

I am using Korea as an example, but I am thinking about whether my suggestions 
would boil down to a generic rule that would apply anywhere.

> Claudius points out that:
> >I guess you are referring to the map rendering at
> > www.openstreetmap.orgbecause MapQuest is also using Mapnik to >render
> > their open map

Yes, indeed.  I meant the Mapnik render on osm.org, which has now been renamed 
to 'Standard'.  I will try to use that in the future.

> I don't know if MapQuest have submitted their changes upstream to Mapnik,
> but regardless of this, the same functionality should be requested on the
> osm.org Mapnik instance.
>
> As for Korea:
> >Should we add name:ko=서울특별시?
> >Otherwise, how do we know the Korean name for this city?
>
> It seems to me that adding name:ko is duplicating data. We should be using
> the local names for the name: tag, so the Korean can go in there. I would
> then have this rendered as "name= (name:en=)" on the osm.org mapnik tiles.
> Such a system could presumably be used worldwide (although I'm sure there
> are plenty of people that would disagree). Having said that, adding
> name:ko= isn't going to hurt and may be of use to other data consumers.

Well, if we *don't* include name:ko=* (for objects in Korea) then we have to 
assume that name=* is Korean.  Once we start making assumptions then we 
become sad.  I think it's better to be explicit.

In fact, I think that if name:ko=* is present, then it doesn't actually matter 
what is in name=*.  The definition of name=* then becomes subtly altered to 
mean "The label we use if no language is specified."  Then we can argue what 
goes into that label...

Best wishes,

Andrew

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Joseph Reeves]

>I would love to be able to see a map with München (Munich) on it.  I am
going
>there on vacation, but I don't speak German.  It would be handy to know the
>real name for the places I only know the English name of.

Exactly what I was thinking.

Copying the idea of open.mapquest.co.uk would work, I think. The only
change I would like would be to have the local name before the English.

"Brussels (Bruxelles - Brussel)" does look messy, but "Vienna (Wien)" is
great.

Cheers, Joseph



On 16 April 2012 14:47, Andrew Errington wrote:

> On Mon, 16 Apr 2012 22:32:14 Maarten Deen wrote:
> > On 2012-04-16 14:15, Joseph Reeves wrote:
> > > As for Korea:
> > >>Should we add name:ko=서울특별시?
> > >>
> > >  >Otherwise, how do we know the Korean name for this city?
> > >
> > > It seems to me that adding name:ko is duplicating data. We should be
> > > using the local names for the name: tag, so the Korean can go in
> > > there. I would then have this rendered as "name= (name:en=)" on the
> > > osm.org [8] mapnik tiles. Such a system could presumably be used
> > > worldwide (although I'm sure there are plenty of people that would
> > > disagree). Having said that, adding name:ko= isn't going to hurt and
> > > may be of use to other data consumers.
> >
> > Hopefully with worldwide you mean only the countries that do not use
> > latin script. It would not be pretty to see München (Munich) or worse:
> > Bruxelles - Brussel (Brussels).
>
> I would love to be able to see a map with München (Munich) on it.  I am
> going
> there on vacation, but I don't speak German.  It would be handy to know the
> real name for the places I only know the English name of.
>
> I'm not advocating this for 'Standard' map tiles at osm.org, but some
> feature
> from some map service whereby I can get a nice map labelled with one or two
> languages of my choice.
>
> Best wishes,
>
> Andrew
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

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

[Janko Mihelić]

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".
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.

Also lots of mappers put "School" in school names, "Airport" in airport
names, "Bay" in bay names, and so on..

My question is, should the renderer join "lake", "school" and "airport"
with their names? I think that would make users put in cleaner data.

Janko Mihelić
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [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" 
. 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
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk