Re: [Tagging] Feature Proposal - Voting - Language information - Closed
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/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Feature Proposal - Voting - Language information - Closed
Hello. The feature proposal for language information did not get enough support. Voting is over. The proposal is closed as “rejected”. 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). With much more than 1 billion people living in the affected region of the world, I think this is a really big issue. For correct rendering, you need two additional informations for text labels: 1.) The language 2.) The script (only for Han) BCP-47 combined both, but there might be other possibilities to provide this information. I would appreciate it a lot if someone else proposes a good solution that could reliably and correctly provide these informations in OSM, and I would love to see if one day in the future this might be implemented in OSM… -- Lukas Sommer ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
