alt_name und name_1 - Voting

Ich hab mir die Diskussionen unter euren Links (danke!) nochmal angeschaut und hab versucht nachzuvollziehen wie das ganze in die OSM-Welt kam.

In diesem Talk wird ein Problem bei einem HOT Projekt beschrieben, in dem sie Daten manuell importierten und dabei allerdings mal die Variante alt_name:2 und mal alt_name_2 verwendet haben. Die Person wollte das nun mit einem vollmechanischen Edit alles auf alt_name_2 ändern, aber nicht nur im Gebiet des Hot Projekts sondern am liebsten auch weltweit.

Das wurde wohl auch extra mit Twain vom Nominatim Team abgesprochen, der dafür einen Patch geschrieben hat damit diese alternativen (alt_name_n) auch berücksichtigt werden. Allerdings war das sonst wohl nicht weiter abgesprochen und dementsprechend entstand eine etwas hitzige Diskussion weil die Variante mit dem Semikolon schon existierte und vorgezogen werden sollte. (wie genau die Diskussion verlief könnt ihr ja nachlesen bei Interesse).
Auf jeden Fall gibt es diese alt_name_n Variante nun knapp 4000 mal in einem Gebiet in Westafrika (http://overpass-turbo.eu/s/4ZL) und eher selten ausserhalb dieses Gebietes.

Allerdings hat Twain (von Nominatim) diese Variante dann im November 2014 ins Wiki geschrieben und damit dokumentiert

mit extra Hinweis darauf, dass ‘;’-Listen vermieden werden sollen, ist ihm das also ein Anliegen?

Im April 2015 wurde dann nochmal präzisiert, dass das dann verwendet werden soll wenn die Zeichenanzahl für die Kommata-Listen nicht mehr ausreichen (so sol man den Satz wohl verstehen, die deutsche Übersetzung war dann noch schlimmer)

Die Dokumentation von name_x kam dann erst im August dazu und basiert wohl nicht auf irgendwelchen Proposals oder Diskussionen sondern auf dem puren Vorhandensein dieses Tags:

Was auch immer man allgemein jetzt von diesen Werten halten will, die Dokumentation im Wiki ist meiner Meinung nach jeweils recht schlecht geraten.

Jetzt könnte man natürlich vermuten, dass das hohe Aufkommen von name_x durch den ID Editor entstanden ist. Interessant dazu wäre ja mal eine historische Entwicklung, gibt es dafür ein Tool? Also ein Taginfo das die Anzahl in der Vergangenheit erhebt? Den ID gibt es ja noch nicht soo lang. Außerdem wäre ein Zusammenhang zwischen “Changeset der mit ID gemacht wurde” und “name_x ist neu getaggt worden” Interessant. Stichproben nach zumindest bestätigt sich, dass das zusammengehört.

Allerdings geht das Problem dann ja auch weiter, wenn man den ID betrachtet. Denn wie in einem der verlinkten Beiträgen auch schon erwähnt wird:

Wie in dem Thread gezeigt wird, handelt es sich übrigens nicht um einen Bug sondern ein Feature, ist also extra eingebaut, wie es dazu kam zeigen diese Kommentare von den Entwicklern:

Also anstatt einer Warnung oder Erklärung baut der ID da eine “Lösung” die die Daten vermüllt und, noch schlimmer, die Leute darin trainiert das auch selbst weiter zu machen. Eigentlich wollte jemand dazu was in den ID Bugtracker schreiben, ich weiß aber nicht ob dass dann passiert ist?

Dieses Verhalten vom ID sollte auf jeden Fall aufgehalten werden weil es völlig unkontrolliert ist und sich ja auch nicht nur auf name_x oder alt_name_x bezieht sondern noch viel mehr Blüten treibt (schöne Beispiele gibts in dem verlinkten Thread).

Trotzdem weiß ich nicht, ob man generell sagen kann “braucht man nicht, muss weg, semikolon ist besser”. Natürlich hat sich zuallererst mal das Semikolon etabliert, auch mit dem Argmument, dass sich das besser auswerten liesse. Das wundert mich allerdings ein bisschen, zwar kann ich das total nachvollziehen für Fälle in denen ich mir einen bestimmten Datensatz genau anschaue. Aber für Programme wie Nominatim beispielsweise die in den Daten suchen ist das doch viel komplizierter / kostenreicher weil dann reguläre Ausdrücke etc. genutzt werden müssen. Allerdings werden sich diese Programme wahrscheinlich sowieso einen eigenen Index zusammenbasteln womit das dann schon wieder obsolet wird.

Viel wichtiger finde ich aber zu beachten, dass es in manchen Ländern nicht so eindeutig festgelegte offizielle Namen gibt und da dann vielleicht wirklich mehrere Namen vorkommen könnten, die den Rahmen von 255 Zeichen sprengen würden? Wahrscheinlich kommt das aber auch nicht wirklich oft vor und wahrscheinlich könnte man das oft mit sprachenspezifischen Name-Tagging auffangen. Ich fänd nur wichtig, dass diese Möglichkeit auch Bestandteil der Diskussion ist. Ich hab mir das nochmal grob in Sierra Leone angeschaut wo es die 4000 alt_name_x gibt. Mir scheint, dass es sich dabei auch eher um sprachliche Variationen handelt, aber hab da natürlich keine Ahnung. Auf jeden Fall seh ich aber auch keinen wirklichen Grund, warum da nicht das Semikolon Tagging verwendet wurde. Für die menschlichen Augen sind die multiplen Tags halt einfacher zu erfassen, das ist glaub ich ein Knackpunkt bei der gesamten Geschichte.

Auf jeden Fall gefällt mir der Vorschlag, darauf hinzuweisen dass immer erst die semantisch reicheren name Tags verwendet werden sollte, dann erst alt_name und im absoluten Ausnahmefall wenn die 255 Zeichen von alt_name nicht ausreichen noch alt_name_1. Aber dann sollte man sich auc nicht wundern wenn das nicht ausgewertet werden kann (sollte eigentlich auch nicht vorkommen der Fall). Problematisch ist, dass viele wahrscheinlich überfordert sind mit der Unterscheidung zwischen den einzelnen Name-Tags, oder auch Operator und Brand etc. Da muss wahrschienlich mehr Arbeit ins Wiki gesteckt werden.

Und name_1 is halt leichter, und der Editor machts ja auch so und es steht sogar im Wiki, da darf man sich nunmal nicht wundern…

Also Fazit:

  1. gibt es einen Bugtracker Report dazu im ID? Ich hab keinen gefunden
  2. Weiß jemand wie man mal auswerten kann seit wann der name_1 benutzt wird oder wie der mit ID changesets zusammenhängt (oder mit Mappern die vorher ID benutzt haben, das wär die Königsaufgabe ;))
  3. Kann ich name_1 und alt_name_1 aus dem Wiki hauen? zumindest aus dem deutschen? Oder wo müsste man dazu noch diskutieren etc? raushauen = empfehlen das nicht zu verwenden etc.

