[Tagging] Draft Proposal: Default Langauge Format

Wolfgang Zenker wolfgang at lyxys.ka.sub.org
Wed Sep 26 21:09:39 UTC 2018

* Christoph Hormann <osm at 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
  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.


More information about the Tagging mailing list