Talk:Key:network:type

network:type=destination_network

In the German forum we were thinking about how to tag a network which is similar to a node network, but where the guideposts have names instead of numbers, like the Schwarzwaldverein network in the Black Forest, Germany. User streckenkundler came up with the tag 'network:type=destination_network' which sounds good to me. Are there any better ideas or votes against? --Doktorpixel14 (talk) 12:02, 19 July 2020 (UTC)

Is the only difference that the nodes have names? Does every node have a name? Do all nodes point to the adjacent nodes? Is every junction of the node network routes a named node? Can you describe long routes as a chain of node names? Are the node2node routes bidirectionally waymarked? If all is the same except that node names are used instead of node numbers, I think it;s simply a node_netowrk.--Peter Elderson (talk) 17:43, 19 July 2020 (UTC)

I've looked again at the example. There is no node name in the signpost, correct? It's a fingerpost with fingers pointing at the roads to use for near and far destinations, and for signed/waymarked routes with symbols. I have got to ask: why is this a network? Who or what will make use of the information? What should be rendered, (how) are navigators/routers supposed to handle it, (how) are planner routers supposed to hande this?

Maybe you just need to add the direction information to the guideposts, like suggested here: https://wiki.openstreetmap.org/wiki/DE:Tag:information%3Dguidepost

Talking about the Schwarzwaldverein network all your mentioned questions apply. Compare the guideposts Katzensteiner Hof with Hilsenberg for example, the closest directions at the top are always the next guidepost. A few mappers (including me) have already mapped some parts of the network which you can find on Waymarked Trails with yellow and blue diamonds. It really works exactly the same as node networks, but the consensus in the German forum was more that node networks have to be connected with node numbers and not names. That's why we thought about a different tag. --Doktorpixel14 (talk) 17:35, 21 July 2020 (UTC)

I see, I agree, thanks for the explanation and the examples. The symbol is the network, the middle shield gives the node name, and the number below that is the height above sea. The first destination on each finger is the next node, and you get the nodes after that for free including the distances. Or at least, the next node is one of the indicated destinations. Indeed, it is a regular node_network only with unique names instead of numbers.

What happens on waymarkedtrails if you just make it a regular node network by tagging all the nodes and route relations with network:type=node_network, just without the lwn_ref=* node numbers and with the node name in name=*? For testing, just leave the node2node routes without ref or name. There is aso no need for a network relation.

Knooppuntnet will probably show lots of "facts" but you can ignore that for now. In a few weeks a new version of Knooppuntnet will be released with a lot of improvements, and if necessary new developments will be accommodated. A node planner comes with the new release, it will handle the network without node refs, but the output (chain of node numbers) will be useless.... but a new output type is not a big deal. E.g. we have a variant node network which uses colours instead of numbers to point the hiker to the next node, so the colour was simply added to the output. Printing a name with every node is not that big a deal! It can be generic: if there is a name, its printed, if there is no name, not.

Nobody will stop you from adding another network:type, but I think a slight adaptation of the regular node network tagging is enough!

--Peter Elderson (talk) 19:37, 21 July 2020 (UTC)

Placed Github issue https://github.com/vmarc/knooppuntnet/issues/102 for Knooppuntnet (vmarc), for simply supporting names in rwn_ref. --Peter Elderson (talk) 10:45, 27 July 2020 (UTC)

vmarc has looked at the network. In principle, it's a node network. Names instead of numbers can be handled by the Planner at the display level, and by the Analyser at the validations level. But you wuld have to put the node network tags on the logical junction node, i.e. the intersection of the ways. A node network in OSM is a logical thing, not a physical thing. This does not conflict with the mapping of the guideposts as features of their own, at the exact location.

Is it an option to test this on say 5 of your junctions? I can do that without altering anything to the current objects and tagging, then show you the results.

--Peter Elderson (talk) 14:26, 27 July 2020 (UTC)

Yes, sure, go ahead. I contacted a few other mappers who already mapped parts of the SWV network and they're generally supporting network:type=node_network --Doktorpixel14 (talk) 19:34, 4 August 2020 (UTC)

