Repräsentation des aktuellen offiziellen deutschen Radverkehrsnetzes (nach den Vorgaben der FGSV) in OSM

Du warst eigentlich nicht gemeint, sondern @segubi.

Auch wenn es Off-Topic wird. Ich habe hier vor Ort, die neuen Radwegschilder genutzt. Jede Kreuzung eines. Was ich da anhalten musste, war grausam. Soll heißen, ich glaube Du wirst bei deinem System nur anders/mehr behindert.

Wie dem es nun auch sei, Osmand und/oder Locus haben eine Funktion, dass sich der Zoom dem Tempo anpasst.

Weiter kann man bei beiden Apps die Zoomstufen vergrößern und verkleinern. Osmand: Langes Tippen auf das + Zeichen rechts unten.

Vielleicht wäre eine App mit aufgeteiltem Bildschirm besser. Ein Teil zeigt den Bereich der in x Metern erst kommt, deutlich vergrößert an.

… achso. Naja, ich habe ja schon ausgeführt, dass ich es nicht als Großprojekt empfinde.
Im Grunde geht es mir genau um die Frage, um die sich gerade der Austausch im Changeset: 127533538 | OpenStreetMap dreht: Wie geht man mit der Differenzierung zwischen alten Netzwerkresten (wie es anscheinend das Südhessennetz mit Nummern) ist, und dem aktuellen Ausschilderungsschema, das bundesweit eingesetzt wird (was ich in der Überschrift als “offiziell” bezeichnet habe) um.
Das ist für mich wirklich eine offene Frage, aber es ist deutlich, dass ein rcn/lcn=yes an den Einzelwegen überhaupt nicht in der Lage ist, im Datenbestand zu definieren, um was für ein Netz es sich eigentlich handelt.
Und da die Netze (zumindest hier in der Region) munter weiter umgestaltet werden, erlebe ich es als einfacher, bei einer geänderten Routenführung zwischen zwei Punkten die Relationen zu korrigieren. Ob dabei Fehler oder Lücken entstanden sind, ist z.B. mit JOSM schon beim Editieren sichtbar. Für das Taggen an Wegen gibt es keine Möglichkeit einer Plausibilitätskontrolle.
An der Stelle, auf die sich o.g. Changeset-Diskussion bezieht, bin ich tatsächlich unentschlossen, was man mit der Überlappung von alten und neuen Netzen macht.
Ich persönlich gehe pragmatisch so vor, dass ich in den Fällen, wo alte Netze und Routen vollständig nach dem neuen System ausgeschildert sind, und insofern in dem neuen Netz aufgehen, ich nur die benannten und nummerierten Routen in Relationen fasse, und die unbenannten basic_network-Relationen für unbenannte Abschnitte verwende. In den Fällen, wo diese Übernahme nur unvollständig ist, habe ich im Moment keine bessere Idee, als die Abschnitte, die nach dem neuen Ausschilderungsschema ausgeführt sind, in basic_network-Relationen zu erfassen, auch wenn sich hierbei Überlappungen mit anderen Routen ergeben.
Wer eine bessere Idee hat, die ermöglicht, diese Information aus den OSM-Daten später wieder zu extrahieren, soll sie gerne mitteilen.

Und dazu muss ich etwas sagen. Ich finde es etwas unglücklich, dass Du aus der Aussage eines Ortskundigen, der ich bin, als Ortsfremder solch weitgreifende Schlüsse ziehst.

Denn das ganze Netz zieht sich über mehrere Landkreise und gestern konnte ich sehen, dass es in einer anderen Gegend, wo ich extrem selten aufschlage, ziemlich gut gepflegt ist.

Dann kommen wir zum Frankfurter Netz, irgendein eifriger Mensch aus Kassel hat eine Monsterradnetzrelation erstellt. Jemand anderes, in NRW lebend, hat sie gelöscht, dabei dürften nicht unerhebliche Daten verloren gegangen sein.

Und jetzt als einfacher Wald und Wiesenmapper, frage ich mich, soll ich jetzt Daten, noch einmal erfassen, weil irgendwelche Leute die Daten als ihre Spielwiese betrachten.

Ich habe die Fehler, die in meiner näheren Umgebung waren, korrigiert. Durch die Löschaktion sind diese Infos perdu.

Okay, durch diese Korrektur kam raus, dass diese Monsterelation existiert. Aber hier in der Gegend gibt es so manch eigenartige Relation. Aber ich fasse die Sachen überhaupt nicht an, weil ich mittlerweile überprüfen muss, ist die Relation korrekt erstellt oder löscht, dass jemand, weil irgendetwas OSM-politisches los ist.

Bei dem Weg in dem Changeset hätte ich schon längst ein lcn=yes drangepappt, und jeder wüsste, okay, soll nett für das Radfahren sein.

Genauso würde ich in Frankfurt, so manches so simpel klären, wenn es da nicht notes und fixme eines nicht ortsansässigen Mappers gäbe, der es ganz genau haben will.
Andererseits klagt just dieser Mapper, dass die Netze so schlecht gepflegt sind. Aber genau der betreibt die Verkomplizierung der Sache, sodass man das halt nicht mehr im nebenbei betreiben kann.

Könnte es nicht sein, dass Du das Problem erzeugst, was Du beklagst und lösen willst?

