ref bei Radrouten nur noch mit offizieller Nummer sonst ohne ref?

Das kann man so radikal sehen, muss man aber nicht.

Wir leiten die refs aus dem offiziellen Namen ab, weil es sonst Algorithmen tun oder Informationen zur praktikablen Unterscheidbarkeit fehlen. Ob die Ableitung korrekt ist, also die Buchstaben in der Reihenfolge vorkommen, ist für jeden überprüfbar. Wir machen das, weil Menschen das besser können als die Algorithmen der Renderer. In anderen Sprachen gibt es keine zusammengesetzten Substantive, da kann haben es Algorithmen leichter, im Deutschen gibt es keinen Anhaltspunkt dafür, welche Buchstaben zu nehmen sind.

Ich vertrete sogar die Meinung, dass ein ref überhaupt nicht ausgeschildert sein muss. Im Prinzip würde eine fortlaufende Nummer schon ausreichen, so wie die ID der Relation. Nur ist das extrem nutzer- und mapperunfreundlich, und wir sollten immer daran denken, für wen wir das hier alles machen.

Dir ist bewusst, dass du eine seit über 10 jahren deutschlandweit bewährte Taggingpraxis über den Haufen werfen willst. Man müsste alle Routen überprüfen und ggf. ändern, die Renderer müssten angepasst werden. In der Übergangszeit werden Radkarten schlechter, weil die Radrouten voneinander nicht mehr zu unterscheiden sind.

Wofür der ganze Aufwand und Ärger? Wo genau tritt ein praktisches Problem beim Mappen oder beim Anwender auf, das damit gelöst wird? Und wenn da eins ist, sind die Auswirkungen so groß, dass es die negativen Auswirkungen, den Ärger und Aufwand wert ist? Wäre dir das soviel wert, dass du da Wochen Arbeit reinstecken würdest und alle Betreiber & Ersteller der Routen abtelefonierts und alle relevanten Datenauswerter überzeugst oder sollend as andere tun?

Ja, man könnte für as abgeleitete ref auch einen andern Tag nehmen, das wäre ein Stück sauberer. Aber was ändert das? Aus Sicht der Hardliner ist das weiterhin frei erfunden. Zudem gibt es auf Dauer ein Kuddelmuddel aus alter und neuer Taggingweise, weil kaum jemand die Lust haben wird, alles systematisch zu überprüfen und zu ändern, ohne dass jemand einen praktischen Mehrwert davon hat.

Mich erinnert diese Diskussion ein wenig an christliche Fundamentalisten, die verlangen, dass die Bibel wortgetreu zu nehmen ist, koste es was es wolle und egal, in welchem Kontext das Buch geschrieben wurde und was die Schreiber damit eigentlich bezwecken wollten.

Ich wünschte mir mehr Pragmatismus, eine Abwägung von Kosten/Nutzen/Schäden bei Änderungsvorschlägen und dass die Auswirkung auf die Nutzer unserer Arbeit eine größerer Rolle spielt.

In der Diskussionsseite im Wiki ist eine Diskussion und entbrannt, ob der Vermerk auf die Strittigkeit des Themas hilfreich und zulässig ist. Wir haben uns hier auf dieses Vorgehen geeinigt, um etwas Zeit für eine Kompromisslösung zu bekommen. Das heißt für mich, dass wir diesen Vermerk nicht ewig stehen lassen sollten, denn wenn sich kein Kompromiss für eine Änderung der deutschen Praxis findet, hat der Verweis keinen Mehrwert.

Daher nehme ich nochmal einen Anlauf dazu. Wenn der keinen Erfolg hat, sollten wir den Verweis wieder rausnehmen.

Wenn eine Änderung der Tagging-Praxis Akzeptanz haben soll, so muss m. E.

  1. der praktische Mehrwehrt für Mapper und Datenkonsumenten ersichtlich sein

  2. negative Auswirkungen minimiert sein, z. B. kein (temporärer) Wegfall von Kurzbezeichnungen in den Karten

  3. Aufwand und praktischer Mehrwert in gutem Verhältnis stehen

  4. eindeutig erkennbar sein, ob es nach neuem oder altem Schema gemappt wurde (das sett/cobblestone-Problem)

Für a) sollten wir alle praktischen Anwendungsfälle auflisten, die mit der bisherigen Praxis nicht gedeckt sind. Ich bin alle 100 Beiträge durchgegangen und habe folgende Anwendungsfälle gefunden:

  1. Streit vermeiden bei verschieden abgeleiteten refs für dieselbe Relation (z. B. Donauradwanderweg als “DRW” oder als “DRWW”) woodpeck in #36

  2. Erkennen des Adressaten (Betreiber oder Mapper) um Vorschläge für ein besseres ref zu adressieren SafetyIng in #75

  3. Entscheidung, welcher ref geändert wird, wenn es in einer Region einen anderen Weg mit gleichem ref gibt JochenB in #77

Gibt es noch mehr?

Für den Anwendungsfall 1) würde ich die Streitenden auf das Forum verweisen. Bislang ist mir eine solche Diskussion aber noch nicht untergekommen.

Für die beiden Anwendungsfälle 2) und 3) lassen sich Kompromiss-Ansätze finden, siehe unten.