Danke für deine Analyse!

Nein.

Du kannst im Wiki schreiben, dass u.a. der iD das so verwendet, aber dass das nicht empfohlen ist, mit Verweis auf diesen und den anderen Forums-Thread. Und hoffen, dass niemand das anders sieht.

Ansonsten musst du die Diskussion im Wiki lassen (habe ich neulich schmerzhaft erfahren müssen). Problematische Wiki-Seiten-Edits werden im Wiki diskutiert.

Wir hier im Forum sind halt nicht die einzige DE-OSM-Community. Es gibt noch den Teil auf den Mailinglisten und den Teil, der nur im Wiki diskutiert…

vielleicht könnt ihr mir ja mal helfen, ich befürchte, dass der ID Entwickler da nicht so ein Problem drin sieht :expressionless:

https://github.com/openstreetmap/iD/issues/2896

Seh ich auch nicht … so lange man sich auf keine bessere Lösung einigt.
Wie soll man denn mehrere Namen, Telefonnummern usw. beschreiben?

Jede bisher vorhandene Lösung wird von irgendeiner Gruppe abgelehnt und Verbindlichkeiten gab es in OSM noch nie … viel Erfolg!

Danke…

Mit dieser Abfrage habe ich Elemente gefunden, wie

lit=yes + lit_1=yes… was nun wirklich Quark ist.

