Knotenpunktnetzwerke

Wenn du willst, leg los. Dann hab ich eine Referenz…

Ja, deswegen die Zwischenlösung mit der Route https://www.openstreetmap.org/relation/11256109 da bei gut 50m Entfernung beides zueinander sichtbar ist…

Sven

Ok, ich habe es gerade umgebaut.
Ich kann mal Versuchen das Prinzip der split nodes kurz zusammenzufassen:
Es gibt technisch mehrere Knotenpunkte, die im Netz mit der gleichen Nummer ausgezeichnet sind. Das ist häufig an großen Kreuzungen und Brücken der Fall, aber auch an Straßensituationen wie dieser.
Man schaut sich nun jede Knotenpunktroute einzeln an, die mit dem Knotenpunkt verbunden ist, und zwar in dieser Beschreibung gedanklich in Richtung des Knotenpunkts. Die Route wird nun ganz normal für beide Fahrrichtungen bis zum ersten Knoten des split nodes geführt. Zusätzlich müssen von allen anderen Knoten des split nodes aus Verbindungen nur für die Gegenrichtung (die sogenannten tentacles) angelegt werden, die bis zur ersten erreichbaren Stelle einer der folgenden Möglichkeiten geführt werden:

  1. dem ersten Knoten
  2. einem anderen tentacle
  3. einem Punkt der Hauptroute

Anders formuliert: In Richtung des split nodes wird die Route nur bis zum ersten Knoten des split nodes angelegt, in Gegenrichtung aber von allen Knoten des split nodes.

Ausführliche Anleitung und komplexe Beispiele gibts hier:

https://wiki.openstreetmap.org/wiki/Cycle_Node_Network_Tagging

Anschließend kann man bei knooppuntnet.nl gut sehen, dass das Routing jeweils über die kürzeste Verbindung geführt wird ohne dass doppelte Knoten oder Routen wie 18-18 nötig sind.

Betreffs der Altmark:

Aus den Fotos ist nicht ersichtlich, was in Mahlitz am Knotenpunkt (KP) 35 ausgeschildert ist.

Wenn dort tatsächlich sowohl der KP 20 als auch der KP 43 mit einzelnen Einschüben ausgeschildert ist, dann sind es auch zwei route-Relationen: eine zum KP 20, eine zum KP 43. Das wäre dann die saubere Lösung.

Wenn am KP 35 nur die 20 ausgeschildert ist, dann ist der Wegweiser am Abzweig Teil des KP 20 und es gibt eine Route 35 <>20 mit einem Split-Node am KP 20.

Der Abstand zwischen KP 20 und KP 43 beträgt 380m. Der Abstand zwischen Abzweig und KP 20 nur 125m. Das spräche dafür den Abzweig tatsächlich als Teil des KP 20 zu verstehen.

Auch die Karte des Knotenpunktnetzwerkes verbindet den KP 35 nur mit dem KP 20. Spricht auch für den Split-Node am KP 20.

Normalerweise heißt Knotenpunktnetzwerk “keep it simpel”. Es wird immer nur der nächste Knoten ausgeschildert, pro Richtung also eine Nummer. Im Bild wird am Abzweig nicht nur der nächste KP 20 sondern gleich noch der übernächste KP 19 ausgeschildert. Man könnte das als weiteren dezenten Hinweis verstehen, dass dieser Wegweiser Teil des KP 20 ist.

Wenn vom KP 35 aus auch der KP 43 ausgeschildert ist, sollte diese Relation trotzdem erstellt werden, sie ist draußen ja auch ausgewiesen, unabhängig von der Sicht der netten Mitarbeiterin der Gemeinde und unabhängig davon, ob der KP 20 gesplittet wird oder nicht.

Noch ein paar Hinweise zum Tagging:

Am Knotenpunkt 20 und 43 wurde der Wegweiser direkt auf den Kreuzungspunkt der Wege getaggt. Das ist nicht im Sinne des Erfinders. Den Wegweiser möglichst dort taggen, wo er steht, den Knotenpunkt dagegen auf den Kreuzungspunkt der Wege (KP 20: node/516386987 und KP 43: node/1808230300).

Im Wiki dazu:

Die Master-network-Relation des Knotenpunktnetzes sollte kein ‘route=bicycle’ haben, denn sie stellt keine Route dar sondern eine Art Sammelkategorie(relation/12331231).

Im Wiki dazu:

<klugscheißermodus an>

