Knotenpunktnetzwerke

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.

Ich finde es sehr gut, dass du dir Gedanken machtst und die hier zur Diskussion stellst. Irgendwann wird jemand sowas mappen und dann hat er das vielleicht nicht so durchdacht und dessen ungünstige Lösung setzt sich womöglich durch. Dann lieber gemeinsam dagegentreten und schauen ob es stehenbleibt oder auch gemeinsam verwerfen (und das dann ggf. im Wiki dokumenmtieren).

Die Zusatzinfos auf den Schildern haben den Vorteil, dass sich jemand intensiv damit beschäftigt hat. Es ist sehr viel wahrscheinlicher, dass die Angaben richtig und relevant sind.

Sie haben den Nachteil, dass sie bereits eine Verallgemeinerung sind und Informationen fehlen, z. B. wo genau die Steigung ist.

Wenn die Informationen sich auf den gesamten Abschnitt der Route beziehen, dann ist die route-Relation schon ein möglicher Platz dafür (neben den Wegweisern), insbesondere wenn es Dinge sind, die sich nicht leicht aus den Wegen ableiten lassen, wie z. B. das Bäumchensymbol.

Selbst die Steigungsangaben wären nicht falsch an der Relation. Die Datenverwerter können ja entscheiden, ob sie diese abstrahierte Information verarbeiten oder sich die Infos detailliert aus den Wegen herleiten. Detailierte Angaben an den Wegen sollten globale Angaben in den Relationen überschreiben. Die Frage ist nur, ob es einen Mehrwert gibt und wie groß die Wahrscheinlichkeit der Missinterpretation ist. Und das sehe ich bei den Neigungsangaben kritisch.

Wenn, dann sollte das m. E. nicht einfach mit ‘incline=down’ gemappt werden sondern vielleicht mit ‘incline_symbol=down’. Somit wäre die Quelle der Angabe gleich mit dokumentiert. Bei ‘incline=down’ könnte man denken, jemand hat das händisch aus den Wegekanten abgeleitet. Das wäre löschenswerter Quatsch.

Wenn sich die Infos nur auf einen Teil der Route beziehen, so müsste man die Route splitten. Das ist es oft bei den Neigungsangaben so. In einem anderen aktuellen Diskussionfaden wurde sich darüber aufgeregt, dass man Wege viel zu viel splittet. Wenn wir jetzt auch noch Relationen in viele Teilrelationen splitten, dann wird das echt unübersichtlich. Da sollten wir uns genau überlegen, ob es das wert ist oder ob wir die Angaben nicht liebr nur an die Wegekanten schreiben.

Ja finde ich auch. Für die Informationen, die sich aus den Wegekante besser ableiten lassen, ist der Mehrwert aber begrenzt. Für alle anderen finde ich es sinnvoll, solange man die Routen nicht splitten muss.

Nur als Idee: Wenn Du die Beschilderung der Wegweiser nicht mit direction_xyz=… einträgst, sondern mithilfe von “destination_sign”-Relationen, könnte man das Steigungs-Symbol unter destination:symbol=… eintragen.

Hab’ ich mir nun mal angeschaut. Stimmt im Prinzip, aber das ist gigantisch aufwändig, ich nehme mal einen aufgeteilten Knotenpunkt zufällig heraus (noch nicht einmal ein besonders umfangreiches Beispiel) Knoten 70 Süd, Bielefeld, es gibt immerhin nur 2 Wegweiser (es gibt auch Knoten mit 3 oder 4 Wegweisern). Auf dem beiden habe ich je Verweise auf 7 Ziele und 4 Knoten. Im Standardfall bekommt jedes Ziel eine Relation, man scheint die Ziele auch zusammenfassen zu können, so dass es immerhin je 3 Richtungen werden (es gehen auch 4-5 wenn man Pech hat). Also muß dieser Knoten mindestens 6 destination_sign Relationen bekommen (statt 2 nodes als guidepost). Das schaffe ich nicht ohne Plugin, das ich nicht selbst programmieren kann. Die Knotendichte ist hier so dicht, dass ich für das Abfahren einer Strecke mit dem Fahrrad weniger Zeit brauche als für das mappen nachher (selbst wenn ich die Hälfte der Strecke durch bereits bekanntes Gebiet fahre), also 4 Stunden Fahrradfahren sind locker 5-6 Stunden Zeit am Computer, wenn ich es halbwegs vollständig machen will.