Ich fahre selbst gerne in der Freizeit Fahrrad und nutze das Fahrrad auch für relativ lange Strecken, um von A nach B zu kommen. Hierfür habe ich die aktuelle Wegweisung grundsätzlich sehr schätzen gelernt, mit der ich mich einigermaßen darauf verlassen kann, dass ich auf dem Weg von A nach B nicht mal 20 km an einer Bundesstraße mit Abgas- und Lärmbelästigung radeln muß (was passiert, wenn ich einen Routenvorschlag über die Routing-Apps annehme), sondern wo möglich auch etwas verkehrsferner geführt werde, ohne dass ich mir einen Weg mühsam aus Themenroutenabschnitten und unzuverlässig getaggten “highway=track” Wegen zusammenklauben muß, um dann doch über Privatgelände mit freilaufenden Hunden zu geraten, weil ein access=private Tag gefehlt hat.

Wenn man aber eine Route planen will und nicht auf gut Glück auf eine längere Strecke losfahren will, ist es schön, eine Karte zu haben, in der man sehen kann, ob es in der gewünschten Region solche Strecken überhaupt gibt, und ob man auf große Umwege geschickt wird.

Dein Problem ist kein Problem der Erfassung, sondern des Renderings. An der von dir angeführten Stelle, ist es für deine Fragestellung vollkommen egal, ob das jetzt die Südhessenroute xyz ist, sondern es ist ein Teil irgendeines Radwegnetzes.

Der Witz ist, das Frankfurter Netz wurde früher ohne Relationen gerendert. Damit es jetzt gerendert wird, muss man es für manche Renderer in Relationen packen.

Edit: Ich hätte kein Problem, den östlichen Teil der Frankfurter Innenstadt aus dem Kopf zu mappen. Aber die ganzen Zusatzinfos, die es nach deinem System braucht, die müsste ich erfassen. Die Zeit habe ich nicht.

In diesem persönlichen Zusammentreffen wird klar, wenn die technische Eingangsschwelle der Erfassung so hoch angesetzt wird, bekommt man nicht die Daten, die man pflegen will.

1 Like

Welche Schlüsse meinst Du?

Die Daten sind verloren gegangen, als sie durch die Monsterrelation ersetzt wurden, nicht durch die Löschung der Monsterrelation, die schon längere Zeit vorher . Das war aber vermutlich nicht einmal der Ersteller der Monsterrelation. Siehe bitte hierzu auf der Userseite von celsius11 | OpenStreetMap . (Sehe gerade auf der Seite, dass Du offenbar ohnehin im letzten September irgendwie involviert warst, also zumindest doch die ganze Angelegenheit schon seither kennst).

lcn=yes heißt NICHT “nett für das Radfahren”, sondern Zugehörigkeit zum “Lokalen Fahradnetzwerk” (was immer das heißt… ist keine für das gegenwärtige Radnetz in Deutschland erfundene Kategorie). Aber kann man so machen…

Dein Ärger ist in den Posts unübersehbar. Ich kann es nachvollziehen, wenn Du Dich unter Druck gesetzt fühlst, ein komplizierteres Taggingschema zu übernehmen. Das mußt Du ja aber doch überhaupt nicht.

Ich mache keine Vorgaben. Gemappt werden muß überhaupt nicht so komplex, wie ich es tue, und das Schöne ist, dass die verschiedenen Vorgehensweisen ohne Probleme parallel existieren können und auch von Routern sowie Renderern ohne Probleme parallel verstanden werden. Ein allmählicher Übergang wäre problemlos möglich, ich kann mir auch vorstellen, dass zur Vereinfachung plugins für die Editoren programmiert werden können, sobald ein ausreichendes Interesse bestünde.

Nur: Die bisherigen Mappingpraktiken ermöglichen nicht die Identifikation des aktuellen Radnetzes im Kontrast zu alten Daten und anderen Routen ohne eine sehr komplexe lokal individuelle Auswertung der OSM-Daten zu machen (z.T. nur über color-Tags, die die Farben der Schilder wiedergeben usw., oder name-Tags, die komplex geparst werden müßten) . Ebenso ist die Beurteilung, wie alt der jeweilige Datenbestand ist, nur sehr schwierig. Es handelt sich im Gegensatz zum Ausbauzustand der Autostraßen tatsächlich um sehr mühsame Beobachtungen. Daher ist der Datenbestand teilweise sehr alt, und eine automatisierte Qualitätskontrolle (mit Informationen wie z.B. “wo sind Routenabschnitte länger als 5 Jahre nicht überprüft worden?”) sehr hilfreich.

Mein Anliegen ist nur, dass wir irgendwie eine Methode finden, wie man es einheitlich machen könnte. Am besten im Konsens und auf der Basis möglichst geringer Änderungen der jeweiligen lokalen Praktiken, so dass möglichst wenig Änderungen im Gesamtdatenbestand nötig sind.

Zu Celsius11. In einer Mail am 14.10 an mich, schreibst Du, dass er der Ersteller der Relation war.

Da ich die History der Relation auf meinem Rechner habe, er hat die Relation erstellt. 92 Prozent der Edits in der Relation stammen vom ihm. Und das Thema, dass durch das einfache Löschen der Relation, dann die von Celsius11 gelöschten Daten noch gänzlicher verschwinden, war zwischen uns beiden in einem Mailwechsel ein Thema.

Auch wusstest Du schon ohne mich, dass Celsius11 diese Edits in sehr kurzer Zeit durchgezogen hat.

Ich greife mal heraus:

die schon längere Zeit vorher

Der letzte Edit von Celsius11 war am 25.9. Die letzten Relevanten am 28.7. Du hast am 17.10 gelöscht.

Es gab in diesem Mailwechsel zwischen uns beiden auch von dir Überlegungen, wie man diesen Datenverlust verhindern könnte.

