Knotenpunktnetzwerke

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.

Meines Erachtens ist die Einführung von 'rwn_name='* unnötig und ‘rwn_ref=o’ eine sehr unglückliche Anwendung.

‘rwn_ref=o’ enthält nicht die Aussage, dass es keine Referenz gibt. Es sagt, dassdie Referenzbezeichnung “o” lautet. Wir haben dann hunderte unterschiedliche Knoten mit der gleichen Referenz, das ist nicht gut! Das gilt genauso für ‘ref=o-o’ an den Verbindungen.

Wenn in Frankreich der Name die Referenz darstellt, so kann dieser in der Form ‘rwn_ref=’ angegeben sein. Es ist ja nirgends festgelegt, dass 'ref='* eine Zahl sein muss. Analog dann auch das ‘ref=<start node’s rwn_ref>-<end node’s rwn_ref>’

Somit kann des vorhandene Schema komplett verwendet werden, oder?

Auch ich habe angefangen das Wandernetzwerk in meiner Gegend als Knotenpunktnetzwerk zu taggen. Allerdings würde ich das etwas anders machen, als ihr es in Frankreich umgesetzt habt. Hier meine Verbesserungsvorschläge:

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= → For more dense and local networks rather lwn_name=
rwn_ref=o (lowercase letter o) → In my eyes tagging for the renderer

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> → I would add spaces before and after the “-” because in my area some names already contain it as a Bindestrich (e.g. “Sausteig-Lourdes-Grotte” → “Sausteig - Lourdes-Grotte”)
** The route relation also contains the guideposts at the end and the start of the route segment*

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

(Sorry to respond in English, mein Deutsch reicht nicht)

I agree withe the rwn_ref observation, and I understand the rwn_name observation. Explanation:

This is the temporary setup to make the current setup work with the universal node network planner Knooppuntnet Planner. See https://knooppuntnet.nl/nl/map/hiking and search/pan/zoom to south-east of Toulouse, give it a try!

The bigger picture is this:
I want to get rid of this trick as soon as possible. To do that, I need an approved tagging scheme, or else the data users will not make the necesasary changes. I have some experience in getting consensus in a relatively unknown field - it’s impossible without a working model.
In the meantime, mappers want to move on.
This tempory scheme allows mappers to move on and enter the data, and start using the current applications. It does not break anything, and it allows data_entry in a way that can be easily reused /retagged.

Now to be more concrete:

The rwn_ref (r*n_ref) was designed for max 2 characters, numbers only. It was adapted to max 3: one letter two numbers, because operators started to use that. We have tried longer refs in the Schlossberg test, you can see the result in WMT here on the second picture: https://wiki.openstreetmap.org/wiki/Proposed_features/Named_nodes_in_node_networks
Knooppuntnet and OsmAnd also did not display this well. Other applications, I dont know, but it’s clear this is not the solution.

As for the choice of o when there is no r*n_ref: it’s a visual choice. o for naught. It’s been used and documented: https://wiki.openstreetmap.org/wiki/Tag:route%3Dmotorboat?section=5#Examples

The o-o ref is then necessary to make Knooppuntnet Planner work. As it heappens, it resembles a node-node connection. In WMT it looks like this: https://hiking.waymarkedtrails.org/#routelist?map=15.411248109086971!43.5088!1.4901 (hope this works…)
Notice how the guidposts near the network nodes show the name when zooming in. You can even click there and get the guidepost information.

While you are on the page, you might take a look at the issues and possible solutions…

This does not mean it should remain that way - but I think it is acceptable as a model and for data entry until the “dummy” rwn_ref and route ref can be eliminated. I have already asked Knooppuntnet if they will accommodate rwn_name instead of rwn_ref (what it would take to add this to their program).

Dummydaten sollte es nicht geben. Priorität sollte ref haben, name ist als Ergänzung zu betrachten.

I agree, the o and o-o trick is tagging for … well, not so much the renderer, it’s for the checking utility Knooppuntnet Analysis and the Knooppuntnet Planner.
I find these are essential for systematic entry and use of node networks (please take a look at Belgium and the Netherlands, for walking and cycling to see the extent of node networks there). The Knooppuntnet Planner is the only utility that makes the OSM node network information directly available for planning and navigation, that’s why I think it is important to have a temorary solution to make it work while an approved permanent scheme is discussed and passed.

Did you read https://wiki.openstreetmap.org/wiki/Proposed_features/Named_nodes_in_node_networks ?
Maybe you would like to add some comments there?

Thought about this some more. It’s not really dummy data - it’s a value saying there is no rwn_ref. Comparable to ‘none’, ‘0’ (zero) and ‘no’ values of other keys.

KISS … do not over-engineer the concept.