[Tagging] Structured approach to the multi-value discussion

markus schnalke meillo at marmaro.de
Thu Feb 25 09:32:38 UTC 2016


I like to suggest the following structured approach to tackle
the multi-value (MV) topic:

Phase 1: Are MV necessary?

First, collect examples of seemingly necessary MVs in a wiki
page. Classify them as ordered and unordered MVs. Discuss
alternative tagging possibilities, which don't need MVs, for
these examples. Try to figure out if MVs are rare or common.
Discuss the variants of name=* separatly because they are most

After the situation is clearly laid out, the community should
agree if (ordered, unordered, both, no) MVs are necessary.

If they are considered unnecessary, goto Phase 4.
If they are considered necessary, goto Phase 2.

Phase 2: Implement MV in the key- or in the value-domain?

MVs can be implemented in the key-domain (e.g. _1 suffix) or
in the value-domain (semicolons), or multiple identical keys
could be allowed (only for unordered MVs). Discuss these three
approaches, without discussing concrete implementations (e.g.
whether _1 or %1 or whatever should be used). This discussion
will also have to balance between a user burden (value-domain)
and a programmer burden (key-domain). This might depend on the
assumption if MVs are a rare thing or if they are common.

Without wanting to stress the already questioned voting
procedure even more, but normally, one would want to ask for
agreement of the community here as well.

If multiple identical keys should be allowed, goto Phase 4.
If MV should be implemented in the value-domain, goto Phase 3.
If MV should be implemented in the key-domain, goto Phase 3.

Phase 3: Which separator to use?

Key-domain: Decide how to separate the key's name and the
unique suffix. Furthermore one should discuss what suffixes
should be used.

Value-domain: The semicolon seems to be the accepted separator
in this case, but the whitespace after the separator might

A relevant aspect in this discussion seems to be if these
suffixes or separators are supposed to be presented to the
user or hidden and automatically handled by the interface

Goto Phase 4.

Phase 4: Transition plan

At this point, all decisions were made and the community
agrees if and how MVs should be handled. Now, the transition
from the current situation to the desired situation needs to
be discussed. Depending on the outcome of the above phases,
the transition could include changing editor software, but
as well it could include re-tagging current MVs in a non-MV
way. In any way, the time frame for such changes will be long.

I suggest, that these phases are processed one after each
other, because otherwise we will hardly agree on the ``higher
levels''. Thus, now we should start to focus on phase 1 only.
The different opinions that will likely show up there, will
explain most of the disagreement that makes our current
discussions, which mix all in one, so difficult, I am sure.

It is already valuable if we could agree in phase 1 although
we might not agree in phase 2. Mixing the discussion all in
one prevents us from having this success in such a situation.

I am willing to set up and care for a wiki page for phase 1,
as such a page seems not to exist yet.
documents the current state, rather than being a tool to
support discussing the future.)

As I'm relatively new to OSM (started mapping about a year
ago, although my account is older), I don't want to force
my way of thinking onto the community. In my opinion the
approach I proposed could help, but if the OSM community
is successful by doing it differently, I rather stay quiet
and watch things evolve.

Hope to help.


More information about the Tagging mailing list