Von dem stufenweisen Vorgehen ist in der Relationshistory nichts zu merken. Du hast 2022-10-14T22:24:10Z gelöscht. Das war deine einzige Maßnahme zu der Relation.

Auf den Löschbutton hätte ich genauso drücken können, aber ich habe es nicht getan, weil ich eine Rettung oder Wiederherstellung der Daten auf die Celsius11 zurückgegriffen hat, für wichtig erachtet habe.

Ich habe nicht den Eindruck, dass dir die Rettung dieser Daten sehr wichtig war. Das Verstecken hinter Celsius11 musst Du mit dir selber ausmachen.

Ich fühle mich nicht unter Druck gesetzt. Ich beobachte nur, dass ich immer wieder auf Dinge stoße, bei denen ich mich in so einer dicht besiedelten Gegend wie im Rhein-Main-Gebiet wundere, warum sie, solange nicht korrigiert worden sind.

Warum sind in den drei Monaten nach Löschen der Monsterrelation in Frankfurt so wenige neue Relationen entstanden, obwohl das Wegenetz visuell von prominenten Karten verschwunden ist und Frankfurt quasi blaufrei ist. Findet da eine Abstimmung mit den Füßen statt?

Weil ich habe mal versucht rauszufinden, wie die neueren Konzepte funktionieren könnten. Alle finden es furchtbar wichtig, aber eine simple Schritt-für-Schritt-Anleitung, mit der man nach 10 Minuten loslegen könnte, scheint eine Fehlanzeige zu sein.

Und vielleicht ist diese zwei Zitate ein Ausdruck der Situation.

Ich übersetze: Ich finde es wichtig und toll, aber es könnte mir zu viel Arbeit sein.

Gibt es jemanden der validiert? Ist das nicht der Radler, der feststellt, Wegführung verändert, das trage ich mal ein? Oder hoffst Du auf Menschen, die sich mit JOSM die Relationen anschauen, und dann im Zweifelsfall denn fragwürdigen Abschnitt vor Ort begutachten?

Wie sieht dieser Prozess der Validierung und Wartung des Netzwerkes überhaupt aus? Warum ist er so sinnvoll und wichtig?

Aktuell führen wir gerade eine Diskussion über die Routeneinschübe an Wegweisern, guidepost-nodes, für die ich gerne Anregungen mitnehme: Es geht um die Ergänzung der direction_= Tags um Routeneinschübe, die an einigen Stellen gemacht wurden. (Changeset: 139261262 | OpenStreetMap)

z.B.: direction_northwest=‘Osnabrück 21.0 km; Bifurkation 1.2 km; Wellingholzhausen 7.1 km;; “Else-Werre-Radweg”; “Niedersächsische Mühlen-Tour”’ in Node: ‪4986/5‬ (‪11079042147‬) | OpenStreetMap

Meine Empfehlung: Eher ein unabhängiges Tag zu verwenden, um die verschiedenartigen Informationen nicht zu vermischen, z.B.:
direction_northwest:route=Niedersächsische Mühlen-Tour; Else-Werre-Radweg

Interessant ist es, tatsächlich die Routeneinschübe vor Ort zu dokumentieren - nicht zuletzt, weil sie oft inkonsistent und fehlerhaft sind. Meine Praxis bisher war, nur die Routenrelationen zu verwenden und ausschließlich Ausschilderungsfehler zu dokumentieren in fix_guidepost=. Wenn ich es dem Betreiber gemeldet habe, auch ein Hinweis zum Ticket und das Datum der Meldung: fix_guidepost:ticket:date= zu hinterlassen.

=================
Inhalt der Changeset-Diskussion:

Segubi:
Ich würde davon abraten, die Routeneinschübe in die Direction-Angaben mit hineinzunehmen. Die Routen werden über Routenrelationen abgebildet. Das Problem ist, dass die “direction” Angaben tatsächlich Ziele beschreiben, also die Routeneinschübe nicht ausgewertet werden. Darüberhinaus ist die Wahl der Namen recht willkürlich und haben ein hohes Risiko, dass sie von Wegweiser zu Wegweiser Varianten aufweisen.
Ich finde aber die Frage tatsächlich ungeklärt, ob und wie man die Routeneinschübe in die Tags aufnehmen sollte, und denke, sie kann gerne weiter diskutiert werden. (Repräsentation des aktuellen offiziellen deutschen Radverkehrsnetzes (nach den Vorgaben der FGSV) in OSM DE:Tag:information=guidepost - OpenStreetMap Wiki DE talk:Tag:information=guidepost - OpenStreetMap Wiki… ). Ich tendiere dazu, diese Zusatzinformationen wegen Redundanz und Unübersichtlichkeit eher wieder rauszunehmen.

… Es muß halt einen zuverlässigen Algorithmus geben, mit dem das Tag so geparst werden kann, dass ein Routeneinschub von einem Ziel unterschieden werden kann. So wie Du es gemacht hast, würde es über die Anführungszeichen funktionieren. Das setzt aber voraus, dass es nie Wegweiser gibt, in denen Anführungszeichen verwendet werden. Das ist schwer garantierbar, auch wenn es sicher nur äußerst selten vorkommen dürfte, wenn überhaupt.

Z.B.: Klappe mal hier die Ziele auf: waymarkedtrails versteht das so nicht. Waymarked Trails - Cycling

Kommentar von GerdP vor 30 Minuten

