Proposal:Named nodes in node networks
| Named nodes in node networks | |
|---|---|
| Proposal status: | Draft (under way) |
| Proposed by: | Pelderson |
| Draft started: | 2020-08-15 |
Last updated: 2021-07-25
Proposal
Please look here for an introduction and tagging conventions for node network mapping.
This proposal establishes additional or adapted tagging for recreational node networks for cases where the junction nodes carry names instead of numbers or codes. The External discussions section references some discussions. The talk page contains argumentation for the preferred solution.
Two changes are proposed:
- **_name=<node name> to tag the node name on the network node;
- ref=mm-nn on the network route is no longer required. If present, it still should match the node numbers.
Rationale
Node networks, typically using numbered junctions for planning and routing along recreational routes, are common in Nederland, Belgium, and increasingly in other countries. A node network uses nearest-node based signposting instead of the usual destination-based signposting. In 2020 the fact emerged that in Switzerland, France, Austria and Germany node networks actually exist, though not by that name, where the nodes have names instead of numbers or codes. In such a network the nodes reference each other (by name), and in between the nodes (if necessary) one waymark symbol (a.k.a. trail blaze) is used for all the node2node routes, which makes it a node network system. The picture (named Node Hilsenberg) shows this: The network symbol is the yellow diamond; The node name and the network name are between the upper hands, and adjacent nodes are always the upper name on each hand. This particuar implementation offers a nice extra service: the hands also shows distances, and which choices are offered at the next node.
Testing and some pilots in different countries have shown that these networks can -in principle- be rendered as node networks and node network planner apps can route them, but there were a few issues.
No node number
There is no node number, but node numbers (**n_ref tags) are currently required.
The node numbers (nn) or codes (Ann) are considered to be refs in a reference scheme for the network, not names of nearby landmarks, as the named nodes often are. The name on a signpost is not a ref. It's closer to a bus stop name.
Solution
- Use **n_name=<node name> for the node name, where **n matches the network involved. When a **n_name=* tag is present, a **n_ref=* tag is not required. If both **n_ref and **n_name are present, it's up to the data user to handle this.
- e.g. For a regional walking node network: rwn_name=<node name> where <node_name> is the name found on the guidepost and referenced by adjacent guideposts.
Since node networks currently exist in 4 geographical scopes (l, r, n and i) and 6 transport types (c, w, h, i, m, p) this potentially introduces 24 new keys to match all the scope/transport combinations. However, currently only regional and local walking networks appear to use named nodes, and for the near future only rcn networks might go the same way; so for now we are looking at 3 new keys: lwn_name to match lwn_ref; rwn_name vs rwn_ref; possibly rcn_name vs rcn_ref.
This allows, but not requires, the **n_ref tag to be absent: If there is a **n_name, use that to determine network and node name; else use **n_ref to determine network and node ref.
Rendering can choose to render the name, e.g comparable to bus stop names.
Planner output can use ** n_name for e.g. node strip output, instead of the **n_ref. This tagging support networks mixing refs and names for the nodes.
No route ref
The route ref (mm-nn, Amm-Ann) was required and should match the node numbers, but there are no node numbers and names are not refs.
The composed route "name" (nodename1-nodename2) is not a name, ref or note, according to the wiki documentation. Because these are generic worldwide keys, stretching the definitions for this particular usage would create local exceptions.
Solution
- Make ref optional instead of required. The node information is available in the relation because the nodes are part of the ways in the relation.
- If there is a ref tag in the relation, it still should match the node numbers. When there are no node numbers, don't put a ref tag in the node2node route relation.
- Optional from=* and to=* tags can hold the start and end node names. This is not new; all routes can do this. In this case, the information is redundant, because the information is already in the start node of the first way ande the end node of the last way in the route relation.
- Optionally, the guidepost nodes with the names can be in the node2node relation. This is not new; all routes can do this.
- Optionally, use description= to record the start and end as a description for display. This is not new; all routes can do this. Again, the information is redundant.
QA-tools might report missing or empty ref, and check if guidepost names or from/to tags match the network node names, without raising red flags.
JOSM personal presets and styles may have to be adjusted.
No impact is expected on current rendering and other data use.
Signposts
The actual signposts are not the network nodes. Do we map the signpost itself, or the intersection, or both?
The network logic is for digital planning and routing, and doesn't need the actual signposts. The signposts are mappable features of themselves, whether or not a node network is present.
Solution
- For the network, map intersections (where ways of the routes meet) as node network nodes, e.g. rwn_name=<node name> & network:type=node_network. This is not a change!
- Optionally map guideposts as guideposts, e.g. tourism=information & information=guidepost & name=<guidepost name>. These have no function in the node network.
- Optionally, guideposts may be members with role guidepost. This is not new; all routes may have guidepost members. This has no function in the node network.
This way, rendering and routing can function and develop separately without interference.
Note that this is not a change, so there is no impact.
Examples
Full examples will be provided once rendering and tools have adjusted.
https://hiking.waymarkedtrails.org/#?map=16.11209514802745!43.521!1.4413 Shows a test model where o is used as a "null-ref". The guideposts near many of the nodes are rendered, producing nearly the desired rendering.
https://knooppuntnet.nl/nl/map/hiking#nhfqoc-2yj4gk9 Shows a node network planner routing over the nodes. Note that the planner currently does not show the names, but node network routing works fine. However, the result (left side) is not very helpful for the hiker.
Tagging
- Use **n_name=<node name> to hold the node name, where **n matches the network involved. e.g. For a regional walking node network: rwn_name=<node name> where <node_name> is the name found on the signpost and referenced by adjacent signposts.
Applies to
Nodes and routes in recreational node networks where node names are used instead of node numbers.
Rendering
Node names could be rendered comparable to bus stop names.
Node network planner output (e.g. node strip) will need to show the name to tell the user where to go.
Features/Pages affected
Please add if you know any!
External discussions
Starting comment: Talk:Key:network:type
Dutch forum: https://forum.openstreetmap.org/viewtopic.php?id=71393
German forum: https://forum.openstreetmap.org/viewtopic.php?pid=797930#p797930
Knooppuntnet github: https://github.com/vmarc/knooppuntnet/issues/102
Comments
Please comment on the discussion page.