Knotenpunktnetzwerke

Stimmt, aber die vielen 18-Nummern sollen zusammen ein Knotenpunkt sein.

Gemeint war eher so etwas: Nr 99 - Nr 99 mit nur 13 km Abstand https://knooppuntnet.nl/nl/map/cycling#qb0qy-q9fut

Auch wenn es die Stadt, in der ich lebe, vielleicht nicht wirklich gibt. In Bielefeld haben sie es geschafft, das doch recht kleine Gelände mit einem engen Knotenpunktnetzwerk zu überziehen, da wimmelt es von Doubletten (alles Luftlinie): 6-6 mit 5,1 km Abstand, 2-2 mit 6,0 km, 77-77 mit 5,5 km, 78-78 mit 7,0 km, 80-80 mit 6,7 km, 27-27 mit 8,9 km usw.
Fast, als ob jeder Stadtbezirk sein eigenes Netzwerk hätte, oder die früher unabhängigen Städte und Gemeinden Heepen, Brackwede usw. sich nach fast 50 Jahren immer noch als autonom betrachten… Man könnte ordnungsgemäß die Route 77-78-80-81-77 fahren und ist dann nicht wieder am Ausgangspunkt. (Allerdings endet in diesem Beispiel ein Abschnitt im Moment blind an einer Autobahn, die Brücke ist gerade eine Baustelle ).

Es unterstreicht meiner Meinung nach noch einmal, dass man beim Mappen auf keinen Fall zu viele Grundannahmen über Netzwerke im Allgemeinen machen kann, sondern tatsächlich schauen muß, wie die Gegebenheiten vor Ort sind, und wie man sie beschreiben kann.

Davon wurde zwar bereits abgeraten - das kann ich aber bezogen auf die hiesigen Routen nur unterstreichen. Weitgehend liegen die Themenrouten entlang Knotenpunkten, aber eben nur weitgehend. Und die ganze Geschichte ist dynamisch. Es ist nicht gesagt, dass eine Route geändert wird, und dann mittendrin plötzlich doch die Knotenpunktroute wieder verläßt. Das wäre dann äußerst mühsam, die Knotenroutenetappen wieder aufzulösen.

Auch das über knooppuntnet vorgeschlagene Verfahren kommt hier in Bielefeld an seine Grenzen, da die Ausschilderung aus welchen Gründen auch immer Merkwürdigkeiten bereithält:

So gibt es z.B. einen Knoten 55, der den Nachbarknoten 51 in zwei Richtungen ausweist, rückwärts gibt es aber nur eine Routenführung… (habe ich versucht abzubilden in den Routen 51-55 und 55-51).

Ja, ja, sowas gibt’s.

Die Knotenpunktnetzwerke befinden sich inzwischen in einer übergeordneten Relation Fahrradknotenpunktnetzwerk NRW, die wiederum in die Relation Radverkehrsnetz NRW aufgenommen ist.

Da es gar kein Fahrradknotenpunktnetzwerk NRW gibt, würde ich hier vorschlagen, den Namen zu ändern in die Mehrzahl Fahrradknotenpunktnetzwerke. Es kann zwar sein, dass in der Zukunft die vereinzelten Netze zu einem großen Netz zusammenwachsen, das beschreibt aber nicht den aktuellen Zustand, und in den offiziellen Bezeichnungen taucht das auch nicht auf. Mir kommt es noch etwas besser vor, die Knotenpunktnetzwerke der Kreise jeweils in die Unter-Relationen des Radverkehrsnetzes aufzunehmen statt noch eine Superrelation neben den jeweiligen Kreisnetzwerken auf der höchsten Ebene zu haben.

Das hätte den Vorteil, dass man für jeden Kreis eine vollständigere Fahrradinfrastruktur in einer Relation verfügbar hätte. Lediglich die Themenrouten bleiben noch unklar, die könnte man eventuell auch noch in den Kreisen unterbringen.

