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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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,
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
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
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
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
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
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
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
27 matches
Mail list logo
