Node networks: Dutch proposition

Communities Deutschland (Germany)
1

LS
Sorry to do this in English, but my German is even worse!

In Nederland, network=rwn and rcn have been (ab)used to accommodate walking node networks and cycling node networks. We would like to repair this, by proposing an alternative way to indicate that routes belong to a node network. I know this is discussed in the German forum as well.

The Dutch have discussed this at length. Bottom line we propose simply to
add a tag **network_type=node_network **to the route relations of the node
networks.
Nodes do not need this tag, the fact that they have the xxn_ref tag says it
all.

This allows node networks to be defined for all modes of transportation and
all geographical scopes. The setup can handle other network_types should
they arise; other modes of transportation; and other geographical scopes if
necessary (so intercontinental drone hub_networks, no problem!)

Node network checking-site knooppuntnet.be/knooppuntnet.nl (the site
formerly known as vmarc.be, i.e. user vmarc) has indicated it is an
easy-to-implement solution and it would allow the site to facilitate german node networks as well.

From statements of waymarkedtrails we understand that they can work with this too; we have asked them (on github) to confirm this.

We think maybe the network relation with all the routes and nodes in it is
no longer necessary. That is in the current system the main
pain-in-the-butt for node network maintenance, and nobody really used it.

Existing base does not need retagging, just add the extra tag to the individual node
route relations. In Nederland this can be done quick and easy because we
have no regional linear routes defined: all rwn routes are node_network
routes.

In Germany I think there is a mix of linear and node rwn routes, so
it’s a project but I think not a large or difficult one. I would be glad to help out if necessary. Maybe this proposal even helps in separating rXn node routes from "real " rXn routes.
Adding the extra tag changes nothing for the current rendering, so existing
data users can keep their system in place while developing handling of the
new system, then changeover at their own time. If they don’t, nothing changes for them.

I would like to hear your questions and comments on this proposal. We have considered a lot of arguments to get to this simple result, but please, surprise me with things we haven’t thought of!

I will share this with the Belgian (Flemish) community as well. Their situation is about the same as in Nederland.

The idea is to get to one common proposal (DE+BE+NL), then present this to the tagging list as the way we want to normalise/undo the exception we created to accommodate the rising node network system in a more generic way.

Fr gr Peter Elderson

2

Oh man, what did I do… Me and my “good” English. Saint Bing help me… :smiley:

I challenged this a bit, because I have now realized that junction networks have a completely different structure than other hiking or cycling path signs. Junction networks are not really comparable with all other hiking or cycling trails…
This should also be better reflected in the tagging and subsequently in the rendering.
Personally, I am very interested in a common solution! I really like that.
As a result, it must be a question of capturing such junction networks in a clean, unambiguous and separate way and making them questionable!
I myself have a brief overview of the situation in the federal state of Brandenburg here in Germany. Here, these junction networks are only built for the bicycle. Therefore, I had the idea to use network=cnn (=cyclenodenetwork) for such networks instead of network=rcn|lcn, which could be extended to network=wnn (walkingnodenetwork).

But I like the idea of “simple” network_type=node_network even more. This does not change the existing data. Above all, existing evaluation tools such as https://knooppuntnet.nl/en/networks/de/rcn do not need to be fundamentally touched. The new network_type=node_network property then ensures that such networks can be separated cleanly from everything else.

We should now consider…

Here, for example, we have pure thematic cycling routes and more and more (bicycle) junction networks. Both always use the same infrastructure. At a junction you can find a themed bike path guide and a hint to the next junction or just a hint to the next junction.
In my opinion, this is also the reason why separate registrations are taking place here and should be the case.

The question now is which objects network_type=node_network must be…

Nodes?
The relationship that summarizes the path relations with the nodes?
Subrelations between the nodes?
To everything?

The bottom line is to capture the relation that summarizes everything as a superroute and set network_type=node_network to the nodes and subrelations that summarize each node.

Example:

the relation https://www.openstreetmap.org/relation/8801845 get additional network_type=node_network + (relation-type) type=superroute
The nodes of the network https://www.openstreetmap.org/node/243202864 get additional network_type=node_network and
the relations between the nodes https://www.openstreetmap.org/relation/9691317 get additional network_type=node_network

In addition to network=rcn, this can then be indentified as a (regional) bicycle junction network.

