[Tagging] Feature Proposal - Voting - Language information - Closed

Christoph Hormann osm at imagico.de
Wed Sep 13 11:38:04 UTC 2017


On Wednesday 13 September 2017, Lukas Sommer wrote:
>
> The reasons for negative vote were various and did not go in only one
> direction. I do not know how these different positons can be
> reconciled. So I will do no further proposals.
>
> Anyway this remains an issue in OSM: Rendering OSM data currently
> does not work correctly for labels that are affected by Han
> unification (and, to a minor degree, cyrillic).

I think a significant part of the problem is that both your proposals 
were specifically targeted to make things easier for rendering.  Which 
is both something that many mappers despise (for good reasons) and not 
an ideal pre-condition to develop a good mapper-centric tagging 
proposal.

I don't want to warm up the discussion on the matter again but a huge 
part of the problem of Han unification can be solved for rendering by 
using corresponding defaults based on geolocation.  This is not perfect 
and can pose some difficulties to rendering workflows but that is not a 
good reason for put heavy workload on mappers.  Once you accept that 
99+ percent of the problem can be solved this way (without adding tags 
to millions of named features in all of China/Japan/Korea) you can 
think about how mappers can and need to be involved in solving the 
remaining <1 percent of the problem.

So i would suggest not to interpret the rejection of the proposal as not 
caring about correct name rendering in those languages but as rejection 
of the idea of trying to solve the problem through brute force mapping 
work.

My suggestion for basic rendering would be:

* look if the existing name:* tags allow to determine the language, i.e 
if the only name:* tag with a value identical to name is name:jp you 
can safely assume name is in Japanese.
* otherwise determine the language from geolocation - this could be 
expensive to do on-the-fly but you can also precalculate a pseudo-is_in 
tag for that.

If this is implemented and you then worry about the problems where this 
does not work reliably (like a Chinese restaurant in Japan where local 
mappers insist it has to have name, name:jp and name:zh all identical) 
you can look for a tagging solution to solve these specific residual 
problems where required information is lacking in the database.

-- 
Christoph Hormann
http://www.imagico.de/



More information about the Tagging mailing list