Talk:Node Networks

I am trying to apply the conventions from this page to a network of walking paths around my city (Toulouse, France). Everything seems to match, except for one thing: the signs are not numbered but named, e.g. "Les Palanques". This breaks the convention for the "ref" tag in network relations. Any idea on how to extend the conventions to handle this case? StC (talk) 15:22, 6 December 2020 (UTC)

Do you have a suggestion? This issue has come up before and we have tried a temporary setup while looking for permanent solutions, but it did not really work.

The problem could be solved by extending the definitions for the tags we currently use, but the new tagging would then affect current maps and applications (Knooppuntnet, Waymarkedtrails, OsmAnd, the OSM-cycling layer) in an unacceptable way. --Peter Elderson (talk) 18:27, 6 December 2020 (UTC)

One thing that could work is to use short (max 3 characters) acronyms as rwn_ref, e.g. rwn_ref=Pal for Les Palanques, rwn_ref=Boi for Bois. When the network is not too large it will allow users too know what direction to choose at a node.

Then make the ref of the routes contain the names (or a short version of it), e.g. ref=Palanques-Bois. This will be displayed along the route on most renderings, but it will be seen as an error in the checking application Knooppuntnet. Which can be ignored, of course, until the validator can handle the situation. The Knooppuntnet validator expects ref=Pal-Boi in this example. If that is acceptable, fine.

The problem that you de not see the actual name when using acronyms, could be solved by separately mapping the actual signposts on their exact positions as guideposts with a tag name=<full name of the place>. You will see these on the maps as guideposts with names, next to the network node. Then visually the are together, while for node network planners the names are not used, only the rwn_ref. Applications could in theory be smart enough to add these signposts to the planner output (labels in the node strips, waypoints in the gpx output)

--Peter Elderson (talk) 18:56, 6 December 2020 (UTC)

I'm still too uncomfortable with the conceptual model used in OSM to be of much help, I fear. How is the rwn_ref used in renderers? is it important that it allows to relate nodes and relations in the network, and how is that used? Before seing your reply, I have found (through Google) your other wiki page in which you describe a proposal and I have implemented the same pattern as in your "Schloßberg Test". Seems to "work", ie it produces usable results in waymarkedtrails, but I don't know if it breaks anything (see relation 11986747). I'm not even clear on where to start reading to understand the underlying theory of OSM tags, actually. However, two remarks:

- asking mappers to create artificial acronyms may add some confusion, when so many already are very creative with the "ref" tag;

- I have found a few signposts with no name at all, either by design or because of wear and tear. However, it might be possible to deduce the name from the adjacent signs

Thanks for your explanations; I'm eager to hear about the next steps. StC (talk) 20:36, 6 December 2020 (UTC)

... and one additional point: I just found a document that describes another network nearby, in which sometimes there are several signposts with the same name. See https://www.toulouse-metropole.fr/documents/10180/532925/carte_laramee/dc811dce-02bc-49b4-9968-685eb79e1739 StC (talk) 20:59, 6 December 2020 (UTC)

Hi Peter

First of all a big compliment for setting up this page. As I will point out later there is some misunderstanding about these networks or probably better, differences of definition. (what is what and how do we call this) So lets start with the definition of a node_network.

Definition of a network

Nodes with or without option to change direction

The definition you use gives me the impression that the vast majority of the nodes in the network leave the user the option to chance direction. In other words the (mostly numbered) nodes connect different ways (that are also part of the network). Of coarse these are nodes but I would rather call these option_nodes. The reason for this is the fact that in OSM there are also networks that consist op nodes of which the vast majority does not leave the user an option. Just follow the nodes and as long as you can still see these nodes you’re fine. Just continue. These types can be found for paddling, mountainbiking, cycling and hiking. Being also from the Netherlands I can understand that these are not mentioned because most recreational networks in the Netherlands are the ones with options. Mainly hiking and cycling. This makes clear that an option_node is a node but not all nodes are option nodes. Or in Dutch… “een knooppunt is een punt maar niet ieder punt is een knooppunt”

