alt_name und name_1 - Voting

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

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.