I think Colin Smale already set up such a page, see Examples on [1] This was part of a longer discussion earlier this year [2]
Some examples that were mentioned in the thread are missing I think: e.g. turn:lanes and opening_hours. regards m [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Multivalued_Keys [2] https://lists.openstreetmap.org/pipermail/tagging/2016-January/028320.html On Thu, Feb 25, 2016 at 10:32 AM, markus schnalke <mei...@marmaro.de> wrote: > Hoi, > > 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 > controversial. > > 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 > not. > > 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 > software. > > 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. > (<http://wiki.openstreetmap.org/wiki/Multiple_values> > 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. > > > meillo > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