Die Redundanz ist eher der Grund für das Mapping am Wegweiser. Ich stoße ja andauernd auf alte Relationen, bei denen nicht klar ist, ob die jemals ausgeschildert waren. Ein besseres Verfahren als bei den direction_* Angaben wäre mir auch recht, aber ich habe erst mal so begonnen, um Erfahrungen zu sammeln, wie gut das funktioniert. Die Darstellung in waymarkedtrails ist da für mich erstmal nachrangig. Ich habe aber tatsächlich wieder aufgehört, die Schilder von meiner Radreise zu mappen, da ich wohl sowieso nie wieder in der Gegend neue Routen erfassen werde. Die Idee stammt übrigens nicht von mir, sondern von einem Mapper-Kollegen aus Cloppenburg.

Kommentar von segubi vor weniger als einer Minute

Die Routen, die nicht ausgeschildert sind, gehören sowieso nicht in Openstreetmap und sollten auch gelöscht werden. Das ist soweit auch Konsens. Ich spreche i.d.R. die Ersteller an und frage nach, wie es sich verhält, und dann werden sie meist einvernehmlich gelöscht, wenn es nur ein “Routenvorschlag” ist.
Vielleicht müssen wir uns noch einen Ort für den Austausch mit etwas breiterer Öffentlichkeit suchen. Ich hätte kein Problem, zusätzliche Tags direction_south:route= xyz zu verwenden, das würde das Parsing leichter machen und die Tags direction_south=* blieben abwärtskompatibel.
Es spricht prinzipiell wenig gegen neue Tags, wenn sie funktionieren, und man damit bestehende Taggings schont.
Die Routenrelationen haben einen Key symbol=*, mit dem recht klar deutlich wird, dass es sich um eine ausgeschilderte Route handelt.
Ich finde es aber insgesamt durchaus sinnvoll, die Routeneinschübe zu mappen, und sie befinden sich am Guidepost, also gehören sie auch irgendwie an den entsprechenden node.
Ich kopiere mal gleich die Changesetdiskussion in den genannten Thread im Forum.

2 Likes

Siehe auch Hilfe gesucht für Landesfernradwege in Ba-Wü - #14 by GerdP und die folgende Diskussion um mögliche neue Rollen wie “disused”, “planned” etc.
Ich habe dort einige Argumente für die Erfassung der Symboltafeln an den Wegweisern im Zusammenhang erwähnt, ohne explizit auf die verwendeten direction_* Tags einzugehen. Für bessere Vorschläge des Taggings oder die “Absegnung” durch die Community wäre ich dankbar. Die Infos in neue Tags zu packen sollte mir leicht gelingen, sofern sich das hier als besser rausstellt.
Angefangen habe ich im Naturpark Wildeshauser Geest Way: ‪Naturpark Wildeshauser Geest‬ (‪1028919997‬) | OpenStreetMap, innerhalbs dieses Gebiets dürften fast alle Wegweiser entsprechend gemappt sein.

Gerade für unvollständige Routen, oder teilweise gut und an manchen stellen schlecht ausgeschilderte etc. wo es schwer operationalisierbar ist, sollte man unbedingt großzügig vom tag “note=*” Gebrauch machen, damit andere Mapper eine Orientierung haben, worum es sich bei dem Objekt handelt.
disused usw. ist ja als Lifecycle prefix - OpenStreetMap Wiki bereits etabliert.
Eine Route, die es nicht mehr gibt, aber mal früher vorhanden war, kann gut als abandoned:route=* getaggt werden. Damit kann man auch Routen markieren, wo einzelne Schilder noch stehen. Hier in meiner Region gibt es z.B. noch https://www.openstreetmap.org/relation/286726 Wege der Weserrenaissance, wo alle 10-20 km nochmal ein Schild hängen geblieben ist, und manchmal auch eher versehentlich in ähnlichen Abständen als Routeneinschub mit an einen Wegweiser frisch wieder eingehängt wurde.

Ich habe gerade mal nach der bisherigen Verwendung von Anführungszeichen in den direction_= Tags geschaut. Die Verwendung ist doch sehr häufig (besonders bei Wanderwegweisern), so dass eine automatische Differenzierung zwischen Zielen und Routen auf die Weise nicht möglich wäre. Das heißt, man muß es anders machen.

In Frage kommen auch die guidepost-Relationen, die ich aber sehr unhandlich finde.

Meine Motivation die Routeneinschübe unter Nutzung des tags “direction_=” zu erfassen war, dass diese wie die meist darüber stehenden Zielangaben zu benachbarten Orten unmittelbar an eine Richtung gebunden sind. Das gewählte Schema habe ich durch Austausch mit GerdP entwickelt und bisher keinen Widerspruch erfahren.
Hauptnutzen der Erfassung war und ist der Fall, dass Routenrelation noch nicht in OSM existieren oder unvollständig erfasst sind. So konnte nach und nach das Routennetz ergänzt werden - ohne gezwungen zu sein, Routen am Stück abzufahren. Ebenso ist einfach überprüfbar, ob der in OSM gewählte Routenverlauf zu der Beschilderung passt.
Die Schwierigkeit der eindeutigen Auswertbarkeit, konnte ich bei den erfassten Schildern bisher nicht beobachten - siehe z.B. hier Node: ‪CLP.048.1‬ (‪8241781657‬) | OpenStreetMap.

Vorschläge für ein passenderes Tag-Schema unterstütze ich. Der Vorschlag von Segubi für direction_northwest:route= finde ich gut.
Sobald ein Schema festgelegt ist, sollte ein “Bereinigen” der zuvor genutzten direction_ tags einfach möglich sein.