Aber die Datenstruktur wäre natürlich deutlich besser. Für auswertende Software hübscher zu parsen als die Umkreissuche nach irgendwelchen hoffentlich passenden guideposts… Also wer schreibt’s Plugin? Oder gibt’s das schon? Ein Fenster, schnell die Richtungen angeben, er findet selbst heraus, welche Wege gemeint sein müssen (Fahrradbefahrbare auswählen, nichts über den Fußweg schicken, oder anbieten, den Fußweg schnell noch mit bicycle=yes zu taggen, vielleicht doch auf die Straße, wenn sie ein cycleway:left:oneway=no hat…) :wink:

Oder eine Software, die aus umstehenden Guideposts Wegweiserrelationen bastelt und vorschlägt? Das wäre durchaus denkbar, wenn das zugrundeliegende Netzwerk bereits gut vorstrukturiert ist. Damit wäre ich bei meinem nächsten post: …

Das betrifft hier übrigens nur eine knappe Handvoll Routen. Es läuft aber da auf eine andere grundsätzlichere Frage hinaus: Man müßte sich Gedanken machen, ob man Routen lieber splitten will, oder Abschnitte mehrfach abbilden möchte. Ich bin da nicht 100% entschieden. Das Radverkehrsnetz NRW ist strukturell erst einmal EIN Netzwerk, das, wenn es nicht fehlerhaft ausgeschildert und aufgebaut ist, ziemlich eindeutig ein Knotenbezogenes Netzwerk ist, an jedem Knoten stehen Wegweiser mit Zielen. Zwischen den Knoten stehen nur Zwischenwegweiser ohne Ziele, ohne spezifische Routenmarkierungen (außer dem reservierten Logo, dem roten Pfeil für eben das NRW-Radverkehrsnetz, mit der Landesgrenze nach Norden wechselt z.B. die Farbe, das ist dann klar ein anderes Netz). Zwischen den Knoten liegen Wege, die gut Routen im osm-Sinn entsprechen. Sie haben Attribute, die durch die Wegweiser an den Enden definiert werden, dazwischen sind keine weiteren Informationen ausgeschildert. Die Knoten können Nummern haben, dann ist es ein “node_network”.

Auf diese Minimalrouten setzen auf der nächsten Ebene längere Routen auf:

  • Das sind die Routen zwischen nummerierten Knoten,
  • die durch die Landkreise unterhaltenen Themenrouten
  • die durch das Land unterhaltenen/organisierten Themenrouten
  • manche Bundesländerübergreifenden Routen, die sich auch hier aufsetzen. (Z.B. BahnRadRoute WeserLippe)

Von der Logik der Daten wäre es so, dass das kleinste Teilchen die oben genannten Routen ohne eigenen Namen sind. Jede andere Art Route setzt sich aus diesen Unterrouten zusammen.

Das erzeugt aber Probleme. Es ist nicht üblich, eine benannte Route sehr vielen Unterrouten zusammenzusetzen, obwohl Langstreckenrouten durchaus aus mehreren Unterrelationen bestehen.

Besonders die Struktur der aktuellen Knotenpunktnetzwerke ist inzwischen zwischen den Niederlanden, Belgien und Deutschland recht großflächig vereinheitlicht, in Frankreich, Österreich und Spanien gibt es auch einzelne Knotenpunktnetzwerke, die diesem Schema folgen. Eine gewisse Abstimmung wäre hilfreich, und/oder Mitarbeit z.B. an dem knooppuntnet Projekt. Man sollte sich da nicht aus der Struktur rauskicken.

