Talk:Node Networks

From OpenStreetMap Wiki
Jump to navigation Jump to search

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 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:!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)