Salut Micheal

What are the inconsistencies you intend to address?

Regarding the network structure, the current Wiki entry seems quite specific: 

> The hiking nodes are labeled guideposts. Each of them contains a small > white signboard with the name of the place (usually open fields names) > and the elevation over mean sea level. They should be tagged as 

> described on tag:information=guidepost.

If I understand you want to change that nodes should be every guidepost instead of only labeled guideposts. What is the reason for this? Which problem should this solve?

I see some issues with using every guidepost as a node:

1. The hiking network is not constant and evolves all the time. E.g. in 2016, the hiking network in Schaffhausen had substantial changes [1]. At the same time, OSM edits can break relations. This happens also regularly. Having metadata about nodes and relations is extremely helpful to see how things connect. The guidepost labels are in most cases sufficient to tell them apart. Having the guidepost labels encoded in the relations identifies them and helps to error check. Thinking further, this would also allow having some validation algorithms to check for consistency. 
2. There are 1000s of already existing hiking relations created in the last years.
3. There are a lot of different guideposts, that are sometimes mapped and sometimes not. Which guideposts should be nodes would not be well defined.
4. There is no harm if a way is part of multiple lwn relations.

It is also important to be aware that the hiking network is/was not planned by computer scientists or using a GIS. Also, the way hiking routes are signaled differs between each canton. There will always be cases where something will not fit into a chosen abstraction. E.g. routes that are only signed in one direction, routes that are signed differently depending on the direction, etc. 

To the list of issues with the Wiki page I would add the following points:

• There are many variations for the symbol tag. The german variants are also used in the non-german-speaking regions. Having a preferred symbol for each route type and language could clarify this. Also, would it be better to use symbol:de, symbol:fr...? Or is it needed at all as a symbol for each language can be derived from osmc:symbol?
• Are routes with a number always rwn or nwn? There seem to be routes with 1, 2 or 3 digits.
• How should "white" routes be mapped. These are normally local "walking" routes of municipalities. 
• There seem to be no guides on how to map wheelchair routes (Or I did not yet spot them)
• It looks as at least some hiking organisations / cantons use routes to plan their hiking network. Some users started to map them as superroutes. An example of such a route is [2]. My view on this is that this mapping is hard to achieve without access to the official GIS
• It looks as some mappers use "online" resources to map, e.g. cantonal GIS. It would be good to have a vetted list of such GIS that can be used. 
• How should incomplete routes be mapped. E.g. routes starting at a visited endpoint and ending somewhere unknown. I currently map them as start=<label of guidepost> to=All names of the sign with a question mark added (e.g. to=Name1? / Name2? / etc) and a fixme=continue to next named guidepost.

Regarding names of relations, I guess this is also something related to iD. If hiking relations have no name, all hiking routes are just named "Hiking Route", which makes it painful to select the right one when mapping. RapiD uses the from/to tags, thus this will maybe trickle down to iD in the future. 

lg rene

[1] https://www.shn.ch/region/kanton/2016-12-12/es-gibt-neue-wanderwege  

[2] https://www.openstreetmap.org/relation/12045190