alt_name und name_1 - Voting

naja, man könnte es ja zumindest als “deprecated” markieren damit es nicht weiter verwendet wird? Offensichtlich gibt es da anscheinend eine Konkurrenz zwischen den beiden Tags

alt_name bedeutet nicht “alter name” sondern “alternativer name”. Ist also vergleichbar mit name_1 und bestimmt nicht “deprecated”.
Das name_1 stammt von iD Editor, wenn man mehrere gleiche keys verwendet und ist daher “gebräuchlich”, wenn auch nicht richtig.
Ich selbst kann mit dem Tag gut leben und seh ihn einfach nur als Ergänzung. Bei Auswertungen kann er ignoriert werden.

ehm, naja is ja klar, genau darum geht es ja hier. Die Frage ist ja, wozu man name_1 neben alt_name überhaupt braucht

Aha, das ist ja interessant, also verbockt der Editor das? Dann sollte das trotzdem nicht im Wiki stehen und Leute dazu animieren den anzuwenden. Wenn name_1 keinen Mehrwert gegnüber alt_name bieten kann sollte er nicht mehr zum taggen vorgeschlagen werden. Im WIki stehen sogar noch solche Sachen wie alt_name_1…

Allerdings kann es wirklich auch vorkommen, dass es mehr als einen alt_name gibt, das ist aber keine Rechtfertigung für name_1

Es gibt ja auch z. B. brand_1 und brand_2 usw. Ich hab das schon bei allen möglichen Tags gesehen, ich meine einmal sogar shop_1 gesehen zu haben.

mh ja und garnicht so wenige

https://taginfo.openstreetmap.org/search?q=shop_1

Bei amenity gibts da auch nochmal einige, wenn man sich fragt woher das kommt, vielleicht wirklich aus dem ID der das einfach so macht? Ist natürlich der leichte Weg wenn man ein Geschäft nicht richtig einordnen kann. Ausgewertet werden kann das dann wahrscheinlich nicht richtig.

Mh schön find ich das nicht, vor allem gibt es bei alt_name ja schon eine Variante, aber ich kann nun auch verstehen wenn man das verwendet wenn sich ein Geschäft beispielsweise nicht so einfach einordnen lässt. Aber es birgt auch die Gefahr, dass man es sich dann zu einfach macht.

Das macht iD automatisch, wenn ein schon vorhandener key nochmals gesetzt wird. Probier’s aus, öffne eine Wohngegend, selektiere einen highway=residential und setz unten unter „Alle Eigenschaften“ von Hand ein highway=motorway dazu.

Sei in einem Haus ein Schuh- und ein Klamottengeschäft. User 1 hat das shop=shoes an den building-way gehängt, User 2 taggt mit iD das Klamottengeschäft ebenfalls an den building-way, dann setzt sein Editor automatisch shop_1=clothes. (JOSM würde fragen, ob das shop=shoes überschrieben werden soll.)

Mich stört daran sehr, daß damit ein Value erstmal „geparkt“ wird, sich aber einer automatischen Auswertung möglicherweise entzieht, sofern man bei der Abfrage diese „_n“-Keys nicht gezielt mit berücksichtigt. Wer bei Overpass nur nach „shop=clothes“ sucht, findet einen mit „shop_1=clothes“ getaggten Klamottenladen wahrscheinlich nicht (außer Overpass berücksichtigt das automatisch).

–ks

Edit: taginfo findet für shop_1 597 Treffer.

Um noch mal auf die ursprüngliche Frage zurückzukommen:

Früher stand name_1 gar nicht im Wiki, das hat jemand eingefügt, um mit der iD-verpesteten Realität Schritt zu halten. :wink:

Für das name-Tag gibt es eine ganze Reihe mehr oder minder wohldefinierter Alternativtags, die den großen Vorteil haben, semantisch reicher zu sein als alt_name oder name_1:

official_name=: offizieller Name, nützlich z.B. für amtliche, aber ansonsten ungebräuchliche Namensformen
loc_name=
: lokaler Name, nützlich z.B. für vor Ort häufig gebrauchte Namensformen
old_name=: frühere Namensformen, z.B. vor Umbenennung einer Straße bei Gemeindereform
short_name=
: für gebräuchliche kurze Namensformen (sollte irgendwann auch mal von einem intelligenteren Renderer verwendet werden, wenn der Platz nicht für name=* reicht!)
long_name=: für ‘lange’ Namensform
abbr_name=
: für gebräuchliche abgekürzte Formen
name:(languagecode)=*: für Namensform in einer bestimmten Sprache
… und einiges mehr.

Dies alles findet sich ja auch auf der Wiki-Seite (http://wiki.openstreetmap.org/wiki/Key:name). Alle diese Alternativtags haben den Vorteil, nicht nur zu sagen: ‘das ist irgendwie ein alternativer Name’, sondern anzugeben, um was für eine Namensform es sich handelt.

Daher sollte man für alternative Namensformen mMn immer (1), wenn möglich, eines der angeführten semantisch reicheren Tags verwenden. Nur wenn (2) von diesen keines passt, sollte man alt_name=* verwenden. Und für name_1=* … bleibt dann eigentlich kein Bedarf mehr.

Es gibt mMn ein noch größeres Problem bei diesem Verhalten von iD: Da iD solche key_n-Tags automatisch erzeugt, “wenn ein vorhandener key nochmals gesetzt wird”, weiß man nie genau, welche(r) Wert(e) nun vom Mapper intendiert ist/sind und welche nicht.

Begründung: Es kommt vor, dass ein Mapper z.B. name_1=* absichtlich setzt, um einen Alternativnamen anzugeben; oder amenity_1=, weil der Mapper mehrere Amenities auf ein Objekt packen will. Es kommt aber auch vor, dass das key_n-Tag von iD erzeugt wird, ohne dass der Mapper das überhaupt bemerkt; in diesem Fall enthält dann manchmal key_n= den Wert, den der Mapper intendiert hat, weil er eigentlich key=* korrigieren wollte, es scheint () aber auch vorzukommen, dass der Mapper danach nochmals den Wert von key= bearbeitet und deshalb key_n=* veraltet ist …

Ergebnis: die Syntax key_n=* ist nicht nur (1) schwer auszuwerten, sondern (2) auch semantisch unklar: es ist nicht eindeutig, ob ein Tag key_n=* nun den Wert von key_=* ergänzen oder ersetzen soll. Daher sind die key_n-Tags mMn ‘verbrannt’ und sollten vermieden werden. Falls wir wirklich mehrfache Werte brauchen, können wir, wenn es nicht spezielle Tags gibt wie bei name=*, auf die gute alte umstrittene ;-Syntax zurückgreifen (die immerhin den Vorteil hat, klar als ‘mehrere alternative Werte’ definiert zu sein, und auf jeden Fall leichter auszuwerten sein sollte).

() Ich habe mal alle damals vorkommenden key_n= in Baden-Württemberg untersucht und das war mein Ergebnis.

Mit dieser Overpass-Abfrage müsste man eigentlich viele der _n-Tags finden: http://overpass-turbo.eu/s/dzY .

[out:json][timeout:25];
// gather results
(
  (
  // Unterstrich-Tags
    (
    node[~".*_[123456789]$"~"."]({{bbox}});
    way[~".*_[123456789]$"~"."]({{bbox}});
    relation[~".*_[123456789]$"~"."]({{bbox}});
    )
   -
  // aber nicht TMC
    (
    node[~"^TMC*"~"."]({{bbox}});
    way[~"^TMC*"~"."]({{bbox}});
    relation[~"^TMC*"~"."]({{bbox}});
    )
  )
  -
  // und nicht fuel
  (
    node[~"^fuel*"~"."]({{bbox}});
  way[~"^fuel*"~"."]({{bbox}});
  relation[~"^fuel*"~"."]({{bbox}});
  )
  ;
);
// print results
out body;
>;
out skel qt;

Wir hatten das Thema der …_1 …_2 …_n-Tags übrigens mindestens schon einmal, nur etwas genereller:

http://forum.openstreetmap.org/viewtopic.php?id=30806

mit allerhand interessanten Beobachtungen und Statements.

Oh danke, da finde ich auch meine beiden Links wieder, die ich eben schon gesucht habe:

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, …