* Christoph Hormann <o...@imagico.de> [180926 20:43]: > On Wednesday 26 September 2018, Wolfgang Zenker wrote: >> it appears to me that before discussing possible solutions we should >> better agree on what the problem is. So far I see several related but >> different problems mixed into one and consequently no possible >> agreement on the solution.
> I summarized the advantages of the proposed approach (in the variant > with a format string which is slightly different from the proposal > discussed) in > http://blog.imagico.de/you-name-it-on-representing-geographic-diversity-in-names/ > The aim is ultimately to: > * allow mappers to accurately document information on names of features > in all situations that might exist world wide where there are > verifiable names with as little effort and in the least error prone way > as possible. > * allow data users to interpret this data without constraints due to > intransparent preprocessing performed by the mappers. I'm not sure that all the participants in this discussion and all the supporters of the draft proposal (and previous proposals) do really agree on the ultimate aim of that proposal. Hence my suggestion to explore the problem space first and find out what problem(s) different people try to solve with that proposal, then identify the constraints that reduce the possible solutions space and the "nice to have" properties that we'ld like to see in the solution. Looking at the result of that second phase we can then decide which problems can be solved together in one proposal and which problems should be solved independently. And only after that it makes sense IMHO to propose a solution. >> d) If there are names in multiple languages combined to form the name >> tag in case a, I want to know how to split a given value into the >> component languages. > That would be kind of the inverse to the method proposed here. Parsing > the existing aggregate name tag based on additional format information > tagged would be fairly complicated, very fragile and hard to maintain > in the databse. Several proposals have been made to tag which language > the name tag contains: > https://wiki.openstreetmap.org/wiki/Proposed_features/Language_information > https://wiki.openstreetmap.org/wiki/Proposed_features/Language_information_for_name > but this only covers the single language case and would only have > addressed a very small fraction of the naming problems in OSM. It's true that the proposal at the head of the discussion covers mostly my case e), and d) would be the inverse, but you yourself mentioned the idea to use language information to control speech synthesis for audio output of names, and the information on which part of the name tag was in which language would of course help with that. One problem that I forgot in my list but now remember having been mentioned in the discussion is f) I want to know which language(s), if any, are "official" in a given place (which might be different from both the spoken language(s) and the language(s) used on name signs). About the "second phase" I mentioned above, identifying "constraints" and "nice to haves", this is of course not a clear cut distinction between the two but more of a continuum. Two give a few examples of what I have in mind here: - The proposal MUST NOT alter the meaning of established tags. This would be a hard constraint. - The proposal SHOULD NOT require adding a lot of redundant data to the database. This would be a constraint, but someone might have an idea why it would be justified to break that constraint and maybe he manages to convince the rest of us that it would indeed be a good idea. - The proposal SHOULD NOT require that mappers change their tagging (constraint) but SHOULD enable editor software to help mappers to create better name tags (nice to have) I'm afraid that a discussion were everyone has hir own implicit definition of the problem in mind without writing down what problem exactly we are trying to solve, and with people disagreeing based on the constraints that they have in mind without the others in the discussion knowing what these are, is doomed to failure. So, I repeat my suggestion that before we try to agree on solutions, we should find agreement on what the problems are that we try to solve. Wolfgang _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