If you want to exclude the non-option-networks from your definition I suggest you explicitly mention this and call the network type described here “option_node_network” and not just “node_network”.

A "Node" in this context is a labeled (usually numbered) junction node in a node network system where the route segments connect. Non-segmented routes do not have this kind of labeled junction nodes.

Other numbers may be present along a route, and there may be reasons to map those, but not every number is a node network junction. I will try to clarify this in the text.

--Peter Elderson (talk) 10:40, 24 December 2020 (UTC)

There are other non segmented networks that have numberd nodes. Like this one. Also see OSM. It is indeed good to make that distinction. (PeeWee32) (talk) 06:30, 27 December 2020 (UTC)

Pointers to adjacent nodes

Your definition says : “On the road, every node is marked with its number, and it has pointers to adjacent nodes in different directions. ” In the Netherlands this is valid for most (if not all) hiking/cycling (not MTB) networks. We do however also have option_node_networks that have no pointers at all like the networks for horses. This would exclude these from your definition but I have the impression this is not what you had in mind.

Networks develop relatively fast: https://riding.waymarkedtrails.org/#?map=13.946758420372268!52.0337!5.4422 and similar all over Nederland) paints a different picture.

Funny you refer to this network because… guess who entered this in OSM. That’s right,.. it was me. ;) My point here is that you added “network:type=node_network” to his relation but according to the definition here it does not qualify so. Reason: it does not have pointers (with or without reference) to adjacent nodes. So there is a contradiction right now. I also consider this a node_network so I guess a change in definition is appropriate.(PeeWee32) (talk) 06:30, 27 December 2020 (UTC)

How does the rider know which way to go at the nodes where 3 routes meet? --Peter Elderson (talk) 08:01, 27 December 2020 (UTC)

Waymarked in between nodes

The option_node_networks for horses are not (all) waymarked in between nodes. This would exclude these from your definition but I have the impression this is not what you had in mind.

I have observed numbered junctions and intermediate general "horse path" signs. The horse path signs lead the way. Usually they are not arrows or pointers, but placed strategically on the way you need to take. I have not paid much attention to how the choices are marked at the numbered network junction nodes, but the different directions must be visible somehow.

So as you can see there are differences in type of node_networks

1. With or without option (to change direction)
2. With or without pointers
3. With or without direction indicators in between nodes.

All these differences can be tagged on the route relation with separate key/values so users know what type of node_network it is. It is up to those who thinks this is important/relevant to come up with a proposal for this.

The first simply is not a node network as defined by the powers that be.

The second: If there is a choice, the different routes must be indicated somehow. It does not have to be literally a pointer on the same post as the node number.

The third: if there is no direction change between the nodes (one path, one way), pointers are not needed, so no, that is not an absolute requirement for each and every node2node section. Some node networks place a network node on every crossing, so you will not find intermediate pinters there. In general, however, most node2node routes will have pointers to the next network node (and, looking back, to the previous node).

There are endless variations in style and topology on the road. That's why I have stated the basics: labeled network nodes referencing adjacent nodes. Next-node based signposting as opposed to destination based signposting. Waymarking in between the network nodes does not require the node numbers (though it may show them as an extra service).

But my point is.. all horses node networks I entered in OSM do not have pointers referencing the next node(numbers). At the junction (or in between) there are no pointers with reference numbers so if you are at say junction 10 there is no sign indication which way to go to either 11 or 12. Of coarse it is obvious which direction your options are based on the fysical appearance of the highway. (bridleway). But if a rider has a paper note with the sequence of the numbers to follow he’ll be lost at the first node because of lack of appropriate signage. A paper map with the network on it will do the job though. (PeeWee32) (talk) 06:30, 27 December 2020 (UTC)