Vorteile wären allerdings: Änderungen der Routenführung vor Ort würden unmittelbar in alle betroffenen Routen (Themenrouten, Nummernrouten, Überregionale Fahrradwege) übernommen, die Kartendaten wären leichter aktuell zu halten. Im Moment bin ich dabei mit jeder Strecke, die ich fahre und korrigiere, locker mal 5 weitere Relationen von verschiedensten Fahrradrouten mit korrigieren zu müssen. Auch temporäre Umleitungen könnten markiert werden (gelbe Verkehrsschilder). Auch die Aktualität einzelner Abschnitte ist besser sichtbar. (survey:date=xyz)

Die Eigenschaften der Unterabschnitte könnten auf Karten schnell sichtbar gemacht werden: z.B. Grüne Abschnitte für die “Bäumchen”-Logos, andere Farben für die starken Steigungen.

Ich benutze im Moment zunächst in Bielefeld eine Mischform: Ich bearbeite das Knotenpunktnetzwerk nach den üblichen Regeln, eine Relation für eine Route zwischen zwei Nummern. Die benannten Routen haben eine komplette Relation (wenn sie sich nicht verzweigen), die unabhängig von den anderen ist. Was dann noch übrig bleibt, bekommt Routenrelationen zwischen zwei Wegweisern, die in das Netzwerk (“Radverkehrsnetz NRW Stadt Bielefeld”) aufgenommen werden.

Im Moment lösche ich aus der Relation “Radverkehrsnetz NRW Stadt Bielefeld” nach und nach alle Einzelwege, die entweder durch das Knotenpunktnetzwerk oder durch Routen in dieser Relation bereits dargestellt sind. Wenn ich das so mache, müßte ich eigentlich auch die Themenrouten in die Relation mit aufnehmen, um dann nur noch ganz wenige unbenannte Routen übrig zu haben. Was aber würde ich mit den überregionalen Resten machen, sowohl in Bielefeld aufnehmen als auch z.B. im Kreis Gütersloh? Die Route nach Kreisen teilen? Das ist alles nicht so elegant. Insbesondere würde das wieder zu nur bedingt sinnvollen Sammelrelationen führen, z.B. wenn man die NRW-Themenrouten auch anfangen würde zu sammeln…

Ich stelle mir vor, dass ich, wenn ich mir die Relation “Radverkehrsnetz NRW” mit allen Unterrelationen anschaue, dann auch das komplette Radverkehrsnetz NRW habe. Da im Moment eine Relation “Knotenpunktnetzwerk NRW” alle Knotenpunktnetzwerke in NRW enthält und diese im “Radverkehrsnetz NRW” enthalten ist, benötige ich für dieses Ziel keine doppelte Anführung von den Routen.

Irgendwie empfinde ich es als ungünstig, wenn “ways” doppelt enthalten sind. Bei Routen fällt mir das nicht so schwer. Im Moment kommt es oft vor, dass ein identischer Streckenabschnitt je nach Route unterschiedlich gewählt wird. Wenn ich von A nach B auf der Themenroute fahre, werde ich vielleicht über den Pfad an der Seite geführt, muß zwischendurch absteigen, weil plötzlich der Radweg nur noch in eine Richtung befahren werden darf etc… Fahre ich den gleichen Abschnitt auf dem Knotenpunktnetzwerk, wird der Weg über die Autostraße geführt, die mit use_sideway markiert ist. Dabei können unterschiedliche errechnete Zeiten und Entfernungen herauskommen, oder ein Weg auch mal gar nicht durchgängig sein. Oder man bekommt Alternativen beim Routing angeboten, die gar keine sind.

Aus diesem Grund bin ich dagegen, Informationen, die sich auf eine Route beziehen (also auf dem WegWEISER und nicht auf dem WEG sind), an Wegen zu taggen.

