Cycle Node Network Tagging

Cycle Node Networks

The basics came from a discussion on talk-nl in September 2008, and it was fleshed out in the months after that. This tagging is currently in active use in parts of The Netherlands and Belgium - and now, 2021 also widely adapted in Germany.

This expanded tagging is based on the following real-world observations:

• a cycle node network encompasses a limited geographic area and has a name
• networks have a number of numbered junction nodes and signs at these junction nodes show the name of the network (in an ideal world; not a universal truth in Flanders; in Germany it is an exception, - the "networks" as tagged in the relations have in most cases no reference on the ground and were used just for structuring the big amount of data).
• there are signs at and between the junction nodes, denoting how to proceed to nearby junction nodes
• networks connect to other networks (the routes which form the connection get the role: 'connection' in both network relations)
• routes can follow different roads, depending on the direction of travel. This can occur due to oneway streets, cycle lanes on both sides of streets and roundabouts with split ways
• junctions can be split, with identically numbered junctions at a short distance from each other (usually less than a few hundred meters)
• there are some nodes which are part of 2 networks. These nodes also get a role 'connection' in the network relation.
• there are routes that lead cyclist to a POI, city or village centers. These routes don't always connect to a numbered node, they often join in the middle of another route. These routes get an extra tag: state=connection and a note like note=34-35 - 57-98 or note=55-89 - Alkmaar Centrum

And the following OSM technical observations:

• relations can be broken by editing mistakes, user misunderstandings, or bad software
• thus, network completeness could be monitored by employing smarter tagging

How?

(A) Node tagging

All numbered junction nodes in a network are tagged:

Key	Value	Comment
rcn_ref	reference	The reference number of the junction. Can be found on or inferred from the signage on the road. Often a 2 digit number.
network:type	node_network	This defines the node as node network node.
expected_rcn_route_relations	count	(optional) can be set to the number of relations ending/starting at this node (junction). This can be used to facilitate (automatic) checking for missing routes. Count only regular routes, route relations with state=connection or state=alternate are not counted towards the number of expected route relations.

There is no need for a network=rcn tag anymore. rcn_ref=xx and the relationship of a network relation makes it clear enough. Some nodes are also part of other networks and may have rwn_ref=yy.

(B) Route tagging

The routes that make up the network are part of a type=route relation:

Key	Value	Comment
type	route
route	bicycle
network	rcn
network:type	node_network	This defines the route as a route in a cycle-node-network.
ref	04-35	The lower number is put first to allow for finding it back easier in a sorted list.
state	empty, 'connection' or 'alternate'	do not set this for regular routes (optional) "connection" if the route connects a POI or a city or village center to the network (or) (optional) "alternate" if this is an alternate route between junctions; it could be a shortcut or just another way to travel between the junctions

Remark

In Germany there are also other routes than "Cycle node networks" tagged as network=rcn. They were there before CNNs appeared in Germany and they are not going away. Those routes tend to have a ref=2 or 3 LETters. The key network:type is used to distinguish the network routes from other regional routes.

The members of this relation are:

• All ways making up the route between the two junction nodes, with proper forward/backward roles, if necessary (different ways used going from xx-yy than from yy-xx, no need to add roles on roundabouts which are used for both directions of travel). They are not indicating that the member way is a oneway road. All those roles mean is that the underlying way is followed in the direction of its arrows for that particular branch of the route.
• There is no need to add the junction nodes to this relation. They are part of the ways, so inherently already part of it. This allows for a more controlled way of downloading the hierarchy (collection/network/route).

Split nodes and the tentacles extending the routes to connect them

• When a route starts or ends at a set of split nodes, all the ways leading up to its start from one of the other nodes are added before the start, or after the end. And this, in such a way that the ways nearest to the start or end point are also nearest in the relation (their order is reversed beyond the end of a route). All these ways also need proper roles, leading cyclists towards the start/end node. The idea behind them is, that when you arrive at a numbered node of a cycle node network from another route, you can look at the relations on the other ways leading up to this node and select the route relation you need. In this relation you will find how to get to the start of the route you wanted to follow. They look a bit like tentacles at the beginning and end of a route and they are only needed when it's not possible to select one single node as the numbered network node.

This is to give people an idea of the whereabouts of the split node we're discussing.

25-26

• 1, 6 (not shown) route member ways used in both directions (no roles need to be assigned)
• 7,8,9 end of route coming from 25, for traffic traveling from 25 to 26. 25-26 ends in a fork.
• 10,11,12 start of the actual route traveling from 26 to 25. (members have roles and seem to be in reverse order)
• 13,14 one tentacle leading traffic coming from 27 to the actual start of this route (ways which are members of a tentacle always have roles and they seem to be in reverse order because they are beyond the higher numbered node)
• 15,16 another tentacle leading traffic coming from 98 to the actual start of this route

• For traffic coming from 30 no extra tentacles are needed, as the end node of 26-30 coincides with the actual start of 25-26

• It is important to notice that simply reversing the order of all the members of the route relation would still yield a valid route, which could then get ref=26-25. I'd prefer to follow the convention to always go from low to high though. This should explain why the order of some members seems to be in reverse.

26-27

• 1 one tentacle for cyclists coming from 30
• 2 another tentacle for cyclists coming from 25 or 98 (the order of the tentacles 1 and 2 could easily be reversed)
• 3-12 The part of the route that needs to be followed when going from 26 (low) to 27 (high)
• 13-18 The part of the route that needs to be followed when going from 27 (high) to 26 (low). It is exceptional that such a fork/branch continues all the way to the next numbered cycle node, like it does here. Therefore all the ways in this relation will have a role, either forward or backward.

26-30

