[talk-ch] Changes to HikingNetwork wiki page

Matthijs Kooijman matthijs at stdin.nl
Sun Sep 5 11:01:06 CEST 2021

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

See also https://wiki.openstreetmap.org/wiki/Proposed_features/Named_nodes_in_node_networks#Signposts

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_networks#No_route_ref

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstreetmap.ch/pipermail/talk-ch/attachments/20210905/acecede8/attachment.sig>

More information about the talk-ch mailing list