Ein wichtiges Kriterium fürs Taggen ist mir auch, dass man eine Struktur schafft, die man automatisiert möglichst einfach in eine andere überführen kann. Das reduziert letztlich die Gefahr, dass Änderungen massiv arbeitsaufwändig und dann ggf. unmöglich würden. Da darf es ruhig auch etwas kleinteilig in manchen Dingen sein. Zusammenführen geht automatisiert einfacher als umgekehrt.

(zu viel Text, ich weiß… ich schaff heute Abend kein Kürzen mehr. Sorry)

Grüße, Sebastian

Das sehe ich auch so. Ausnahme: Wenn es noch keine route-Relation gibt, der Mapper nicht den gesamten Verlauf kennt oder mit Relationen nicht gut umgehen kann, wäre z. B. ein lcn=* an die Kanten eine Alternative, bis sich jemand findet, der die Relation anlegt.

Das wurde hier kürzlich auch irgendwo diskutiert, finde es aber nicht mehr. Dort fand das nicht so Anklang. Ein Argument war glaub ich, dass die Themenrouten nicht immer deckungsgleich sind mit den Netzverbindungen.

Ich finde es problematisch, dass man diese Routen beim Bearbeiten der Wege bzw Verbinungs-Relationen nicht sieht. Das die Themenroute dort lang geht erfährt man erst durch einen Blick in die Elternrelationen der Netzverbindung. Das birgt Gefahren und erschwert die Pflege.

Im Prinzip sind die Master-Relationen reine Sammelrelationen. Die Kreisrelationen helfen aber, beim Mappen des Netzes den Überblick über alle Verbindungen zu halten, Verbindungen zu Nachbarkreisen mit Rolle ‘connection’. Insofern sind für mich solche Kreisrelationen für das Netz OK, egal es ein Knotenpunktnetzwerk ist oder ein Grundnetz ohne Routen-Symbole.

Die Themenrouten würde ich nicht in kreis- oder länderspezifische Masterrelationen aufnehmen. Das macht die nur unübersichtlicher.

Eine master-network-relation für Themenrouten würde ich nur machen, wenn es ein spezielles Netz eines besonderen Betreibers ist und es nicht durch administrative Grenzen definiert ist. Ein solchens Beispiel wären die Routen des “Rad- und WanderParadies Schwarzwald und Alb”. Dann hat man das problem des Teilens an Grenzen auch nicht.

Das ist doch gut so. Nur dass es zwei Master-Relationen für das Netz gibt, finde ich verwirrend, insbesondere, wenn das Netz des Kreises in großen Teilen in ein Knotenpunktnetzerk aufgegangen ist.

Das Tagging-Schema der Knotenpunktnetze sieht ja auch route-Relationen mit ‘state=alternate’ vor. Damit könnte man die Verbindungen ohne Knotenpunktwegweisung versehen. Wenn sich mein Vorschlag mit dem ‘network:type=basic_network’ durchsetzt, wäre das eine wesentliche Anwendung dafür.

Diese Verbidnungen könnten alle in eine Master-network-Relation. Die unterschiedliche Wegweisung würde anhand des ‘network:type’ an der Relation erkannt, so dass Renderer die unterschiedlich darstellen können. Fänd ich übersichtlicher.

(The Belgian forum has just discussed this again). Here is (slightly edited) what I posted:

So the first use case (long theme route) failed: unmanageable for long routes with many node2node sections.
Example (look at the sections in the information panel): https://hiking.waymarkedtrails.org/#route?id=9576945

The second use case (local loops) turned out to be beneficial. The node network actually benefits from the colours, and the loops benefit from the node planner. You can see the colours (colour=* on the node2node relations) in the output of the Knooppuntnet Planner.
Compare:
https://hiking.waymarkedtrails.org/#search?query=enschede&map=14!52.2936!7.0487
https://knooppuntnet.nl/nl/map/hiking#6cid37-1sxwo4a-1af08on-5777a2

