Knotenpunktnetzwerke

Bei der Freizeikarte-Android wird die render library mapsforge verwendet. Diese erlaubt die Text Darstellung nur über das Name Tag.
D.h. für jeder Knotenpunkt Bedarf es einer Vorauswertung, um die rcn_ref, rwn_ref, etc. zu transformieren. Wenn man aber die verschiedenen Netze trennen will, muss man sich für eines entscheiden. Oder man muss eigene Punkte erzeugen. Dies dann im gleichen ID Range wie die Rohdaten. :frowning: Dies ist aufwendig und führt immer wieder mal zu Problemen.

Solche “mapsforge Probleme” haben wir bei allen Mulituse-Nodes. Darum ist jeder, welcher mapsforge verwendet, kein Fan davon.

Der Punkt ist, dass die Knoten mittels der Zahlen aufeinander verweisen. An den Knotenpunkten wählt man kein endgültiges Ziel, sondern eine nachfolgende Nummer wo man wieder wählt. Die Route zwischen zwei Punkte die nach einander verweisen ist ein Knotenpunktrelation. In ein richtiges Knotenpunktnetz sind die meiste Knotenpunkte exp… > 2.

Genau das ist hier das Problem. Wie ich bisher erkennen konnte, verläuft durch den Landkreis Ludwigsburg von Norden nach Süden ab Kirchheim am Neckar über Bietigheim-Bissingen und Ludwigsburg bis Kornwestheim nur eine Strecke mit Knotenpunkten und von Bietigheim-Bissingen nach Vaihingen an der Enz von Ost nach West eine weitere Strecke mit Knotenpunkten. Alle weiteren ausgeschilderten Strecken haben nach meinen Kenntnissen keine Nummer, somit auch keinen bekannten Knotenpunkt. Bis wann sich da noch was ändert, ist mir nicht bekannt.

Sorry to press this point. In node networks, the routes are not numbered, or if they are the route numers are not part of the node network.

The nodes have numbers and point to adjacent nodes by node number.

So node xx points to node yy using an arrow or pointer mentioning yy as the next node in a particular direction, and node number yy points back to xx and forward to zz [, aa, bbb, …]. No similar numbers in between.

If that is not the case, it is not a node_network. A node is a point where you choose directions to other nodes.

So, not every numbered guidepost is a network node. If it does not direct you to another number it is not a network node.

From the description I get the impression the routes do bring you along numbered points, but these are not used to choose directions, they are more like numbered milestones on a fixed route.
Of course this could be the beginning of a real node network, but one long route cannot be a network, can it?

Ich hoffe, dass dies der Beginn ist eines echten Knotennetzwerks. Im Bundesland Baden-Württemberg wurden jetzt vom Verkehrsministerium
BW zum ersten Mal Knotenpunkte festgelegt und bei diesen Wegweiser aufgestellt. Neben dem Land planen auch der Landkreis und die Gemeinde (zumindest an meinem Wohnort) ein Radnetz zu erstellen. Bis wann dies fertig ist, weiß momentan niemand. Ich wollte jetzt aber bereits die von anderen Mappern erstellten Relationen, bezeichnet mit “Radroutennetzwerk, Streckenrelation zwischen zwei Knotenpunkten” entlang den neuen Knotenpunkten, die zumindest eine feste Nummer haben, in ein Netzwerk aufnehmen, damit das Ganze auch übersichtlicher wird.

Wieder eines komplett…

Das Knotenpunktnetz meines heimischen Landkreises Dahme-Spreewald ist nun zu 100% fertig: https://knooppuntnet.nl/en/network/10953719 zumindestens soweit ich es vor Ort feststellen konnte. Mein Dank gilt auch den Usern WegefanHB, der mich mit Fotos unterstützt hat und besonders auch den Usern FA-KW und Osmegnos die den Nordteil des Kreises bearbeitet haben…
Damit ist das Netz wahrscheinlich eher in OSM, als das es eine Papierkarte gibt. Eine letzte Liste mit Anmerkungen und fehlenden Schildern geht noch an den Landkreis.

