[OSM-talk] Transcription and 'internationalization' in place names
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
Re: [OSM-talk] Transcription and internationalization in place names
Am 16.04.2012 22:17, Miloš Komarčević: Hi all, On Mon, Apr 16, 2012 at 11:01 AM, Daniel Kastldan...@georepublic.de 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
On Tue, Apr 17, 2012 at 5:01 AM, Stephan Knauss o...@stephans-server.de 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
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
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
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
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 wendo...@uni-paderborn.dewrote: 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/talkhttp://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
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 talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Transcription and 'internationalization' in place names
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/talkhttp://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org
Re: [OSM-talk] Transcription and 'internationalization' in place names
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
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 a.erring...@lancaster.ac.ukwrote: 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
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 a.erring...@lancaster.ac.uk [9] 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
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
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
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 a.erring...@lancaster.ac.ukwrote: 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
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 Gardahttp://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. 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
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 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Transcription and internationalization in place names
On Mon, Apr 16, 2012 at 4:58 PM, Janko Mihelić jan...@gmail.com 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
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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Transcription and 'internationalization' in place names
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 p...@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
Re: [OSM-talk] Transcription and internationalization in place names
Hi all, On Mon, Apr 16, 2012 at 11:01 AM, Daniel Kastl dan...@georepublic.de 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
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+space+(+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
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
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
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
[OSM-talk] Transcription and internationalization in place names
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
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 claudiu...@gmx.de 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/talkhttp://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
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 iknowjos...@gmail.com: 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 claudiu...@gmx.de 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/talkhttp://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
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
