Proposal talk: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)

rwn_name -

• 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

rwn:name -

• 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.

--Peter Elderson (talk) 10:47, 20 December 2020 (UTC)

History

Rationale

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.

Examples

to be added

Tagging

to be developed

Applies to

Nodes and routes in recreational node networks.

Rendering

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.

Features/Pages affected

to be determined later

Comments

I like the idea of keeping name and ref apart. --RobHubi (talk) 21:08, 4 February 2021 (UTC)

Point to Point or from, via, to

Thanks for the proposal. I did not understand how the start and end node is exactly determined. Is it like the bike node system that these names are on the guidepostes and only the next node for each direction is on the sign? Or is it more like you have a route from village to village with some named places in between also signed? For the second version, I think node network is an misinterpretable name and I'd prefer to use different tags if the two systems are not identical in their structure. --Skyper (talk) 13:43, 13 April 2021 (UTC)

The basic node network system consists of nodes connecting node2node routes. Each node points to one or more adjacent nodes, and alle adjacent nodes point back to this one. In between the nodes a single symbol suffices for the whole network, because the user is always on the way from one node to the next, where (s)he chooses the next node to go to. Die gelbe Raute habe ich oft gesehen, oder ein Schild mit einem Fahrradsymbol.

The user has to use a planner or planning map to plot the route for a trip over the network. The planner app links the connection routes to a chain. The planner app has no need for labels on the nodes or the connections. It's the user who needs labels in the result output, so that (s)he can find the right direction at a choice point, i.e. a network node. The form of the label does not make a difference, it's just a label. Numbers a very common, codes (T04, W56) are used in many areas, I have seen mnemonics used, I have even seen fairy tale figures (figurines for the nodes, drawings for the arrow shields). The result is a list of node labels to follow on the road, as opposed to a series of turn-by-turn directions or end goal based directions ("Follow Berlin until you see Moskou, then follow that up to Minsk....").

There is an awful lot of variation in implementation of signing on the road. I like the German/French/Swiss/Austrian habit of pointing to the next node and adding the next choice in advance, with Km or hours walking. I like named nodes because it is more informative (more touristically attractive) for the user. "Church - Bridge - Wood - Mountain peek - Gold Mine - Holy Grail" sounds more like a trip than "01 - 34 - 54 - 99 - 20 - 61", even if it gives exactly the same route, and both rely on node labels, pointers to adjacent nodes and simple intermediate signing of the node2node connection routes.

I don't know if this helps? --Peter Elderson (talk) 15:29, 13 April 2021 (UTC)

Sorry, I did not point to the discussion in the forum. Do not know if you understand German, though.

Yes, we are talking exactly about the "yellow diagrams" (gelbe Raute) and the mostly green bicycle symbols. These are general symbols for the basic network. Unlike the "real" numbered node to node (bicycle) system, here we often have more than one destination per direction and some of the destinations are intermediate places or junctions in between to the further distanced destination. Here rises the question if the numbered node system and this kind of named node system are 100% comparable or if the later is more a named destination node system with a distanced major destination and some other "via" destinations in between. Maybe, we should use a different network:type=* like destination_network but some used this already for destination name systems with unnamed guidepostes.

For the destination name systems without named or referenced guidepostes we are currently discussion about using network:type=basic_network or even only tags, like lcn=yes or similar, on the ways without any relations. --Skyper (talk) 14:37, 15 April 2021 (UTC)

I understand. I had the same questions and reservations. But no matter the other things, the uniform waymarks between nodes, the reciprocity of references to adjacent nodes and the individual labeling of the nodes make it possible to use the system as a node network system as developed initially using only numbers. You can analyse, maintain and use it for planning with the same tools, they just need to work with name labels instead of number labels. It's fine if the German community decides not to want that or -more interestingly- to achieve it in another way, but I feel you would miss out on the benefits of this existing system, in particular the node planner and the network integrity check system in Knooppuntnet.

