Ich hab doch geschrieben sollte vermieden werden. Du schreibst es doch selbst in deinem ersten Satz nach deiner Frage?!
Die komplette Seite hier ist voll mit “sollte vermieden werden” und wird idR “nicht ausgewertet”.
Ich hab sogar geschrieben, dass es auswertbar ist … es macht nur kaum einer, da liegt der Unterschied.
Mein Fazit: Ich halte beides aus verschiedenen Sichten für sinnvoll.
Da OSM ein Datenbank ist, wie hier ja auch immer behauptet wird und es sowieso keine Regeln sondern nur “allgemein anerkanntes Vorgehen” gibt kann jeder machen was er will. Die Datenbank ist auch voll von so Zeugs, wie sich jeder auf Taginfo überzeugen kann.
Der Renderer kann sich demnach bedienen wie er will, aber anscheinend hält zur zeit keiner was von Semikolons noch von Keys mit Zahlen.
Normale Tags wie amenity oder name auf jeder Karte. name_1 usw in jedem Editor leicht lesbar.
Das dabei jede menge Mist erstellt wird ist außer Frage, die Beispiele zeigen es, bei der Größe der OSM Datenbank findet sich aber für jede Interpretation ein Beispiel. Mir wäre es lieber, aus den Wiki-“Richtlinien” würden Regeln und die Editoren würden Wildwüchse eindämmen durch Meldungen, anstatt allen Mist einfach durchzuwinken.
Seufz. „Sollte nur dann vermieden werden, wenn …“ habe ich natürlich gemeint. Ein generelles „Semikolon sollte vermieden werden“, wie du es nahelegst, kann ich nicht erkennen.
Ich habe ein Beispiel geliefert, wo Semikolon viel leichter auswertbar ist als _n. Und wäre jetzt an einem Gegenbeispiel interessiert, beziehungsweise an einer Aufdeckung meines Irrtums.
Ja. Aber davon wird es weder besser noch richtiger.
Und Semikolonwerte sind im Editor nicht leicht lesbar? Oder inwiefern ist das ein Argument?
D’accord. Und genau darum geht es in diesem Thread.
100% Übereinstimmung. Für den alten Thread (http://forum.openstreetmap.org/viewtopic.php?id=30806) hatte ich mir ja die Mühe gemacht, fast alle xxx_1=, xxx_2=, …-Tags in Baden-Württemberg anzusehen, und habe die Ergebnisse ja damals (zu ;)) ausführlich berichtet. Fast alle Kommentatoren waren der Meinung, dass diese xxx_1-Mode eingedämmt werden sollte, auf jeden Fall, dass iD aufhören sollte, die Datenbank damit zu verpesten und wohlmeinende Mapper auf die Idee zu bringen, man müsse das eben so machen. Aber es wusste wohl niemand so recht, wie man die iD-Developer dazu bekommt, unsere Sorgen ernst zu nehmen … Dabei wäre, wie Kreuzschnabel so schön beschreibt, die Lösung ja recht einfach: iD bräuchte einfach (mehr) vernünftige Fehlermeldungen, Warnungen und Nachfragen, aber ebensolche möchten die Entwickler (wenn ich recht verstehe) möglichst nicht einbauen, vielleicht weil es ihrer Meinung nach einige Novizen verschrecken könnte.
Wat machn wir denn nu? Auf iD schimpfen bringt uns ja auch nicht weiter …
Ich hab jetzt erst mal mit nem großen ammer Ich hab jetzt erst mal nen großen Hammer genommen um das aus dem Wiki rauszubekommen, vielleicht wollt ihr euch beteiligen?
iD würd ich danach nochmal nen Ansatz machen, ich bastle grad an nem script dass zeigen sollte wieviele _1 taggins durch ID verursacht werden, vielleicht bringt das ja was.
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
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?
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…
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.
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:
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):
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).
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…
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…
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…
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…
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.
