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@openstreetmap.ch
http://lists.openstreetmap.ch/mailman/listinfo/talk-ch