I have created a small network with named nodes. See https://experimental.knooppuntnet.nl/en/map/hiking#4vnb9e-4mmg05-4mmfut-6w1soh where I planned a route over this network. Control-Click on a node or route wll take you to Knooppuntnet Analysis where you can see the details of the tagging. Waymarkedtrails also displays names instead of numbers: https://hiking.waymarkedtrails.org/#routelist?ids=11168677,11168687,11479534&map=15!48.6077!8.1559

--Peter Elderson (talk) 13:37, 12 August 2020 (UTC)

network:type=basic_network

There is an ongoing discussion in another german forum about the introduction of another network:type. In Germany there is evolving a bicycle guidance scheme which combines numbered node networks and connections between unnamed nodes. They also try to integrate existing theme routes, roundtrips, long distance routes into this signposting scheme. Basically it has quite similar features with named or numbered node networks, the aim is that you have normally bidirectional routes, between nodes there are only way markers with arrows but without any other information. The routes between two nodes can be part of some other route like between numbered nodes or named theme routes. But it is also possible that some routes are mainly practical connections between two places emphasizing on the needs of cyclists (e.g. relatively secure separation of the routes from motorized traffic).

These routes could be tagged with network:type=basic_network as User:JochenB is preparing to propose officially.

It would be nice to give renderers the possibility to show these routes without giving them special names, and maybe a special e.g. thin rendering. It could also be possible to mark the whole network this way and suppress the rendering of these routes if there are any overlying other routes. I started to use this tag in and around Bielefeld. With little exceptions e.g. waymarkedtrails and other cycle maps show parts of the expected effects.

In Bielefeld the result of this tagging is at the moment that the bicycle network is complete if you add the relations of the numbered node network and the basic network. Theme routes and long distance routes are lying over these two basic networks. Difficulties arise from the fact that the neighbouring districts just started to implement the system and have a lot of misleading and open ways. I hope theses problems will be solved in the next time.

--Segubi (talk) 23:16, 5 June 2021 (UTC)

I am not opposed to a new network:type, but I think the proposal should be presented, discussed and preferably approved before the new value is added to the wiki page!

At this point, it is not clear what this new network:type entails. What sets it apart from just routing along cycleways, what is the added value of organizing the cycleways into relations, how will this be used by cyclemaps and routers; is it just for cycling or does it apply to all recreational routes? Is it like a system of preferred cycleways, mainly defined by, say, quality requirements and special guide signs and aimed at a higher preference weight in routing software? Could the same be achieved by adding a tag to the preferred ways, without the added maintenance burden of route relations? Recreational routes often prefer smaller roads and unpaved roads, how can you guide these over a network of preferred routes?

A proposal could/should clear this up before introducing the tag, IMO.

--Peter Elderson (talk) 10:36, 7 June 2021 (UTC)

Thanks for your feedback. I agree. We are beginning to write the proposal but it will take a bit time, I am still very new to the background structures of osm. I chose to use this structure just because it is much easier to maintain the data, especially for others who want to contribute. There are a lot of misunderstandings concerning the guidance system described by the ministry of traffic, I use the new tag to make clear what kind of routes I mapped to avoid new confusions and mixing it with other routes which would be difficult to separate again in future. It was important for me not to lose the distinguishing information and I see no other easy to use possibilities. The entry here is a try to explain what I meant if someone looks up the tag. Surely not the usual way and not meant as a definite introduction, the network could be mapped in another way in the future. Hope I made that clear in the entry. I just add the link to my german and even there incomplete collection of features and signs of the guidance system (situation in North-Rhine-Westphalia, but quite similar in other federal states with sometimes other colours).

--Segubi (talk) 06:03, 8 June 2021 (UTC)

network:type=basic_network is in use

So I realised that network:type=basic_network is a mandatory and necessary addition to network:type=node_network here. It can be applied in the same way to other, non-node-based bicycle networks.

Personally, I consider network:type=basic_network to be in use regardless of the proposal status. I strongly recommend it for use in such networks!

--streckenkundler (talk) 21:44, 2 Sept 2023 (UTC)