[talk-ch] Changes to HikingNetwork wiki page
matthijs at stdin.nl
Sun Sep 5 11:36:13 CEST 2021
the suggestions from Raphael and Yves, to just tag the highways with
something and omit the route relations entirely seems like an clean
approach here, if you primarily want to be able to know which ways are
part of the hiking network (e.g. to color them), and the actual routes
themselves are less of interest (as I think is the case).
However, it does seem that by omitting the routes, you are making things
more fragile and are omitting some valuable information, though I find
it hard to translate that intuition into actual examples.
One advantage of adding route relations, I think, is that it allows
more powerful automated checking of the network, to detect cases where a
route was accidentally deleted, a way was removed from a route, etc. One
example of such checking (which I forgot to point out in my earlier
post), is done by knooppuntnet.nl, see
https://knooppuntnet.nl/en/analysis/ for some examples. I think support
for named nodes is still in progress, though.
Of course there is a potential fallacy here: If adding routes enables
automated checking, but that checking only exposes problems that would
not exist in a tagging scheme without the routes, then the
"allows-analysis" argument by itself is moot. However, I suspect there
are still some problems that can be detected more easily/reliably with
relations (e.g. distinguishing a dead-end route to a viewpoint from a
Also, Sarah makes a good point about consistency toward data consumers,
which expect route relations currently.
On Sat, Sep 04, 2021 at 09:28:45AM +0100, Sarah Hoffmann wrote:
> Long story short: mapping the waymarkings on ways is another dimension here
> and I'm not sure it is a good idea to bring it into the discussion right now.
> The same is true for the node network mapping schema.
I'm not sure I agree with the latter entirely. Your argument about using
route relations for consistency towards data consumer seems to apply
to using the node network mapping schema as well. That is a documented
(though still in-progress) schema for networks such as these, so
supporting it (maybe with some changes to the schema, maybe making some
things optional, like tagged junction nodes) would make it easier for
data consumers to consistently use the data. One could argue that this
should be a separate discussion, but I'm not sure if there's much point
in settling on a schema for Switzerland first, and then afterwards
starting to think about the node networks separately.
In any case, like I mentioned above, having automated analysis tools like
knooppuntnet.nl support the Swiss network would, IMHO, be quite useful.
Whether that means adapting the Swiss tagging scheme, or adapting
knooppuntnet.nl (and/or the documented node network tagging scheme) is
to be determined, IMHO.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the talk-ch