In that case I would say it is by design a node network, but the forgot to add one necessary detail: to show the nearby destinations at the choice points. I would still call that a variation. There is another variation where the next node is nod pointed to, so without a gpx or map you can't see how to get to the adjacent nodes. Instead, numerous coloured arrows are present, but without a map showing the coloured roundtrips or a gpx or other external information which colour goes to which node, you can't choose. I think the operators missed the whole point of the node networks: directions to labeled near-junctions! If no directions are given at choice points, the signage is near useless. And I know the kind of post they use. It would not be hard to add numbers to every direction at choice points. The paths you can take are clear from the position of the posts; on average two number shield per network node are needed. Given the materials, I could do it in a couple of days. A signage firm would need more prepatation but deploy much quicker, using a vehicle and two employees who know their stuff. --Peter Elderson (talk) 08:21, 27 December 2020 (UTC)

Nodes as Orientation

Nodes in all networks (option or not) are also relevant for determining your location. Without this a horse rider can easily get lost in the middle of a forest. Or a person in a canoe is also helped. Or a mountainbiker that has had an accident can use the node for location purposes. So as far as I am concerned all nodes within a network should be mapped regardless of their exact function. In practice I think most of them are l*n_ref of r*n_ref.

Emergency access and determining location for other purposes is not the goal of a route network. If you are on the route you are not lost; if you are lost, the route references won't help very much.

--Peter Elderson (talk) 10:39, 24 December 2020 (UTC)

How does someone know that he is on the route? Right.. if there are signs. If you do not see signs for a long time chances are that you missed a reference and you are off the route. When you see a numbered node you are sure you are on the route. But it might still be that you do not know which way to go. Let me explain. In my area there are node_networks for horse riders that only have numbered nodes. No direction indicators at or in between the nodes. Riders have a paper map of the network with them. When the see the number they know exactly where they are and can determine which direction to follow to reach their destination. Here is an example of such a map. I know first-hand this map is sent every year to those who pay for their licence and this is invaluable for first time riders. (PeeWee32) (talk) 06:30, 27 December 2020 (UTC)

I hope all of this helps to improve this wiki and again… well done for making this wiki

Cheers PeeWee32 (Peter)(talk) 21:59, 23 December 2020 (UTC)

KISS: keep it simple

At least in France, nodes are already mapped as guideposts.

Guideposts are mapped as objects, features of themselves. Not all the guideposts for all the geographical scopes and transport methods have been mapped. Network Nodes are logical connection points in a Node network. They may or may not have an associated guidepost mapped. The network system has therefore been designed to function independant of the mapping of the objects.

Also, guideposts are generally not a node of the highway. You don't change such an OSM approved way of mapping for a niche. So you will need another way to assign the physical post to the route relations. We have chosen to tag the relevant intersection as the network Node, which makes it easy on the software. You could use proximity search, but that is not 100% guaranteed (which distance?) so not preferred. We preferred (actually, I was not around then, but I fully agree) assignment over guessing. You could enter the guideposts as nodes, but then you are obliged to map all the guideposts and enter them in all the relations, and still the network Nodes would not actually guarantee contuinuity. So the method with the logical nodes actually connecting the ways of the route relations was chosen. The logical nodes don't need to be members of the relations, because as part of the highways they already are in the routes. The connection to the actual physical post is given by the specific ref for the node network. So the only tags needed are the **n_ref (or _name) and network_type=node_network. The guideposts need not even be mapped at all. This is generic, it works everywhere in the same way, so that you can connect node networks around the globe, and maintenance tools and planners (currently only one available, but who needs more?) work globally.

Of course you can devise a different system for a specific case, e.g. where all the guideposts have been mapped as objects, no problem.

For me, "nodes" are a duplication of guideposts.
ref_nwn=* is a duplication of ref=* (and also not "supported" by editors and OSM website).
Same issue with ref_name=*.

What kind of support is it you need? OsmAnd and WMT render node networks, showing **n_ref. OSM has a cycle map supporting cycle node networks, including rcn_ref. If needed, you can create issues to ask for other support. The major tool is of course Knooppuntnet, offering global node network planning of all node networks, analysis and maintenance, interfacing with Id and JOSM. It's on github and accepts requests.

