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.
Gut, also ihr habt ja schon alles errechnet, das Proposal war also erfolgreich und ich habd ie Wikiseite folgendermaßen abgeändert:
https://wiki.openstreetmap.org/w/index.php?title=Key%3Aname&type=revision&diff=1271795&oldid=1267803
Also ich bin froh, dass ich doch ein Proposal aus dem Thema gemacht habe. Ich habe ja anfangs gedacht, dass das so eine eindeutige, unkomplizierte Sache ist, dass man das “auf dem kurzen Dienstweg” erledigen kann und es eher ein mit Kanonen auf Spatzen schießen ist wenn ich da jetzt ein Proposal anstoße. So konnten aber auf jeden Fall alle an den Diskussionen beteiligt werden und das Ergebnis ist erstmal eindeutig. Mühsam ernährt sich das OSM Eichhörnchen.
Interessant fand ich, dass die negativen Stimmen erst nach Start des Proposals aufkamen. Erst hatte ich geacht, es nur jeweils eine statt zwei Wochen laufen zu lassen, weil die Stimmung vorher hier im Forum recht eindeutig war. Zudem hatte ich ja gezeigt, auf welchem Wege die Tags ihren Weg ins Wiki gefunden haben. Auf jeden Fall nicht auf offiziellem oder abgestimmten Wege. Daher ist es eigentlich erstaunlich, dass es so aufwändig ist diese nicht abgestimmten Tagginganweisungen wieder aus dem Wiki heraus zu bekommen. Das sollte uns auch auf eine gewisse Weise zu denken geben. Ich glaube ein Grund dafür ist auch, dass das Wiki nicht zwischen Taggingrichtweisen und Dokumentation von existierenden Tags unterscheidet. Und hier hier war es ein Fall, wo es zwar einen Tag verursacht durch Importe und Editor “Features” gab, aber eigentlich die wenigsten wirklich empfehlen würden den auch beim mappen zu verwenden.
In dem Sinne habe ich dann auch einen großen Fehler bei der Betitelung des Proposals gemacht. Das ist mir auf jeden Fall eine Lehre gewesen, dass ein radikaler Titel den erklärenden und konstruktiven Inhalt überschattet. Mit “Remove suffixed tags” war natürlich nicht wirklich eine Eliminierung aus dem Wiki gedacht, was im Text auch nicht so verlangt wurde. Aber einige haben das vermutet und vorgeworfen, ich würde die Dokumentation eines existierenden Tags löschen wollen. Die Zusammenfassung am Ende, was das Proposal will wurde da anscheinend übersehen.
Daher würde ich auch davon ausgehen, dass die negativen Votings von Lyx, Glassmann und die Enthaltung von Gormo eher ein Resultat dieses Missverständnisses durch den schlecht gewählten Titel waren?!
Interessant fand ich auch Frederiks Oppose Kommentar:
Das geht auch wieder genau in diese Richtung, soll das Wiki dokumentieren oder empfehlen. Also ich folge natürlich seiner Ansicht, dass es blöd ist dass die knapp 40 Stimmen für ein so großes Projekt keinen Weg vorgeben sollten, allerdings steht die Beteiligung natürlich jeder/m offen.
Aber trotzdem find ich die Antowrt doch auch sehr eigenartig, denn faktisch wird das Wiki natürlich zum empfehlen und Vorgeben von Taggingrichtlinien genutzt, und nicht nur zum dokumentieren wass sich irgendwer ausdenkt. Und welchen Platz haben wir denn sonst um Taggings zu wählen und die Ergebnisse aus den Entscheidungen zu dokumentieren?
Außerdem will ich nochmal auf den iD eingehen. Da findet/fand ja auch eine Diskussion im Github statt die irgendwie keine schönen Wege genommen hat und die ich dort unbedingt noch kommentieren will. Der iD Entwickler sieht sich da als Opfer einer Kampagne, vor allem auch durch dieses Proposal wie es mir scheint. Leider aber verharrt er auch sturköpfig auf seiner Position und lässt sich nicht wirklich auf Diskussionen ein ob es nicht Alternativen für das gewählte renaming Feature gibt. Ich glaube nicht, dass das Proposal viel daran ändern wird, deshalb habe ich es auch sehr vorsichtig und nur in Klammern gesetzt formuliert, dass das Ergebnis vielleicht “einen Weg ebnet” um iD zum überdenken dieser Position zu bewegen.
Denn eins möchte ich nochmal etwas betonen, dass ich auch an anderen Stellen erwähnt habe. Es ging mir vor allem und ersteinmal nur darum, das Wiki an dieser Stelle zu veränden. Denn, wie gesagt, die Tags hatten meiner Meinung nach absolut keine Berechtigung als Schema vorgeschlagen zu werden. Sie sind auf nicht abgestimmten Wege ins Wiki und in den Nominatim gerutscht, zudem waren sie schlecht beschrieben und sehr schlecht von den anderen Tags bzw. Überhaupt nicht voneinander abgegrenzt. Dass der iD, mehr oder weniger zufällig, auch genau dieses suffixed Schema für sein double-name Feature verwendet, hat eigentlich erstmal überhaupt nichts damit zu tun. Wenn dann eher im Gegenteil, denn der iD Entwickler hat teilweise durchblicken lassen, dass er das Schema auch nicht als gut empfindet und es eher signalisieren soll “hier muss nochmal jemand reinschauen” wenn der Editor das automatisch erstellt. Dass diese Methode sehr fragwürdig ist, wenn man betrachtet was sie verursacht sollte auf jeden Fall nochmal in Angriff genommen werden. Das Proposal hat auf jeden Fall eine Aufmerksamkeit dafür geschaffen, das ist gut. Darum auch nur “Weg ebnen”. Das es nun ein überzeugendes Argument ist das Feature zu ändern würd ich nicht annehmen, denn die Probleme liegen da noch etwas tiefer.
Und jetzt wirklich zum Schluss, will ich nochmal bemeckern, dass es ziemlich schwierig ist bei so einem Einzelprojekt die Übersicht über die verschiedenen Diskussionsstränge in verschiedenen Mailinglists, Wiki Diskussion, Forum etc. zu hehalten. Dann auch alle mit verschiedenen Formatierungsmöglichkeit etc. Was ich mir sehr wünschen würde, ist dass wir zumindest die Mailinglisten wie bei nabble.com ins Forum integieren könnten. Naja wohl ein frommer Wunsch erstmal. Interessant und gleichzeitig unglücklich fand ich auch die Diskussion über die Multivalues auf der Taggingliste. Interessant deshalb, weil sie erst mit so außerordentlichem Elan betireben wurde und dann OSM-typisch auch schnell wieder versandet ist, und ärgerlich weil der Thread über die suffixed Tags dadurch entführt und damit totgelegt wurde. Auf jeden Fall ist eine allgemeine Auseinadersetzung über die Multivalues notwendig.