The implementations (variations) of the node network system are still developing rapidly, and we adapt the definitions and tools to accommodate every variant we encounter, as long as the above mentioned basic principles apply. In particular integration of the node (planning) system with long distance paths, local loops (usually colour based) and regular destination based guidepost systems is definitely a trend. We also have boating networks where 3 different overlapping node networks are layed out using the same set of labeled nodes, just with different selections according to boat type (represented by node shields in three different colours) . We even have horse networks with numbered nodes and a common symbol between all the nodes, but lacking the pointers to adjacent nodes - which is strange, but it works fine for checking and planning routes and and result lists/maps/gpx-tracks, but the user has to mark the direction choices on paper or see the route itself when (s)he is out there. Happily the operator plans to add arrows and numbers after receiving a lot of comments.

We have another variant lacking pointers to adjacent nodes. At numbered nodes, you cannot choose another number to go to, but the directions have colours so you have to choose the colour to follow. We have adapted to that by adding the colour (or colours) to the connecting routes, and adding that to the output of the Knooppuntnet Planner. So you get a list of numbers, and all or some of them may list colours between the numbers, or codes in this case. As if to say "From X25 follow yellow to T40, then red-white to S03...

For nodes with names (we have a few in one area in Nederland, but it is not common) the adaptations are: On the map, display node names instead of node numbers or codes. On the routes, don't display a route name OR use <start node name> - <end node name>. My preference would be don't display route names, because you can see them already at the nodes. In the result list, use whatever label(s) the node has: name, number/code, or even both. For the planning function, it makes no difference: the Planner does not require the node labels nor the route refs or names. Just junction nodes interconnected by route relations. --Peter Elderson (talk) 15:35, 15 April 2021 (UTC)

Is It is also about calling the whole "node network" if the nodes have numbers. The motivation is to avoid confusion.

"Node network" is (only in germany?) a technical term to distinguish the sign-posting of node numbers of the sign-posting for places. It would be nice if we use the technical terms as used within OSM as they are used outside OSM.

We only need to find a suitable term for network:type, e. q. network:type=named_node_network?

Since otherwise almost everything is the same, it should not be great effort to process these networks with the great tool, right?

I was happy if such networks find a suitable representation in the tools.

(Sorry for errors in the text, which is only Google translated) --Jo (talk) 20:30, 15 April 2021 (UTC)

The system is called node network, because it has nodes interconnected by linear sections, like an (irregular) fishing net: where the strings cross there is a node. The format of the labels/shields is styling; technically it makes no difference for the network system. I think equating node with number is not useful. The node network system works exactly the same, whether you label the nodes with numbers, codes or names, or a mix. A network with numbered nodes can interconnect with coded nodes or named nodes.

If in Germany peaople assume that only numbered nodes can form a node network system, I think that might cause some confusion. I think it's not enough reason for a separate network:type, because the named node network is essentially the same, just with words instead of numbers or codes.

The numbers have the advantage of being short. The names have the advantage of carrying meaning. Memonics as node labels are somewhere in between. The codes in Nederland sometimes are just codes, while other operators give subregions a letter and make sure numbers are not reused within a subregion, so they can use the code as a true Id within their territory. The tagging and mapping is designed to be generic, i.e. indifferent to such operator specific implementation styles, so we can keep interconnecting the node networks.

--Peter Elderson (talk) 12:56, 21 April 2021 (UTC)

I also see that, from a technical or mathematical point of view, both systems are very similar.

And from the point of view of the user, it is certainly a difference to note / remembering a sequence of numbers or to read a sequence of longer names and then reading them on the way, especially at a faster ride (two digits instead of e.g. ten letters per node). Node networks are often combined with target signposts to balance the disadvantage of the meaningless numbers.

The idea of using short numbers instead of long names has called a "node network". The term is not only used in tourism experts, but also in the marketing of number networks. The node numbers are highlighted as the most important property of the node networks.

Yes, that's certainly not a good idea to define the number network exclusively with this term. In addition, the term "node network" is not self-explanatory, because every network has nodes. I would have taken another term.

But we cannot change that anymore. In the tourist professional world, this term is occupied, I suspect, not only in Germany (for example here). I would find it good if we use the term as it is used there and not for the opposite.

(hopefully Google did not disfigure my text) --Jo (talk) 20:52, 21 April 2021 (UTC)

