Sebastian @segubi hat in einer Diskussion vorgeschlagen, für das ausgeschilderte System in einer Relation die Tags network=lcn und network:type=basic_network zu verwenden. Ich habe das erweitert um die Wegweiser und die Wege aufzunehmen. Die Wegweiser bekommen die Tags role=guidepost und die Wege werden ohne Rolle aufgenommen, es sei denn Hin-und Rückweg unterscheiden sich in der Linienführung. Die Reihenfolge in der Relation spielt eine Rolle, es beginnt mit mindestens einem Wegweiser, es folgt mindestens ein Weg ein den Abschluss bildet ein Wegweiser. Die umgekehrte Reihenfolge gilt für den Rückweg.
Durch die Erweiterung des Tags guidepost auf guidepost:direction_north kann an der Abzweigung aus einen zugehörigen Tag des Wegweisers (direction_north=Zielangabe/n) in einer Routing-App die Angabe auf dem Display erscheinen oder über eine Sprachausgabe vorgelsen werden. Ich habe ein solches Netz im südlichen Ostholsstein gemappt. Das Ergebnis lässt sich über Overpass ansehen: overpass turbo. Ich arbeite auch an einer App für Android, die auf diesem Netz ein Routing durchführt.
Ich verfasse einen Blog-Beitrag für die Erläuterung, dessen Link ich hier teilen werde.
Ich habe jetzt ein semi-automatisches Verfahren gebastelt, um die vorhandenen Knoten auf das neue Tagging-Verfahren mit suffix :route für die Routen umzustellen.
Ein paar Stolperfallen gab es zu überwinden, aber jetzt sollte das Ergebnis passen.
Zum Verifizieren: Das Ergebnis meiner Umstellung sieht so aus: Changeset: 140276677 | OpenStreetMap
Es geht erst mal um weitere 1607 Knoten mit information=guidepost, in denen ich der letzte Updater war und die Routen in den direction_ Tags haben.
Edit: Hier meine weiteren Umstellungsänderungen
Changeset: 140302105 | OpenStreetMap
Changeset: 140302967 | OpenStreetMap
Ich sehe den Vorteil von diesem neuen Schema nicht. Wir haben schon drei verschiedene Arten die Ziele einer Ausschilderung zu erfassen. Dein neues Schema sieht mir nach einer Kombination von guidepost-Nodes mit destination_sign Relationen aus. Dabei verlierst du aber alle erweiterten Möglichkeiten, die destination_sign bietet.
Diese Taggingmethode scheint auch nur bei wenigen Wegweisern zu funktionieren und macht sie damit nicht universell einsetzbar. In allen Fällen wo nicht ein Wegstück in beide Richtungen ausgeschildert ist und keine Verzweigung dazwischen hat scheint es mir nicht verwendbar zu sein.
Hast du von einigen eher komplizierteren Wegweiser Bilder damit man sich vorstellen kann, wie die Schilder hinter dem Tagging aussehen?
Sind die Routenangaben immer unabhängig von den genannten Zielen, oder gibt es auch Fälle, bei denen eine Beziehung zwischen einzelnen Zielen und einzelnen Routen zu erfassen sein könnten?
Ich habe von allen Wegweisern Fotos, meist eine ganze Reihe. Welche würden Dich interessieren?
Die Frage verstehe ich vielleicht nicht. Meinst Du sowas wie “Haus im Moor”? Radroute mit Abstecher
Wenn ich das richtig verstanden habe, dann definierst Du die Rollen forward und backward neu. Das dürfte ziemliche Probleme verursachen.
Destination_sign zielt darauf ab, an einer Kreuzung den die Richtung einer Zielangabe mit dem Beginn eines Weges zu verbinden. Es wirkt nur lokal und nicht bis zum nächsten Wegweiser. Dabei wird nicht der Aufbau des Netzes abgebildet, sondern der Aufbau der Kreuzung.
Das ist bei mir anders, da zwei Wegweiser in Beziehung gesetzt werden, die durch einen Weg verbunden sind. Somit ist das Netz selbst abgebildet.
Korrekt. forward und backward steht nicht für den Hinweg/Rückweg, so wie im Blogbeitrag beschrieben.
Ich bin mir nicht sicher ob ich das ohne Beispiele des Auftretens der Rollen in anderen Kontexten beurteilen kann.
Eine Anwendung der Rolle forward/backward, mit denen ich Erfahrung habe, ist die Erfassung von Fahrrad-Routen. Dort dient es dazu, eine Abfolge von Ways so zu erfassen, dass eine unterbrechungfreie Folge von Ways entsteht, d.h. der letzte Node des Vorgängers mit dem ersten Node des Nachfolgers übereinstimmt und damit eine unterbrechungsfreie Abfolge eines gesamten Ways über die Abfolge einzelner Ways zu erzeugen. Dort kann die Rolle forward/backward bedeutsam sein, wenn ich Einbahnstraßen gegen die vorgegebene Richtung befahre.
Wenn ich einen way mappe, ist es völlig willkürlich, an welchem Ende ich anfange. Die Richtung hat keine Bedeutung. Nur wenn ich eine geordnete Abfolge in einer Route anlegen möchte, muss ich aufgrund dieser technischen Lösung bei der Route ob dieses Wegstück entlang seiner Richtung in der Datenbank in der Route vorkommen soll, oder gedreht wird. Das mach ich mit forward/backward.
Ich stimme dir zu, dass die Übertragung einer Lösung für eine technische Gegebenheit auf eine semantische Anwendung zur Verwirrung beitragen kann. Ich bin für eine bessere Namensgebung dankbar. Für meine Anwendung ist die geordnete Abfolge keine Forderung, da sowohl die Darstellung auf einer Karte oder die Berechnung der Entfernung zwischen den Wegweisern aus dem dazwischen liegenden ways keine geordnete Abfolge erfordern. Mit Hilfe der Rollen forward/backward kann ich zwei getrennte Abflogen von ways für den Hin- und den Rückweg erzeugen. Da diese dann bei ausgeschilderten Wegen ohne Verzweigung sind, lassen sie sich auch nachträglich zu einer lückenlosen Abfolge sortieren, sollte das erforderlich sein.
Die Bedeutung der Rollen forward und backward bei type=route Relationen ist im OSM Wiki beschrieben. Ich habe einige Zeit gebraucht, bis ich das verstanden habe, weil ich es auch so erwartet habe, wie Du es im Blog beschreibst.
Ich bin mir jetzt nicht sicher, ob Du das im Blog nur ungeschickt beschrieben hast oder ob Du es wirklich umdefinieren möchtest.
Ich bin mir nicht sicher, ob ich verstanden habe, was du sagst.
Bei mir stehen forward/backward für den Hin- und Rückweg einer in beiden Richtungen befahrbaren Strecke. Sie beziehen sich nicht auf die technische Richtung des ways in der Datenbank. Dies habe ich in der Antwort auf den Beitrag von GerdP etwas ausführlicher beschrieben.
Doch, genau darauf beziehen sie sich.
Ich hoffe, dass ich die Seite erwischt habe, auf die du dich beziehst: Relation:route - OpenStreetMap Wiki.
Dort wird in der Tat forward in Bezug auf die technische Richtung des way beschrieben. Aber so wie wir nicht für den Render mappen, sollten wir auch nicht für die Datenbank mappen, denke ich. Ich nehme mit forward Bezug auf die Richtung der Strecke von Ort A nach Ort B und mit backward darauf dass die Richtung von Ort B nach Ort A geht. Vielleicht lassen sich bessere Bezeichnungen finde, die dieses Missverständnis vermeidet. Würde onward/rearward passen?
Alternativ lässt sich alles ohne rolle forward/backward mit etwas Redundanz in zwei getrennten Relationen darstellen. Dem steht entgegen, dass mit der Redundanz die Datenbank etwas aufgebläht wird (ein Argument von Sebastian/@segubi ), aber vor allem, dass für den menschlichen Leserder Relation der unmittelbare Bezug zwischen Hin- und Rückweg verloren ginge.
Ich denke, die bereits vorhandene Festlegung im Wiki ist zwar nicht leicht verständlich, aber sie ist in diversen Tools umgesetzt. Wenn Du eine andere Bedeutung brauchst, dann müsstest Du einen neuen Relations-Typen festlegen. Für type=route sind die nutzbaren Rollen vergeben und ein einzelnes Mitglied kann ja nur eine Rolle haben.
Achtung! Da hängen dicke Mißverständnisse drin: Grundsätzlich: OSM ist eine Datenbank, und genau für die wird gemappt. (Wofür denn dann sonst?)
Natürlich wird auch gemappt, dass nachher gerendert werden kann. Das bleibt eine der Hauptaufgaben einer Geodatenbank wie OSM. Mit “don’t tag for the renderer” ist gemeint, dass man keine tags falsch benutzen darf, nur um eine erwünschte Darstellung in einer bestimmten Karte zu bekommen. Schöne Beispiele gibt es hier im Wiki: Tagging for the renderer - OpenStreetMap Wiki (die berühmten 3d-Hochhäuser …)
Die Rollen forward und backward sind klar definiert und sollten auf keinen Fall zweckentfremdet werden. forward heißt, der Weg wird im Rahmen einer Relation nur in Richtung des OSM-Weges benutzt, backward heißt, der Weg wird im Rahmen einer Relation nur in Gegenrichtung des OSM-Weges benutzt. Ob eine Routenrelation vorwärts und rückwärts ausgeschildert ist, wird mit signed_direction=* ausgedrückt. Default ist, dass die Relation in beide Richtungen befahren wird, und muß daher nicht extra erwähnt werden. signed_direction=* ist nur vernünftig auswertbar, wenn die Relation sortiert ist. Bei einer in beiden Richtungen befahrbaren Route kann man prinzipiell die Wege sortieren, wobei sich die Endpunkte bei Vollständigkeit ergeben.
Bei den Knotenpunktnetzwerken ergeben sich hierbei kompliziertere Strukturen durch aufgespaltene Knoten. Im Detail erklärt im Wiki: Cycle Node Network Tagging - OpenStreetMap Wiki Das Taggingschema bleibt allerdings problematisch, wer sich mehr für die Tücken der Tentakel und deren Interpretation interessiert, kann u.a. hier schauen, z.B. bzgl. dieser Route.
Hm… Ein Piktogramm in Text umwandeln kontraproduktiv? In was denn sonst? Wir haben ja nichts anderes. Mit (Bf) ist tatsächlich das Piktogramm gemeint. Auf den Schildern steht das “Bhf.” auch nicht in Klammern.
Die (Bf) usw. müssen klar von den Routensymbolen getrennt werden.
Es gibt offiziell folgende Systematik und Begriffe (zumindest in NRW in eine Verordnung gegossen): Zielwegweiser können zusätzliche zu den Zielen Piktogramme enthalten und zwar: Streckenpiktogramme hinter dem Ziel, die die Strecke als z.B. Freizeitstrecke, Bahntrassenweg oder Weg mit deutlicher Steigung beschreiben. Vor dem Ziel stehen die Zielpiktogramme, die das mit dem Text beschriebene Ziel präzisiseren: Bahnhof, S-Bahnhof, Radstation, Touristeninformation usw. Das ergibt eine konkrete Aussage zum tatsächlich ausgeschilderten Ziel. Bei Bahnhöfen, die deutlich entfernt vom Ortskern liegen, ist es z.T. üblich, dass nur das Bahnhofs-Zielpiktogramm und der Name des Bahnhofs auf dem Schild gedruckt ist. Die entsprechende Information gehört inhaltlich zum Ziel, es wäre praktisch unmöglich, sie aus anderen Tags zusammensuchen zu müssen, da ja klar werden muß, zu welchem der Ziele sie gehören. Siehe unterstes Beispiel im Wiki information=guidepost.
Das das sprachlich nicht optimal ist, ist mir auch klar. Ich finde allerdings die vorgesehenen Werte für Symbole zu lang, um sie in die destination_tags mit einzubauen. Meine Einträge im Wiki und die Aufforderung, sie um weitere zu ergänzen haben vor allem den Zweck der Vereinheitlichung, die eine Änderung erleichtern könnte, wenn einem etwas besseres eingefallen ist. Schwierig wird es tatsächlich, wenn ein und die selbe Sache mit verschiedenen Abkürzungen belegt würde. Niemand wäre mehr in der Lage ohne Überprüfung vor Ort festzustellen, ob es sich bei verschiedenen Abkürzungen noch um dasselbe Konzept handelt.
Die Routeneinschübe sind inhaltlich und in der Ausführung (eben getrennt von der Wegweisung, unterhalb) etwas völlig anderes. Hier geht es um die Beschreibung von Routen, die von Strecken unterschieden werden müssen. Strecken sind nur Teilabschnitte von Routen bzw. eines Netzwerkes, im Regelfall zwischen zwei Knoten, wobei der Begriff Knoten in den HBR leider doppeldeutig benutzt wird für
- jede Aufzweigung von Wegen im Radnetzwerk - obligat mit Richtungswegweisern auszustatten.
- Nummerierte Knotenpunkte eines Knotenpunktnetzwerkes.
Das Bild zum Knoten Node: 10598490681 | OpenStreetMap
Sorry für die schlechte Qualität, wurde am 31.1. bei wenig Licht aufgenommen.
Die roten Schilder sieht man nur in der Nähe der Route “Twistringer Erlebnisroute Archäologie” (TEA), aber ich denke nicht, dass die direkt etwas miteinander zu tun habe. Ist einfach eine Spezialität rund um Twistringen. Die Route wird (nur in eine Richtung) mit dem Schild unten am Mast ausgewiesen. Habe ich manchmal auch nur als Marker erfasst. Weitere Besonderheit ist, dass hier bei den Entfernungen die Angabe “km” fehlt. Ich habe die seinerzeit immer ergänzt, weil ich das Wiki so verstaden habe. Unterdessen habe ich aber häufiger Daten zu Wegweisern gesehen, die ohne “km” auskommen. In manchen Gegenden hier ist das durchaus gemischt. Kann ich gerne noch mal durchschauen.
Das Bild zum Knoten https://www.osm.org/node/7667489699:
Hier ist vor allem die Menge der Routen besonders, ansonsten noch interessant das - bisher nicht erfasste - Symbol für Hügelgrab vor dem “Pestruper Gräberfeld 4.4 km”, das in meiner Gegend häufiger auftaucht.
Ja, und da wäre die Frage: Ausschreiben (Bahnhof Münster) oder Abkürzen
(Bf.) Münster ? Oder beides zulassen?
Hier noch zwei Bilder aus Bersenbrück zur Kreuzung https://www.osm.org/node/245417120:
Normalerweise sind ja die Texte auf den Schilder an einer Kreuzung gleich, aber
In Bersenbrück gibt es die Besonderheit, dass die Entfernungsangaben je nach Schild sehr unterschiedlich sein können. Wehbergen z.B. ist einmal 5.0 und einmal 3.9 km weit weg. Habe ich dort - und bisher nur dort - an einigen Kreuzungen so beobachtet.
Auch interessant: Unterschiedliche Schriftbilder und refs auf den einzelnen Schildern. Evtl. wurden dort Schilder recycelt?