Ich hatte Beispiele wie 3671384964 mit direction_northwest=‘Freizeitanlage “Haus Rott” 0.8 km’, 3694744999 mit direction_southwest=‘Schulzentrum “Edith-Stein-Straße” 0.2 km’, 4124133461 direction_west=‘Freilichtmuseum “Zeitsprung” 400 m; Cottbus Chósebuz 15 km; Klinge 0,4 km’ usw. im Blick.

Ok, das ist noch machbar: man müßte dann alle als Routeneinschübe interpretieren, bei denen die Richtungsangabe unmittelbar mit den Anführungszeichen losgeht.

Aber dann gibt es z.B. diesen hier: 6726253464 mit direction_south=‘Seedorf 5,8 km; Route “Am Rand des Schwarzwalds”’. Die Information, dass keine Entfernungsangabe dransteht, ist auch nicht zuverlässig verwertbar, da manchmal einfach keine Entfernungsangaben an den Wegweisern dranstehen, besonders bei sehr kurzen Strecken und Einzelzielwegweisungen.

Ich glaube, ich würde das ein paar Tage abwarten, und mich dann daran machen, die Sachen umzutaggen, sowie im Wiki eine Ergänzung zu den Routeneinschüben zu machen.

Absolut einverstanden! Deswegen finde ich es auch wichtig, dass keine Information verloren geht.
Das ist wirklich eine schwierige Aufgabe, für die ich auch kaum eine gute Lösung habe. Leider sind halt die Routeneinschübe - hier zumindest - Kraut und Rüben. Oft melde ich ersteinmal den Kommunen über die Meldeplattform zurück, dass Fehler vorliegen, die brauchen dann manchmal über ein Jahr, bis sie reagieren und etwas ändern (falls überhaupt). Selbst neue Routen starten erst einmal mit Fehlanlagen. Und meine Lust, offensichtlich falsche Routeneinschübe zu mappen ist sehr begrenzt, daher habei ich mich bislang vor dem Mapping der Einschübe gedrückt, und daher kommt meine Verwendung von fix_guidepost als Tag. Die Routen erschließen sich dann oft erst bei rückwärtigem Befahren oder Interpolieren von Lücken…

Fehler bei den Routeneinschüben habe ich bisher in meiner Gegend nur selten entdeckt, aber ein paar Stellen kenne ich auch, wo offensichtlich die Tafeln von zwei Routen verwechselt wurden: Eine fehlt, eine falsche ist zuviel. Habe die entsprechenden Stellen auch gemeldet, aber es ist noch kein Jahr vergangen und daher noch keine Änderung zu sehen gewesen :wink:

Gut möglich, dass ich es übermäßig wahrnehme… wenn es passiert, hält es ziemlich lange auf. Habe nochmal overpass befragt, etwas über 1500 Guideposts sind von mir zuletzt bearbeitet worden, Fehler habe ich bei etwa 1% eingetragen, nur bei 49 habe ich etwas zu den Routeneinschüben moniert (da habe ich aber noch einen Überhang, den ich noch nicht eingearbeitet habe). Also… eher selten Fehler ;-)…

Nach einigem Nachdenken neige ich eher zu direction_:symbol als zu direction_:route. Keine Ahnung, wie verbreitet diese Einschubtafeln in anderen Ländern sind, ich kenne die vor allem aus D, aber ich glaube, in Österreich ist es ähnlich, müsste mal meine alen Fotos sichten. Als Bezeichnung für die Dinger kennen ich auch noch “Fähnchen” oder Dein “Routeneinschub”.
Bevor man es offiziell im wiki dokumentiert: Hier ein paar mögliche Problemfälle für Mapper:

  1. In vielen (den meisten?) Gegenden werden die Nummern der Nachbarknoten von Knotenpunktnetzwerken auch bei den Themenrouten “eingeschoben”. Hier solte man klären, ob man die mit erfasst und wenn ja:
  • nur die Nummer (mein Favorit) oder
  • die dadurch ausgedrückte Knotenroute. Bei einem Zwischenwegweiser der KP-Route 5-28 hätte man dann etweder “5” und “28” oder zweimal “5-28” (oder nur 5 und 28 bzw. 5-28)
  1. Wie man mit Symbolen umgeht, für die es noch keine Relation gibt und für die man (noch) keinen Namen hat. Siehe z.B. Name der Route? Schwarze Karnevalsmaske auf weißem Grund
    Ich habe noch so einen ähnlichen Fall, wo auf dem Schild kein Name steht, Symbol ist ein alter Mann mit Hut, ich glaube, so habe ich es auch erfasst und eine entsprechend note drangehängt.
  2. Im Südwesten Niedersachsens findet man oft Routen, die (im Internet) einen langen Namen haben, aber nur mit z.B. mit “BR 3” oder anderen Kürzeln (also der ref=*) ausgeschildert sind. Ich habe dann dieses Kürzel gemappt. In Bremen findet man eine Mischung aus beidem: Name der Route und Kürzel. Zum Beispiel die Route “H5 - Grün und Grenzenlos” hat eine Tafel, auf der "Grün und Grenzenlos steht und darunter in anderer Schrift “Grüner Ring H5”. Mit war da noch nicht klar, ob die ref zum Namen gehört oder nicht. Den Namen der Route werde ich wohl noch ändern und dann evtl. auch die Texte zu allen Wegweisern. (Hier ist diese Redundanz nachtürlich echt anstrengend, vor allem, weil man nicht so einfach ersetzen kann. Ich mache das daher mit JOSM in 4 Schritten: a) Alle zu änderden Knoten mit einem temporären Tag versehen, so dass sie als geändert markiert sind. Dann die Objekte als *.osm speichern. b) Mit Notepad die Änderungen an der *.osm durchführen und danach c) die Datei wieder in JOSM laden und das tempöräre tag löschen. d) Nochmal prüfen, ob Texte mit Umlauten richtig sind und dann hochladen.
  3. Im Raum Osnabrück findet man fast an jedem Wegweiser und oft (immer?) in alle Richtungen eine Tafel, die zuerst wie ein Themenroute aussieht, aber doch nur das Radwegenetz in Osnabrück beschreibt. Hier zum Bespiel in der Nähe des Bahnhofs Bramsche:

Ich habe diese Tafeln bisher nicht erfasst, aber einen guten Grund habe ich dafür auch nicht. Vermutlich wird an den Grenzen des Osnabrücker Gebiets manchmal nicht in jede Richtung so ein Schild dran gehängt?
In NRW scheint es gleich mehrere solcher Netze zu geben, die dann an fast allen Wegweisern auftauchen, z.B. die “NiederRheinroute” Relation: ‪NiederRheinroute‬ (‪5406832‬) | OpenStreetMap.
Die Symbole unterscheiden sich vielleicht geringfügig durch Farben und manchmal zusätzlich Nummern, wenn ich das richtig verstanden habe, aber diese “Netze” sind eigentlich keine Routen. Habe das aber nur auf Radreisen kennengelernt, da sollte man die Experten vor Ort noch mal fragen.
5. Haben die Symbole eine Reihenfolge? Die meisten dieser Tafeln kann man ja von vorne und hinten lesen, daher ist es nicht offensichtlich, in welcher Reihenfolge man die mappt. Ich dachte zunächst, immer vom Pfosten aus zu starten und dann nach aussen weiter, aber es gibt ja auch Schilder, die in der Mitte am Pfosten befestigt sind. @jmsbert hat vorgeschlagen, sie immer alphabetisch zu ordnen. Das habe ich dann so gemacht, aber notwendig finde ich es nicht.
6. Bei information=route_marker gibt es auch unterschiedliche Varianten, wie mit Themenrouten umgegangen wird. Ich kenne da bisher

  • Tafeln mit Pfeil (grün auf weiß oder rot auf weiß)
  • Tafeln für eine bestimmte Route, also Pfeil und Namen einer Route, z.B. für Hunteweg oder Brückenradweg. Scheint aber veraltet.
  • Tafeln mit Pfeil und mehr oder weniger vielen Routen-Symbolen, die denen an den Wegweisern entsprechen.
    grafik
    Ich habe die Liste der Symbole bisher nur in eine note=* gepackt. Interessant in diesem Zusammenhang sind Routen, die nur in einer Richtung ausgeschildert sind. Da sind dann entsprechend unterschiedliche Listen auf Markern an der der gleichen Kreuzung.
  1. Welchen Text erfasst man? Nimmt man genau das, was auf dem Schild steht (falls überhaupt), oder, wenn schon eine Relation vorhanden ist, den Text, der dort als name=* angegeben ist? Ich habe da noch keine klare Präferenz.
    Beispiel: Auf den Symboltafeln zur Relation https://www.osm.org/relation/151754 https://www.osm.org/relation/151754 finde ich “Hunteweg” und darunter “Fernradweg”.
    Wie umgehen mit Routen, die mehrsprachig “benamst” sind, aber keinen Text auf der Symboltafel haben? Beispiel: Diese Route https://www.osm.org/relation/2073135 wird durch eine Symboltafel ausgewiesen, auf der ein Leuchtturm zu sehen ist, aber kein Text. Ich war da erstmal mit meinem Latein am Ende. Würde man dann in D “Fietsallee am Nordkanal” mappen und in NL “Fietsallee langs de Noordervaart”?

Ich werde zunächst mal mit dem bisher verwendeten Verfahren weiter machen. Zumindest im Raum Niedersachsen habe ich noch sehr viele Fotos nicht verdatet, möchte das aber noch tun. Den Rest von D habe ich eher als Forschungsreise betrachtet, um mal über den Tellerrand zu schauen. Wie immer bei OSM: Je mehr Fälle man kennt, desto weniger sicher ist man sich :cry:

(Zentrale Messages zuerst:

  • Bitte nicht zuviel Aufwand in die Routeneinschübe stecken!
  • Zielsetzung des Projektes im Auge behalten: Die Wartung und Überprüfbarkeit der Routen zu verbessern
  • Grundlegende Ziele: Auswertbare Daten zu behalten. Taggingaufwand soweit im Rahmen zu halten, dass man mit den stetigen Änderungen on the ground halbwegs Schritt halten kann
  • Das Tagging der nummerierten Knotenpunkte hierbei außen vor zu lassen).

Zu Details:

… ich sehe die ganzen Punkte und Schwierigkeiten und stimme zu, Du nennst damit viele Gründe, warum ich bisher die Finger davon gelassen hatte. Ich habe in der Konsequenz mich aber eben auch vorwiegend um lokale und halbwegs zu bewältigende regionale Routen kümmern können, wie schon erwähnt. Das Mappen der Routeneinschübe (dann ist es übrigens sinnvoll, ein survey:date=* mit einzufügen, so weiß man schon im Node, wie alt die Info ist, und muß nicht die Changesets und Metadaten mit beurteilen), ist ja offenbar aus der Problematik heraus entstanden.

