Knotenpunktnetzwerke

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.

Not really helpful… what exactly do you mean?

Names: In the proposal as well as and in the temporary setup, names and punctuation on the route relations are optional and free format.
Guideposts: Optional in all hiking routes.

I would like to know the rationale for adding guideposts to the route. I don’t know of any application of that association, do you? The applications I know just ignore the guidepost members.

Ah, ich habe erst jetz gesehen, dass der Vorschlag 'rwn_name=‘* hier schon länger diskutiert wird und im Wiki gelesen, dass 'ref=’* eher was mit Zahlen ist, mitunter sogar mit begrenzter Länge. Mein Post #163 ist damit hinfällig.

Grundsätzlich fände ich das Verwenden von ‘name’ am Knoten und 'from=‘* und 'to=’* an der Relation der Wegeverbindung wunderbar einfach und völlig ausreichend. Ich verstehe den Mehrwert von 'rwn_name='* nicht. Ich habe aber nicht die ganzen 171 Beiträge durchgelesen - krasser Thread! - und mein Englisch ist begrenzt.

Dafür muss der Knoten lediglich ohne Verwendung von 'rwn_ref='* als als Netzwerknoten des jeweiligen Netzwerkes markiert werden. Daran erkennt der Renderer, dass er den Kreis zeichnen muss. Wenn mehrere Namen am Knoten notwendig werden, dann nutzt man Namensräume. Ein Knoten könnte dann so aussehen:

rwn:name=Katzensteinerhof
rwn:network:type=node_network

Da der Renderer kein 'rwn_ref='* findet, schreibt er keine Zahl in den Kreis und setzt den Name daneben - fertig.

Das mit dem ‘rwn_ref=o’ und ‘ref=o-o’ widerstrebt mir zutiefst. Nicht nur weil es “Tagging für Renderer” ist, sondern auch, weil ein Merkmal für etwas “missbraucht” wird, wofür es nicht gedacht ist. Dann besser ein temporäres zusätzliches Merkmal erfinden wie ‘rwn:has_ref=no’, dann bleibt da alte Merkmal sauber.

Im Wiki steht dazu: “Wenn eine Straße oder ein Weg keine Nummer hat, benutze diesen Schlüssel nicht; damit ist sichergestellt, dass Navigationsprogramme nicht versuchen, die Straße mit einer Nummer zu benennen.”.

Ich würde für Geduld plädieren, bis die Renderer mit einer neuen Lösung umgehen können und bis dahin 'rwn_ref='* nicht füllen und/oder nur ‘rwn:has_ref=no’ taggen.

edit: statt ‘node_network_node=yes’ das etablierte ‘network:type=node_network’ verwendet

Grundsätzlich: Ist ein Netzwerk ein Knotenpunktnetzwerk, nur weil die Wegweiser einen Namen haben? Für mich absolut nicht.

Knotenpunktwegweisung wäre es m. E. erst, wenn

a) auf den Wegweisen ausschließlich die Namen der nächsten Knoten ausgeschildert würden,

oder

b) sich die Ausschilderung der nächsten Knoten optisch stark von der Ausschilderung entfernter liegender Ziele unterscheidet (bei Radwegnetzen in Deutschland durch Einschübe mit den Nummern unten am klassischen Wegweiser)

Das Beispielbild vom Wegweiser “Katzensteinerhof” im Proposal hat für mich keine Merkmale eines Knotenpunktnetzwerkes. Es ist nur ein Wegweiser einer klassischen Wegweisung mit einem Namen.

Womöglich gibt es gar keine Knotenpunktnetzwerke ohne Knotenpunktnummern und das ist eine Phantom-Diskussion durch ein Missverständnis, was ein Knotenpunktnetzwerk ausmacht.

Ich finde mehrer Gründe, um Wegweiser in die Relationen aufzunehmen:

Wegweiser helfen bei der Orientierung. Womöglich ist es hilfreich, beim Verfolgen einer Route die zugehörigen Wegweiser mit anzukündigen und alle anderen Wegweiser auszublenden.

Mitunter gibt es mehrere Wegweiser an einer Kreuzung an verschiedenen Standorten. So weiß man, in welche Richtung man schauen muss.

Es gibt Routen, die sind nicht an jedem Wegweiser ausgeschildert. So weiß mann, dass man sich nicht verlaufen hat, nur weil ein Zwischenwegweiser nicht das Routensymbol hat.

Man kann statistisch auswerten, wieviele Wegweiser zu einer Route aufgestellt wurden. Routen mit vielen Wegweisern gelten als gut ausgeschildert, was ein Qualitätsmerkmal sein kann.

kiss = keep it simple and stupid

Zuerst habe ich genau das Gleiche gedacht, aber das zweite Beispielbild (Hilsenberg) hat mich überzeugt.
Für mich ist entscheidend, das es ein spezielles Netz von Kreuzungen gibt, die auf einander zeigen, und das unterwegs ein einziges Zeichen oder Symbol die Route zum nächsten Kreuzung in das Netz zeigt. Man folgt nicht ein Wanderung wie “die Rote Wanderung”, aber man plant seine eigene Route durch das Netz, durch Aneinanderreihen kurzerer Strecken, die alle mit dem gelben Diamanten markiert sind.

