Gar nicht. destination:distance
gibt es, wenn Ziele an Straßen erfasst werden. Wenn Relationen verwendet werden gibt es entweder distance
oder destination:distance
, die synonym sind (der “destination:” Präfix wird nicht gebraucht, da er sich aus dem Zusammenhang ergibt).
direction_north:distance
kann es nur an guideposts geben, weil die direction_north
Tags nur in diesem Zusammenhang definiert sind.
Hmm, wenn ich das engl. Wiki Relation:destination_sign - OpenStreetMap Wiki
richtig verstehe, dann hätten das 6 Relationen mit jeweils einer Entfernung sein sollen?
" For signs with multiple destinations, one destination_sign relation should be created per indicated direction. (When multiple destinations are indicated per direction, these can be listed in the relation’s ‘destination’ field separated by semicolons. If supplementary information must be provided, like distance or time, one destination_sign relation per destination should be created)."
Mir geht es um den letzten Satz. Demnach sollte sowas wie
distance=7.5;0.6
entweder nicht angegeben werden (so wie bei den Relationen zum nahegelegenen Wegweiser Node: 6903123832 | OpenStreetMap)
oder eben für jedes einzelne Ziel eine Relation. Im deutschen Wiki finde ich diese Einschränkung nicht.
Dort steht “per indicated direction”, nicht “per indicated destination”. Also pro Richtung, nicht pro Ziel. Da dieser Wegweiser in drei Richtungen zeigt, gibt es auch drei Relationen.
Die Einschränkung muss auch gar nicht explizit angegeben werden - das ergibt sich schon alleine daraus, dass die Relationen nur einen Weg mit der Rolle “to” haben darf.
Diesen Teil meinte ich.
Ach da steht das. Den Satz muss man nicht beachten, das funktioniert auch einwandfrei mit mehreren Einträgen.
Die Aussage finde ich klasse. Wenn ich das Wiki beachte, das mir sagt, ich soll (Bf) für das Bahnhofs-Piktogramm verwenden, mache ich “Absichtlich falsche Einträge”. Das engl. Wiki soll ich auch ignorieren.
Je nachdem, ob ich den Satz beachte oder nicht habe ich entweder
- eine Relation pro Ziel und damit keine Übersicht mehr, in welcher Reihenfolge die Wegweiser am Mast hängen (und damit wirds auch sehr schwer, nachzuvollziehen, welcher Eintrag noch fehlt)
oder - mehrere mit Semikolon-getrennte Listen, die bei Wegweisern mit mehr als 4 Zielen pro Richtung ziemlich unwartbar werden (und natürlich den Konflikt mit dem engl. Wiki)
Da gibt es dann wohl doch noch Klärungsbedarf.
Ich versuche auch gerade noch zu verstehen, warum bei Relation: 11364971 | OpenStreetMap
der “to” Way nicht am “intersection” Knoten hängt. Für mich sieht das falsch aus.
Umgekehrt: Der ‘from’ Weg hängt nicht an der Intersection. ‘to’-Weg und ‘intersection’-Knoten sollten nach Möglichkeit immer zusammenhängen. Wenn das nicht geht, würde ich als Auswertender vorziehen wenn ‘to’ als Knoten erfasst wird - aber auch wenn nicht, dann lässt sich das per Software mit etwas Aufwand klären.
Aber das Schild kann man von der Kreuzung aus nicht sehen, nur vom ‘from’ Weg aus, deswegen der Abstand.
Das kurze Stück der Hohemarkstraße könnte man als “via” erfassen, aber das ist eigentlich auch nicht wirklich notwendig.
Ah, stimmt. Da habe ich nicht genau genug hingeschaut. Dann passt das wohl doch.
Wenn man es genau nimmt, dann steckt diese Info mit dem via-Weg aber auch nicht im Wegweiser. Manchmal stehen an komplexeren Kreuzungen ja noch extra route_marker, aber längst nicht immer.
Genau deswegen dürfte es auch eher schwierig sein, vollautomatisch zwischen den beiden Tagging-Verfahren umzuwandeln. Das eine sagt nicht, wo der Wegweiser hinzeigt, das andere nicht, was damit gemeint ist.
Ich habe mir gerade noch mal die Änderungen am Wiki Key:direction_north - OpenStreetMap Wiki
genauer angeschaut.
Dabei ist mir aufgefallen, dass auf dem Schild im Beispiel die Angabe “km” als Einheit fehlt, aber bei den tags
direction_northwest=(Bf) Stadtmitte 10 km;Holthausen 2.0 km
wurde sie ergänzt.
In meiner Gegend (vor allem die Landkreise Oldenburg und Vechta) steht tatsächlich immer “km” auf dem Schild, anderswo nie. Im LK Diepholz findet man beides, manchmal sogar am gleichen Mast:
(Das Bild ist vom 23.1.2023)
Ich habe in der Vergangenheit immer " km" ergänzt, wo es auf dem Schild fehlte, aber andere Mapper (z.B. im Ruhrgebiet) machen das nie. Was ist denn jetzt sinnvoller?
Auch in Nederland eine Ausnahme. Die meisten thematischen Radwege sind – in OSM – von den Knotenpunkten getrennt, auch wenn sie oft denselben Straßen folgen.
Bei mir genauso, ich habe in Düsseldorf oder Kreis Mettmann auch noch keine “km” explizit gesehen, aber es schadet ja nicht, das zu ergänzen. Da habe ich mich immer an Tag:information=guidepost, wo direction_north
usw. ja herkommen, gehalten. In den HBR, Kapitel 3, Seite 2 wird die Einheit auf km festgelegt, aber nicht, ob diese auf dem Schild stehen muss.
Ich springe noch einmal an den Ausgangspunkt zurück, weil ich zu meinen ursprünglichen Fragen noch nicht weitergekommen bin, wenn auch viele Anregungen Teilaspekte erfassen, auf die ich bisher noch gar nicht so viel wert gelegt habe.
Die Grundfrage, die ich ursprünglich meinte war: Wie kann ich Daten in OSM so repräsentieren, dass ich in der Lage bin, überhaupt die Strecken des regulären Netzwerkes zu identifizieren. Damit könnte man auch mit Fahrtanweisungen über Zielangaben routen: Fahre zunächst Richtung Lage, dann, sobald ausgeschildert, weiter Richtung Detmold, von dort weiter nach xyz… damit steht ein wesentlich umfassenderes Netz als die nummerierten Knotenpunkte zur Verfügung und es ist meiner Meinung auch einfacher, danach zu radeln. Ich habe nochmal die Bilder durchforstet, um klarer zu machen, was ich meine.
Also: Das ist die Wegweisung, die ich mit “offiziell” meine: (Hier mal alle Routentypen: Knotenpunktnetzwerk, Basisroute ohne Routeneinschub, Themenrouten. Alle werden über Zwischenwegweiser geleitet, an jeder Aufzweigung finden sich auch Zielwegweisungen).
Diese Ausschilderungen bezeichnen andere Routen und passen nicht dazu. Und ich würde das gerne den OSM Daten entnehmen können, was bislang noch nicht möglich ist:
Der Reihe nach: Das alte NRW-“R-Netz”, Strecke 49, “Halle/Westfalen 4”, See-Route Bad Lippspringe, St. Anna-Route Verl, Eselsweg, Terra.trail 17, Fietsen naar Praag, ZIG: Keine Ahnung, was das ist, scheint ebenfalls eine internationale Route zu sein, wohl nicht in OSM enthalten, RSC Permanente, offenbar eine Radsportstrecke, die Relation ist kurz, die Route könnte ohne Probleme über 100 km lang sein, nach der Verteilung der Marker zu urteilen… Allesamt Fahrradrouten und in OSM nicht unterscheidbar vom offiziellen Netzwerk, aber eindeutig auch Fahrradrouten im OSM-Sinne.
Es gab schon ausführlichste Diskussionen in der Tagging-Mailingliste, (Beginnend mit: [Tagging] Feature Proposal - RFC - value 'basic_network' for keys 'network:type', 'lcn' and 'lwn' )
Den dortigen Gedanken, cycle_network dafür zu verwenden finde ich durchaus attraktiv. Das Problem ist allerdings, dass das Tag schon weitflächig für die unterschiedlichsten Zwecke verwendet wird, zumeist, um die Bezeichnung des jeweiligen lokalen Netzwerks dort einzusetzen. Es würde eine Menge Änderungen erfordern, über die zunächst ein Konsens hergestellt werden müßte, da ja nicht klar ist, wer die Inhalte von cycle_network=* jetzt nutzt, und danach nicht mehr wie bisher nutzen könnte.
Die meisten der Einzelabschnitte des Radverkehrsnetzes sind gleichzeitig auch Teile benannter Routen. Leider verläßt je nach Region ein großer Teil der Routen auch mal Abschnittsweise die standardisierte Wegweisung, so dass man nicht 1:1 aus den benannten Routen auf das normale Radverkehrsnetz schließen kann.
Es gibt Routen, die in den HBR-NRW als alte, “noch nicht” HBR-konform ausgeschilderte Routen bezeichnet werden, die über "Routenabzweiger integriert werden sollen (Rundweg Gütersloh 10, R10):
Und es gibt Routen, die teilintegriert sind, aber sich auch nicht um die HBR-“Routenabzweiger” scheren (“Industrieroute” im Kreis Lippe, noch nicht in OSM), siehe insb. Detail im großen Bild: Routeneinschub nach rechts vorne am oberen Bildrand (leider abgeschnitten), nach links eigener Wegweiser):
Wenn man wenigstens ein Tag hätte, mit denen man die benannten Routen, die komplett über Routeneinschübe an Zielwegweisungen geführt werden, markieren könnte. Dann bräuchte man für diese Strecken nicht noch irgend etwas zusätzlich markieren. (so etwas wie hbr_conformity=yes oder full/mostly/partial/none).
Hallo allerseits, bin nun von einer Radtour an die Nordsee zurück und habe festgestellt, dass es mancherorts eine ziemlich inflationäre Verwendung von Piktogrammen auf den Wegweisern gibt.
An der Stelle stimme ich völlig zu: Dafür zig verschiedene Kürzel, die auf der deutschen Sprache basieren, zu verwenden ist nicht gut. Schon allein deshalb nicht, weil bei 2-3-buchstabigen Kürzeln ja auch kein fließend Deutsch sprechender Mensch mehr ohne nachzuschlagen zuverlässig zuordnen kann, was jeweils gemeint ist. Begonnen habe ich das auch nur in Fällen, wo die Information nicht redundant schon im Text enthalten ist.
Aber ich stelle fest, auch die englischen Symbole decken anscheinend bei weitem nicht das ab, was da alles so verwendet wird. Und wir haben noch keine Unterscheidung zwischen Streckenpiktogrammen und Zielpiktogrammen im Tagging.
Mir schon allein allgemeingültige Bezeichnungen (Vielleicht finde ich auch einfach nur nicht die entsprechende Wikiseite) für die Logos. (/Die Franzosen benutzen anscheinend ein eigenes System. Im Prinzip wäre das auch für Deutschland nicht ganz unsinnig, aber wir haben keinen zentralistischen Staat und z.T. verschiedene Vorgehensweisen je nach Gemeinde… Wiki Signalisation routière en France#Idéogrammes routiers de type ID
Weiß jemand oder hat Vorschläge für die Symbolbezeichnungen für:
Streckenpiktogramme: Radschnellweg, Freizeitstrecke, Steile Strecke, Bahntrassenradweg
Zielpiktogramme: Zoo, Universität, Fachhochschule (in Osnabrück als eingekästeltes “Zoo”, “Uni”, “FH” gesehen)… Edit 13.10.: Fahrradladestation… (habe nur ganz miese Fotos):

Habe keine gute Idee dazu… Grüße, Sebastian
Vielleicht könnte man das durch ein weiteres Trennzeichen im Wert von direction_north:symbol
ausdrücken. Aktuell haben wir ja ;
für die Trennung der einzelnen Ziele (Zeilen), dann ,
für mehrere Piktogramme eines Ziels. Jetzt fällt mir noch |
als üblicher Trenner ein, den man zwischen den Ziel- und Streckenpiktogrammen nutzen könnte. Dann hätte man z.B. direction_north:symbol=train_station,info|steps;|steps
für (Bhf.) und (i) am Fernziel sowie Treppen auf dem Weg zu Fern- und Nahziel.
Im Vergleich zur :lanes
-Syntax sind hier die Rollen von ;
und |
vertauscht, aber das hier ist ja ein anderes Schema.
Zu den Symbolbezeichnungen: Die, die du schon unter Elemente_NRW-Radwegenetz aufgeführt hast, finde ich gut. Für S-Bahn schlage ich mal etwas von der Art S_train
(Wikipedia), suburban_train
oder local_train
vor. Radstation könnte man wörtlich als bicycle_station
übersetzen (?)
Und als Streckenpiktogramme kenne ich noch Fähre ferry
und Treppe steps
.
Gruß, Hendrik
Nicht 100% im Thema, aber es trifft hier die passendsten Leser: In Bremen bin ich über zahlreiche Relationen mit Namen “Rad-Hauptroute” gestolpert, die inhaltlich genau dem Konzept der unbenannten Routen mit “network:type=basic_network” entsprechen. Ich habe mich mit @Romwriter ausgetauscht, der maßgeblich an der Gestaltung beteiligt war, und die Rückmeldung bekommen, dass ein automatisierter Edit im folgenden Sinne in Ordnung wäre:
(1) Dass die name-Tags gelöscht werden können und dafür das Tag “network:type=basic_network” eingesetzt werden kann, in Ordnung wäre. (1b) Darüber hinaus würde ich das Tag ref=“HR” löschen.
Begründung: Aktuell sind die Relationen automatisiert nicht von Themenrouten unterscheidbar. Die unter name=* angegebene Bezeichnung ist nicht der Name der entsprechenden Route sondern eine Charakterisierung derselben. Diese wird gegenwärtig mit “network:type=basic_network” in Verbindung mit bicycle=yes in Deutschland eindeutig beschrieben.
Das Tag ref=“HR” ist in den Relationen redundant, da es auch in den übergeordneten Relationen gesetzt ist.
(2) Darüber hinausgehend würde ich allerdings auch dafür plädieren, dass das Tag ref=“HR” auch aus den übergeordneten Relationen entfernt wird, da diese Routen de facto keine Referenz haben, nicht über das Kürzel referenzierbar sind. (Dieser Schritt führt auch ggf. zu einem Rendering ohne Kürzel in z.B. waymarkedtrails.org, was ich prinzipiell wünschenswert fände, da damit erkennbar wäre, dass es sich nicht um eine benannte/Themenroute handelt. Beispiel in Bielefeld, beachte die lokale Route BSS, die nicht über Knotenpunktrouten geht, und dennoch vom Grundnetzwerk unterscheidbar ist, das nämlich gar keine Logos enthält).
Wie sieht es aus? Gegenargumente? Gegenmeinungen? Nutzung meiner ersten Umfrage?
Grüße,
Sebastian
- Gegen eine Änderung
- Nur Variante 1
- Auch Variante 1b
- Variante 2 auch gut.
Ich habe mich in den letzten Wochen mal auf die nicht ganz konformen Radwege begeben, und möchte meine Frage von anno dazumal (Repräsentation des aktuellen offiziellen deutschen Radverkehrsnetzes (nach den Vorgaben der FGSV) in OSM - #132 by segubi) nochmal aufleben lassen:
Das Radwegenetz in waymarkedtrails hier in der Umgebung wird dichter und unübersichtlicher, selbst wenn man nur die markierten Routen einträgt. Meine Wunsch, dass man mit einem Knopfdruck nur die offiziellen Routen des Verkehrsnetzes angezeigt bekäme, benötigt ein entsprechende Tagging.
Da der Begriff HBR (“Hinweise zur wegweisenden Beschilderung für den Radverkehr”) nur in Nordrhein-Westfalen offiziell ist, ist er nicht so elegant.
Der Verweis auf die FGSV (“Forschungsgesellschaft für Straßen- und Verkehrswesen”) ist dann schon etwas überregionaler.
Da käme man auf etwas wie
Tag | Erklärung |
---|---|
fgsv-conformity=full | Eine Route, die komplett über die offiziellen Zielwegweiser mit Routeneinschüben und Zwischenwegweisern ausgeschildert ist. Es gibt keine Abzweigungen ohne Zielwegweisung. |
fgsv-conformity=mostly | Eine Route, die Ausnahmen von der obigen Definition von weniger als 10 % der Strecke beinhaltet. (Beispiel: https://openstreetmap.org/relation/14166784 , Radweg für Genießer, mit ca. 200 m abweichender Ausschilderung aus Gott weiß was für Gründen bei Gesamtlänge von 114 km). |
fgsv-conformity=partial | Eine Route, die in einigen Abschnitten das offizielle Radverkehrsnetz nutzt, und über Routeneinschübe markiert ist, aber auch z.T. unabhängig verläuft, z.B. Ziegelroute ( Relation: Ziegelroute (14384062) | OpenStreetMap ). Die außerhalb des Netzes liegenden Routenmarkierungen sind unabhängig vom offiziellen Netz gestaltet. |
fgsv-conformity=legacy | Eine Route, die in einigen Abschnitten das offizielle Radverkehrsnetz nutzt, und über Routeneinschübe markiert ist, aber auch z.T. unabhängig verläuft, die Abzweigungen aus dem Zielwegweisungsgebundenen Netz erfolgen aber mit offiziellen “Routenabzweigern” und nutzen im Verlauf die üblichen Zwischenwegweiser. Z.B. R10 Gütersloh Relation: R10 (3160175) | OpenStreetMap. Die Terra.trail Routen des Geopark Terra.vita (Wiehengebirge/Teutoburger Wald) sind z.T. ebenso gestaltet, z.T. eher als partial. |
fgsv-conformity=no | Eine Route, die nicht das offizielle Wegweisungsnetz nutzt. (Aufkleber an Pfosten, andere Wegmarkierungen, z.B. Eselroute s.o., Sportrouten). |
“legacy” schlage ich letztlich aufgrund folgendes Zitats der NRW-Vorgabe vor:
(https://www.radverkehrsnetz.nrw.de/downloads/HBR_NRW_Kap03_Jul2019.pdf, Seite 16):
Zweigt von den nach HBR NRW-Standard ausgewiesenen Routen eine Route ab, die aus Gründen des Bestandsschutzes mit ihrer vorhandenen, noch nicht HBR NRW-konformen Beschilderung weitergeführt werden soll, so ist an diesen Abzweigepunkten ein Zwischenwegweiser mit Routenlogo zu verwenden. Dieser - nur in dem beschriebenen Ausnahmefall - zu nutzende „Routenabzweiger“ hat die Regelmaße 350 x 350 mm und zeigt ein integriertes Routenlogo (vgl. Kap. 7.2.3)
Etwas, das sich für internationale Verwendung eignet, fällt mir nicht so recht ein. Auch z.B. in Frankreich gibt es eine mehr oder weniger einheitliche Ausschilderung und parallel inoffizielle und veraltete Routen.
In der Taggingmailingliste wurde tendenziell empfohlen, die Zuordnzung einer Route zu einem konkreten Netzwerk über cycling_network=xyz zu machen. Das halte ich allerdings nicht für gangbar, weil man in großem Umfang bisher bestehende Tags ändern müsste, wofür man jeweils den Konsens mit den Erstellern suchen müßte, die für ihre Taggings auch ihre Gründe haben.
Ich finde einen neuen Key sehr viel besser, da er mit nichts und niemandem kollidiert, und jeder fröhlich so weiter machen kann, wie bisher, wenn es ihn nicht interessiert, andererseits aber eine Möglichkeit bestünde, die Informationen schon einmal grob unterzubringen.
Unklar bleibt noch bei den Mischformen, wie man die nicht-konformen Strecken identifiziert.
Gibt es andere Vorschläge für den Namen eines solchen keys, oder andere tags?
Grüße,
Sebastian
Da der Begriff HBR (“Hinweise zur wegweisenden Beschilderung für den Radverkehr”) nur in Nordrhein-Westfalen offiziell ist, ist er nicht so elegant.
da wir für tags am liebsten keine Abkürzungen verwenden wäre der tag
hinweise_zur_wegweisenden_beschilderung_conformity=yes, oder?
Ich bin nicht überzeugt, dass das eine Information ist, die in dieser Form in OSM Sinn macht.
Wenn es tatsächlich eine Übereinkunft gibt, dass das erfasst werden soll: Etwas wie eine “fsgv” gibt es womöglich an vielen Stellen der Welt, in dieser konkreten Bedeutung aber nur in einem sehr begrenzten Gebiet.
Das führt dazu dass in jedem Gebiet ein komplett neues Tag erfunden werden muss oder es Mehrfachnutzungen des gleichen Tags gibt.
Tags sollten global verwendbar sein und bei nur regionaler Bedeutung mit Länderkürzel markiert werden. Ein besseres Tag wäre daher etwas in der Form von
conformity:DE:NRW:HBR = *
Wie das Haupttag heißen soll ist natürlich noch zu diskutieren. Aber die grundlegende Form des Tags macht klar, dass es um eine lokale Ausprägung einer Eigenschaft geht, vermeidet mögliche Namensdoppelungen in anderen Regionen und lässt sich problemlos auf die (imaginäre) FietsMarkerRegelungen in den Niederlanden erweitern - conformity:NL:FMR
Das macht nichts. Ich bin’s. (any tag you like - und ich glaube kaum, dass ich in dem Fall der einzige bin). (Mir reicht letztlich schon, dass die Karte der offiziellen Website des Landes: https://radservice.radroutenplaner.nrw.de/rrp/nrwrvn/cgi?lang=DE unglaublich schlecht gepflegt ist, und das Potenzial besteht, über osm einfach eine aktuelle Karte zu haben, mit der man wirklich etwas anfangen kann. Dann wäre man für die Routenplanung auch nicht auf das Engagement der einzelnen Gemeinden in puncto Radverkehrsnetz angewiesen, das ähm…, unterschiedlich ist…)
Das finde ich einen guten Vorschlag. In der allgemeinen Fassung, wie ich es verstanden wissen möchte, meine ich auch nicht die regionale Variante, sondern die nationale. In ganz Deutschland werden Fahrradrouten offiziell inzwischen so ausgeschildert, mit gewissen Abweichungen im Design. (Ich erinnere daran: Diese Ausschilderung hat auch einen besonderen rechtlichen Status und hebt sich dadurch von anderen markierten Routen ab. Und ist leider doch innerhalb des offiziellen Netzes so variantenreich…)
Das wäre dann so etwas wie conformity:DE:FGSV
Ich finde für die Radroutenplanung wichtig, wie breit Wege sind, wie ihre Oberfläche ist, wie viele Kreuzungen es gibt, wer den Weg sonst noch benutzen darf - und nicht, ob irgendwer an einem Schreibtisch beschlossen hat, ob ein Weg zu irgendeinem offiziellen bla gehört oder nicht.
Klar, wenn irgendjemand sagt: Alle unsere “offiziellen bla”-Wege sind mindestens X breit und haben mindestens Y Oberflächenbeschaffenheit, dann ist in Abwesenheit detaillierter Tags in OSM (!) die Information vielleicht interessant, weil sie mir eine Untergrenze für bestimmte Qualitätseigenschaften liefert. Aber sobald die Qualitätseigenschaften selbst in OSM gemappt sind, ist die Zugehörigkeit zu irgendeinem offiziellen bla völlig belanglos.
Ich störe mich daran, wie oft das Wort “offiziell” in dieser Diskussion vorkommt. Ich finde, OSM soll seine eigenen Daten machen und nicht irgendwas hinterherhecheln, was irgendjemand “offiziell” beschlossen hat.