Sorry to disagree on this issue! The node network system was in use and was further developed long before German tourism chose to equate numbers with nodes. We should not adapt the generic system to what tourism in one country thinks should be the 'selling point' in marketing. I am glad they picked it up, and in time they will recognize that there are variants of the same system using other labels. I think it is far more important to keep the system in OSM generic and, e.g. link networks with all kinds of labels (numbers, codes, names) interchangeably so that users can plan a bike ride over all linked node networks, independent of region, country, and types of shields and node labels.

E.g. an issue is that in France and Germany mappers tend to use l*n and l*n_ref and l*n_name for the networks, while Nederland and Belgiume use (for historical reasons) r*n, r*n_ref and r*n_name. Knooppuntnet now does not link these two scopes. We are now thinking to drop the scope altogether. The routes and nodes are mostly local, while the networks range from local to national. Because of the backlog in the OSM database, and because there are diffent preferences, we do not want to prescribe a particular scope; instead we want to integrate the different scopes at the data use level. Waymarkedtrails already ignores the scope and has one rendering for all node network connection routes. This would make the system more generic and linkable, so users can eventually plan a node network routes anywhere, using the same tools. Very, very OSM!

The node network system in OSM could also support multi-mode planning, e.g. a trip involving canoe and horse sections over two existing types of node network. It would involve connecting canoe nodes to horse nodes. Because such connections are not signed "in the field", it would involve a proximity detection, or a free routing function in the trips, which are available techniques, but a challenge to implement in the planner. Just mentioning it to illustrate my thinking!

--Peter Elderson (talk) 07:12, 23 April 2021 (UTC)

Thanks for this proposal! It should work very well for the Swiss hiking network (with lwn_name on the nodes) and it would be great for quality control if this is then supported by Knooppuntnet.

I don't see any need to use a different network:type value, it's much better to have a generic system. That nodes are named, not numbered is obvious from using **n_name instead of **n_ref, otherwise the key features are the same (nodes have identifiers and indicate directions to the next nodes). --Eginhard (talk) 13:08, 30 April 2021 (UTC)

Network-specific name?

Is it possible to use standard junction=yes + name=* instead? If the name may not be only used for the network users themselves (ie can be used widely by the public), and no conflicts exist with any other junction name. ---- Kovposch (talk) 12:19, 23 April 2021 (UTC)

Interesting question...

I think junction=yes name=* declares that the junction (the node representing the area shared by the roads) itself has a name, as found on a name sign. If that is the case, and the name on the guidepost for the walking or cycling network is the same, you could combine it. But to serve as a naming principle for network routing nodes, every network node should have a junction name, and the name of the junction should always be the one on the guidepost. Also, the network node should in fact be a junction, where network nodes may have only 1 or 2 routes landing on it.

In wooded or other natural areas where the ways are all paths and the junction is always a path junction, you probably can say safely that the name on the guidepost is the junction name. But if a junction gets more complicated and serves multiple transports, has multiple guideposts for different transports and networks, I don't think you can equate the name shield on the guidepost for a particular transport to the entire junction. And I think you will find nodes named after e.g. buildings or mountain peaks, at junctions with no name or a different name. The "French Bunch" near Toulouse certainly has lots of those.

I think it is best to stick to a dedicated name for a particular network. If it coïncides with a general junction name, and/or other networks using the same junction as a node, no problem; if it does not, also no problem.

Also, remember that the idea is to interconnect the node networks, whether they use numbers, codes or names as labels for the nodes. A named node walking network in Germany should link seamlessly to a coded node walking network in Nederland and a numbered node network in Belgium. The apps using it should be able to recognize an OSM node as a node network node, and determine the type and scope of the network and the label of the node within that network, even of multiple other networks use the same node. That is now only possible because of the **n_ref or **n_name tag. The network tag is not used for node network nodes, because one node has only one network tag, and semicolon separated value lists are generally considered a problem, compared to separate tags. If you switch to only name, this network specificity is lost and you need to find another way to distinguish networks. Using **n_name, modeled after **n_ref, you keep the system as generic and versatile as it is now, without much ado.

--Peter Elderson (talk) 13:29, 23 April 2021 (UTC)