[Tagging] Merging tagging scheme on wiki pages of Hiking, route=hiking, route=foot and Walking routes

[Warin]

On 16/08/19 01:01, Peter Elderson wrote:
>
>
> Op do 15 aug. 2019 om 15:00 schreef Andy Townsend <ajt1047 at gmail.com 
> <mailto:ajt1047 at gmail.com>>:
>
>     On 15/08/2019 10:56, Peter Elderson wrote:
>     > ... So the lowest level always contains only ways, the higher
>     level contains only relations.
>
>     Please don't make things more complicated than they need to be. Most
>     hiking routes are just a single relation and are best left that way.
>
>
>     >
>     > The ways in the main relation should form one continuous sorted
>     (sortable) route,
>
>     No.  Don't assume that route ways are sorted in OSM as they
>     usually aren't.
>
>
> I know, and it's a pain. If software could easily sort it, fine but it 
> can't. That's why things that break sorting should be avoided.
>
>     > which data users can extract or link to for navigation or
>     planner software.
>
>     Pretty much irrelevant.  As long as the data's there, software can
>     figure it out.
>
>
> Not if there is too much data and no way to know what to choose, or no 
> data at all, or conflicting data.
>
>
>     > Note that rendering routes is not that critical,
>
>     This depends entirely on the use case.  As an example, it is for me.
>
> I mean, the rendering can be critical for the use case, but the order 
> and consistency of the ways is usually not critical for useful rendering.

It can be critical for routing. If a route uses a single way twice - 
once forwards and then backwards then the order of the route can be hard 
for a computer to figure out.

> If it is in your case, you would have problems with lots of routes, 
> because almost all routes I see are damaged in a few places. If I 
> repair it and come back two weeks later, same thing.

Yes.

Even more so for admin boundaries the use roads. The roads get edited 
and that editing brakes the boundaries.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190816/da8ffb11/attachment.html>