[talk-ch] Changes to HikingNetwork wiki page
michael spreng (datendelphin)
mailinglist at osm.datendelphin.net
Sat Sep 4 13:24:45 CEST 2021
The effort on other hiking tagging was mentioned by Robert now over a
month ago, but unfortunately I didn't find time to read those
I think consensus has been reached for the names. And you are right,
documenting what has been previously done as an info box explanation is
a good idea.
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.
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.
With overlapping and non overlapping: It does not matter much for data
consumers, and both ways are acceptable, with mutual respect.
Documentation is under way, thanks to René.
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.
Relations are not categories. operator should be tagged on the routes
and/or guide posts.
I have never seen those numbers on guide posts, seems to be a cantonal
thing. A ref tag seems perfectly fine, as well as the usage in from/to
if there is no name.
Cantonal Data: I think the
https://wiki.openstreetmap.org/wiki/Switzerland/Datasources is currently
the best place to look which ones are available.
Have fun with the hiking route mapping
On 23.08.21 20:20, Matthijs Kooijman wrote:
> Hi all,
> I'm new to this list, so let me start with a small introduction: I'm a Dutch
> mapper, but I visit Switzerland every now and then (my brother lives in Rieden
> SG) and I like to do some hiking and mapping here. In the Netherlands, I've
> done some mapping on the cycle node networks, and in Switzerland I like to work
> on the wanderwegen network (though I have not mapped much, so treat my input
> I've been involved on the wiki page discussion section before, and from
> the wiki page history found a link to this thread, which I have read
> with much interest. Hopefully I can add something to the discussion in
> this thread.
> From reading this discussion, it seems that there are still some matters
> where no consensus has been reached (in particular the matter of
> overlapping or non-overlapping routes). But it also seems that there has
> been some discussion about this off-list. Maybe some consensus has been
> reached elsewhere?
> In case you have not seen it yet: there has been some effort (initiated by
> Peter Elderson AFAIU) to document current practices and rationale about node
> networks. This is mostly based on the numbered cycle/walking networks in NL/BE,
> but explicit effort has been made to also include named networks like Germany
> and Switzerland uses. AFAIU there has already been some experiments involving
> parts of the german network.
> The current state of this documentation can be found here:
> If this has not been done already, I would suggest considering to make the
> Swiss tagging scheme either conform to that page, or modify/generalize that
> page to also apply to the Swiss tagging.
> I just read through the page, and here's some notable observations from the
> current Swiss practice:
> - The primary goal of the model specified is to facilitate routing and
> rendering of node networks. For example, the knooppuntnet.nl website allows
> entering a starting and ending node, and calculates a route between them
> using only routes part of the network, and produces a list of node numbers
> to follow (support for names instead of numbers is nearly complete, I
> believe). For the Swiss case, this could work the same, but produce a list
> of named nodes/guideposts the route passes (so you could walk the route
> without bringing an actual map, just follow signs to each of the names in
> - That page specifies to tag the actual junctions (as part of the ways they
> connect), instead of (or in addition to) the physical guideposts (besides
> the way they connect), which is a significant difference from the current
> Swiss practice. I believe the goal is to simplify routing, since you can
> then know which named junctions you pass exactly, without needing to find
> guideposts based on nearness. It can also help with network consistency
> checks (especially when combined with the expected_STn_route_relations
> - That page also talks about junctions without a number or name, and specifies
> to create multiple partially overlapping routes in that case (and tagging
> the unnamed nodes with `xxn_ref=*`).
> Note that for the Dutch case, unnumbered junctions are very rare and almost
> always in the near vicinity of a numbered node, so in the Swiss case in
> regions that have more unnamed junctions, overlapping routes might have
> additional downsides (such as a potential explosion of possible routes when
> multiple unnamed guideposts exist between named routes, and the extra
> difficulty mapping partial routes).
> - That page specifies to use `name=from-to` for named node networks (numbered
> networks use `ref=from-to`), while discussion on this list was moving
> towards not using the name anymore. However, it might be that that page
> specifies this to match current practice and could be changed without
> - That page specifies a "network" relation (not strictly required, though),
> that collects all the routes and nodes belonging to a specific node network,
> to allow semantically grouping routes and specifying e.g. the operator once
> for the entire network. In the Swiss case, I think this could amount to one
> network relation for each Canton.
> - That page specifies a `network:type=node_network` attribute for nodes,
> routes and networks, to help distinguish them from regular routes.
> Some earlier discussion about supporting named node networks has been done here:
> Then, reading the wiki page in its current state, it seems to better reflect
> current and intended practice, which is good. However, I think there are still
> some things that could be clarified. In particular:
> - How to tag unnamed guideposts? Common practice seems to be to just omit
> name, maybe that should be explicit on the wiki?
> - How to handle numbered guideposts? For example in Graubünden (I walked in
> the area around Trin), I've seen guideposts (named and unnamed) that have a
> three-digit number that were already mapped with the number in the `ref`
> attribute, maybe that would be good to add to the wiki? For an example
> (with photo) see: https://www.openstreetmap.org/node/6100531211 Similarly, I
> understand that newer guideposts have a 6-digit unique number.
> - Would it make sense to put these guideposts numbers in the relations?
> Especially when using the "non-overlapping routes between junctions"
> approach, putting these numbers in the from and to attributes could help
> diagnose issues. OTOH, they are mostly meaningless to users, in the sense
> that the signing does not point *to* these numbers, you can only see them
> when you are at a particular guidepost.
> - How to tag from/to with unnamed guideposts? Should we invent names?
> Just omit the tag? I think no full consensus might have been reached
> - Maybe make explicit that name= was used with from-to before, since a
> lot of existing routes still have that. If it is explicit that this is no
> longer recommended, that will be less confusing for new mappers.
> - Is it ok to copy routes from the cantonal GIS systems? If not, or
> only from some, maybe make this explicit?
> talk-ch mailing list
> talk-ch at openstreetmap.ch
More information about the talk-ch