I agree, one has to be careful not to create difficulties in doing that. But I don’t exactly know what you mean by “can’t sort” and “can’t see the order”. In the mentioned relation 9576945 the members seem to be ordered correctly and I see it in JOSM. It isn’t indicated next to the relations, but the order is sorted and visible. And even waymarkedtrails shows the elevation profile in the proper order and has no difficulties. The sections there are ordered alphanumerically, if waymarkedtrails left them unsorted they had the proper order I assume.
Hm. I see an issue: there are no roles forward an backwards set for the relations. That would be necessary I think. My comment on the elevation profile is incomplete. It looks fine because there are so many fragments that I don’t see, whether these are sometimes reversed…
So its a matter of the editing or rendering software and not of the data. I agree that sorting relations would be more difficult than sorting ways and more error prone, and a connection between routes is difficult to define if there are split nodes not just a binary value connected/not connected! Maybe it’s some project for the future if the structure of the networks still would suggest that way.

True. I have asked for that, but got no response. Maybe you could try? The same goes for other sectioned routes, that’s why they get names with a section number in it.
The elevation profile (and the export gpx) actually solve most ordering problems, unless there are too many errors: gaps, crossing ways, or unsolvable puzzles such as closed way roundabouts, pedestrian areas, or if roles are involved, then it fails.
The same is true for sorting in JOSM (yes, if you know the order you can see it’s allright, but the continuity line is not correct and if the order is messed up, you need external sources and individual placement of the members to get it right again).

True, better tools could do a lot, but I can’t build them and I don’t see much enthousiasm of programmers for this niche… so until the brighter future arrives, we’ll have to manage without. And, if I look at other challenges in OSM, I have to admit this is not the highest priority.

Hallo allerseits,

ich erfasse das neue Radwegeknotennetz Altmark. Dabei stoße ich auf ein Problem: Laut zuständiger Behörde enden Routen auch an Punkten ohne Knotenpunkt. Ist diese Fallgestaltung bereits aufgetreten und wie kann man dies lösen?

https://cycling.waymarkedtrails.org/#?map=16!52.7525!12.1056
https://knooppuntnet.nl/en/analysis/changeset/113364774/4786928

Gruß
Ainadilion

Hallo Ainadilion,

einige Frage zur Verständnis, bevor ich das beantworten kann:

Eine Knotenpunktroute ist es ja nur dann, wenn sie mit den entsprechenden Knotenpunktnummern ausgeschildert ist. Ich nehme an in die eine Richtung ist KP35 ausgeschildert. Welche Nummer ist in die andere Richtung ausgeschildert? Und welche Nummern sind an diesem Wegweiser vorhanden? https://cycling.waymarkedtrails.org/#guidepost?id=516386981