Grüße, Sebastian

Ist das ein Problem? Es gibt keine Knotenpunkte, die in zwei verschiedene Richtungen auf 99 zeigen.

Das ist eine laufende Arbeit, denke ich? https://knooppuntnet.nl/de/analysis/network/11177857/facts

Nein, es ist kein größeres Problem. Allerdings sollte der Netzbetreiber die Nummern so vergeben, dass gleiche Nummern möglichst weit auseinanderliegen.

Wenn du z. B. Punkt 99 als Ziel hast und siehst wenige Kilometer vorher einen Wegweiser zum 99, dann denkst du vielleicht dass das eine Abkürzung ist oder du vorab nicht richtig geplant hast. Wenn du dich dann spontan entscheidest, die Route zu ändern, dann hast du dich verfahren.

Na ja, sie tun was sie tun, ohne uns zu befragen!

Wohl eher 1-3h reine Fahrzeit, je nach Geländeform, Untersatz und Windverhältnissen.

… kann man wohl sagen… Der Anteil der korrekten Abschnitte war auch schon einmal größer, als ich erst die Hälfte der Routen eingegeben habe. Da ich aber die Strecken abfahre, auch um zu schauen, ob sie wirklich befahrbar beschildert sind (es ist auch vor Ort noch ziemlich neu und hat viele Fehler), dauert es. Und soweit ich das überblicke, habe ich im Moment nicht viele Mitstreiter. Einige Probleme bestehen aber tatsächlich: es gibt viele Baustellen, Strecken sind hierdurch nicht befahrbar, und manche Tentakel sind wirklich unlogisch oder zumindest kompliziert ausgeschildert mit mehreren Split nodes und überkreuzten Tentakeln, da kommt knooppuntnet nicht immer ganz hinterher, auch wenn es auf der Straße wirklich so ist, wie ich es gemappt habe.

Es wartet aber tatsächlich noch viel Korrekturarbeit. Ich stelle im Moment weiter die Routen zusammen, an die Anpassung an die Anforderungen von knooppuntnet mache ich mich erst in einem weiteren Arbeitsgang, das ist viel Arbeit…

Besonders mühsam ist es, die Durchgängigkeit für das Fahrrad zu überprüfen, also ob die Tags bicycle yes/no oder use sideway usw. vernünftig gesetzt sind. Wenn nicht, wird es nämlich schnell sehr aufwändifg, wenn man die Fahrradwege links und rechts der Fahrbahn jeweils mappen muß und dann noch mit den entsprechenden Rollen versehen - und dann sind diese Wege halt primär oft nicht komplett gemappt, so dass es nicht reicht, die Relationen zusammenzustellen. Und manche Sachen sind nicht ohne eine neue Besichtigung vor Ort nicht zu klären.

Sie haben es tatsächlich fertig gebracht, kurze Abschnitte in das Fahrradknotenpunktnetzwerk einzubauen, in denen man gar nicht Fahrradfahren darf (eine enge Brücke z.B.). Ich habe mich jetzt entschieden, hier noch bicycle=dismount einzufügen, um zu signalisieren, dass es trotzdem eine Fahrradroute sein soll…

Danke dafür!!!

