Talk:Proposed features/Named nodes in node networks
Explanation of choices for proposal
The choices can be summarized as:
a. Change the system, or adapt as little as possible
This was an easy one: if possible, keep the system and make backwards compatible changes with as little impact as possible. So we're not changing to guidepost-based networking, but keep the intersection-based networking and add node-name tagging as an alternative to node-ref tagging.
b. Choose a tag for the node name
Candidates were: rwn:name and rwn_name (for regional walking networks) and their **n variants. Technically they are equivalent.
Pros and cons (rwn example)
- causes a warning in JOSM because it is seen as a variant name without the presence of a name=*.
- matches rwn_ref which looks more logical
- possibly requires retagging of 39 nodes in Nederland
- passes validation in JOSM without a warning
- looks like a name space
- does not match rwn_ref; rwn_ref next to rwn:name is not logical
The proposal prefers rwn_name (**n_name), because -
- The warning in JOSM is a temporary inconvenience which can be easily suppressed
- the existing named nodes are actually numbered nodes with an additional name, where the name is not used for networking. The proposal is about node names required for networking. Introducing rwn_name does not affect these nodes
- rwn:name looks like an rwn:* namespace, but rwn is a network containing different elements with names: nodes, routes (also non-node-network routes) and network relations. To do this right with namespacing, the tag should be e.g.
rwn:node:name=* ore even rwn:node_network:node:name=*
- To introduce namespacing-like tags here, you would expect rwn_ref (**_ref) to change to rwn:ref (**n:ref). That would affect tens of thousands of network nodes, and all applications using the **n_ref tag. We don't see that happening any time soon. So we would end up with rwn_ref + rwn:name, which looks illogical and will probably lead to mapper errors.
Node networks using numbered junctions for planning and routing along recreational routes are common in Nederland, Belgium, and increasingly in other countries. The node network uses nearest-node based signposting instead of the usual destination-based signposting. Recently 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. The nodes reference each other and in between the nodes one waymark symbol is used for all the node2node routes, which makes it a node network system. Preliminary testing has shown that these networks can -in principle- be rendered as node networks and node network planner apps can route them, but there are a few issues.
1. The node numbers (nn) or codes (Ann) are considered to be refs in a reference scheme, not names of nearby landmarks, as the named nodes often are. The name on a signpost is not a ref. It's comparable to a bus stop name. Options:
Because the r*n_ref=* tags are specifically created for network nodes, we could stretch the definitions to also allow junction node names. Or we could create r*n_name tags to hold the names, to be used when the r*n_ref is not known. This allow the r*n_ref tag to be absent: If there is an r*n_name, use that to determine network and node name; else use r*n_ref to determine network and node ref. Or we could simply use name=*. Note that the network node is not the signpost itself, which carries the name, but the intersection where the hiker/biker/rider/skater/... changes direction. Using name=* for a specific node in the node network means it can not carry a different name for another purpose or another network.
Currently the proposal leans toward r*n_name=<node name as found on the signpost>. Planner output can use r*n_ref for the node strip instead of the r*n_ref. This would support networks mixing refs and names for the nodes. It's simplest and the most unambiguous option.
One step toward better rendering
Comments: 2020-12-10 Suggestion to use r*n:name because r*n_name generates a warning in JOSM validator. It has some actual usage.
2. The route references (mm-nn, Amm-Ann) are considered to be refs in a reference scheme, not names or notes. 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 options:
Just do not tag route names or refs. The start and end nodes are part of the first and last ways, so the information is already there. Another option would be to use the from=* and to=* tags to hold the start and end node names. Or include the guidepost nodes with the names in the node2node relation. Note that as it stands, including nodes in relations can hinder sorting and validations. Or use description= to record the start and end as a description for display.
Currently, the proposal leans toward allowing routes without name or ref. QA-tools might report this fact without raising the red flag. The other options remain free for use.
It's the simplest and cleanest option.
3. The actual signposts are not the network nodes. Do we map the signpost itself, or the intersection, or both?
One option is to incorporate the guideposts in the route relation. The planner/router will have to search for the junction to be used for routing. Another option is to map the signposts as features exactly on the geographic location where they stand, with al the secondary tags deemed necessary, and add minimal node network tags to the intersection node for the network.
Currently, the proposal leans toward tagging both guideposts as information features for rendering, and network nodes with minimal tags for node network routing.
This way, rendering and routing can develop separately without interference. Note that e.g. the symbol would go on the routes, while the operator would go on the guideposts.
Please feel free to add to the issue list! For comments, questions and preference statements please use the talk page.
to be added
to be developed
Nodes and routes in recreational node networks.
Node names could be rendered comparable to bus stop names. On the other hand, if the named signposts are rendered nearby, maybe no specific rendering is needed! Just a dot or circle to mark the node near the rendered signpost will do. Node network planner output (e.g. node strip) will need to show the name, of course, to tell the user where to go.
to be determined later