“Routeneinschub” ist die offizielle Bezeichnung in den “Hinweise zur wegweisenden Beschilderung für den Radverkehr” in NRW, die als Verwaltungserlass rechtsverbindlichen Status haben, daher nutze ich recht konsequent die entsprechenden Begriffe. In den anderen Bundesländern sehen die Schilder ähnlich bis identisch aus, der Rechtsstatus ist mir allerdings nicht so klar geworden, das System ist im Grunde ja dasselbe: Zielwegweisung (weitgehend, NRW: gefordert, aber auch nicht 100% umgesetzt) konsequent für jede Richtung an jeder Aufzweigung angegeben, Routenwegweisung zusätzlich als Einschübe. Zwischen Aufzweigungen Wegweisung durch kleinere Zwischenwegweiser (auch technisch definierter Begriff). Ich habe versucht, die HBR und de facto Situation soweit sie mir begegnet ist, auf meiner Userseite zusammenzufassen.

Knotenpunktnetzwerke

Hier gibt es schon viele Wegweiser, es gibt in Deutschland leicht konkurrierende Taggingschemata, die ich nicht anrühren wollte. Mir geht es aktuell darum, ein neu auftretendes Phänomen (Mappen der Routeneinschübe) frühzeitig zu ordnen. Da Knotenpunktnetzwerke ein internationales Phänomen sind, ist die Angelegenheit komplexer. (s. Wiki). Eins von mehreren etablierten Schemata ist, die Knotenpunkte in die direction=* tags mit aufzunehmen als “KP xy”. Das hat seinen Sinn bei der Auswertung der Wegweiser, dass die Knotenpunkte auch als “Ziel” erfasst werden.

In NRW ist vorgegeben, das die Zwischenwegweiser keine Routenangaben enthalten, insofern auch nicht die KP-Routen, und sollten auch nicht getaggt werden.

Bezeichnungen für Routen/Routeneinschübe

Auch das ist einer der Gründe, warum ich die Routeneinschübe ungern mappe. Es gibt viele verschiedene Möglichkeiten, textkodiert einen Routeneinschub zu bezeichnen. Bei einer Route habe ich es mal so gemacht, dass ich verifiziert habe, ob in den regionalen Routenrelationen schon ein Anfang gemacht worden ist, nachdem ich nichts finden konnte, habe ich die Routenrelation angelegt, das Logo dort unter symbol beschrieben und in der note angemerkt, was ich wußte.

An einer anderen Stelle habe ich einfach am guidepost die Routeneinschübe mit note=“Hier finden sich noch Routeneinschübe R3 und R14”, wobei es keinerlei Routenrelation gab, auf die es sich hätte beziehen können.

Gut ist es hierbei, sich mit dem “Erfinder” von Namen und Ref ins Einvernehmen zu setzen, um keinen Editwar zu provozieren. Da gibt es schon manchmal ziemlichen Streit drum, ob die “ref” objektiv verifizierbar sein muß. In der Regel haben die Routen vom Betreiber einen Namen bekommen, den man nicht unbedingt an den Wegweisern erschließen kann. Wenn diese Route mit z.B. “H5” ausgeschildert ist, ist das wenigstens klar die Referenz.

Jap, der Kreis Osnabrück hat das überall drangehängt… :wink: Das würde ich auf keinen Fall mappen. Im Moment wird die Information auch dadurch abgebildet, dass zumindest die unbenannten Routen in einer Relation zusammengefaßt sind. Wer es unbedingt mappen will, könnte das über das Tag cycle_network machen. Das allerdings völlig unsystematisch verwendet wird. Inhaltlich wäre das passend.

Zwischenwegweiser

Für NRW gibt es immerhin inzwischen behördliche Vorgaben. Es sind nur reine Routenmarkierungen ohne Routensymbole zugelassen, “Routenabzweiger” - roter Pfeil mit Routensymbol dürfen nur als Bestandssicherung für alte Routen benutzt werden. Und: natürlich gibt es Fahrradrouten OHNE offiziellen Charakter! Das ist der Ausgangspunkt für diesen Thread: “Wie Taggen wir die OFFIZIELLEN Routen?”
Es gibt dennoch unglaublich viele alte Routen, die noch anderen Regeln folgen, aber man sollte im Blick haben, dass diese sozusagen “deprecated” sind.

Die “NiederRheinroute” ist als Ganzes keine Route im OSM-Sinn, sondern ein Netzwerk und entsprechend type=network und nicht type=route getaggt.
Der Rest scheint tatsächlich eine fortlaufende Route über die ganze Fläche zu sein. Dazu gibt es Querverbindungen, die anscheinend Nummern haben (soweit die Daten in OSM).


Kein Wunder, dass man überall auf die Route stößt… Das ist aber nicht NRW-typisch, denke ich, sondern die Konzeptidee am Niederrhein. So wie es mal das “Waben-Konzept” im Münsterland gab, das wieder abgebaut worden ist, oder ein Ringe-System in Bünde, wovon die Ringe noch erhalten sind (und nicht 100% HBR-Konform ausgeschildert sind).

Schluss:

Das Ringsystem in Bünde nehme ich für einen Abschluss des überlangen Posts: Die Ringe habe ich an den Wegweisern nicht gemappt, sondern nur die Relationen erstellt, und halte das auch für überflüssig, obwohl da überall die Nummern der Ringe hinter den Zielen stehen:
Meine Praxis ist, Informationen zu markieren, die nützlich sind (für mich im Prozess interessantere Dinge zu mappen; oder direkt schon für andere nützlich). Die Routeneinschübe halte ich für flächendeckendes Tagging für zu aufwändig. Hier werden jedes Jahr Wege umgebaut, das hätte die Konsequenz, dass die Routeneinschübe schnell veralten und der Datenbestand wertlos wird. Das heißt, man sollte sich bewußt sein, dass diese Daten z.T. nur einen Interimscharakter haben. Die Fehleranfälligkeit ist hoch, weil die grafische Information nicht zuverlässig durch einen Text abgebildet werden kann. (Name der Relation? Ref. der Relation? Beschreibung des Logos).