Zwischenwegweiser sind nur die kleinen Pfeil-Schilder auf der Strecke zwischen zwei Hauptwegweisern. Dort gibt es keine Ortsangaben sondern maximal Aufkleber der Routen und einen (!) Pfeil.

<klugscheißermodus aus>

Sorry, ich hatte Deine Fotos letztens übersehen.

Die Ausschilderung an KP 35 wäre interessant.

  1. nur 20 ausgeschildert

KP20 müsste ein split node sein. Ohne split node würde man bei der Route 35->43, streng der Beschilderung folgend, das letzte Stück zum KP20 hin und zurück, also doppelt fahren. Allerdings ist für eine korrekte Beschilderung mit einem split node die 35 am Schild bei KP43 zuviel und an Deinem “Zwischenwegweiser” (der dann auch ein KP20 wäre) müsste die 20 durch die 02 ersetzt werden.

  1. 20 und 43 ausgeschildert

Kein split node, die Rrouten 35->20 und 35->43 wären größtenteils identisch (unschön). In diesem Fall wäre die 19 an Deinem “Zwischenwegweiser” zu viel.

Mir scheint es hier so zu sein, dass die Planer selbst nicht ganz genau wussten, wie sie diese Situation ausschildern sollen :wink:

In den Niederlanden ist das genau so!
Wir haben sogar Operatoren, die keine Zahlenreferenzen auf die Knotenpunkte schildern! Woher weiss man dann, wie man zum nächsten Punkt gelangt?

Knotenpunkte mit Namen statt Nummern: Knooppuntnet hat das jetzt eingebaut, für Analyse und für Map (Planer).

Ich habe gesehen, dass Deutsche Mapper im Schwarzwald bereits viel Arbeit geleistet haben, Kudo’s!

Waymarkedtrails unterstützt Knotenpunkte mit Namen (noch) nicht, aber da WMT die Wegweiser anzeigt, sieht es immer noch vernünftig aus.

Die Methode ist für alle Typen von Knotenpunktnetzwerke gleich. Aber, zB, lwn und rwn zu mischen das funktioniert noch nicht. Also alle Elemente lwn, oder alle Elemente rwn.

Die ersten Pilotversuche zu diesem Ergebnis wurden in Deutschland durchgeführt. Vielen Dank dafür!

Das geht mit Wanderwegen im Schwarzwald aber leider nicht mit Fahrradwegen. Der Grund ist simple. Die Wanderwege haben am Ziel einen Wegweiser mit Namen. Die Fahrradweg haben aber nur Richtungsangaben ohne Angaben eines Namens am Wegweiser und häufig fehlt am Ziel auch ein Wegweiser. Der Anfang und das Ende bleiben dadurch immer unscharf.

Ich habe auch schon Beispiele gefunden, wo jetzt die einzeln Segment-Relationen in die übergeordneten Relationen eingebaut wurden. Vom Prinzip, ja richtig, allerdings Frage ich mich in wie viele Ebenen von Superroutes wird dann einen europäischen Radwanderweg eintragen wollen. Beim ÖPV gibt es starke Bedenken bei Segment-Relationen aufgrund der zusätzlichen Ebenen, aber vielleicht ist dann bicycle und hiking ein Türöffner.

Insgesamt fände ich es auf jeden Fall gut, wenn wir einen Tag für die Unterscheidung von Fahren nach Zahlen bzw Fahren nach “Namen” haben.

Ich denke, Peter redet nur von Knotenpunktnetzwerken mit Namen, nicht den von skyper angesprochenen “Radverkehrsnetzen” in Deutschland.

Es gibt:

  1. Knotenpunktnetzwerke mit fester Bezeichnung für die Knoten:
    – Nummern
    – Namen

  2. Radverkehrsnetze / Zielwegweisung

Hier gehts um 1), über 2) wird u.a. hier diskutiert: https://forum.openstreetmap.org/viewtopic.php?id=72458

++1

Der Begriff “Knotenpunktnetzwerk” ist bereits belegt für das “Radeln/Wandern nach Zahlen”, wo i.d.R. nur die nächste Knotenpunktnummer ausgeschildert wird. Idee war ja, dass sich der Tourist nur eine Reihe von Nummern merken/aufschreiben muss, keine langen Namen.

Ein Netzwerk, in dem die Wegweiser Namen statt Zahlen haben und i. d. R. mehrere Ziele ausgewiesen werden, fällt nicht unter diese Definition. Das hatte ich ja an anderer Stelle bereits mit Quellen belegt.