• 1,2,3,4 tentacles leading traffic coming from 25 and 98 to the actual start of 26-30
• 5,6,7,8,9 way member used to travel from 26 to 30
• 10-17 way members used to travel going from 30 to 26. Notice that JOSM is not able to show that these are continuous, because as far as JOSM is concerned, this branch/fork starts in the middle of nowhere (i.e. JOSM cannot find a connection with the rest of the route). When reversing those members, they do seem continuous (and even the whole route seems continuous), but then the route in its entirety cannot be reversed anymore and still yield a valid route. So even though it looks odd, this is the correct order for those route members.

26-98

• 1,2 First halve of a tentacle
• 3,4 Second halve of the other and a tentacle in its own right. This shows that tentacles can be 'telescopic'.

• 1,2,3,4 leads from route 26-27 to route 26-98
• 3,4 leads from route 26-30 to route 26-98

• 5 First way of the actual start of the route. No need for roles anymore, whereas tentacles always have roles.
• 6,7,8,9,10,11,12 rest of the route leading to 98

For somebody coming from 98 the first 26 they reach, is the end of their journey on that route. Regardless which way they want to go now, they can start following tentacles which will lead them to the following start of the route they want and then beyond.

(C) Network tagging

One relation for each (named) cycle node network is created. This relation describes all elements of the network.

Key	Value	Comment
type	network	Denotes that this relation is a collection of all junctions and routes making up the network.
network	rcn	Denotes that this is a cycle node network. 'rcn' is the currently established tag for a cycle node network in Belgium, The Netherlands and Germany.
network:type	node_network	This defines the network as a node_network.
name	name	The name of the network. E.g. "Fietsroutenetwerk Zeeland".
operator	operator	The name of the operator of the network. E.g. "Toerisme Oost-Vlaanderen".

This relation holds:

• All numbered junction nodes (A) of this cycle node network. Do not add the junction nodes of the opposite end of routes with role=connection, as those are members of another network.
• All routes (B) that make up this cycle node network.
  • Routes connecting to another network get a role=connection role.

If a junction node is in two networks, which can happen in border areas, it is added to both of these network relations and it gets a role=connection role for consistency.

All nodes and routes with a role=connection role should therefore be members in two network relations

In some cases, a very large network is further divided in distinct areas (sub-networks). In this case, another relation of the above type can be created, which holds as members only the relations for the sub-networks. Example: the above network is divided in sub-networks, like "Oost Zeeuws-Vlaanderen" and "Schouwen-Duiveland". The parent relation then holds the name for the entire regional network, while the child relations hold the name of a particular part of the network. Junction nodes are (in theory, as exceptions do exist) uniquely numbered within a sub-network, but will most likely be repeated in the other sub-networks.

(D) Collection tagging

One relation for each collection of network relations is created. At the moment there is one for Belgium. One for The Netherlands will be created soon.

Key	Value	Comment
type	collection	Denotes that this relation is a collection of all networks in a given area
network	rcn	Denotes that this is a cycle node network. 'rcn' is the currently established tag for a cycle node network in Belgium, The Netherlands and Germany.
name	name	The name of the network. E.g. "Fietsknooppuntennetwerken in België".
operator	operator	The name of the operator of the network. E.g. "Toerisme Vlaanderen".

This relation holds:

• All the networks in a given area

It can be used as a starting point to download all CNNs for a country from the servers, or as the starting point for a script to do some Quality Control. When downloading, only the relation will be downloaded, not all its members and submembers. RMB (right mouse button) Select members on the relation and then RMB Download missing members for all networks and after that for all routes, will result in a skeleton of the whole collection of networks and its routes and numbered junction nodes. After downloading the network relations, only the numbered junction nodes will be visible in an off line editor like JOSM.

Advantages

• "Tag what's on the ground"

It's the junctions that are named/numbered and part of a network.

• Hierarchy is introduced.

Specific networks can be found and named. Member junctions can be identified. Maps for specific networks can now be created.

• Redundancy is reduced.

In NL, the name used to be repeated on every route, but it's now set once in the network relation and the name tags are in the process of being removed

• Programmatical checks for completeness.

A complete route would now contain an unbroken string of ways connecting the end nodes (simplest case).

Sometimes the routes branch (due to cycle ways on both sides of a street, one way streets, roundabouts with split ways, etc), in that case first the ways going from lower number to higher node number are added with roles, until the place where the branches join again. Then the ways from where the split occurred go in with reversed roles. The end result is that when checking for continuity, one can take all the members with no roles and the first continuous set of members of a branch for checking the direction from low to high node number.

For the other direction (high to low), one can take all the members with no role and the rest of the members with a role that were not consumed in the previous step, then reverse the whole set of ways.

It is not important at this point whether this role is forward or backward. In fact the majority will be forward (due to oneway streets). What is important is the order of the members of the route relation. The first set after the branch belongs to the low->high group, the set after that until where the branches come together again belongs to the high-low group of members.

At the beginning and end of the routes some members can be found with roles too. They are 'hints' showing how to get from a split end node to the actual start of the route one wants to follow. (At the actual start of the route, there is either a numbered node, or all these tentacles come together there). The same applies beyond the end of the route (They are all in the process of being sorted from lower numbered node to higher numbered node) but in reverse.

See Python script which runs inside JOSM for an example implementation

Examples of already existing network relations

• 51947 Altena Biesbosch
• 116285 Oost Zeeuws-Vlaanderen
• 116286 Meetjesland
• 155047 Limburg(Belgium) (currently contains no connections, only nodes
• 207888 Fietsroutenetwerk Antwerpse Kempen

JOSM

user:polyglot made some styles and other tricks to make the editing of the cycle node networks in JOSM easier. You can find it here: User:Polyglot/Some_ways_to_simplify_editing_cycle_node_routes_with_JOSM

Quality control with Python script in JOSM

Quality control with Python script in JOSM