Sven

Das Hauptproblem ist ja, dass das in ID nicht mal als Tagginglösung gedacht ist, sondern nur als “da will jemand einen tag eingeben den es schon gibt, bevor er den löscht setz ich mal eine _1 dahinter, dann merkt er ja dass da was nicht stimmt und er löscht keine daten”. Das heißt, es ist nur eine Absicherung aber entspricht keinerlei Taggingschema. Die User verstehen es unter Umständen aber als Taggingschema, und dann kommt da halt auch so ein absoluter Mist wie hier gut zusammengefasst bei raus: http://forum.openstreetmap.org/viewtopic.php?pid=497888#p497888

Wie schon gesagt: mit beschreibenden Schlüsseln wie old_name=, alt_name= oder loc_name=*. Dann stehen die Namen nicht nur numeriert nebeneinander, sondern es ist auch kodiert, welcher Name in welchen Kontext gehört. Kannst du da wirklich keinen Mehrwert drin sehen?

Konstrukte wie name=foo, name_1=bar, name_2=rumpel und name_3=stilzchen sagen nicht mehr aus als name=foo;bar;rumpel;stilzchen. Es werden einfach Werte aufgelistet, ohne zu sagen, welcher Wert wie aufzufassen ist.

Wenn wirklich die Notwendigkeit besteht, einem Element mehrere Teflonnummern zu geben, finden wir da auch einen entsprechenden Weg.

–ks

Sicher kommt dabei Mist heraus… wie ein Straßenobjekt mit lit=yes und zugleich lit_1=yes… Aber… von einem unbedarften Nutzer kommt auch das heraus: http://overpass-turbo.eu/s/dAL

hier mal herausgegriffen: http://www.openstreetmap.org/way/290393925 Da kann man sicher weiterarbeiten… man sieht, was der Nutzer meint…

Im Sinne der Fehlerprüfung wäre das eine Routine die in Standardanwendungen (Osmose, oder KeepRight!) aufgenommen werden sollte… Interessant wäre es, wie groß die Anzahl der Key-Werte mit Key_n=* wäre… Im Bereich Berlin und südliches Brandenburg waren es nicht sehr viel…

Sven

Somit sind wir wieder soweit wie bei den letzten 10 Diskussionen.
Keiner findet TAG_1 TAG_2 etc gut.

Semikolon kann verwendet werden, sollte aber wie im WIKI immer wieder steht vermieden werden. Auswerten kann es kaum einer (Renderer, Karten, taginfo, XAPI, …) obwohl durchaus machbar (Walter hat mal ein schönes Beispiel gezeigt), und viel schlimmer noch: Qualitätstools melden es als Fehler und auf der Karte werden Semikolonwerte ausgeblendet, während TAG, TAG_1, TAG_2 wenigstens angezeigt werden.

Meines Erachtens liegt das Problem somit nicht beim taggen, sondern an der mangelnden Umsetzung und er damit verbundenen Empfehlung (siehe QS-Tools) es nicht zu verwenden. Jeder Neuling, der richtig taggt und seine Objekte nicht auf der Karte findet, wird die Lösung mit den Nummern verwenden. Je länger das so weiter geht, umso mehr nummerierte Tags wird es geben.

Man sollte also nicht bei ID einen Fehler einstellen, sondern z.B. beim Renderer von openstreetmap.org, bei osmose, …

Na so was. Vielleicht hat das ja einen Grund? Oder sind die alle einfach nur doof?

Wo steht das?

Semikolon sollte vermieden werden, wenn semantisch sinnvoller getaggt werden kann. Wenn ein Name „offiziell“ und ein zweiter lokal ist, dann sagt name=* und loc_name=* halt mehr aus als name=; oder name=* und name_1=*.

Semikolon ist aber da angebracht, wo Werte wirklich gleichberechtigt nebeneinander stehen und keine unterschiedlichen Bedeutungsebenen haben – z.B. ref=A8;A81 an der Autobahn südlich Stuttgart.