Auch sollte dem Renderer die Chance gegeben werden, beides anhand eines Taggs zu unterscheiden. So kann er damit anders umgehen.

Ich hatte Probleme, das zu verstehen. Mir war nicht klar was nun genau der “Split-Node” ist. Der Knotenpunkt als Ganzes oder die einzelnen OSM-Knoten? Schwierig war für mich auch das “in der Gegenrichtung”, da mir nicht klar war, von welcher Richtung es die Gegenrichtung war. Nächster Stolperpunkt: Was ist eine “Hauptroute”. Zudem: Wenn das Tentakel nicht an einem Split-Node sondern auch an einem anderen Tentakel enden kann, so muss man ggf. bei der Fahrt durch den Knoten 2 mal die Relation wechseln. Das ist m. E. nicht im Sinne des Erfinders. Erschwerend kommt dazu, “Knoten” in diesem Kontext dreifach belegt ist:

  • Knoten des Knotenpunktnetzwerkes

  • OSM-Knoten, die diesen Knoten darstellen

  • Knoten im OSM-Graph allgemein

Auch den englischen Text in wiki/Cycle_Node_Network_Tagging habe ich erst verstanden, nachdem ich das Beispiel intensiv studiert habe. Das kann aber auch an meinem Englisch liegen.

Ich habe es selber versucht. Es ist echt schwer, das textlich so zu beschreiben, dass es eindeutig ist und man es trotzdem versteht. Auf jeden Fall wird es länger. Hier der Link zu meinem Vorschlag für das Wiki mit zwei abstrakten Beispielen:

