destination:...-tags

[mueschel]

ref’s werden noch nicht “geslottet”, die tauchen im Augenblick immer unten auf. Ich werde das demnächst mal ausprobieren, ob das funktioniert oder zuviele falsche Darstellungen bei “normalem” Tagging ohne Slots verursacht.

[Jojo4u]

@mueschel

Ich hatte das eher so verstanden, dass er nicht möchte, dass Änderungen an seinem Proposal einfach eingefügt werden. Aber das kann nur er selbst sagen.

Seine Aussage dazu ist eindeutig: Please write your own proposal if you are not satisfied with this one. I do not propose the colour subkey.

[Jojo4u]

@mueschel

Proposal - request for comments - voting (ein halbes Jahr vielleicht) ist der übliche Prozess, allerdings hier etwas schwierig.
Viele “Spezial-Tags”, und zu denen zähle ich die destination-Details auch, wurden nicht über Abstimmungen eingeführt und trotzdem benutzt. Das Problem einer Abstimmung ist dabei immer die Zahl derer die mit “nein” stimmen mit Begründungen wie “wer braucht das schon”.

Tags die in Benutzung sind, können ja durchaus auch eine eigene Wiki-Seite haben, die dann als Tag-Status draft, proposed, in use, oder de facto haben. Ich würde damit anfangen, für die Tags diese Seiten anzulegen, vorrangig in Englisch, jeweils mit Status = proposed, Link zum Proposal und das auch jeweils in einer der ersten Zeilen zu erwähnen. Bei Keys, die schon weit über 1000 Mal verwendet werden, sehe ich da kein Problem, auch wenn sie nicht “approved” sind.

Ich stimme zu. Zum Thema destination: Imagic bringt seine Proposals üblicherweise nicht zur Abstimmung (Voting is bullshit). Sie werden erstellt, getestet, überarbeitet und setzen sich dann durch oder nicht. Der Proposal Prozess ist für komplexe Dinge nicht sehr gut passend da diese sich iterativ entwickeln müssen. Dass abgestimmte Proposals Probleme bereiten (natural=water vs. landuse=reservoir; relation type=parking, PTv2) ist durchaus schon vorgekommen.