Genau. Und dann geben wir noch je Eintrag die Sprache an und die Farbe und die Form des Schildes und die gewählte Schriftart 
Habe ich noch was wichtiges vergessen?
Welcher Mapper will die ganzen Semikolons in den Listen zählen?
@GerdP Du hast schon hinreichend klargemacht, dass dich diese Details von Schildern nicht interessieren.
Das destination Schema hat bei der Entwicklung schon einige Jahre und Stufen hinter sich und wird weltweit hundert tausende Male eingesetzt, davon viele tausende mit den von @Allroads erwähnten destination:distance Tags. Mir ist nicht klar, warum alle diese Diskussionen hier wieder geführt werden müssen - es gibt Personen die diese Details erfassen wollen und solche die nur einfache Einträge machen wollen. Für die ersteren gibt es ein ausgereiftes Schema, dass sich bewiesenermaßen auch dazu eignet realistische Darstellungen von Schildern zu generieren. Alle anderen dürfen gerne darauf verzichten und nur grundlegende Informationen eintragen. Absichtlich falsche Einträge anzupreisen weil sie vermeintlich einfacher sind (a la “(Bf)”) ist nicht hilfreich für die Qualität der Daten.
Ich bin biher noch nicht auf einen Radwegweiser gestoßen, der mit solchen Tags erfasst wurde. Hast Du mal ein Beispiel?
1 Like
Wegweiser sind Wegweiser, egal ob sie für Fußgänger, Radfahrer oder Reiter gedacht sind. Wir brauchen keine unterschiedlichen Tagging-Schemas dafür.
Aber auch Radwegweiser mit explizit und korrekt erfassten Symbolen und Entfernungen gibt es zuhauf. Ein schnell gefundenes Beispiel:
Hm, das (bzw. die Wikis dazu) muss ich mir länger anschauen. Diese Relationen sind mir bisher nicht begegnet.
Ich hatte nach dem von @Allroads erwähnten direction_north:distance gesucht. Wo würde das in diesem Schema auftauchen?
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.
1 Like
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.
0
voters
1 Like