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

Nein, die ref ist nicht «genau genommen nur “1”», denn die Form bzw. Farbe des Schildes kodiert den Straßentyp. In schriftlichen Unterlagen ist die korrekte Referenz “B 1” (über den Abstand kann man ggf. noch streiten :).

Aber eher nicht, um es in OSM einzutragen. Natürlich sind sämtliche Namen, Referenzen usw., die wir eintragen erfunden - sogar die Zeichen, die wir dafür verwenden sind erfunden. Der wesentliche Punkt, um den es hier geht, wenn wir von “erfunden” sprechen, ist, ob/dass eine Bezeichnung von einem Mapper nicht aus einer Quelle übernommen wird, sondern sie sich selbst ausdenkt.

Das selbe Prinzip haben wir z.B. auch beim name-Tag. Wenn eine Straße keinen Namen hat, dann erfinden wir nicht einen, nur damit sie auf der Karte leichter zu finden ist und offensichtlich erfundene Werte ohne Quelle (z.B. schon oft gesehene name=Ausblick auf tourism=viewpoint) lassen wir auch nicht einfach bestehen, ohne dass es dafür einen Beleg gibt.

Weitere unwichtige Details:

Hier wurde im April 2008, einen Monat vor dem die Deutsche Anleitung erstellt wurde, der REF-Schlüssel für Radrouten (Relationen) im internationalen Wiki erstmals dokumentiert - https://wiki.openstreetmap.org/w/index.php?title=Cycle_routes&diff=91249&oldid=83122 - Autor ein in OSM Kreisen namhafter Brite. Die rcn_ etc. Prefixe kann man sich bei der Relation sparen, weil aus dem Network klar.

Merke: Der Datentyp ist “number” und ist es dort bis dato geblieben.

Hierzulande (Österreich) gibt es den R3, der müsste nach britischer Manier “3” als ref bekommen, natürlich hat der “R3” als REF, weil das steht auf allen Schildern so. Auf Schweizer Gebiet hat der tatsächlich eine rein numerische REF, sobald auf Deutschem Gebiet allerdings ein Kürzel aus Buchstaben als REF, das garantiert nirgends ausgeschildert ist :wink:

+1

Das klingt doch nach einem vernünftigen Vorschlag.:slight_smile:

Mein Anliegen für das Starten der Diskussion war a) zu klären, ob die die Wikiänderung breite Unterstützung findent und bleiben kann und b) einen Kompromiss zu finden, wenn dies nicht der Fall ist.

Beides ist nicht zu erkennen, deswegen habe ich das Wiki erstmal im Sinne von Mammi71s Vorschlag geändert.

Das erscheint mit aktuell auch die beste Lösung.

Das sehe ich auch als das wesentliche Problem, wenn man die Regeln für ref zu streng auslegt. Es gibt keinen Algorithmus, der aus den z.T. sehr komplexen Routenbezeichnungen das Wesentliche extrahiert. Dafür ist statt KI die normale Alltagsintelligenz weiterhin besser.

Mit “erfunden” hat das nichts zu tun, auch was komplexe Algorithmen erzeugen, ist im Grunde “erfunden” und gut ist es häufig nicht.

Das mag in manchen Regionen nicht so problematisch zu sein - wo ich lebe, gilt es ein unglaubliches Kuddelmuddel aus verschiedensten Routenbezeichnungen mit Moden der letzten 40 Jahre irgendwie abzubilden. Und es gibt vereinzelt offizielle Referenzen, die sich in Nachbarkreisen doppeln (noch spätauswirkungen einer 70er Jahre rationalistischer Fortschrittsmentalität, alles mit kryptischen Kürzeln zu technisieren), dann offizielle Namen als blumige Beschreibungen in ganzen Sätzen, jetzt eher knackige Pop-Worte, die die Werbeentwicklung im Zuge der SMS, Twitter und Messenger widerspiegeln.

Das ist eine ziemliche Herausforderung, und die Integrationsleistung der Menschen vor Ort, die die Situation kennen, ist nicht einfach “Erfindung” sondern häufig prägnant und gut nutzbar.

So würde ich da nicht argumentieren. Es ist m.E. nicht “Hilfe für den Renderer” sondern Aufbereitung der Daten als solche für allgemein bessere Nutzbarkeit - allerdings nicht mit streng mathematischen Regeln sondern “fuzzy logic”.

Der Begriff “falsch” ist m.E. hier wirklich fehl am Platz und paßt auch nicht in das Konzept von OPENstreetmap. Es müßte eher “dem Wiki widersprechend” heißen. Wenn der Konsens ein anderer wäre, wäre wieder etwas anderes richtig und falsch. Außerdem bleibt immer ein Stück Interpretationsspielraum. Ich denke, wir sollten die Polarisierungen in dieser Art hier vermeiden, das führt nur zu Unmut und blockiert die Lösungsfinden.

Grüße,
Sebastian

In Deutschland stimmt die Abkürzung wenigstens noch. In Österreich war das historisch genauso, mittlerweile sind die B-Straßen aber Sache des Bundeslandes und nicht mehr des Bundes, die Abkürzung B ist aber geblieben (außer in Vorarlberg, wo laut Wikipedia B n in L n umbenannt wurden). Trotzdem werden sie oft umgangssprachlich noch als “Bundesstraßen” bezeichnet.

Ich komme erst jetzt dazu einige Dinge nachzuarbeiten und zulesen… hatte rechtes Schulteraua (einklemmter Nerv) was ich übers Wochenende mit Salbe und Heizkissen auskurierte…

