[talk-ch] Changes to HikingNetwork wiki page

René Buffat buffat at gmail.com
Mon Jun 21 21:58:06 CEST 2021

What I want to point out is that metadata describing a relation is
important to maintain the network.

To give an example I found this probably faulty route:

The route was created 8 years ago. Maybe it was faulty from the beginning.
Maybe it broke during the years. It could very well be that the hiking
routes now are different compared to 8 years ago. Having the metadata about
the route identifies what the relation was intended for in the beginning.
This could be used to identify that there is something wrong with this

Now look at https://hiking.waymarkedtrails.org/#route?id=12853664 There is
no metadata for this relation. It looks very strange, but there is no
information documenting what this relation should represent without
visiting it. Also, without this metadata, it is not possible to check for
consistency programmatically.

The Swiss hiking network is 65'000 km long. There are only a handful of
people actively mapping it. Things will break constantly, either through
OSM edits or changes of the hiking network. At one point some validator
tool will be required otherwise the data will be too outdated/broken to be
of any use.

Personally, I would not just give up on this metadata. If there are long
routes without labeled guidepost, why not use names of villages / mountain
peaks as nodes. Typically, locations of the same route are shown on one
guidepost in order of travel time. For example in [1], there would be a
route Alpthal -> Butzi -> Spital -> Euthal. Why not use any of these
location as node even if there is not a labelled guidepost present at any
of these locations. If there are regions where it would not be feasible,
then limit it to these regions.

lg rene

[1] https://www.schweizer-wanderwege.ch/de/signalisation

On Mon, 21 Jun 2021 at 16:05, michael spreng <
mailinglist at osm.datendelphin.net> wrote:

> Hi René
> On 20.06.21 23:08, René Buffat wrote:
> > Salut Micheal
> >
> > What are the inconsistencies you intend to address?
> That the naming of guide posts has nothing to do with junctions in the
> network.
> There are regions where only very few guideposts got a name. And at
> places it seems quite arbitrary.
> > Regarding the network structure, the current Wiki entry seems quite
> > specific:
> >
> I can't offer you more explanation than you already got from another
> mapper:
> https://github.com/waymarkedtrails/waymarked-trails-site/issues/312. It
> was assumed that all relevant intersections have one, which turns out is
> rather not the case.
> > 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?
> Make it clear how the relations should look like for regions where many
> junctions have unnamed guideposts. There is no value in trying to puzzle
> together routes from named to named guidepost in such a way that every
> segment of hiking network is at least covered once. In the worst case
> for a region with n named guideposts one would create n squared routes.
> > I see some issues with using every guidepost as a node:
> That is not what my text says. I write of junctions. Places, where two
> or more hiking routes meet. They should have a guidepost, as they would
> be unsigned otherwise.
> As an aside: there are cases where it makes sense to extend the one
> relation to another junction, when those junctions are close by, to
> avoid splitting the network into many very small relations. But still
> each way being only part of a single lwn network relation.
> >  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.
> The from/to tag seems to work fine for this, or what is your concern? I
> fail to see how having one way in many relations makes maintenance any
> easier in such cases.
> >  2. There are 1000s of already existing hiking relations created in the
> >     last years.
> There are many relations with a name tag. It seems very forced and has
> lead and will lead to a lot of conflict. I think the from/to tag should
> work well as a compromise.
> >  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.
> That's why I write about junctions in the network and would not
> emphasize guideposts too much. And of course an unmapped guide post is
> just missing data, nothing bad about that.
> >  4. There is no harm if a way is part of multiple lwn relations.
> But it does add a lot of overhead for the mapper. And makes the data
> more difficult to use for data consumers. I don't see a reason why a way
> would need to be in multiple relation to map out the usual hiking network.
> >
> >
> > 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.
> What is that supposed to mean? By the way I think there is a tag for
> signed only in one direction: signed_direction=yes. At least that seems
> to fit our abstraction.
> Greetings
> Michael
> _______________________________________________
> talk-ch mailing list
> talk-ch at openstreetmap.ch
> http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.ch/pipermail/talk-ch/attachments/20210621/a6e4e457/attachment.htm>

More information about the talk-ch mailing list