alt_name und name_1 - Voting

kann mir jemand den Unterschied zwischen diesen Tags (alt_name / name_1) erklären? Aus dem Wiki konnte ich nicht wirklich was herauslesen, auch schon verwendetes Tagging erschien mir nicht schlüssig.

name_1 ist falsch und muss entfernt werden, wenn es irgendwo vorkommt. Gilt für alle Tags, die auf _1, _2 usw. enden.

na und warum stehts dann im Wiki? im Grunde fänd ich das ja auch richtig, aber was macht man dann wenn es mehr als einen alternativen Namen gibt?

So ein schmarn. Wie kommst du zu der Aussage, dass einfach etwas zu löschen ist??
Sofern möglich, ist ein alternatives Tag dafür zu verwenden, aber sonst nix.
Dafür wäre dann ein Beispiel auch mal ganz hilfreich… :wink:

Nun mal langsam. Davon gibt es derzeit 1343 Nodes (Poi) in OSM. Ways und Rels kämen noch dazu.
Ein pauschales “das ist Mist und kann weg” ist hier nicht angebracht.

Klar, ich wäre das Zeug auch gerne los, aber nicht so.

Gruss
walter

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!