Möglicherweise handelt es sich um einen split node (siehe https://wiki.openstreetmap.org/wiki/Cycle_Node_Network_Tagging)). Die sind etwas komplizierter, technisch aber leider notwendig, wenn ausgewiesene Knotenpunkte mit einer Nummer geometrisch und der OSM ways her nicht an ein und dem selben Punkt liegen.

Ich würde einfach darauf verweisen einen “Endpunkt” zu benennen, da “Radeln nach Zahlen” schließlich an einer Zahl enden sollte. Als Tourismusverband sollte man auch an dem “ordentlichen” Aufbau der Routen interessiert sein. Wie komm ich denn von “endet zwischen den KP 20 und 43” weiter, wenn dort nichts ausgeschildert ist?

Guten Abend zusammen,

Ich hatte ja Ainadilion per PN geraten, sein Problem in diesem Beitragsfaden darzulegen. @Ainadilion Danke! :slight_smile:

Ich stecke zwar recht gut in dieser Materie drin, bin mir hier aber auch unsicher…
Auf solche Situationen stößt man aber immer wieder mal…

Ich habe hier bei mir vielleicht eine ähnliche Situation…

Knotenpunkt 14 verweist unter anderem auf Knotenpunkt 18 (zunächst) Richtung Südwest…

Hier die Karte dazu (bitte merken)…

Der Wegweiser mit dem Knotenpunkt 18 hingegen ist hier: https://www.openstreetmap.org/node/85778579

und verweist in fragliche Richtung nur zum Knotenpunkt 17 (dieser wiederum dann nur zur 18…)

Dann, am Abzweig zurück zum Knotenpunkt 14 gibt es nur dieses Schild:
Bild 1:

Bild 2:

Sowohl vom Knotenpunkt 17, als auch 18 gibt es direkt keinen Hinweis auf den eingangs genannten Knotenpunkt 14.

So… kommen wir zum “bitte merken”…
betrachtet man sich nochmal die oben gezeigte Karte, ist der Knotenpunkt 18 an eine Stelle gesetzt…

Ich selbst interpretiere das für mich so, als daß ich beide hier dargestellten Punkte https://cycling.waymarkedtrails.org/#?map=18!52.1066!13.7598 als ein Knotenpunkt “18” betrachte (Entfernung: ca. 50m)… entsprechend ist es erfasst…

Zurück zur Ausgangsfrage von Ainadilion…

Mich würden Fotos der beteiligten Wegweiser der Knotenpunkte dringend interessieren…

Das ist ja immer eine Abwägung zwischen einem theoretischen Netz und dessen praktischer Umsetzung. Im Moment würde ich hier aber zu einer ähnlichen Lösung wie von mit dargelegt, tendieren…

…erst mal eine Zwischenmeinung…

Viele Grüße,

Sven

PS: Ach ja: alle Fotos in diesem Beitrag haben Geokoordinaten sowie Fotografierrichtung!!

Moin streckenkundler,

ich habe mir deine Situation mal mit deinen Fotos und mapillary angesehen. Das ist eindeutig eine split node Situation. Für die Fehleranalyse und das Routing von knooppuntnet.nl sind hier sogenannte tentacle in den Routen nötig. Das ist wie schon erwähnt auf dem ersten Blick etwas komplizierter, kommt bei mir in Köln und Umgebung aber häufig vor.
Bei dir hast du aber das perfekte, einfachste Beispiel dafür. Wenn du nichts dagegen hast, würde ich die Stelle bei dir einfach mal entsprechend umbauen. Das hilft dir vielleicht als Anschauung direkt weiter?

Hallo,

ein Foto des Knotenpunktes findet sich hier:
https://photos.google.com/share/AF1QipO71w4QIIc84EVLyRRaQbTu8OAZczoatbnLeLgG8Aih34oeD_mb-r3NUApqpU0QyQ/photo/AF1QipN8BZD9fl_SwDsfiXy8B-pq_6viyXQs5LjsgyU3?key=WktwY2R6SmI3TkFzcEJUUlZXNTNvc3VRYmN5WEJR

Hier der Zwischenwegweiser:
https://photos.google.com/share/AF1QipO71w4QIIc84EVLyRRaQbTu8OAZczoatbnLeLgG8Aih34oeD_mb-r3NUApqpU0QyQ/photo/AF1QipP3DZTAmMVznVtlMGLHjNVQKzAXf3EFdMbpMWOd?key=WktwY2R6SmI3TkFzcEJUUlZXNTNvc3VRYmN5WEJR

und hier schließlich der Punkt 43
https://photos.google.com/share/AF1QipO71w4QIIc84EVLyRRaQbTu8OAZczoatbnLeLgG8Aih34oeD_mb-r3NUApqpU0QyQ/photo/AF1QipMVERN6INgssVilNBPtGPZ7rvy4lqskKey2_yLI?key=WktwY2R6SmI3TkFzcEJUUlZXNTNvc3VRYmN5WEJR

Gruß
Ainadilion

Die Auszeichnung vor Ort ist allerdings unvollständig… Optimalerweise müssten an beiden Wegweisern bei Knotenpunkt 18 jeweils die Nummern 14, 16, 17, 27 ausgewiesen sein. Was mindestens fehlt ist die 14 an dem Wegweiser mit der großen 18 oben drauf, den Rest kann man auch so machen wie es ist.