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.
- 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.
- 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.
- 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.
- 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