[wiki/User:JochenB/split_nodes](https://wiki.openstreetmap.org/wiki/User:JochenB/split_nodes)

**Stimmt das Vorgehen so? Ist der Text verständlich? **

Das Beispiel 2 entspricht dem Beispiel auf wiki/Cycle_Node_Network_Tagging

Unschön ist, dass sich in den Relationen durch die Tentakel keine durchgehende Wegekette mehr ergeben. Diese Durchgängigkeit ist normalerweise ein einfacher Qualitätscheck. Leider kann man die Tentakel nicht über eine Rolle wie z. B. ‘link’ markieren, da die Rollenfelder schon mit ‘forward’ bzw ‘backward’ belegt sind.

Der Text ohne Beispiele nochmal hier:

lwn Knotenpunkte mit Namen sind getaggt mit lwn_name=
lwn Knotenpunkte met Zahlen oder kurze Coden sind getaggt mit lwn_ref=
Ich denke das genügt, oder?

Die von den Belgiern und Niederländern entworfene und in Zusammenarbeit mit anderen Ländern weiter ausgebaute Definition des Knotenpunknetzes in OSM ist nicht auf Zahlen beschränkt. Es ist eine funktionale Definition: Knoten haben eine Marke als Referenz für den Benutzer, und benachbarte Knoten verweisen zu zweit aufeinander. An Zwischenkreuzungen müssen nur Pfeile vorwärts und Pfeile zurück vorhanden sein, die Knoten dazwischen müssen nicht erwähnt werden, obwohl dies oft der Fall ist. Wenn die Knoten keine Namen oder Nummern, sondern Bilder oder Symbole oder (warum nicht) Pieptöne hätten, könntest du die Route genau so planen und so erhältst du eine Liste von Bildern usw., denen der Reisende folgen kann.

Das System ist so konzipiert, dass es in all diesen Fällen gleich funktioniert. Deshalb finde ich es gut, den gleichen network:type zu verwenden. node_network zeigt an, dass die Segmente an diesen Punkten miteinander verknotet sind, wie die Schnüre in einem Fischernetz.

Beispiel: extreme Split-Node-Situation mit alternativer Lösung, der „Cluster-Methode“.
https://knooppuntnet.nl/nl/analysis/route/11512870/map

Ja, damit wären wenigstens die Knotenpunkte unterscheidbar.

Ich finde es nicht gut, wenn wir Dinge in OSM anders definieren als draußen. Vermutlich ist das jetz so etabliert, dass man es nicht mehr geändert bekommt.

Wie kann ich anhand der Daten unterscheiden zwischen Relationen eines klassischen “Knotenpunktnetes” mit Zahlen bzw. kurze Codes und den Relationen eines Wanderwegenetzes mit benannten Wegweisern? Die Knotenpunktnetze sollten ja genau die Nachteile der Namen beseitigen, in OSM sind sie nun wieder gleich.

Es gibt keine universelle Definition von “Knotenpunktnetzwerk”. Es gibt Beschreibungen, die die gängigste Form als Beispiel angeben. Da es viele andere Varianten gibt, die sich in vielen kleinen Punkten unterscheiden, aber im Wesentlichen das gleiche Funktionssystem verwenden, würde OSM meiner Meinung nach gut daran tun, sich nicht auf eine Implementierung festzulegen.

Knotennetzwerk sagt genau, was es ist: ins Netz verknoten. Jeder, dem die Verwendung von Zahlen wichtig ist, kann diese Implementierung Number Network nennen. In den Niederlanden betonen einige Betreiber, was der Wanderer tun muss: Sie nennen es Auswahlpunkte.

Aufgrund des generischen Tagging-Systems spielt dies für OSM keine Rolle. Diese Implementierungen sind funktionell ähnlich und entsprechen dem Bild eines geknoteten Fischernetzes.
Sie können daher grundsätzlich gleichzeitig und gekoppelt verwendet werden; man kann ein Trip über nummerierte Knoten, Wahlpunkte mit Farben oder Knoten mit Namen planen; wenn sie verbunden sind, funktioniert es und der Unterschied liegt hauptsächlich in der Routenliste für den Benutzer.

Die Knoten sind Teil der Relationen, nämlich der erste Knoten des ersten Weges und der letzte Knoten des letzten Weges. Damit sind die Informationen verfügbar. Man könnte es auch redundant für alle Relationen separat, oder für die Network Relation taggen, aber warum sollte man das tun, wenn es keinen funktionalen Unterschied macht?

Das Argument die Mitglieder der Relation ranzuziehen finde ich zu einfach. Damit bräuchte ich ja nicht einmal die Fallunterscheidung zwischen altbackener Route und Knotennetzwerk.
Mir ist es herzlich egal wo und wie unterschieden wird, aber es sollte aus den Tags der Relation ersichtlich sein, um welche Art von Knotenbezeichnung es geht. Zahlen, Farben, Namen und Symbole wurden jetzt schon genannt, gibt es noch mehr?

Ja, der Unterschied war ja nur gedacht um den Fall zwischen “zu Fuß” und “Rad” in BaWü besser einzuordnen.

Die restlichen Anmerkungen gelten aber für bei Threads, wenn ich den europäischen Radwanderweg durch Schwarzwaldquerweg oder Fernwanderweg Freiburg-Bodensee ersetze. Ich habe jetzt zig destination_sign Relationen für jeden einzelnen Wegweiser, jeweils ein Segment von benannten Wegweiser zu benanntem Wegweiser, dazu dann Superroutes für die einzelnen übergeordneten Ziele (eventuell auch schon in mehreren Relationen verschachtelt, weil das Fernziel die gleiche Strecke wie das nähere Ziel hat) und dann erst kommen die übergeordneten “normalen” Routen á la Fernwanderweg, diese auch schon in einzelne Etappen unterteilt. Habe jetzt vergessen zu zählen, aber vier bis fünf Ebenen von Relationen könnte ich locker erreichen.

Ich bin nicht sicher, ob ich dich hier richtig verstehen. Wo sind denn solche Relationen angelegt? Kannst du jeweils ein Beispiel zeigen?

In den Niederlanden laufen oft genug 20 Relationen über 1 Straßenabschnitt. ÖPNV-Routen, lange/kurze/Knoten/bevorzugte Fahrradrouten, lange/kurze/Knoten/bevorzugte Fußrouten. Nicht selten folgen 6 Fern- oder Nahwanderwege dem gleichen Weg.

Es gibt keine klare allgemeingültige Hierarchie für cycleways, cyclable paths etc. Ja, das glauben nationale, regionale und lokale Gremien, aber jeder hat seine eigene Idee und, wie soll ich sagen, sie passen nicht immer gut zusammen.

Ich persönlich halte von Relationen vom type=destination_sign nichts… Es ist in der Erfassung zu aufwendig und in der Masse der vorhandenen Wegweiser (z.B. Rad~, Wander~) nicht leistbar das selbst ansatzweise vernünftig zu erfassen…

Ich selbst werde die Finger davon lassen… Das ist aber eine eigene Disskussion…

Sven

So schnell finde ich leider die konkreten Beispiele nicht (mehr?), Sorry. Eine kurzzeitige Sperre und ein JOSM Ticket später, kann ich nur sagen, dass ich in diesem CS solche kurzen Abschnitte zwischen zwei Wegweisern aus der Etappe des Rheinradweges geschmissen habe, finde sie aber nicht mehr und meine damaligen Änderungen haben gefruchtet, was die Struktur angeht. Sieht jetzt schon viel sauberer aus, wurde aber auch einiges geändert.
Bei den Wanderwegen ist es leider nicht groß anderes.
Daher hier nur ein paar Beispiele für Routen, die von solchen Zerlegungen betroffen sein könnten:

  • Der Rheinradweg ist jetzt schon in drei Ebenen. Die Etappen könnten aber durch aus noch in Teile von Stadt zu Stadt unterteilt werden und in Köln dann wohl zusätzlich noch die einzelnen Abschnitts-Relationen von Wegweiser bis Wegweiser als unterste Ebene verwenden. Da bin ich dann bei fünf Ebenen.
  • Der E1 hat selbst schon drei Ebenen. Eine unterste Ebenen hat aber deckungsgleiche Teilabschnitte mit den “einfachen” Ausschilderungen ([1], [2]). Diese könnten nun aber auch noch in Teile von Wegweiser zu Wegweiser geteilt werden, da wie gesagt, die Wegweiser eigene Namen und Höhenangaben haben. Dachte, das hatte ich auch schon mal entdeckt.

Hoffe, das hilft ein bisschen weiter.

Hallo Peter,

ich sehe hier Analogie zu einem klassischen Nichtverstehen zwischen Techniker und Produktmanager. Du

Aber erstmal zur Definition:

Wo genau hast du gefunden, dass dies nur ein Beispiel unter vielen ist?

Ich habe nur die an mehreren Stellen dokumentierte Definition gefunden, nach der Knotenpunktnetzwerke sich auszeichnen durch ein a) Netz mit nummerierte Knoten, an denen b) die Nummern der Nachbarknoten ausgewiesen sind.