Nachträglich auch von mir
+1

ich engagiere mich ja soweit ich die Möglichkeiten habe, hier in Südbrandenburg mit der Erfassung, Pflege und Vervollständigung von Fahrradknotenpunktnetzen. Ich habe dazu auch immer wieder mal Kontakt mit anderen Mappern, die etwas Beitragen und ich im Laufe dessen sie animiere mehr zu machen… So z.B. https://www.openstreetmap.org/changeset/107780917#map=14/51.7318/14.5939&layers=N Mit ihm bin ich im PN-Austausch…

Dies geht aber auch immer einher mit Themenradrouten, um deren refs es ja hier geht… Wenn man systematisch solche Routen ergänzen, vervollständigen und/oder korrigieren will, kommt man um eine Nutzung eines Routen-refs nicht herum, und wenn es ein in OSM festgeleger, zunächst als intern zu betrachtender ref ist… Auf diese Notwendigkeit kommt man als praktischer Mapper und nicht als jemand der alles streng Wiki-Affin auslegen möchte…

Ich habe viele der vom mir erfassten Kontenpunkte mit einer note=* (z.B. https://www.openstreetmap.org/node/2026273154) versehen. … unterm Strich völlig unstrukturiert und nicht auswertbar, diese Themenradrouten-ref’s im note-Tag habe ich leider immer ignogiert, was mir in der nachträglichen Auswertung auf die Füße fällt… Struktutiert erfasst, auch in Verbindung mit ref=* einer Themenradroute könnte man da durchaus eine OSM-interne Gegenprüfung entwickeln, um herauszufinden:

Verlaufen Gurkenradweg (ref=GUR) und Niederlausitz-Spreewald-Radweg (ref=NSR) zwischen Knotenpunken 71 , 69 und 65 auf den selben Wegen oder nicht (wiedrum ein Querverweis zur Benutzungspflicht von Radwegen…
Auch eine Verarbeitung im von mir nicht sehr geliebten direction-Tag wäre durchaus denkbar…

So bleibt nur eine äußerst zeitaufwändige visuelle Auswertung…

datenverarbeitungstechnische Grüße,

Sven

Ich bin kein Deutscher, lese dieses Forum nicht und lese auch keine 4 Seiten Diskussion hier im Detail durch*. Ich diskutiere auf talk-at, wenn mich jemand erreichen will. Allerdings wurde mir gesagt, ich solle doch hier meine Meinung kund tun und so mache ich da.

Ich finde jedenfalls, dass jegliche ref=* die nicht vor Ort ausgeschildert ist, als frei erfunden zählt (ganz gleich, wovon sie abgeleitet ist oder sowas), und in der OSM-Datenbank genauso wenig verloren hat wie komplette Phantasienamen und -daten. Dass hier im duetschen Wiki zu etwas angeregt wurde, was IMHO Falschmapping ist, gehört m.E. sofort revidiert, und bestehende ref=* nur dort belassen, wo sie auch dementsprechend vor Ort ausgeschildert sind. Denn bei OSM gilt so weit ich weiß nach wie vor die Regel, dass das korrekt ist, was man vor Ort so auch findet - und nicht etwas, das am Renderer hübsch aussieht, weil man ja sonst gar keine Kürzel gerendert sieht. Das ist Taggen für den Renderer und gilt so weit ich informiert bin, also verpönt in der Community. Warum es hier also korrekt sein soll, entzieht sich meines Verständnisses.

  • Bearbeitung: Ich habe jetzt die 4 Seiten doch durchgelesen und daher ergänze ich noch etwas: Wenn man zur Erleichterung von Auswertungen diese “erfundenen” Kürzel trotzdem abgeben will, dann würde ich vorschlagen, das zur Klarheit in einem eigenen Tag zu machen, sowas wie community-proposed:ref=* (oder etwas kürzer, wenn eine gute Idee dafür existiert), und dieses Tag dementsprechend im Wiki zu dokumentieren. Jene Renderer oder andere Tools, die darauf zurück greifen möchten, können das dann tun, und die “Integrität” des eigentlich ref=-Tagging muss dadurch nicht kompromittiert werden. Es kann auch ein abbr_name= oder sowas sein - wie gesagt, wenn es dafür im Wiki dementsprechend dokumentiert ist.

Das klingt haargenau wie das, was man so als REF vorfindet :slight_smile: Als Fremdschlüssel defamiert, als “interner Verarbeitungsbehelf” gelobt.

Ich zitiere mich mal selbst:

Ich gehe sogar noch weiter. Selbst für eine interne Datenberarbeitung, Routenvergleich oder Fehlerprüfung wäre ein ref für einen Mapper notwendig… wenn es ein “offizieller” ref ist, übernehmen wir ihn… gibt es einen solchen “offiziellen” ref nicht, obliegt es den “offiziellen” Stellen, unseren ref zu übernehmen.

Ich habe lieber “direction_= mit einer ref-Angabe der Themen-Radroute die in diese Richtung geht, als daß ich auf ref verzichte… Da ackere ich lieber meine Fotos der Knotenpunkte durch und hacke sie ins direction… Auch wenn ich direction für praktische Anwendungen für nicht auswertbar halte…

Sven

Naja, genau genommen haben wir mit der Relations-ID so einen internen ref. Allerdings ist diese lange Zahl alles andere als endnutzer- und anwenderfreundlich.

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.