Ich erinnere mich an einen Urlaub in Deutschland, in dem meine Frau und ich dachten, wir würden den Yellow Diamond Walk machen. Wir haben uns hoffnungslos verlaufen, und überall schienen gelbe Raute zu sein; wir haben es einfach nicht verstanden. Erst jetzt verstehe ich warum: Knotennetzwerk, nur mit Namen statt Nummern!

Der Katzensteinerhof Wegweiser zeigt: Operator und Symbol für dat ganze Netzwerk; Name; Namen und Richtungen benachbarte Auswahlpunkte (erste Name pro “Hand”). Klassische Wegweisung gibt an erster Stelle Endziele die man auf jedem Wegweiser seht. Direkt benachbarte Auswahlpunkte zeigen Katzensteinerhof am ersten Stelle. Die zweite un dritte Reihe sind “Service”: sie Zeigen bereits die nächste Auswahl.

Also ja, das ist ein Knotenpunktnetzwerk, nur mit Namen statt Nummern.

I can add that solution to the proposal page, I’m just not sure to which issue…

Ich habe noch einen Gedanken zur Vergabe von rwn_ref. rwn_ref=o finde ich auch nicht gut. rwn_ref sollte ein kurzer (1-,2-,3- oder bis zu 5-stellig) Ausdruck sein, der auf ein Objekt verweist und an dessen Namen angelehnt ist.
Wenn das Objekt nun zwar einen Namen (“Katzensteiner Hof”) aber keinen offiziellen ref hat, dann könnte der Mapper eine Abkürzung wählen, deren Länge eine vorgegebene maximale Länge (2-,3- oder bis zu 5-stellig) nicht überschreitet, aber eindeutig auf den vollständigen Namen verweist. Genau so sind doch bereits die meisten Rad- und Wanderrouten erfasst. Es gibt meistens einen Namen, aber keinen offiziellen ref, so dass der Mapper den ref frei vergibt.

Beispiele: PeerkePad → PP, Ronde van Nederland → RvN, Deutsche Fußball Route NRW → DFR.

Für Katzensteiner Hof würde ich einfach rwn_ref=KH vergeben. Weiteres Beispiel für eine der Netzwerkrouten bei Toulouse:
Ancienne Vigne - La Garrigue

network node “Ancienne Vigne”
network:type=node_network
rwn_name=Ancienne Vigne
rwn_ref=AV

network node “La Garrigue”
network:type=node_network
rwn_name=La Garrigue
rwn_ref=LG

network route
network:type=node_network
ref=AV-LG
name=Ancienne Vigne - La Garrigue

Damit würden wir kein neues Schema einführen. Wir würden stattdessen einfach ein Schema fortführen, das in einem verwandten Bereich (den Routen) bereits so angewandt wird.

Analogie mit rwn_ref. Wir haben auch rcn_ref, rhn_ref, rpn_ref, rmn_ref und rin_ref, und im Zukunft möglist mehr. Ein einzelnes Node kann mehrere Nummern tragen, also ref ist nicht unterschiedend. Daher rn_ref. Für Namen gilt das auch, sicher wenn meherere Operators Netzwerke verwalten.
2.
name= sollte der Namen eines sichtbaren Objekts sein (wiki). Knotenpunkte (intersections) sind keine sichtbare Objekten, die Wegweiser sind die Objekte und sie tragen den Namen schon. Der Knotenpunkt referiert an den Namen des Wegweisers für das r
n_ Netzwerk.

Diese Vorschlag ist bereits im Proposal enthalten: rwn:name statt rwn_name.
Renderer, Router un Planer können rwnname als erste benutzen; wenn es die nicht gibt, rwn_ref. Das ist generisch für alle rn Knotenpunktnetzwerken

Das hilft nicht als Zwischenlösung für Knooppuntnet Planner. Dann besser nichts machen, denk ich. Dann hat Deutschland keinen Pilotmodell. Auch kein Problem.

Die Renderer sind kein Problem, dafür braucht man nichts extra zu taggen, was die Renderer überhaupt nicht verwenden werden!

Danke! Gibt es Apps die das so machen oder machen können? Vielleicht für Radknotenpunktrouten?

Danke! Ich denke das würde sicherlich funktionieren, aber…

  • Die Beispiele sind für lange Routen, nicht knotenpunkte, und die Abkürzunge sind nur für Display, im osmc:symbol-Tag. Also keine Refs.
  • 5 Buchstaben ist zu viel. Wenn das einmal passiert, okee, aber mit ein ganzes Netzwerk, wie die Renderer das jetzt machen, ich denke das Bild ist nich akzeptabel.
  • Genau dieses schlug ich den französischen Mappern vor. Die haben gesagt, das kann vielleicht für ein kleines Testnetzwerk, aber nicht wenn es grösser wird, man kann einfach die Abkürzungen nicht mehr verstehen; Die vollständigen Namen sollten auf der Karte und in der Output des Planners angezeigt werden.
    Aber wenn ihr es so machen wollt, fine with me!