Und ich habe noch eine Ergänzung. Ich weiß nicht, ob irgend ein Renderer das verwendet, aber ich werde mal die Routen, soweit ich die Beschilderung zur Verfügung habe, mit den Tags “incline=up” und “incline=down” ergänzen. Das ist leider nirgendwo explizit empfohlen, und auch vielleicht nicht verallgemeinerbar.
Aber in NRW haben sämtliche Streckenabschnitte den Charakter von Knotenabschnitten. Schilder stehen nur an bestimmten Punkte, dazwischen gibt es nur kleine Pfeile ohne jede Zusatzinformation. Die Routen werden also durch die Beschilderung zwischen je zwei Wegweisern definiert. Unter den vorgegebenen Routentypen ist für NRW vorgesehen, dass Steigungen und Gefälle > 4% pauschal angegeben werden. Das bezieht sich dann immer auf den kompletten Abschnitt zwischen zwei Punkten (vielleicht gibt es auch Stellen mit beiden Symbolen? muß ich mal drauf achten). Einige der Routen sind auch als “Freizeitroute” mit einem Baum-Symbol charakterisiert. Das bedeutet hier in Bielefeld effektiv, dass der Weg durch Wald geht, ungepflastert ist, ggf. nicht für Rennräder geeignet sein dürfte, oder vielleicht auch nur größere Umwege in Kauf nimmt. Da weiß ich noch nicht genau, wie ich das tagge.
Wenn jemand bessere Vorschläge hat, wie man diese Information von den Wegweisern den Routen zuordnen kann, gerne…
Und hier fällt mir gerade auf: Das könnte tatsächlich ein Grund sein, die NRW-Einzelwege von Wegweiser zu Wegweiser als je eine Relation zu mappen, und die Knotenpunktrelationen zusätzlich zu mappen, auch wenn dann die Wegabschnitte doppelt vertreten sind. Eine Knotenpunktroute geht nämlich oft über mehrere Wegweiser mit Abzweigen, die Steigungen sind dann natürlich nur auf den unmittelbar auf den Wegweiser folgenden Unter-Abschnitt bezogen.

Im Moment hatte ich leider gerade begonnen, alle doppelt gemappten Abschnitte aus der Relation “Radverkehrsnetz NRW Stadt Bielefeld” zu beseitigen. Es wird wohl noch ein bißchen dauern, bis das alles einigermaßen konsistent ist. (Nebst so Kleinkram, dass Richtungen von Radwegen verkehrt herum sind, so dass beim Tag oneway=yes plötzlich für den Router Linksverkehr angesagt ist und eine Strecke nicht mehr durchgängig ist - das ist eine der Hauptfehlerquellen dafür, dass knooppuntnet so viele issues hat…)

Good idea! I think it is much requested information about a route, so if it’s visible on the ground it’s worth tagging.
The relations are ordered, so you can use incline with yes, no, or even positive ande negative values, with respect to the order of the ways within the route. This would then (I think) represent the average incline of the route. The individual ways within can of course have very different inclines of their own.