Den praktischen Mehrwert im Sinne c) schätze ich als eher niedrig ein. Niedrig, weil die Alternative wäre, Mapper und Betreiber anzuschreiben, um zu erfragen, woher der ref-Wert kommt. Es wird also für jeden Anwendungsfall der Aufwand eines zweiten Mailverkehrs vermieden. Da die Anwendungsfälle eher selten sein werden, ist die Summe des eingesparten Aufwands überschaubar. Der Aufwand aufgrund der Wiki-Änderung darf wegen c) also nicht hoch sein.

Folgende Kompromissansätze habe ich in den 100 Beiträgen gefunden:

  1. Differenzierung der Praxis für DE und für AT im Wiki, falls Radrouten in AT üblicherweise offizielle refs haben Pfad-Finder in #41

  2. ‘short_name’ und ‘alt_name’ SafetyIng #48

  3. 'source:ref=‘* zusätzlich zu 'ref=’* JochenB in #51

  4. 'abbr_name='* Negreheb in #55

Für 1) habe ich schon den Anfang gemacht, und im Wiki die Ableitung als deutsche Praxis bezeichnet.

  1. hat das Problem, dass es hier ja nicht um Namen geht, sondern Codes, Zahlen bzw. Abkürzungen.

  2. hat das Problem, dass die Kürzel (vorerst) aus den Karten verschwinden so dass b) nicht gewährleistet ist. Zudem tritt d) ein: bei einem fehlenden ‘abbr_name’ wird man weiterhin nicht wissen, ob der ref-Wert offiziell ist oder ob das noch die alte tagging-Praxis ist. Das ist genauso wie man bei ‘surface=cobblestone’ auf lange Zeit nicht wissen wird, ob das wirklich unbehauene Pflastersteine sind oder noch die alte Interpretation, wo cobblestone auch gehauene Steine (neu ‘sett’) umfasste.

Drum hatte ich 3) vorgeschlagen, z. B. ‘source:ref=derived/official’ hier ist keine praktische negative Nebenwirkung erkennbar. Allerdings wird der Wunsch nicht erfüllt, dass die abgeleiteten Werte einen eigenen Tag erhalten. Da aber erkennbar ist, ob der Wert abgeleitet wurde, vermute ich, dass man damit leben kann.

Was denkt ihr darüber?

…die dann uneindeutig wird, wenn eine Themenradroute aus mehreren Teilrouten besteht… Da wäre für mich Chaos vorprogrammiert… abgesehen davon, was der Auswerter dann mit dem Relations-ID im direction-Tag anstellen müsste und der Endanwender mit der Nummer nichts anfangen kann…

Jeder der touristisch mir dem Rad unterwegs ist, sollte “Hist 6” als “Radrouten historische Stadtkerne 6” verstehen, wenn es auf einer Online-Routingangabe oder einer Karte steht. Versteht er es auch noch, wenn der Relations-ID “4028424” angegeben ist? Die verlinkte Themenradroute hat übrigens mehrere Teilrouten; keine Seltenheit.

Ich selbst kann nur davor warnen, hier die gelebte Praxis, daß etablierte System in Frage zu stellen… Das wäre ideal, die erfassten Daten, die jetzigen Auswertemöglichkeiten vollends kaputt zu machen.

Sven

+1. Mindestens in DE hat die “normative Kraft des Faktischen” (=die Tatsachen machen das Gesetz) so weit gewirkt, dass die Versuche einiger Nutzer, “ref” auf eine enge Auslegung zu beschränken, in meinen Augen wie der Versuch anmuten, Zahnpasta in die Tube zurückzustopfen. Die “breite” Auslegung von “ref” ist seit Jahren geübte Praxis in DE, die Renderer und ggf. Router sind darauf eingestellt, alle Anwender leben gut damit. Warum also ändern? Nur wegen der “reinen Lehre”? Ich mache bei OSM mit, weil ich als regelmäßiger Anwender etwas zurückgeben will. Wenn Daten wegen “reiner Lehre” verschlimmbessert werden, kann ich meine Zeit auch woanders verbringen.

In CZ - mit einem rein zahlenbasierten Radroutensystem - sind die Refs selbstverständlich die offiziellen Zahlen und nicht zum Beispiel “CSO” (frei erfunden für “Cyklostezka Ohre”, Eger-Radweg). Das ist die Radroute mit ref=6. Aber DE ist nicht CZ.

Absolute Zustimmung!

+1

Flasche “Kurzbezeichnungen” sollten jedenfalls wegfallen, IMHO. Und wenn man OSM-spezifische nicht ausgeschilderte Kurzbezeichnungen will, dann muss man sie mal in einem neuen Tag taggen, und als ref wegnehmen, und dann müssen die Renderer angepasst werden, um das neue Tag zu verwenden. Dabei muss man gewillt sein, dass vorübergehend etwas nicht gerendert wird, sonst ist nie ein “Druck” bzw. ein gutes Argument da, um den Renderer wirklich anzupassen.

Aber generell läuft diese Diskussion wohl darauf hinaus, dass ich bei meinen Edit in der Zukunft wohl wenn ich gerade Lust hab, frei erfundene ref-Tags dort dranhänge, wo es mir gerade gefällt (ganz gleich, welche Objekte das sind, Routen greife ich eh selten an), weil das ja eh gängige Praxis in OSM ist.