Wenn ich dich richtig verstehe, hältst du also Semikolonwerte für schwieriger auswertbar als _1-keys? Das verstehe jetzt, wer will. Konkretes Beispiel: Ich habe gerade für den Wikipedia-Artikel „A1 road" eine overpass-Abfrage zwecks Übersichtskarte gebaut. Dabei ist zu beachten, daß ich nicht nur nach ref=A1 suchen kann, weil dort, wo die A1 mit anderen Straßen koinzidiert, Semikola stehen (z.B. ref=A1;A145). Lösung ist ganz einfach, ich suche per regex nach \bA1\b im ref, also A1 in Wortgrenzen (damit ref=A168 keinen Fehltreffer erzeugt). Dein „Auswerten kann es kaum einer“ bedarf einer mittleren Erklärung.

Wie würde ich aber diese Abfrage gestalten, wenn ref=A145 und ref_n=A1 getaggt wäre? Ich müßte sicherheitshalber alle Keys bis ref_9 abfragen und wäre nicht mal dann sicher, ob die A1 sich nicht irnkwo im ref_10 versteckt. Die Abfrage wäre a) umständlich zu formulieren und b) hochgradig serverlastig, weil der viel mehr Schlüssel abfragen muß.

–ks

wo wird das denn angezeigt?

Und was kommt dabei heraus?
http://www.openstreetmap.org/way/79738882
Ein Rathaus komplett für die Notdurft :roll_eyes:

Ja, das ist für den A… :wink:

Der ID Entwickler hat das Issue jetzt geschlossen mit der wunderbaren Begrüdung, in OSM machen ja alle Chaos und wenn es einen wirklich stört kann man ja einen Bot schreiben grrr

Ok, ich bin ja echt kein Fan davon wenn ich merke, dass viele Leute auf etwas herumhacken wie ich es beim ID immer mitbekomme. Aber so ein Verhalten macht mich auch echt stinkig!

Ja. Das klingt wie ein trotziges Kind: Macht doch, was ihr wollt, ist doch eh alles scheiße! Dabei wäre die Lösung so einfach: statt _n-Tags zu setzen, müßte iD nur den User darauf aufmerksam machen, daß der betreffende Schlüssel schon gesetzt ist und fragen, ob der jetzt zu taggende Wert den alten Schlüssel ersetzen oder entweder per Semikolon oder in Form eines anderen Schlüssels ergänzen soll. Das Vorgehen ist gut genug definiert: zwei gleichartige, gleichwertige Bedeutungen (mein Lieblingsbeispiel der koinzidenten Straßen): Semikolon, zwei unterschiedlich gewichtete Werte: unterschiedliche Schlüssel, die nicht nur die Werte speichern, sondern auch die Unterschiede abbilden.

–ks

Gegen solche Auswüchse vorzubeugen wäre für mich Sache der API: Tags mit Zähler, Großbuchstaben, Leerzeichen usw. - sowas sollte eine API abfangen. Es wäre IMO auch an der Zeit das Erfinden neuer Tags (und je nach Tag auch der Values) zu blockieren - nach so vielen Jahren OSM dürfte genügend beisammen sein um erst zu diskutieren und dann neue Tags aufzunehmen. Mittlerweile verursacht das (leider!) mehr Ärger als es Gewinn bieten kann - und das dürfte sich weiter so entwickeln… Zumindest für überdenkenswert halte ich dies. Und um es klar zu sagen: Ich fände das nicht nur toll & begrüßenswert, es wäre auch ein großer Verlust.

Wenn ich ehrlich bin: name_old, name_alt, name_loc wäre schlaucher gewesen, da dann alle name-Tags bei alphabetischer Sortierung nacheinander kämen. Aber was soll’s …

Wenn sich diese Haltung per ID ausbreiten sollte, dann gute Nacht OSM.
Es ist um Größenordnungen leichter, Unfug in eine Datenbank einzutragen, als diesen wieder zu entfernen.

OT: ja hat mich auch schon gewundert, normalerweise sollte man das so bei Variablenbenennungen so machen

Noch ein sehr schönes Beispiel aus dem Thread Kurioses: https://www.openstreetmap.org/node/3928952768