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: https://hiking.waymarkedtrails.org/#route?id=2991114
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 route.
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@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.
- 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 _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch