bzw, hab jetz doch nochmal ein formales proposal gestartet, acuh wenn ich nicht das Gefühl hab dass es nötig ist, aber naja, schadet ja auch nicht wenn es mal im Wiki festgehalten ist 
http://wiki.openstreetmap.org/wiki/Proposed_features/Remove_suffixed_name-tags_from_wiki
son bisschen soll das ja auch dazu dienen die Aufmerksamkerit auf dieses iD Problem zu lenken dadurch
Willst du das nur auf die name-Tags begrenzen? Letzendlich sind auch andere Tags betroffen…
Ich kann das auch da noch mal reinschreiben…
Sven
naja, es geht ja jetzt erst mal darum, dass die im Wiki vorgeschlagen werden (name_1 und alt_name_1) und ich das entfernen würde.
Ansonsten wir ja norgendwo erwähnt, dass man die verwenden kann, daher weiß ich nicht ob es notwendig ist zu erwähnen dass sie nicht verwendet werden sollen. Bzw. die Frage wäre, wo im Wiki sollte man es überhaupt erwähnen?
Ok…
Ich befürchte ja, daß diese Unart von iD in das allgemeine Taggingverhalten von wenigmappenden Usern Einzug hält… Ich hab gerade eine PN-Unterhaltung bezüglich des Mappings von THW-Standorten. Da nutzt der user squad_1=, squad_2= ect… Ist letztendlich das selbe Problem wie mit name_1. Da er die Daten mit QGis auch auswerten will, habe ich ihm Lösungen aufgezeigt, wie er ohne diese _n- Tags auskommt, sowohl in der Auswahl, als auch in der Darstellung, z.B. Beschriftung… Mal sehen, ob er meine Ratschläge annimmt. Auf die Disskussion hier habe ich verwiesen, er meint aber, daß man im Forum nur disskutiert wird und zu keiner Lösung kommt… Nun gut…
Sven
Es gab vor ein-zwei Jahren eine längere Diskussion (IMHO auf talk) zum Thema die damit endete, dass _n als “legales” Tagging “akzeptiert” wurde.
Fand ich auch nicht sehr elegant, aber ich denke es ist nicht sinnvoll dies durch ne kleine Gruppe, essentiell ohne die Rest-Community zu beteiligen wieder umstossen zu wollen. Es wird auch nichts Gescheites dabei herauskommen.
mh das würd ich gern mal nachlesen, hast du mehr Anhaltspunkte damit mand as finden könnte? Talk:de oder en?
Also das Proposal läuft noch, ich dachte ja erst dass eine Woche reicht, da die Stimmung eindeutig schien, aber da kamen doh noch ein paar kritische Stimmen. Allerdings dreht sich die Diskussion (auf der Tagging Liste) jetzt ziemlich im Kreis bzw. wabert OSM typisch aus. In den nächsten Tagen würd ich das Voting starten, falls ihr euch noch beteiligen wollt:
http://wiki.openstreetmap.org/wiki/Proposed_features/Remove_suffixed_name-tags_from_wiki
http://gis.19327.n5.nabble.com/Removing-name-1-and-alt-name-1-from-Wiki-tp5864465.html
http://gis.19327.n5.nabble.com/Please-don-t-think-name-1-tags-are-errors-tp5864875.html
Ich werd dann vielleicht auch nochmal einen konkreteren Textvorschlag machen
gruß
Voting ist gestartet, bitte kommt kurz vorbei mit eurer Meinung (die Sache soll auch ein bisschen dazu dienen, dem iD Editor zu zeigen, dass das suffixing-Verhalten unerwünscht ist):
https://wiki.openstreetmap.org/wiki/Proposed_features/Remove_suffixed_name-tags_from_wiki
Da hast du definitiv Recht. Ich wundere mich nur, inwiefern das ein Argument ist, dem Proposal zuzustimmen. Eigentlich möchte man doch wissen, in welcher Beziehung ein Name zu einem anderen steht. Das kann weder name_42 noch das Semikolon bieten, sondern man braucht dafür loc_name, old_name, name:en oder ähnliche aussagekräftige Schlüssel.
Meine Schlussfolgerung ist, dass wir dieses Konzept ausbauen sollten, falls noch Ausdrucksmöglichkeiten fehlen. Mapper zu ermuntern, die Namen einfach ohne semantische Beziehnung aufzulisten, ist aus meiner Sicht der falsche Weg – egal ob diese Liste mit Semikolon oder Nummerierung hingeschrieben wird.
Genau. Und das Proposal möchte dazu ermuntern, diese aussagekräftigen Schlüssel statt _1 zu verwenden:
Ich sehe zwischen deiner Ansicht (die ich unterstütze) und dem Proposal keine großen Diskrepanzen. Das Proposal unterstützt semantische name-keys und schlägt Semikolon-Werte nur für den Fall vor, daß mehrere Namen gleichberechtigt nebeneinander stehen, von den semantischen keys also maximal alt_name sinnvoll einsetzbar wäre. (Und da alt_name keine Wertung vornimmt, gibt es zwischen den Taggings name=foo / alt_name=bar einerseits und name=foo;bar andererseits keinen wirklichen Unterschied).
–ks
Ich persönlich sehe Key’s der Form Key_n=* als äußerst problematisch an. Datenbanktechnisch ist das nicht sinvoll auszuwerden, man muß alles betrachten, aber wo fängt das dann an, wo endet es? Fängt es bei Key_1=* an und endet es bei Key_3=, fängt es bei Key_10=an und entet es bei Key_11=???
Aber auch hier hat man keine Aussage, in welcher Beziehung key_1 zu Key_2 oder Key_3 zueinander stehen…
Bei einer Anwengung von Key=; mit dem definierten Trennzeichen “';” im Value hat man wenigstens die Chance die Value-Werte anhand des Trennzeichens auszuwerten.
Lässt man Key_n=* zu öffnet man auch Tür und Tor für die Anwendung dieses Taggings in anderen Key-Werten… Ich hab in Brandenburg ein solches Beispiel…
THW…
http://overpass-turbo.eu/s/e05
squad_1=* bis squad_n=* wurde vom User nur angewendet, damit er die Daten leicher Auswerten kann (Studentenprojekt)… so seine PN. Da besagter User auch QGis zur Auswerung benutzt, konnte ich ihm leicht einige Auswertealternativen unter Verzicht des Taggings Key_n=* benennen… leider kam dann keine Antwort mehr… Für mich gehört das aber zu grundsätzlichen Kenntnissen der GIS-Datenverarbeitung… Aber es muß ja alles schnell schnell gehen, ohne zu Wissen, was man tut… 
Darum übrigens meine Frage http://forum.openstreetmap.org/viewtopic.php?pid=570370#p570370
Sven
Ich persönlich sehe Key’s der Form Key_n=* als äußerst problematisch an. Datenbanktechnisch ist das nicht sinvoll auszuwerden, man muß alles betrachten, aber wo fängt das dann an, wo endet es? Fängt es bei Key_1=* an und endet es bei Key_3=, fängt es bei Key_10=an und entet es bei Key_11=???
Aber auch hier hat man keine Aussage, in welcher Beziehung key_1 zu Key_2 oder Key_3 zueinander stehen…
Bei einer Anwengung von Key=; mit dem definierten Trennzeichen “';” im Value hat man wenigstens die Chance die Value-Werte anhand des Trennzeichens auszuwerten, ohne Klimzüge zu machen um herauszufinden, wieviele Key_n - Werte auszuwerten sind.
Lässt man Key_n=* zu öffnet man auch Tür und Tor für die Anwendung dieses Taggings in anderen Key-Werten… Ich hab in Brandenburg ein solches Beispiel…
THW…
http://overpass-turbo.eu/s/e05
squad_1=* bis squad_n=* wurde vom User nur angewendet, damit er die Daten leicher Auswerten kann (Studentenprojekt)… so seine PN. Da besagter User auch QGis zur Auswertung benutzt, konnte ich ihm leicht einige Auswertealternativen unter Verzicht des Taggings Key_n=* benennen… leider kam dann keine Antwort mehr… Für mich gehört das aber zu grundsätzlichen Kenntnissen der GIS-Datenverarbeitung… Aber es muß ja alles schnell schnell gehen, ohne zu Wissen, was man tut…
Darum übrigens meine Frage http://forum.openstreetmap.org/viewtopic.php?pid=570370#p570370
Sven
das unterstütze ich absolut! Ich habe im proposal auch gleich zu Anfang darauf hingewiesen, dass am besten sowieso andere tags bentutz werden soltlen. Ich bin deshalb auch ein wenig erstaunt, wieviel aufhebens um die Sache mit den Semikolons gemacht wird, da wir im Grunde multiple Values ja sowieso vermeiden wollen.
Aber gerade dann, wenn man es vermeiden will, sollte man dann nicht noch zusätzlich zwei verschiedene Schematas haben (wo ein bestimmter Editor eines davon auch noch selbst automatisch erstellt…)
Genauso (nämlich eigentlich ganz im Sinne Tordaniks) habe ich Hakuchs Proposal auch verstanden, daher habe ich dafür gestimmt. Ich finde es schade, wenn nun wichtige Mapper wie Tordanik dagegen stimmen, nur weil die Semikola-Möglichkeit erwähnt wird. Denn auf diese Weise droht das Proposal zu scheitern. Wenn aber nicht einmal dieses bescheidene Proposal durchkommt, werden weitere Schritte gegen die Unterstrichitis (*) erst recht scheitern. Es ist doch klar, was das bedeutet: die Unterstrichitis wird sich immer weiter verbreiten, und dadurch werden gerade diese semantisch reicheren Tags, die uns so wichtig sind (old_name, local_name, int_name etc. pp.), immer weiter verdrängt und ertränkt werden von der Schlammwoge der _1 _2 _3 …-Tags, die alles überspült.
(*) Unterstrichitis, die: Erfindung und massenhafte Verbreitung von neuen, semantisch völlig unklaren Tags durch Anhängen von Suffixen der Form ‘_’ an etablierte Tags.
Wie ist denn das offizielle Endergebniss?
nach meiner Rechnung: 78% Ja( 38 Stimmen), 20% nein(10 Stimmen), 2% Enthaltung (1 Stimme) Gesamt: 49 Beteiligt…
fragt Sven
ja will ich die ganze zeit machen, hoffe morgen, wollte eigentlich noch was mehr dazu schreiben, gruß
Ich habe es im Wiki gerade auf 37 Ja-Stimmen korrigiert.
Vielleicht will das nochmals jemand nachzählen?
Wobei ich mir nicht sicher bin, ob das mit den 78,723% stimmt (habe die Berechnungsmethode von Kelerei übernommen).
37/47 = 0,78723
oder doch eher (mit Enthaltung)
37/48 = 0,77083
?
Wieso ist denn die Stimme von Geri-oc im nachhinein rausgenommen worden? Das war die 38te, die ich gezählt habe…
fragt Sven
Stimmt, hatte ich nicht bemerkt!
Kelerei hat die Stimme von Geri-oc versehentlich entfernt:
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features%2FRemove_suffixed_name-tags_from_wiki&diff=1271469
Habe das rückgängig gemacht und das Ergebnis wieder verbessert.
Und was passiert nun? Ich würde die iD-Entwickler ganz nett (oder ganz heftig?) auf dieses Proposal hinweisen Es sein denn, die wenigen Ablehner kommen gerade von dort. Dann sollte die das Ergebnis ja kennen 
Klar, das verpflichtet zu nix, sollte die aber nachdenklich machen.
Gruss
walter, der die Abstimmung leider verpasst hat aber mit dem Ergebnis zufrieden ist.