Hi Michael,
Thanks for your answers! I'll respond to some below.
As mentioned, The Swiss network has no focus on nodes. It is planned as routes. Navigating with only a list of guidepost names will probably fail often, because that is not considered by the maintainers when destinations are chosen for each guidepost. Assembling navigation instructions as a list of intermediate destinations would need destination sign mapping.
Yeah, to allow fail-safe navigation instructions, you would indeed need destination sign mapping, but it seems also reasonably safe to assume that from each named guidepost, the closest named guideposts are always indicated, which means that a list of all named guideposts should always result in a navigatable list. Of course I'm unsure how much people would actually want to use the data in this way...
Putting the guidepost besides the way, between the correct ways, is a help for orientation, so that is probably why this won over putting the guide post on the intersection. I would question that it is necessary for building a router that those guide posts are on the intersection, and would not like to tag for a router.
Right, I think the idea is not to put the guideposts on the intersection (that would not reflect reality properly). Instead, the idea is to tag the junctions as (logical) nodes in a network, and optionally tag the guideposts *as well* in their actual positions (in the Dutch cycle system, the guideposts are usually omitted since there is little value, but for the Swiss system I think mapping them separately can be more valuable).
See also https://wiki.openstreetmap.org/wiki/Proposed_features/Named_nodes_in_node_ne...
You are then partially mapping for ther router, which I agree is something to be skeptical about. However, an additional benefit of this approach is that it is easier to also apply automated checking on the network, since you're not just mapping the route itself, but also the endpoints of these routes (which might introduce a little information duplication, but that allows detecting situations where a route got detached from its intended endpoint).
I feel no consensus has been reached for how to handle from/to for starting/ending on unnamed junctions. However, I think we can take a lot of liberty there, as the tags are intended specifically for the mapper, like the note tag. So if one uses the closest field name or the elevation of the guide post, it should work somehow. And maybe we will converge in the future on something that prove the most useful.
Under the assumption that from/to are really just for the mapper, I agree that there is a lot of liberty. Still, some consistency would be useful (i.e. to help interpret these tags, am I looking for a ref, elevation, name on a guidepost, or is the name invented, or something completely different?). I can imagine making this explicit, e.g. `from=ele 123` or `from=near Kirche Niederurnen`, things like that?
Also, is from/to really mapper-only territory? It seems that for regular routes, from/to is not strictly defined, but there is some ad-hoc usage of it: https://wiki.openstreetmap.org/wiki/Key:from Similary, the named node network proposal also mentions using them (without stating they are mapper-use only), see https://wiki.openstreetmap.org/wiki/Proposed_features/Named_nodes_in_node_ne...
I might be overthinking this, though...
Cantonal Data: I think the https://wiki.openstreetmap.org/wiki/Switzerland/Datasources is currently the best place to look which ones are available.
Ah, indeed. Might be good to link to that page from the hiking network page, then.
Gr.
Matthijs