Bislang habe ich nach stundenlangen Suchen garnichts gefunden, das einen Hinweis gibt, dass das nur eine unter mehreren möglichen Definitionen des Fachbegriffs ist.

Ich glaube hier liegt der Kern, warum wir nicht zusammen kommen.

Du schaust aus technischer Sicht drauf. Der Technik ist es egal ob kurze Nummern oder lange Zahlen, ob wenige oder viele Ziele. Programmiert ist das nahezu gleich. Das sehe ich auch so.

Die mir einzig bekannte Definition von “Knotenpunktnetzwerk” schaut aber eben nicht aus technischer Sicht drauf. Sie beschreibt die Nutzersicht auf die Wegweisung. Die Grund-Idee ist eben, die Vereinfachung durch kurze Nummern und (in der Regel) nur eine Ziel-Nummer je Richtung. Das ist ein Begriff aus dem Tourismus Marketing, kein technischer.

Die Kern-Funktion eines “Knotenpunktnetzwerks” ist diese Vereinfachung. Nicht der technsiche Aufbau.

Der Begriff kann gar nicht technisch definiert sein. Aus technischer Sicht ist “Knotenpunktnetzwerk” absolut nichtssagend. Ein Netz hat immer Knoten(punkte), sonst wäre es keines. Technisch gesehen könnte man ja alles oder nichts darunter verstehen.

Hier sind wir wieder bei der technischen Sicht versus Nutzersicht.

Aus Nutzersicht empfinde ich es nicht als “kleinere Abweichungen”, wenn die beiden Kern-Funktionen eines Knotenpunktnetzwerks ins Gegenteil verkehrt werden. (lange Namen statt kurze Nummern, mehrere lange Zielbezeichnung je Richtung statt eine Ziel-Nummer)

Für die Nutzer der Karten ist ein wesentlicher funktionaler Unterschied, ob er ein Wegweisungssystem nach der außerhalb von OSM bekannten Definition eines Knotenpunktnetzwerks vorfindet, oder eben eine klassische Wegweisung, bei der Wegweiser teils lange Namen tragen.

Wir bauen OSM letzen Endes dafür, dass am Ende Nutzer die Daten nutzen, nicht für - noch so gute - technische Werkzeuge, die die Datenqualität checken.

Nun gut, dass diese hier verwendete Definition von der draußen verwendeten Defintion abweicht ist ja genau das, was ich kritisiere.

Und hier ist halt der dritte wesentliche Dissens. Ich finde es tut OSM gar nicht gut, zwei aus Nutzersicht völlig gegensätzliche Ansätze unter dem selben Namen festzulegen.

Nun, mit diesem Argument braucht man das ‘network:type=node_network’ garnicht, denn es lässt sich ermitteln, ob an beiden Enden nummerierte Knoten liegen.