Knotenpunktnetzwerke

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.

Nein, das stimmt nicht. Technisch ist es anders, aber für den Planer und Benutzer ist es das gleiche System. Nur mit Buchstaben statt Zahlen. Man plant eine Trip, und endet mit eine Liste von Knotenpunktlabels. Unterwegs seht man den nächsten Knoten auf die Liste und die Pfeile zeigen die Richtung.

Ich mag auch kurze Zahlen mehr als Namen, aber in manche gebieten sind Namen informativer für den Wanderer.

Dieses Tag wurde eingeführt, weil Datennutzer gebeten haben, Knotenpunktrouten mittels eines Tags eindeutig von anderen Freizeitrouten zu unterscheiden.
Es gibt auch andere nummerierte Knoten, und wenn ein Knotenpunkt fehlt, möchtet man nicht, dass die Route aus der Ansicht und aus und aus den Validierungen verschwindet.

Über die Definition: Dieses System stammt nicht aus Deutschland, sondern aus Belgien, wo eine Mischung aus (vielen) Nummern und (weniger) Namen verwendet wurde. Eine deutsche Organisation ist daher nicht die Quelle einer allgemeingültigen Definition, egal wie wichtig diese Organisation in Deutschland ist.
Unterwegs und im Planer kann das gleiche Netzwerksystem genutzt werden, mit Namen, Codes, Nummern, Farben oder einer Mischung daraus. Dies ist für die Benutzer wichtiger als eine Definitionsfrage.

Ich beende jetzt meine Teilnahme an dieser Diskussion, weil alles oft genug gesagt ist! Ich wünsche Ihnen viel Erfolg beim Ausbau der verschiedenen Netzwerke.

+1, ja, bitte, eine Unterscheidungsmöglichkeit und klare Definition der Relationen.
Sonst kann ich auch gleich noch auf network=* verzichten, denn mit Hilfe der Mitglieder und Eltern ist ja die Länge und auch das Gebiet ermittelbar. :roll_eyes:

Ich kann eine so gute Idee nicht ignorieren… wie lang sollte eine Route für l, r, n und i sein?

Und welches Tag wäre nützlich um eine mit ref=nn-mm getaggte Knotenpunktroute von einer ohne ref-Tag unterscheiden?

Fragen, Fragen…


(Jetzt zurück in den Winterschlaf)

Ist Ok, da es scheinbar nur uns beide interessiert bringt die Diskussion auch wenig.

Es kommen ja auch keine neuen Quellen oder ähnliches, ich hatte darauf gehofft. Ich hatte auch auf belgischen Seiten gesucht und nur etwas gefunden, was meine Aufassung stärkt. Aber da gibt es eine Sprachbarriere.

Man muss sich nicht in allem einig sein. :slight_smile:

…Hintergrundinformationen zu Knotenpunktnetzen in Brandenburg…

Liebe Knotenpunktfreunde…

durch Zufall bin ich bei der TMB (=Tourismus-Marketing Brandenburg GmbH) auf folgende Seite gestoßen: https://www.tourismusnetzwerk-brandenburg.de/projekte/projektbeschreibung/erfolgsfaktoren-und-prozesse-bei-der-einfuehrung-der-knotenpunktwegweisung-in-brandenburg/

Besonders positiv beeindruckt hat mich dieses pdf: https://www.tourismusnetzwerk-brandenburg.de/intranetfilestorage/projects/167_Erfolgsfaktoren_und_-prozesse_bei_der_Einfuehrung_der_Knotenpunktwegweisung_in_Brandenburg/Die_Potenziale_der_Knotenpunktwegweisung._Ein_Leitfaden_fuer_Brandenburg.pdf
Wir als OSM-Gemeinschaft werden da aktiv genannt unsere Daten (hier Netzwerkrelationen) aktiv verlinkt. Das bestärkt mich auch im meiner Meinung, daß nur über OpenData wie wir es umsetzen, solche Dinge verarbeitbar sind. Auch unsere Holländischen Nachbarn haben mit ihrer Seite https://www.knooppuntnet.nl/en/analysis/cycling/de/networks einen ganz gewichtigen Beitrag mit dazu geleistet…

Da sieht man, wo die Reise hingeht… Es scheint auch so zu sein, als daß für den Landkreis Potsdam-Mittelmark sich Knotenpunkte materialisieren könnten. Also: Augen auf und bitte drauf achten…

Viele Grüße,

Sven

  • 1 :slight_smile:

Michael!

:slight_smile:
Diese Ehre geht an vmarc in Belgien und sicherlich auch für seine fantastische Planer-Anwendung. Betreiber können jetzt einfach verlinken und müssen keinen Knotenpunktplaner selbst programmieren.

Hallo Zusammen,

User dx125 hat mir Fotos vom Knotenpunkt 26 in Radewege geschickt. Vielen Dank dafür. Dieser Punkt und eine Handvoll andere Punkte liegen im Landkreis Potdam-Mittelmark, im Amt Beetzses, der bisher kein eigenen Netz hat. Dieses bisher kleines Netz wird sicher im Zusammenhang mit dem Netz Landkreis Havelland entstanden sein.

Ich tendiere dazu, daß man diesen Bereich als eigenes Netz abspalten sollte, auch die bisher in der Stadt Brandenburg liegenden Punkte in Routen würde ich dann in ein eigenenes Netz verschieben. Es scheinen auch hier neue Punkte hinzuzukommen: z.B.: https://www.mapillary.com/app/?pKey=887048998832892

Das würde dann auch mit den Angaben passen, die im pdf dargestellt sind (vg. Beitrag https://forum.openstreetmap.org/viewtopic.php?pid=847984#p847984)

Meinungen?

Sven

Es sind ja doch schon einige Knotenpunkte im Landkreis Potsdam-Mittelmark erfasst. Im Sommer gab es die zumindest im Raum Werder noch nicht, wurden die tatsächlich alle in den letzten Monaten beschildert? Dann sollten die auf jeden Fall ein eigenes Netz bekommen.