In what I observed in Savoie (France):

• nodes are members of the relation node network itself plus members of the routes with a node and adjacent nodes.
• routes are also members of the node network.

Both are not required! It's the maintainers who want to enter more details than necessary. That creates more redundancy than putting the node number or node name on the node!

So this is a bit redundant: the node don't need to be member of the node network.

Also, the name of the node itselft is a duplication of the name of the guidepost.

True. This facilitates easy production of planner output. For the trip planning process, names or numbers are not needed at all, but in the end the user needs to have node labels in the itinerary. Since it's in the tag, it's easily available with hardly any processing.

In mountain the altitude is important, but this information is not available on nodes.

Excellent one for a github request! I don't know if this needs a tag on the node, I think vmarc can give advice about that.

The guideposts are members of the node network, but there is no link between a "node" and the guidepost.

The link is the node number or name. But the node system works without the guidepost.

So I suggest to "merge" nodes and guideposts, more precisely , I suggest to use the guideposts as nodes.

The nodes are the actual connections of the ways in the routes, which guarantees that a trip over the node network is a contiguous string of ways without gaps. This also works when there is no guidepost mapped at all, which is currently the situation in the vast majority of node networks.

--Peter Elderson (talk) 16:28, 10 August 2021 (UTC)

--Pyrog (talk) 09:41, 10 August 2021 (UTC)

KISS: use also standard tags

Note: in december 2021, all node networks in France were standized/simplified. That represent more than 4200 km of routes.

In France most "Nodes" have a unique name (even if the walking guidepost/node is shared with MTB, riding…).
So we would simply use name=* or ref=* instead of the complicated lwn_name=*, lcn_name=*….

Also, JOSM and iD display name=* or ref=* in relation member list, not xxn_name=*…

So I suggest to support these tags in places where network are simples (the majority at least in France), an still continue using i.e. lcn_ref=* + lwn_ref=* in Belgium, Netherlands where different networks are intertwined.

--Pyrog (talk) 11:32, 3 December 2021 (UTC)

1. The **n_ part of the key tells the data user which network it is: transport and geographical scope.

2. French standardization for hiking and cycling networks does not apply 1:1 to the rest of the world, and not to all Node networks. The current model for Node network tagging is designed to be as generic as possible, for all transport methods and all geographic scopes in all countries, in a way that all networks with equal **n_ can be connected and used in the same way.

So, while I understand that just name or ref would be simpler when mapping common Nodes for French cycling and hiking networks, it would be much more complicated for data users to select and compute what to render and what to use for a network-specific Node network planner.

If you can model the idea in a way that works for networks of all transport modes and all geographic scopes in all countries AND also keeps the support for the current tagging it would be great.

--Peter Elderson (talk) 12:56, 3 December 2021 (UTC)

1. I understand that ;)

2. I appreciate the generic tagging :)

I don't propose a universal french scheme :D Just some flexibility in the current model.

Does the only alternative is to reinvent the wheel with the basic network?

So to be clear, I don't want to remove **n_ prefix that are necessary when i.e. cycle and walking network share some Nodes, but theses Nodes are named/referenced differently in each network.

I asked to support also standard tags name and ref when i.e. cycle or walking networks are completely separated, or when different networks share the same Nodes with the same label.

To display the appropriate label, the algorithm is simpler (I could detail it if needed).

One could also use walking/riding/… tiles generated by knnooppuntnet that store the appropriate label.

--Pyrog (talk) 17:24, 3 December 2021 (UTC)

I strictly discourage using a simple "ref". Think of waymarkedtrails, which provides different views for hiking, cycling, skiing, etc. Every view should only show the appropriate nodes, e.g. "hiking" shows rwn_ref=* and does not bother you with cycling or skiing nodes. And even more, the different sports might use different namespaces, e.g. "461" for hiking and cycling might match "G51" for skiing. --GerdHH (talk) 15:20, 17 March 2022 (UTC)