Mal sehen, wieweit ich mit den angrenzenden Netzen Landkreise Elbe-Elster, Oberspreewald-Lausitz und Spree-Neiße komme… Fotos mit Geokoordinaten von nicht erfassten Knotenpunkten sind immer Willkommen.

Sven

Sieht gut aus! Und der neue Planer funktioniert gut damit. https://experimental.knooppuntnet.nl/nl/map/cycling

Kudos!

Habe das gerade gesehen: “Datum letzte Inspektion” als farbliche Darstellung - sehr gut.
Dazu müsste aber ein check_date= in die Daten - meine Meinung - an die Relation und Knotenpunkte. Falls die Auswertung über “last updated” erfolgt genügt ein “verschieben eines nodes (Wegweiser)” zur angeblichen Prüfung.

Recht so. Das Wichtigste ist aber jetzt, die Knoten systematisch einzuführen. Wenn’s nicht komplett in OSM steht, kann man überhaupt nicht zuverlassig planen.

Worauf ich ja auch geachtet habe, zusätzlich zu dei Knotenpunkten und Routen sind die Themenradrouten. Daher ist es essenziell, auch Fotos der Knoten zu haben. Gelegentlich wurden diese Themenradrouten in der Routenführung verändert, oder weichen (noch) vom Knotenpunktnetz ab. Das habe ich einmal, in Langengrassau…https://cycling.waymarkedtrails.org/#?map=15!51.8359!13.6343

Manchmal tauchen auch nicht erfasste Routen auf, so z.B. einige im Muskauer Faltenbogen…

Vor allem solche Routen anzupassen ist recht aufwendig…

Sven

The torture never stops - Frank Zappa

und warum dann nicht mit image=* verlinken am “Wegweiser” (Knoten)? Dann kann auch einmal die andere Route kontrolliert/Korrigiert werden. Lieber später eventuell ein älteres Foto - sagt auch mehr als “Worte”.

Ja, das wäre schön, wenn so einfach ginge… :frowning:

Ich habe immer mehrere Fotos pro Knotenpunkt… Nur wenn man äußerstes Glück hat reicht eines, in der Regel brauche ich für LDS immer mind. 3 Fotos… 2 für die Richtungsfahnen und eines für die Pfostennummer (+1 für die Karte am Pfosten). Ja und aus 3 eines zu machen ist auch nicht so leicht… und mir fehlt die Zeit… bei ca. 200 Knotenpunkten in LDS gehen vielleicht 2/3 aud mein Konto…

Sven

I am glad you like this function. Knooppuntnet currently looks at tag “survey:date=", or the combination of “source=survey” and "source:date=”. It looks like it would be useful to add “check_date=*” to this?

Hallo,

seit einigen Tagen beschäftige ich mich relativ intensiv mit den Rad- und Wanderrouten im Rheinland (bisher in der Region zwischen Köln und Bonn). Die Knotenpunktnetzwerke sind hier bereits relativ gut erfasst, die übrigen Routen waren jedoch größtenteils in einem schlechten oder veralteten Zustand (bis 10 Jahre alt). Ich habe nun folgenden Gedanken:

Viele aktuelle Themenradrouten sind zum großen Teil auf das Knotenpunktnetzwerk gelegt und somit eine Aneinanderreihung von Knotenpunktrouten. Wäre es sinnvoll, die Themenrouten aus den Knotenpunktrouten-Relationen zusammenzusetzen, statt aus den einzelnen Linien der Wege? Dann wären die einzelnen Linien der Wege nur noch Bestandteil einer Relation (der Knotenpunktroute) statt zweien oder mehr. Das könnte den Wartungsaufwand verringern.

Testweise habe ich das mal bei der von mir neu angelegten RegioGrün Erlebnisroute Süd so gemacht. Zumindest auf waymarkedtrails wird das so aber nicht richtig gerendert.

Gibt es bereits Überlegungen zu dem Thema? Ich konnte bisher leider nichts dazu finden, auch kein anderes Beispiel. Müssen die Kind-Relationen eine bestimmte role erhalten?

