Hallo Everyone
I like to continue on Renés respons.
All the Swiss Hiking Network with the yellow, red and blue markings contains of single routes. The start- or endpoint of each route is the bottom name on each section of a guidepost. The top name of each section is the next named main-guidepost of each route. There might be more named guideposts in the direction of the next main-guidepost. This varies from canton to canton. On the guidepost [1] mentioned by René there are 6 start- or endpoints and a short access-route from the busstop. At the busstop-end you might find a guidepost with an arrow "zu den Wanderwegen". Main-guideposts are mostly close to public transport or at a place of touristic value. No-name-guideposts are mostly in the middle of nowhere or at least away from public transport.
To find out which of all the names build a complete route you have to visit the next marked guideposts. In this example you go to Butzi and check which name is there below Alpthal on one section of an arrow. If there is no other name on that section the route is Alpthal - Euthal. Which in this case is most likely. Routes normally are not longer than 6 or 7 hours. If there is a guidepost with only one arrow or multiple arrows in the same direction, this is obviously an official start-/endpoint and all the lowest names are start-/endpoints from all the routes from/to this guidepost. On a guidepost with two arrows and only one section per arrow the route is most likely from the lowest name on the one arrow to the lowest name on the other arrow.
The routes and guideposts are maintained by local groups. In Zurich it is Zürcher Wanderwege formerly ZAW, in Thurgau it is Thurgauer Wanderwege... Each new installed guidepost in Zurich and maybe in other cantons contains a small number of 8 digits. This is the official reference of this guidepost. The first 6 digits are for the square of the Swiss coordinate-system, the last 2 digits are to clearly identify the guidepost. On many poles from the guideposts there is a sticker with informations of the operator.
Beside the Swiss hiking network there are the routes from wanderland schweiz numbered with 1 digit = nwn, 2 digits = rwn and 3 digits = lwn. This routes use most of the time sections of the Swiss hiking network. This routes should always contain operator=Wanderland Schweiz, the number as ref=* and the number in the osmc:symbol=green:green::*:white. And last but not least there are a lot of localy marked hiking routes, which are not part of the Swiss hiking network such as planet-walks... This routes follow sometimes in short sections the Swiss hiking network but have their own signs. The osmc:symbol= of this routes should never start with yellow, red or blue.
Conclusion: I highly recommend to map sections between main-guideposts as routes and complete routes as superroutes containing the routes as members. Like this there are sections of highways which contain several routes but the superroutes can easily be maintained. If all the sections between two guideposts wether they contain a name or not are mapped, this creates a huge amount of short routes from no-name-guidepost to no-name-guidepost. Like this a superroute might contain several unnamed members. So it will be difficult to keep the superroutes sorted. And still there might be highways which contain more than one route because there can always be a local route which is not part of the Swiss hiking network.
Liebe Grüsse Urs
Am 21. Juni 2021 21:58:06 MESZ schrieb "René Buffat" buffat@gmail.com:
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 substantialchanges
[1]. At the same time, OSM edits can break relations. Thishappens
also regularly. Having metadata about nodes and relations is extremely helpful to see how things connect. The guidepostlabels
are in most cases sufficient to tell them apart. Having the guidepost labels encoded in the relations identifies them andhelps
to error check. Thinking further, this would also allow havingsome
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 notbe
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