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.