KISS: allow anonym Nodes

"Old" networks in France have guideposts without name.
"New" networks haven't been published in open data so this is difficult to know the guideposts names.
(Even on the field, because sometime guidepost were vandalized and the name plate is missing).

See What is really the difference between a node and a basic network ?

--Pyrog (talk) 11:42, 3 December 2021 (UTC)

Unclarity in about join/split away from nodes

Under "Tagging Principles" it says:

11. sometimes Node2Node routes join/separate some distance from the actual Node. The way(s) between the split/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/split point is not at the Node junction.

I do not quite understand what the last sentence means. The first sentence says that sometimes two routes from a node overlap some distance, and the split point is therefore not on the node but a bit further. But then the last sentence says that in only some of these cases the join/split point is not at the node? Or is the last sentence just referring to some of *all* cases (instead of some of the previously described cases) and is that sentence just redundant? Also, I'm not sure how visual distance is relevant here?

--Matthijskooijman (talk) 16:15, 23 August 2021 (UTC)

Sorry for the delayed response. The thought was: if the user sees the actual Node, (s)he will associate the split point with the labeled network Node. Then a simple short overlap of the 2 routes is fine. If it's outside visual range, it's less obvious that the split point actually is sort of an assistant of the actual Node. This is where the mapper can use '*' as a node ref. I'l try to clarify the text. --Peter Elderson (talk) 11:45, 3 December 2021 (UTC)

On the field (at least in France), I see 2 cases:

• Split location with Node: routes don't overlap.

• Split location without node: routes overlap.

--Pyrog (talk) 10:14, 3 December 2021 (UTC)

Thanks for the diagrams. Reality always knows how to escape the model! The first diagram is a regular Node junction. For rendering and planning applications, it doesn't matter what label the network Nodes carry; maybe different or maybe the same as the neighboring network Nodes. The second diagram shows the split Node issue. If there is no labeled Node at the T-junction, and the traveler can not see the adjacent nodes, (s)he can't know how to proceed. So there should be a post or signs to indicate directions to the adjacent labeled Nodes. That's when you can use the '*' Node mapping. This *-node is no end point, but it appears as a middle point in the Node2Node routes passing there. --Peter Elderson (talk) 11:45, 3 December 2021 (UTC)

Applying this tagging scheme to Swiss Wanderwege

I've previously pointed out the Swiss (and similarly German) wanderwege networks with named nodes, and this proposal seems to facilitate such networks as well. Recently, there has been some discussion on the talk-ch mailing list about updating the policy for the Swiss Wanderwege, which might be interesting. By now, discussion seems to have died down again, but I just sent a followup to (among other things) point out this wikipage to the Swiss mappers, suggesting they consider adopting (parts of) it.

My followup can be found here, earlier discussion here (june) and here (july).

Maybe people watching here have additional insights or suggestions to share in that discussion?

--Matthijskooijman (talk) 23:35, 23 August 2021 (UTC)

I think the Swiss network could easily be modeled as a Named_Node network, enabling the use of Knooppuntnet Planner or comparable. The route relations are all there. There is a fair amount of Node tagging work involved though.

For rendering, the Swiss network is fine as it is. If they want more end user functionality such as trip planning, routing and navigating, then it's up to them to weigh the work against the added value. Of course, a working model helps, so they could take a look at the growing French and German hiking Node networks. But these are not fully grown yet.

Or, they could set up a pilot network to see how it works out for them. If it doesn't work, for whatever reason, they can simply delete the tags afterwards.

I am always ready to help set it up, and to ask vmarc for support in Knooppuntnet.

--Peter Elderson (talk) 13:15, 3 December 2021 (UTC)

Skiing

In Norway in some regions (e.g. Golsfjellet/Viken) we use node point networks also for skiing. The appropriate references (lsn_ref=*, rsn_ref=*) should be added to the scheme (cf. Node network proposal). --GerdHH (talk) 15:04, 17 March 2022 (UTC)