supplementary opinions? I think it should work.

Greetings from the Spreewald,

Sven

3

In our opinion, after consulting with vmarc and with Sarah from waymarkedtrails, only the subrelations between nodes need the tag network_type=node_network. However, it does not hurt to add it to the nodes and the superrelation.

The nodes are identified as network nodes because of the xxn_ref says it all. Waymarkedtrails then just renders the nodes on the right map, it does not use the overall network relation at all. For network analysis, vmarc also does not need an extra tag for the nodes. Same thing: the xxn_ref is enough, and they are also part of the overall network relation.

I don’t know enough about other renderers, checkers and datausers to tell. But we in NL will not need to add the node_network tag to the nodes.

The node network relation, we think it has to have the network_type=node_network tag.

[(Sidestepping: At the same time, we are considering not to use a node network superrelation any more! It groups nodes and node2node routes into networks, mainly for consistency checking. In reality, all of Nederland is becoming one big node network, resulting in an unmanageable superrelation without structure or order.
For administration, checking and maintenance, it would be simpler to use e.g. municipal boundaries to group nodes and node-routes into manageable divisions. No mapping necessary, and we wouldn’t need special rules and roles for connection routes. Network names found in the field could still be recorded and could be rendered, but nothing would depend on that.)

4

About long distance routes or theme routes routed over the node network: We build the longer routes as superroutes containing the node2node routes as sections (instead of the separate ways). In waymarkedtrails that works fine because they handle nested routes very cleverly. Which means other renderers and routers can do the same! It’s explained on the waymarkedtrails site https://hiking.waymarkedtrails.org/help/rendering/hierarchies

5

Slightly OT, but: could we -not- use type of network/route encoded in the network value for any new route tagging scheme?

The means of travel is already tagged in the route tag and encoding it in the network value instead of just using “international”, “national”, “regional” and “local”, is really really silly. The damage has been done for conventional routes (with the exception of inline skating) but we don’t need to repeat the same mistakes time and time again for new schemes.

6

I see your point… but in this proposal we do not add new modes of transport or new scope values, we just want to add a tag for network configuration type so node networks can be handled separate from regular routes. The use of xxn values corresponding to xxn_ref tags in the nodes, I think that is established now for cycling and walking, it’s used widely in NL, BE and DE, so we do not want to touch that now. But on the other hand, this proposal fits another network mode/scope tagging scheme just as much.

7

Have a look at the node network in Barnim county north of Berlin. It works fairly well with my preferred rendering and routing tools (waymarkedtrails, mapy.cz).

Example:
https://www.openstreetmap.org/relation/8946367

I certainly agree with Streckenkundler’s proposition not to introduce a solution that interferes with established tagging, but rather add a tagging for node networks “on top”.

8

@Pfad-Finder Looks good! How does mapy.cz use the cycling node network? I can see it on the map, but is it used for the routing?

The main reason for our proposal is to clearly separate non-node route networks from node networks. We undo the hijacking of rwn and rcn, and get them back for true regional routes. Bonus of our proposal is that extra network configuration types could be accommodated, and node networks can now be defined at all four geographical levels. (In Nederland, the LAW network already looks like a node network, they just haven’t numbered the nodes yet).

9

Hi! The Dutch community has reached consensus about the following:
**
We add the tag network:type=node_network to all the junction nodes, to all the node2node route relations, and the node network relation of the node network.
**

This applies to all recreational node networks: all transport modes, and all geographical scopes.

This means that network=rcn in itself no longer implies that it is a cycling node network. Without the network:type=node_network tag, network=rcn denotes a regular cycling route.

We checked that this solution fits Nederland and Belgium, and we believe it fits Germany as well.

To make it work in rendering and other data use, some work has to be done: tagging all the node networks. Until that time, nothing really changes!

But that’s up to you, if you want to use this solution.

10

Status report
All elements of all recreational node networks in the Netherlands now have the tag network:type=node_network. The maintenance site https://www.knooppuntnet.nl is being modified to check for the tag.
I think it is up to the German and Belgian communities to add the tag to ‘their’ node networks. Of course, we would be glad to help out, when asked.

11

Waymarkedtrails hat die Knotenpunktnetzwerk-Rendering implementiert. Siehe https://hiking.waymarkedtrails.org/#?map=14!51.5521!5.2

Die Logik lautet: Wenn es ein Tag network:type=node_network gibt, wird network=* ignoriert und wird das Rendern des Knotennetzwerks verwendet.

Es ist jetzt möglich, echte regionale Routen auf der Karte klar zu unterscheiden.

12

Yippie… Das sieht sehr gut aus… Ich finde ein sehr gutes Ergebnis.

Vielen Dank an alle Beteiligten und besonders an Peter und Sarah.

…jetzt geht es weiter mit der Datenpflege.

freut sich Sven

13

Übersetzung:

14

Mit der Winterausgabe der Freizeitkarte Android werden wir (Dank Stephans Arbeiten) auch das Thema Knotennetz umfänglich unterstützen. Routen (local, regional, national, international) sind ja bereits jetzt enthalten. Stellt man Routen und Knotennetz gleichzeitig auf der Karte dar, wird der Benutzer von der Fülle an Informationen nahezu erschlagen. Von daher soll sich der Benutzer wahlweise das eine oder andere anzeigen lassen können (beides gleichzeitig geht auch). Dies geht von der Annahme aus, dass der Kartennutzer sich typischerweise entweder an den Routen oder am Knotennetz orientiert. Frage: Ist diese Annahme korrekt bzw. so zu erwarten?

15

Ich benutze oft Karten zum Planen und Reisen. Für die Planung verwende ich fast nie Knotennetze. Ein Wahlschalter ist schön zu haben.
Die Darstellung der Knoten selbst ist auch für die Planung und Nutzung längerer Strecken sehr angenehm. Sie sind gute Bezugspunkte auf der Straße und auf der Karte.

Wenn ich Routen auswähle, möchte ich die Knotenpunkte auf der Karte sehen, ohne die Knotenrouten.

16

Bin zwar nicht mehr so der aktive Radfahrer und solche Knotennetzwerke gibt es in der näheren Umgebung nicht. Würde aber nur die Knotenangabe nützlicher finden. Wie man zu diesem Knoten kommt ist ja nicht “ausgewiesen”. Routen sind ja auch unterwegs noch durch Wegzeichen im Streckenverlauf gekennzeichnet.

17

Och komm… Landkreis Spree-Neiße ist doch schon fast nähere Umgebung… :smiley:

Das ist ja vorgesehen: entweder Knoten oder Route oder beides… Das ist in meinen Augen eine äußerst nützliche Auswahlmöglichkeit.

wenn es eine Themenradroute ist ja, wenn es eine Knoten-zu-Knoten-Route ist: es kommt drauf an… gelegentlich findet man Schilder mit der Richtung, in der die Route geht, aber nicht immer…

@toc-rox: der Vorschlag ist sehr gut und in meinen Augen sehr praktikabel.

Sven

18

Das unterscheidet sich aber schon: Knotennetzwerkrouten und Fahrradrouten - das auswählen finde ich ja schon gut. Bei Knotennetzwerkrouten sollte man noch so etwas auswählen können https://www.openstreetmap.org/relation/418812#map=13/54.1354/12.0488 oder z.B. nur die node wählen können: https://www.openstreetmap.org/node/45928088 oder eben auch beides.

Würde ich jedenfalls sinnvoll finden - und habe auch Peter so verstanden.

19

ach optional nur die Knoten, ohne dazugehörigen Routen? Hm…

Wenn in Ergebniss eine ähnliche überlagernde Darstellung wie hier: https://cycling.waymarkedtrails.org/#?map=14!51.8606!14.1156 rauskommen würde, würde ich mich freuen und es würde mir reichen… Da ich dann ja z.B. lcn und rcn sehe und auch das Knotennetz. Ich finde es nicht schlimm, neben den Knotenpunkten, dann auch die knotenpunkt-Routen mit zu sehen.

Welche Router unterstützen denn Knotennetze in der textlichen Routenbeschreibung? Im Moment kenne ich nur: https://cycle.travel/map?from=53.041279,12.130153&suggest=1 …oops, nächste Baustelle.

Sven

20

Hmm, wozu denn überhaupt die Knotennetzverbindungen anzeigen? Hört sich für mich nach einer sehr speziellen Nutzungsweise an.