(Work in progress)
This page about Node Networks describes the current practice in the Netherlands. Other communities may, and probably will, have different practices. Node Network mapping is still very much in development. History and reasoning behind choices are described to help people make up their minds about these matters.
What is a node network?
A node network consists of numbered junctions called nodes, and routes interconnecting the nodes. On the road, every node is marked with its number, and it has pointers to adjacent nodes in different directions. In between the nodes, the route is waymarked in both directions with arrows, often without numbers.
Node networks are mainly used for recreational purposes. One finds an area of interest, plans a trip within the network, and writes or prints a list of numbers to follow. Of course, this process is increasingly digitized with planner sites, planner apps, gpx output, rendering apps and navigation apps.
Variants include letters or codes instead of numbers, or different colour markings on the node2node routes. This makes no difference when planning a longer route using the node network. Planned routes in the end consist of a chain of numbers or codes to follow.
A particular variant uses coloured routes to connect the network nodes. On the road, you cannot choose the next number, you choose which colour to follow. The planned route has to add this colour information to the user output.
Waymarking on the road may differ between regions, and may require some getting used to when following the routes on the road. Many cycle networks use separate shields for the node2node route waymarking, where walking networks often use simple stickers and small shields combined on shield posts. Some give the next node number on every shield, some just use an arrow or shield without a number. In Germany, many operators have integrated all waymarking and direction-pointing systems in one system of numbered signposts and shields for all purposes.
The pictures above shows a style using metal shields, where the colour, size and an icon indicate cycling or hiking, and the shields show the direction and the node number you will reach next. The boat node example shows the use of colours to differentiate between the types of boat.
Node networks are maintained on the road by various (and often changing) operators. Most operators have their own network maps and sometimes a planner site or app. OSM uses the nodes and routes as found on the road and in the field. In The Netherlands, mappers are allowed to use the Wandelnet node route planner https://wandelnet.routemaker.nl/routeplanner/wandelen as a source.
Sources of data
Survey is of course the most valuable source. Other sources may help. Operators may provide their data as open data (Odbl, CC-BY-SA or comparable). This allows mappers to use that information for OSM. In The Netherlands, mappers are allowed to use the Wandelnet node route planner https://wandelnet.routemaker.nl/routeplanner/wandelen as a source. Both the Wandelnet data and OSM are (2020) well underway to complete coverage for the Netherlands.
Node networks started out as separate cycling networks in Belgium and The Netherlands. Later different networks interconnected and the system was applied to walking. Nowadays, for cycling and walking in the Netherlands the whole country is evolving into one big node network, and other countries follow this development. Also node networks for horse riding, motorboat, canoe and inline skating are being rolled out.
The basics of OSM-tagging of node networks came from a discussion on talk-nl in September 2008, and it was fleshed out in the months after that. Since then, many things have changed but the basic system is the same. See (Cycle node tagging). This development is still going on.
This page gives the reasoning and the essentials for all node networks. Details for a particular type of node network can be found on various tagging pages. Variations and rules for particular countries may exist and should be described on the localized pages.
Tagging is based on the following real-world observations:
- a node network encompasses a limited geographic area and usually has a name and other specific attributes
- a node network is a routing system for planning trips and navigating along the planned route.
- the physical elements indicate the network elements. The tagging is designed for routing, not for exact location.
- node networks tend to grow and connect to surrounding networks, so they tend to merge into larger networks
- networks have numbered or coded junction nodes. The numbers are not unique id's; they are often repeated even within a network.
- signs at the junction nodes may or may not show the name of the network or the operator, even if there is one.
- there are signs and markings at and between the junction nodes, denoting how to proceed to nearby junction nodes
- networks connect to other networks in two ways: 1. A node belongs to two networks; 2. a node2node route connects 2 nodes which belong to different networks
- routes, in particular cycle 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 nodes at a short distance from each other (usually less than a few hundred meters)
- sometimes routes join/separate some distance from the actual node. The way(s) between the join location and the node then belong to more than one node2node route. This may or may not be within visual distance, which means in some cases the join/separation point is not at the node junction.
- some routes do not connect nodes. They may connect to a city centre without nodes or to a ferry. They are more like approach routes.
- some of these approach routes join the network in the middle of another route, without an official node.
- Additional attributes have to be considered, such as access tags on roads, minimum clearance for boats, conditional access, oneway tags for cycleways or implicit cycling lanes.
The objective is to make the node networks routable and planner-ready, and renderable as special networks, different than regular cycling, hiking, horse, canoe, motorboot and inline skate routes. So we are building a model for data use, while staying as close to the real world as possible. This can be compared to the way roads are mapped and connected as linear features to enable routing, while in reality they are areas.
The system should be extendable to accommodate new transport or sport types (rXn); node networks of smaller or larger scope (lXn, rXn, nXn, iXn) and different network types (network:type=*), e.g. hierarchical grid or destination based networks
The system should also be scalable to cope with the possibly very large number of elements involved.
This was achieved as follows:
- Not the actual physical features (poles, signposts, arrow stickers and roads) are mapped and tagged, but the node2node routes and the intersections of the ways of the node2node routes.
- Junction nodes are tagged with network:type=node_network and with the node number or code as rXn_ref=* (where X indicates the transport mode: w for walking, c for cycling, h for horse_riding, i for inline_skating, p for paddling, m for motorboat)
- The intermediate waymarks are not tagged as features, because they just indicate the route i.e. which ways to put in the route relation.
- Each bidirectional node-to-node connection is a separate <transport mode> route relation, tagged as usual with route=<transport mode>, network=rXn and additionally network:type=node_network and ref=*. The ref tag holds the reference of this short route: ref=mm-nn where mm and nn are the rXn_ref numbers of the end points. By convention, mm is the lowest node number and nn is the highest ref node number; mm and nn may be short codes instead of numbers but no more than 3 characters. Note that the low2high convention is not required for routing and rendering, but many mappers find that it helps with the maintenance.
- For each node network a relation of type=network is created and tagged with network:type=node_network and optional name=*. The members are alle the nodes and route relations of the network. Note that for rendering and routing this network relation is not required! It holds network information and may be used for OSM network checking and maintenance.
- New nodes and node2node routes may be added to a network relation at any time when the network is expanded or changed.
- Merging networks means moving al nodes and routes from one network relation to the other, then delete the empty one and adjust the merged network (name, operator, remove the roles from duplicate connecion routes and remove duplicate routes.
- The name of the network or the operator, if present on the physical junction nodes, goes on the network relation and is optional. The routing function does not require names or operators for any element of the node networks.
- Nodes and node2node routes belonging to different networks are added to both network relations and get the member role "connection" in both.
- Connection routes and connection nodes are added to both network relations, with the member role "connection".
- From 9. and 10. it follows that a connection route has one end node in one network and the other one in a different network. Also that a connection node must head/end at least one route in each of the networks the node belongs to.
- The node2node routes can be different for the two directions, in particular cycle routes. This is handled by using split nodes. If node2node routes with split ends land on a roundabout or complicated junction, additional nodes are tagged as network nodes with the same node numer, so that each split end lands on its own node. All the nodes have the same numer and are interconnected with one or more short routes to enable all connections for all directions. Often in these situations, multiple signposts with the same node number are present around the junction.
- Waymarked approach routes connecting a node or a regular node2node route to a city centre or to a ferry, are tagged with "state=connection". They are added to the network relation without a role. The ref is not precisely defined. For a node2city or node2ferry connection ref="mm-" may suffice. For a route2city or route2ferry connection, "mm_nn-". Take care not to put a lengthy description in the ref; use description=* for that.
Integrity and maintenance of the OSM network representation
- The sheer numbers of nodes and node2node routes relations make it impossible to check these networks manually.
- The networks change much more than long distance routes do.
- Routes and connections are easily broken by editing mistakes, mapper misunderstanding or software validation errors.
- Therefore, error detection is critical for the maintenance of the node networks in OSM.
Knooppuntnet has been designed to perform extensive checking on a node networks and node network elements. The results are presented by network as "facts" with direct edit links to OSM and JOSM.
In addition to the regular tagging above, extra tagging can optionally be used for very tight maintenance. This includes:
- Entering Start and End nodes as members into the routes. This should match the ref. When editing, this is a simple visual aid to avoid numbering errors theat are easily made.
- Tag expected_rXn_route_relations=. on network nodes. On the road at a network node, count how many adjacent nodes it refers to. If one route is forgotten, deleted or not yet entered, value of expected_rXn_route_relations will differ from the actual route count. Knooppuntnet will detect that.
- When editing a network node in JOSM in the network style for your transport mode, the expected_rXn_route_relations tag value should match the number of routes you see landing on the node. When the nodes are entered as members into the relations, you can easily see in JOSM how many relations the node is a member of, compared to the expected_rXn_route_relations tag.
- network=rXn tag on nodes is no longer required At first, network=rcn was tagged on the nodes. Network in this tag means the combination of range (local, regional, national, internatiional) and transport mode (cycling, walking, horse, motorboat, inline_skates, paddling) and it was used for linear, circular and mixed topology routes. When rwn node networks arose, the problem was that the nodes often coincided for both networks, but you couldn't add a second network tag. But since the transport type is also present in the rXn_ref tag, one didn't need the network=rXn tag anymore for the nodes, and it was dropped.
- The "collection" relation which could hold a national collection of network relations as members, no longer exists. This system never took hold, and it has no support with data users.
- network:type=node_network has been added recently. Before, the network=rXn tag was (ab)used to indicate node networks in Nederland and Belgium. This meant that Nederland and Belgium could not use rXn for truly regional routes. When node networks started to appear in Germany, this became a problem, because Germany has many truly regional routes. This problem is now over. All node networks and elements have received the extra tag. Major renderers have implemented special rendering for node networks based on this tag, and Nederland and Belgium now have regional routes not obliterated by node network routes.
- note=* and name=* have been replaced by ref=*. Before, mappers used name=*, note=* and ref=* to hold the reference of the routes. This still can be found in many places. Nederland had first chosen note=* and used that consistently. Later it was recognized that the note tag is meant to hold notes for mappers, not references of objects. Real notes were now placed in tags like comment=*, description=*, remark=*. After discussions and some preliminary double tagging for testing, Nederland has moved all note=mm-nn to ref=mm-nn, for all Dutch node networks. While the use of ref for this purpose is not entirely undisputed, it is certainly better than name=* or note=*. Note that from an informational point of view, the tag is redundant as the routes connect two nodes tagged with the numbers.
- The order low > high rule is no longer considered an error The node2node route relations are supposed to be ordered from the low number node tot the high number node. This is neat and handy in a listing and when searching, but it is not necessary for the use of the network. Most mappers like the order, some think it unncessary maintenance work. In knooppuntnet, the check is still performed and reported, but it no longer counts as an error. An unordered route, however, is considered an error.
- Area based network maintenance, in addition to network based maintenance. The network relation is not useful for planning, routing or rendering. It is useful as a named administrative collection in checking and maintenance though knooppuntnet. In 2020 a pilot started to see if administrative areas (country, province, municipality) can be used to navigate and maintain the node networks in the area. The driving force behind this is that small named networks with no or just a few connections, tend to grow and merge. Eventually the whole country is covered by one big network. While it is possible to cretae such a large network relation, it can hardly be maintained or used. The network relation system is not scalable and flexible enough to keep up. It's no longer worth the effort. Knooppuntnet has checks based on the membership of network relations, known as the "Orphan checks". If all elements should be in a network relation, then if you find an element tagged as a network node or route that is not in one, you have an error. The other way around, if a route or node is in the network and does not have the required tagging, there is an error. Also, checks are done that connection routes are in two adjacent networks. However, because all elements are now tagged with network:type=node_network, much of the orphan checks and connection checks are mainly checking if there is a network relation, not if the connections and nodes form a consistent network altogether. This is still very usefull when node networks are indeed separate networks, but it becomes increasingly difficult when networks grow and merge. On many occasions, the information about (former) network boundaries is simply no longer available. For the moment (2020) the two systems will coexist, and the network relations are considered required. Larger scale testing shows that routing, planning, checking and maintenance can be done without network relations, but the coexistence of the two systems still requires some development.
- The "tentacle model" for tagging cycling networks is being revised This model was used to solve cases where split-end cycling node routes land on / depart from duplicated nodes. The model was too complicated for most mappers, and required some intricate preprocessing. In this document, we suggest more practical alternatives that will solve most cases.The "tentacle model" is still supported by Knooppuntnet.
- Named Nodes are used at several locations in Germany and Switzerland. The guidepostst represented by the network nodes have a name as reference, and the node2node routes are named after the nodes. Rendering support and planner support are needed to accommodate this. A small test network is used to model this (2020-08-12). There is a preliminary proposal.
- Operators are increasingly using special cases, such as end nodes e.g. for a parking or ferry terminal; loops starting and ending on the same node (excursion); split points which have no node number because they never act as a destination. As long as these creative solutions work on the road, we will have to support it.
- The expected_rXn_route_relations will be simplified. Currently, it does not count routes tagged with state=alternate or state=connection. This exception will disappear, mainly because these routes are no longer in use. They are still valid though, but the integrity checks no longer treat them as exceptions. This means that is they are used, the mapper has to count them in for the expected_rXn_route_relations value.
Although in theory node networks could be defined at local, regional, national and international scale, currently all node networks are still defined as regional (network=rXn). In this tagging instruction we will assume regional scope, and use c for cycling to explain the tagging. For other transport types, use w for walking, h for horse, p for paddling (canoe), i for inline skating instead of c for cycling, in these tags:
(A) Node tagging
The node you tag does not represent the physical feature (pole or post) but the intersection of the ways making up the node2node route relations. In other words, the junction node is the intersection node that the routes "land" on. This node links two routes together when planning a trip over the node network.
All numbered junction nodes in the node network are tagged:
|rcn_ref||reference||(Mandatory) The reference number of the junction. Can be found on or inferred from the signage on the road. Often a 2 digit number, sometimes a three letter code.
If the node is also a member of another network, e.g. rwn, just add rwn_ref=nn tag. Boating networks often use the same nodes for canoes and motorboats.
When the node is not an actual node but a split point without a node number, enter '*' as the special value.
|network:type||node_network||(Mandatory) This defines the junction as a node network node. Note that this does not contain the network, i.e. the transport mode. If the same node is used with different rXn_refs, the network type is valid for both. If in the future other network:types arise, you will need to create one node per network:type.|
|expected_rcn_route_relations||count||(optional) can be set to the number of rcn relations ending/starting at this node (junction). This can be used to facilitate (automatic) checking for missing routes. The count should include route relations tagged with state=connection or state=alternate. Connection routes, which are in two network relations with the role connection, are regular routes and do count.
If the node is also a member of another network, e.g. rwn, just add an expected_rwn_route_relations=n tag.
(B) Route relation tagging
The routes that make up the network are part of a type=route relation:
|route||bicycle||(Mandatory) or foot, hiking, horse, inline_skates, canoe, motorboat, mtb, running if a node network is found for the type of transport or sport.|
|network||rcn||(Mandatory) or rwn, rhn, rin, rpn, rmn|
|network:type||node_network||(Mandatory) This defines the route as a route in a node network (node2node route)|
|(Mandatory) This tag is the identification of a route. It is composed of the lowest node number of the route, a hyphen and the highest node number of the route. The lower number is conventionally put first to allow for finding it back easier in a sorted list. When the nodes have three-letter code refs (often simply the number prefixed by a capital letter), the routes follow this convention.|
|(note)||(nn-nn)||(Deprecated) (The note tag should not be used for this purpose any more. Use the ref key instead. However, the note key is still in use in some countries for this purpose.)|
|state||state||do not use this for regular routes. Values for state are:
(optional) "connection" if a waymarked node route connects a POI or a city's center to the network (or)
Note that the tag state=connection on a route is rare, and very different from the role connection for a regular node2node route in two network relations.
|(optional; sometimes necessary) Use a colour tag when route choices are identified by a colour.
In some node systems, the arrows do not indicate the adjacent node by number, but by colour. The user of an application then needs to know the colour, not the number. Some systems use colour to indicate which subtype of transport can use the route, e.g. an open low motorboat vs a closed motorboot needing higher clearance. This information can be recorded in the colour tag.
A route can have a single colour, e.g. colour=purple. If two-coloured symbol or sign is used, enter the two colours separated by a hyphen, e.g. colour=white-red. If the route (node2node section) can be followed using more than one separate colour, enter the colours or combinations as a semicolon-separated list, e.g. black;white-red;yellow.
Other regional routes also have the network=rXn key. The key network:type=node_network distinguishes the node network routes from other regional routes.
Route relation members
- Required: The chain of all ways making up the route between the two junction nodes, sorted, starting (conventionally) at the node with the lowest number. Most node network use single strand routes, the ways for both directions are exactly the same. Especially in cycling routes, the two directions may use different ways, indicated with forward/backward roles as described in detail here: Tag:route=bicycle#Members . In fact, these relations contain two routes which may share some ways. When combined with split nodes this requires some intricate tagging.
- Optional: The junction nodes themselves, the lowest numbered node first, the highest last. This provides a visual control when editing: the ref tag should contain the same nodes as the member list in the same order. Automated integrity checks do not need this information, because the nodes are already in the first and last ways.
(C) Network tagging
One relation for each (named) node network is created. This relation holds and describes all elements of the network.
|type||network||(Mandatory) Denotes that this relation is a collection of all junctions and routes making up the network.|
|network||rXn||(Mandatory) Denotes that this is a regional network for transport mode X. Currently (2020-11), nearly all node networks are considered to be regional.|
|name||name||(Mandatory) The name of the network. E.g. "Fietsroutenetwerk Zeeland".|
|network:type||node_network||(Mandatory) This defines the network as a node_network.|
|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 named node network.
- All routes (B) that make up this node network
Routes connecting to a node in another network get a role=connection role in both network relations.
If a junction node is in two networks, which can happen in border areas, it is added to both network relations with a role=connection role.
All nodes and routes with a role=connection role should therefore be members in two network relations
Split nodes: handle as separate nodes*
Sometimes two nodes close to each other have the same node number. The provider considers those to be one logical network node. Usually, but not always, the split nodes are within visual range of each other, for example, at both sides of a bridge.
In this case, as a rule* we simply treat the split node as separate nodes which happen to have the same number. The nodes are interconnected by a short node2node route which happens to connect two nodes with equal numbers. The routes land on the first node they "see". Routing, planning, rendering and checking applications can handle this, because the actual numbers do not make a difference in handling.
When there is no split node but two of the routes use the same road for a stretch, it is allowed that this common section is entered into both route relations.
Complicated junctions and roundabouts may even have three or more split nodes. The general rule for most routes* is: put a network node at the intersections where there is a choice. Then connect the nodes where necessary with short interconnection routes. You are allowed to use short interconnection routes with multiple nodes with the same number. In most cases, the logical split nodes will more or less coincide with the positions of the actual node posts. Then let each routes land on the first node it "sees".
- For routes with backward/forward roles to indicate where one direction uses different ways than the other, it's not that straigtforward. This happens mainly in bicycle routes, including bicycle node routes. See the Advanced section below.
(Advanced) Bicycle routes with split sections
Bicycle node routes often have split sections, where the low to high direction (Lo2Hi) uses different ways than the high to low (Hi2Lo) direction. All the ways (common, Lo2Hi and Hi2Lo) are entered into one relation. The common ways are entered without a role; the split ways for either Lo2Hi or Hi2Lo are entered with a role (forward or backward).
For the chain of ways, only the fact that there is a role counts.
The roles forward and backward are assigned wit respect to the drawing direction of the way in OSM. If you cycle in the same direction as the way, it's forward. If you cycle against the drawing direction, it's backward. That is why most of the roles will be forward both for both directions. https://wiki.openstreetmap.org/wiki/Forward_%26_backward,_left_%26_right explains the terms forward and backward for OSM.
NB. To see and do this properly, you need to use JOSM and its relation editor. It shows the Lo2Hi and Hi2Lo chains and the way directions in its continuity line. This description assumes you use the JOSM relation editor.
Basic Tagging Recap: Split in the middle, common ends; the route lands on single junction nodes at both ends
- Start at the low network node and add the common ways up to the split. Look at the continuity line to make sure the chain is unbroken.
- Then add the Lo2Hi ways with roles up to the rejoin point. Look at the continuity line: the arrows show the OSM way direction. If you go (Lo2Hi) against the way direction use backward; otherwise use forward.
- Then add the common ways towards the high network node. That completes the Lo2Hi ways. The continuity line shows where the branch begins and ends. It is continous, but the Lo2Hi-branch is shifted to the left and beside it, you see a dotted line representing the expected Hi2Lo-branch.
- Now start at the rejoin, imagine the ride, and add the Hi2Lo ways above. Keep in mind you are cycling from high to low now, so the ways are added above each other. Use forward if you are moving with the way, backward if you are moving against the way. The arrow shows way direction, and the continuity line should show a continuous branch line.
- When you reach the rejoin point, the continuity line closes.
- Done! In your mind, picture the branches next to each other. The editor can only show the ways as separate lines below each other, but the dotted continuity lines show where the other branch would be if they could be shown next to each other.
- Now, you can even sort the route. The sort will take the branches into account. This branch tagging is not specific to node network routes.
Split end; route landing on split node
- We now consider one end of the node2node route, landing at the high node on a highway junction with two node poles for one logic network node: one pole for each direction. The crossing highway is a simple road and has no difference between back and forth. This is quite common. Somewhere near the junction, the route splits. One direction lands on one node pole, the other direction starts from the other node pole. The other node2node routes are simple routes to both ends of the crossing road.
- Put two logical nodes at the intersections: HiA where the Lo2Hi lands, and HiB where the Hi2Lo starts
- Start the route at the low node and add the ways up to the split.
- Continue the Lo2Hi branch with proper roles up to the HiA landing node
- Now you have a choice:
- Method a: Closed loop method
- * Start at the HiA landing node, add the way(s) to the HiB return node, and continue to add the ways down to the split/rejoin point, with proper roles
- * Let the other routes land on the closest node from their "point of view".
- In the end, section HiA-HiB is part of all three the route relations.
- This method guarantees connectivity between all directions of all the routes, but it needs some redundant tagging.
- OR method b: Cluster method.
- * Start at the HiB return node, and add the ways down to the split/rejoin point, with proper roles.
- * Then create a short route from HiA to HiB (Cluster method)
- * Let the other node2node routes land/start at the first node they see.
- In the end, Section HiA-HiB is a completey separate route relation.
- This method guarantees connectivity by adding an extra relation.
Methods a (Closed loop method) and b (Cluster method) are equal for rendering and routing, and both pass all consistency checks.
Four routes with split direction branches landing on a roundabout with split nodes
- Complicated? Don't worry, it's easier than it looks, once you have mastered the branch tagging. Just pick one of the following methods, both will get you there!
- Closed loop method: closed loop route relations contain the roundabout sections
- First, enter all the network nodes at the intersections where a route lands or leaves.
- Then create one of the routes with branches for the directions as described above. Let one branch land on the first node it sees.
- Now let the return branch begin on this same node. Add the ways of the cycleway roundabout up to the appropriate leaving node.
- Finish the return branch up to the common ways of the route.
- Do the same with the other three routes.
- Every section of the roundabout is now a member of 3 or 4 route relations. This is alright.
- Cluster method: split end routes; the whole roundabout is a separate route relation.
- First, enter all the network nodes at the intersections where a route lands or leaves.
- Then create the cluster relation. This is a node2node route relation all around the roundabout, connecting all the nodes with the same node number.
- Then create one of the routes with branches for the directions. Let one branch end on the first node it sees.
- Now let the return branch start from the appropriate return node. Finish the return branch up to the common ways of the route.
- Do the same with the other three split routes.
- Every section of the roundabout is now a separate member of the cluster relation. This is alright.