Cycle Node Network Tagging
Contents |
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.
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)
- 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 city and village centers. These routes don't always connect to a node, they often join in the middle of another route. These routes get an extra tag: state=connection and a 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 | a reference | The reference number of the junction. Can be found on or inferred from the signage on the road. |
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 | |
| note | 04-35 | A fast way to identify a route in an editor, and widely used. This is also of great value when the route is not complete yet, and gives a definite hint which (still unmapped) junction is at the other end. The lower number is put first to allow for finding it back easier in a sorted list. |
| state | state | do not set this for regular routes
(optional) "connection" if the route connects a POI or a city's center to the network (or) |
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 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 note=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. |
| 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.
- A complete route would now contain an unbroken string of ways connecting the end nodes (simplest case).
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
Potlatch2
Unfortunately the developers of Potlatch2 refuse to show the note tag for the route relations, so users of Potlatch2 are stuck with looking at large integer numbers instead of a hint about what kind of route it is. For people who want to get serious about working on route relations, it's probably better to 'upgrade' to JOSM anyway, where it is now a real pleasure to work with them, thanks to some research and Jiri's implementation of custom name formatters. See link above.