Ich habe in den Niederlanden damit experimentiert. Es ist möglich, aber es ist sehr schwierig zu verwalten, wenn es mehr als etwa 10 Node2node Routen werden. Ich mache es also nicht mehr mit längeren Strecken, sondern nur mit kürzeren Rundwanderungen via 3-10 Knotenpunkte.

Ich verwende die Regel, dass der Operator sie selbst als Knotenpunktwanderung anbietet.

z.B.
https://hiking.waymarkedtrails.org/#routelist und https://hiking.waymarkedtrails.org/#route?id=11914748&map=16!51.8839!5.1994

Warum ist das schwierig?

Ok, dann werde ich auch erstmal keine Knotenpunktrouten in Themenrouten aufnehmen und stattdessen ganz normal die Wege erfassen.

Bei meinem Beispiel funktioniert das Rendering auf waymarkedtrails mit den Themenrouten auch immer noch nicht richtig. Die gezeichnete Linie und die Schilder sind unvollständig, das Highlighting bei ausgewählter Route ist aber da. Ich werde die Route in den nächsten Tagen zur einfachen Route ohne Kind Relationen umbauen.

Die richtige Anordnung. Man kann das nicht einfach sehen und die Sortierfunktion macht das auch nicht.

Das ist das Anordnungsproblem. Man muss die Kind-Relationen selbst in die richtige Reihenfolge bringen. Erst dann kan WMT sie als eine Totalroute verwenden. Das Höhenprofil in WMT zeigt das Problem.

Ok, bisher habe ich die Sortierfunktion von JOSM nicht verwendet und immer alles von Hand sortiert. Ich habe das Gefühl, vor allem bei parallelen Teilstrecken mit Einbahnstraßen und den forward/backward Rollen geht das besser.

Die Kind Relationen habe ich auch in der richtigen Reihenfolge aufgenommen. Funktioniert es vielleicht nur, wenn innerhalb der Knotenpunktrouten die Linien in der richtigen Reihenfolge sind? Also muss es z.B. 4-8,8-15,15-3 sein und 4-8,15-8,15-3 funktioniert nicht?

Auffällig ist folgendes: Ich habe weder meine obige Beispielrelation noch die entsprechenden Knotenpunktrouten angefasst und seit gestern wird bei WMT plötzlich der nördliche Teil der Route richtig gerendert. Meine einzige Änderung in dem Gebiet war, dass ich das Radverkehrsnetz NRW in Köln von type=route auf type=network geändert habe. Aber das sollte mit der Themenroute ja nicht in Zusammenhang stehen.

LS
Ein französischer Mapper gebt jetzt Netzwerke in der Nähe von Toulouse ein. Das sind richtige Knotenpunktnetzwerke mit Namen, keine Zahlen.
Er möchte, dass es gut aussieht und funktioniert in waymarkedtrails, OsmAnd und Knooppuntnet Analyse un Knooppuntnet Planner.

Wir haben noch keinen Konsens über die endgültige Tagging, aber er möchte die Daten bereits eingeben. Vorläufige Lösung:
(auf English, entschuldige)

**guidepost node on its exact position:
*** tag name and ele and whatever you normally put on it (in this case they were already present)

network nodes (= intersections of the ways where the routes end/start)
network:type=node_network
rwn_name=
rwn_ref=o (lowercase letter o)

network routes (mode2node route relations)
network:type=node_network
ref=o-o (lowercase letter o, hyphen, lowercase o)
name=<start node’s rwn_name>-<end node’s rwn_name)

network relation
network:type=node_network
name
operator
… whatever deemed necessary.

Note that network relations are not really necessary any more.
Also, the node2node routes do not really need the name tag. But it looks good in Waymarkedtrails!
The guideposts may be included in the route relations with the role guidepost, but this is not necessary.

This temporary scheme will give no “facts” in Knooppuntnet Analyse, Knooppuntnet Planner will work technically, and Waymarkedtrails and OsmAnd have a reasonable rendering and information popups/sidebar.
Knooppuntnet has been asked to display rwn_name instead of rwn_ref in the result list and in the pfd exports.