Die Information über den Routenverlauf für den Endanwender gehört in die Routenrelation. Insofern sind die Routeneinschübe selbst redundant, wenn sie zusätzlich an den Wegweisern gemappt werden.

Daher halte ich es für sinnvoll, sie unabhängig von den Zielangaben in eigene Tags unterzubringen, damit sie nicht die anderen, stabileren Informationen überlagern. (Die Routeneinschübe haben ja den Zweck der leichten Austauschbarkeit, um Routen schnell um- und neu gestalten zu können, ohne das Grundnetzwerk ändern zu müssen). Meine persönliche Praxis war, in unabhängigen Tags auf Diskrepanzen hinzuweisen. (note, fix_guidepost)

Wie das Tag genau heißt, ist letztlich egal, und wenn der nächste User einfach eins verwendet, sollte er durchaus im Wiki (DE:Bicycle/Fahrradrouten kartieren - OpenStreetMap Wiki und Key:direction_north - OpenStreetMap Wiki https://wiki.openstreetmap.org/wiki/Key:direction_north:myextension) darauf hinweisen, damit die übernächste Userin nicht ein anderes für den gleichen Zweck erfindet. Eine Erläuterung hierzu und Verweis auf den thread hier, sollte in der Diskussion gegeben werden. (+ Erwähnung hier ist natürlich sicher sinnvoll. Das wiki ist groß, Einträge werden schnell übersehen).

Liebe Grüße, und sorry für die Länge…

Oder führe adhoc das neue Tag ein :wink: (Der Umbau in die andere Richtung und die Umbenennung des Tags ist einfacher als das Parsen der Routeneinschübe aus den direction-Einträgen!)

Ich kenne das, dass die Radtour weniger Zeit braucht als die Datenverarbeitung danach. So sollte es eigentlich nicht sein…

Wollte gerade mit direction_northeast:symbol loslegen, aber so recht gefallen tut mir das auch nicht. Man beschreibt ja nicht die Symbole, sondern die Bedeutung derselben. Also wohl doch eher so was wie
direction_northeast:route
Ich würde da aber eher die Mehrzahl verwenden, also direction_northeast:routes. Diese Variante wird bisher anscheinend auch noch nicht verwendet.
Sollen die doppelten Hochkomma dann bleiben oder nicht? Also

  • direction_northeast:routes=“Alfsee-Tour”; “Artland-Rad-Tour”; “Bauernhof Tour”; “Hügeltour”; “Land-Schaft-Kultur”; “NordWestBahn-Tour”
    oder einfacher (und mein Favorit)
  • direction_northeast:routes=Alfsee-Tour; Artland-Rad-Tour; Bauernhof Tour; Hügeltour; Land-Schaft-Kultur; NordWestBahn-Tour

Zumindest bisher ist mir nie ein Semikolon in den Namen untergekommen, die doppelten Hochkomma sind also wohl eher nicht nötig.

direction_*:route oder routes finde ich beides auch ok. Ob es da eine übliche Regel für Singular oder Plural gibt, weiß ich nicht.
Ich würde auf jeden Fall möglichst bald eine (zunächst englische, da direkt für jeden zu finden) Wiki-Seite anlegen und die Seite direction_north, die es als Sammelseite gibt, entsprechend ergänzen.

Ich würde auf die Seite eine Beschreibung dessen packen, was Du tust, damit andere, die das Verfahren übernehmen, es genauso machen. Wichtig finde ich, dass grundsätzlich für die Guidepost-nodes gilt: Es wird nur das getaggt, was tatsächlich sichtbar ist. Das ist der Grund, warum ich symbol zunächst naheliegender als route(s) finde, man beschreibt ja eben doch die Symbole, in dem man die Namen der Route referenziert.

Es sollte kein Routentag gesetzt werden, wenn es am Wegweiser fehlt. (Das ist bei Wegweisern mit nur 2 Richtungen recht häufig). Genauso wie man ja auch Schreibfehler auf dem Schild in der Regel übernehmen soll. Von der Regel kann man abweichen, wenn man das in note=* genauer erklärt. Ich würde hier es aber eher so machen, dass ich in Note hineinschreiben würde: Routenverlauf xy-Route nach NW, entsprechender Einschub fehlt. (Wenn man sowieso nur daran vorbeifährt, kann man es ja oft auch nicht wissen.)

Ich halte es für sinnvoll, dann auf die Anführungszeichen zu verzichten und entsprechend dem Gebrauch in anderen Tags mit Semikolon trennen, so wie dein zweiter Vorschlag. Ich glaube, es ist zwar relativ viel Text, aber gut nachvollziehbar, wenn man das name=* Tag aus der entsprechenden Routenrelation als Bezeichner im Tag direction_:routes= benutzt. (Auch das würde ich im Wiki so beschreiben.) Alternativ ginge ref, aber ref ist nicht immer gesetzt und z.T. umstritten, wenn es ein willkürlich gewählter Wert ist, und auch nicht immer ganz eindeutig. (Hier z.B. gibt es doubletten der Referenzen Rxy: Altes “R-Netz-NRW” und “Rxy” Rundwege).

Würde ich dann genau so empfehlen.