If more detailed incline/decline patterns witthin a route are given on the signs, e.g. [#Km] incline + [#Km] decline, max incline / max decline, I think a special value syntax would be required. But I guess that could be a later addition.

If this community decides to do it this way, I would be glad to pass it on and document it as “in use”.

Why wouldn’t it be verallgemeinbar?

Ich sehe incline eher am way als an der Route. Bei so manchem Abschnitt zwischen 2 (Ziel-)Wegweisern im Bergland müsstest Du sonst auswürfeln, ob Du die lange mäßige Steigung von der einen Seite oder die kurze knackige von der anderen Seite aus unterschlägst.

Das ist überall in Deutschland so, wo die Verbindungen mit Wegweisung ein Netz bilden. Um das von Themenrouten zu unterscheiden, habe ich ja die andere Diskussion gestartet.

Ich habe in meinem Vorschlag als Endpukte für die Routen folgendes geschrieben: “Knoten, an denen sich diese Wege kreuzen, verzweigen oder enden”. Wobei man - im Gegensatz zum Knotenpunktnetzerk - die Relation auch auch über mehrere solcher Knoten hinweg führen kann, Hauptsache sie bildet eine durchgängige Wegekette und verzweigt sich nicht. Das verringert die Zahl der zu pflegenden Relationen. zudem kann man so z. B. Minirelationen von einer Kante vermeiden.

Die Kreuzungs-, Abzweig und Endpunkte sind üblicherweise auch die Punkte, an denen Vollwegweiser stehen (Tabellen oder Pfeilwegweiser). Dazwischen gibt es meist nur Zwischenwegweiser mit kleinen Pfeilen und ohne Ortsangaben.

Allerdings wird an Kreuzungen mit größeren Straßen oft ebenso ein Vollwegweiser gesetzt, ohne dass andere Wege des Fahrradnetzes kreuzen oder abzweigen. Hier die Relation enden zu lassen und eine neue zu starten bringt m. E. eine Schwemme an Relationen mit sich, die sich schwerer überschauen lassen.

Das wirkt auf mich eher komliziert und ich vermute, für andere wird es schwer nachvollziehbar, warum du die Verbindung auf mehrer Relationen aufteilst udn poppelt erfasst. Da ist die Gefahr groß, dass das jemand das zusammenfasst und Dupletten löscht.

Die Neigungssymbole am Wegweiser sind draußen hilfreich, weil man dafür nicht auf die Karte schauen und diese interpretieren muss.

Die Neigungsangaben in OSM an die Relation zu schreiben halte ich für nicht notwendig und ungenau. Wenn, dann sollte das direkt an die Kanten, die in der Neignung liegen.

Aber selbst das ist nicht notwendig, denn gute Navis / Kartendarstellungen bekommen das anhand der Höhenlinien selber und genauer raus.

keep it simple

Thank you for your encouragement. The precipitating idea was just trying to map the visible situation and its logic seen in the guideposts.

In fact: secure would be only to describe the guideposts. The transfer of the information of the guideposts to the routes implies an interpretation and depends on the correct place and content of the guideposts - which is not completely given, as we are confronted with reality. It is possible to place any posts with any information at any place without relation to anything real (they did so last year )

So I really think, we really should wait before such a method would be stated as “in use”. If the state keeps this system: dividing the net into single routes between nodes that have clear properties - “Freizeitroute” “Schnellweg” “Incline” … then it would be appropriate to apply it to the network. But I’m not quite sure whether they’ll really stick to this structure.
An advantage of my tagging scheme is that it can be changed very quickly. I think it could be a good idea to later involve also marc (vmarc) from knooppuntnet.nl. An application of the tags could obviously be to create schematic maps with symbols between the nodes. But this would imply that the routes between the nodes can be subdivided. The “incline” information applies to a route between two nodes of the “Radverkehrsnetz NRW” and not two nodes of a “Knotenpunktnetzwerk” which are less dense.

With “nicht verallgemeinerbar” I want to say that these tags only fit to a whole route if the operator uses the same sign on both ends of the route. In Bielefeld it seems to be the case. The operator (Straßen.NRW, that’s Land Nordrhein-Westfalen) claims to show stronger inclines on the guideposts. But they don’t suggest exact values, only >4% and >10%. So the tagging scheme had to include expressions with inequations as well as maximum values. And I’m not sure, whether it could happen that on a guidepost also could occur an incline AND a decline. This could be the reason for the operator to put nodes on the passes, even if there is no branch there. (eg. node 76 - btw. the route tagged bicycle uphill there is a bit nonsense. There are no signs for bicycles there and it leads over stairs. I didn’t delete it for the Stadt Bielefeld shows it in their description of one bicycle route and it looked like they made the entry by themselves. Just added notes and a fixme.)

Das schöne ist: Ich muß es nicht auswürfeln, es ist bereits ausgewürfelt und auf die Wegweiser gedruckt. Das wäre in diesem Fall nicht das Problem. Damit kann man sogar abbilden, dass die Wegweiser auf einen Anstieg verweisen (über die Route), und dass in Wirklichkeit auch Gefälle dabei sind (über die Wege). (Or in other words: The dice have already been used - by the operator. I don’t see a real problem. One uses the tags in the route to show the description of the guideposts that is intended by the operator - this is the logic of the route, just a virtual thing that is the logical representation of the content of guideposts. And one can use tags in the ways to describe the characteristics of the street in real life, there we also have the description of the surface and so on).

… ja, sorry, Deinen Vorschlag muß ich wirklich mal durcharbeiten. Hatte den Link versust. Danke für den Hinweis. Das ist übrigens genau die Frage, ob man es nicht doch so wie im Knotenpunktnetzwerk machen sollte. Du hast natürlich recht mit dem keep it simple. Ich werde sicher als nächsten Schritt erst einmal die zahlreichen Inkonsistenzen im Knotenpunktnetzwerk Bielefeld reduzieren, bevor ich neue Baustellen aufmache…

Agreed. If the signs consistently give attributes of the node2node routes, they can be tagged on the routes. By the way, this is is no different from any other recreational route, but on longer routes I think it is only useful on shorter routes/sections. Nederland had motorboat networks where minimal passage height/width (to be compared with vessel heigth and width) and minimal water depth (compared with vessel depth) and even max allowed boat length (for turns) are given, and we recorded those values on the node2node routes.

Planners could show this on the network map, similar to current display options for quality, unpaved or last surveyed. For incline display, an arrow or a double pointy bracket could show light/heavy incline or decline. Planner output could show this information in the node strip.

It all depends on what the operator puts on the signs, it should be verifiable by survey.

Die Idee, starke Neigungen in die Karten zu bringen, finde ich verlockend. Gute Radkarten haben dort einen Pfeil in Richtung der Steigung oder Ähnliches. Das vermisse ich bei den OSM-Radkarten.

Das an die Relationen zu schreiben birgt die Gefahr, dass dieser Pfeil an die falsche Stelle gezeichnet wird. Häufig wird die Neigung ja nicht den gesamten Abschnitt betreffen und nicht überall gleich stark sein. Das ist dann ärgerlich, wenn ich einen Umweg fahre um diesen Pfeil zu umgehen, um dann doch vor dem Berg zu stehen.

Um das zu vermeiden, müsste die Relationen auch noch zwischen den Wegweisern zerstückelt werden (und man sollte den anderen Mappern im 'note='* erklären, warum das zerstückelt wird).

Die Pfeile sollten nur an Steigungen dargestellt werden, wo eine Radroute oder Netzverbindung langgeht. Will man alle Steigungen darstellen, ergäbe das unübersichtlich viele Pfeile. Es sollten je nach Länge und Schwere der Steigung auch nur ein oder wenige Pfeilssymbole sein.

Ich denke völlig unkritisch ist es, den Inhalt des Wegweisers am Knoten des Wegweisers zu taggen. Nur muss man dabei die Richtung angeben. Wäre das so korrekt?:

incline:northwest=down

Das ist für eine Kartendarstellung aber kaum brauchbar.

Dafür wäre das Vorhandensein einer route-Relation mit ‘route=bicycle’ der Auslöser, eine solche Darstellung zu prüfen. Der Renderer müsste dann entweder incline-Angaben an den Kanten auswerten. Wenn es die nicht gibt dann die kreuzenden Höhenlinien.

Wenn eine Mindestdifferenz und Mindestneigung erreicht wird, sollte der Pfeil gezeichnet werden. Bei steileren Neigungen ein Doppelpfeil. Wenn die Neigungen länger gehen sollten nach einem Mindestabstand weitere Pfeile gezeichnet werden, ansonsten sollte der Pfeil mittig zwischen Beginn und Ende der Neigung sein.

Anders kann ich mir es schwer vorstellen.

Die Steigung betrifft nicht nur Radfahrer sondern ist eine Eigenschaft des Weges, sollte also auch nur genau dort gemappt werden. Das hat in einer Route bzw. in einer Relation nix zu suchen. incline muss nur gemappt werden und Router und Renderer müssen das gescheit auswerten.

Vielleicht ist es auch mißverständlich. Mir geht es darum, den systematisch angewendeten Inhalt der Wegweisung zu mappen. Das ist auch auf dem Boden (“on the earth”) noch einigermaßen in Entwicklung, die Nachbarkreise sind nur teilweise so konsequent darin, aber es ist letztlich das gesamte Netz hier als Knotenpunktnetzwerk aufgebaut, auch wenn die Knoten nicht alle benannt sind. Das heißt, die Wegweisung zeigt nicht nur in diffuser Form in eine Richtung, sondern verbindet streng zwei Punkte miteinander und zusätzliche Eigenschaften zwischen diesen Punkten werden auf beiden Seiten der Wegweisung markiert. Das betrifft auch noch ein Symbol mit einem Bäumchen für “Freizeitroute”, was heißt, die ist nicht zum schnellen Fahren geeignet, sondern geht über Waldwege, benötigt wegen ggf. ebenfalls vermehrt anzutreffenden Fußgängern auch ein langsameres Tempo (also das genaue Gegenteil von z.B. einer MTB-Route).

Diese Marker beziehen sich, sofern keine Fehler in der Beschilderung gemacht werden, auf den gesamten Routenabschnitt. Es stimmt schon, ein Routenplaner muss das wissen. Und das ist gewährleistet, wenn das Tag in der Route steht. Es eignet sich für schematische Karten, die z.B. voraussetzen, dass ein Fahrer auf dem NRW Wegenetz bleiben möchte, das zwischen zwei Knoten nur immer durch die roten Zwischenwegweiser ohne jegliche Zusatzinformation zusammengehalten wird. Da könnten dann die Logos oder Äquivalente mit verwendet werden. Wenn die Informationen in dem Fall aus den Wegen rekonstruiert werden müßten, würde es komplexe Algorithmen erfordern, und die Situation der Wegweiser würde auch nicht abgebildet werden können.

Das über die Wegweiser regeln zu wollen, wäre zwar inhaltlich sauberer (weil man dann nicht mit den z.T. auftretenden logischen Fehlern in der Beschilderung in der Realität kämpfen müßte, und wirklich nur 1:1 abbildet, was da ist), würde aber erfordern, diese Information noch in die direction_xyz=… unterzubringen, womit diese Tags nicht mehr ohne parsing vernünftig lesbar wären oder sehr umständlich und wahrscheinlich uneinheitlich würden. Die aktuelle Syntax ist noch menschenlesbar.

Ich will mich auch gar nicht darum schlagen, so ein Tagging einzuführen. Für mich als Freizeitmapper ist es schon so aufwändig genug, das bisherige Tagging anzuwenden. Ich finde es nur ein bißchen schade, diese Informationen, die so offen auf der Straße liegen, einfach zu ignorieren.

Ich empfehle auch durchaus, die HBR NRW - Hinweise zur wegweisenden Beschilderung für den Radverkehr zu lesen. Ich weiß nicht, ob es für die anderen Bundesländer ähnliche Publikationen gibt, aber es ist m.E. eine große Hilfe in den Entscheidungen, wie man das Netz abbilden könnte. In den Gebieten, in denen das in NRW noch nicht so sehr umgesetzt ist, kann man sich dann auch schon darauf einstellen, was kommt, statt nachher alles neu strukturieren zu müssen.

Es gibt hier übrigens einen Punkt, der auf EINEN anderen (51) in zwei verschiedene Richtungen zeigt (alternative Routen). Weiß auch nicht genau, was planner damit anfangen sollen… Rückwärts ist übrigens nur eine Richtung angegeben.

Ja, das sehen wir auch in Nederland. Eigentlich sollte es einen Zwischenpunkt geben, aber Operatoren vergessen das manchmal. Die Kreuzung hat oft ein Schild “Alternative mit Hochwasser” oder ähnliches, damit der Reisende wählen kann. Mit Knooppuntnet und anderen Planern kann man einfach die richtige Route auswählen.
Die Aufgabe besteht darin, das zu markieren, was wir sehen. Wir können nicht alle Mängel lösen.