Salut Micheal
What are the inconsistencies you intend to address?
Regarding the network structure, the current Wiki entry seems quite specific:
The hiking nodes are labeled guideposts. Each of them contains a small >
white signboard with the name of the place (usually open fields names) > and the elevation over mean sea level. They should be tagged as
described on tag:information=guidepost
https://wiki.openstreetmap.org/wiki/Tag:information%3Dguidepost.
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?
I see some issues with using every guidepost as a node:
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. 2. There are 1000s of already existing hiking relations created in the last years. 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. 4. There is no harm if a way is part of multiple lwn relations.
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.
To the list of issues with the Wiki page I would add the following points:
- There are many variations for the symbol tag. The german variants are also used in the non-german-speaking regions. Having a preferred symbol for each route type and language could clarify this. Also, would it be better to use symbol:de, symbol:fr...? Or is it needed at all as a symbol for each language can be derived from osmc:symbol? - Are routes with a number always rwn or nwn? There seem to be routes with 1, 2 or 3 digits. - How should "white" routes be mapped. These are normally local "walking" routes of municipalities. - There seem to be no guides on how to map wheelchair routes (Or I did not yet spot them) - It looks as at least some hiking organisations / cantons use routes to plan their hiking network. Some users started to map them as superroutes. An example of such a route is [2]. My view on this is that this mapping is hard to achieve without access to the official GIS - It looks as some mappers use "online" resources to map, e.g. cantonal GIS. It would be good to have a vetted list of such GIS that can be used. - How should incomplete routes be mapped. E.g. routes starting at a visited endpoint and ending somewhere unknown. I currently map them as start=<label of guidepost> to=All names of the sign with a question mark added (e.g. to=Name1? / Name2? / etc) and a fixme=continue to next named guidepost.
Regarding names of relations, I guess this is also something related to iD. If hiking relations have no name, all hiking routes are just named "Hiking Route", which makes it painful to select the right one when mapping. RapiD uses the from/to tags, thus this will maybe trickle down to iD in the future.
lg rene
[1] https://www.shn.ch/region/kanton/2016-12-12/es-gibt-neue-wanderwege
[2] https://www.openstreetmap.org/relation/12045190
On Sun, 20 Jun 2021 at 18:14, michael spreng < mailinglist@osm.datendelphin.net> wrote:
Hi
There was some discussion last month about hiking tagging. And I was just asked again about some inconsistencies of the HikingNetwork wiki page https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork
I propose some changes to it. First and foremost I would like to clarify that the network structure is important. That means no way should be part of multiple lwn relations. And that relations obviously can end on unnamed guide posts. Nothing we can do if a there is a junction but the guidepost has no name. This was also discussed with a few mappers at the Zurich meetup last year and seems uncontentious.
I would also suggest to remove the text "The following section is a proposal. Comments are welcome" as it is there for more than 10 years now.
Adapted text for section "Hiking path network"
===Recommended tagging===
The hiking network is different from hiking routes discussed above: As a network, only routes between junctions are linear and therefore, each route between two junctions (the “edges” of the network) gets its own route relation. Each part of the network is then part of only one relation. Each junction (node of the network) should have a guidepost, as we only map signposted routes.
===Guideposts===
Along the hiking routes you can find guideposts. Some of those guideposts have a small white signboard with the name of the place (usually open fields names) and the elevation over mean sea level. They should be tagged as described on tag:information=guidepost.
[then follows the table, and a bit further down:]
===Routes===
A way between two junctions in the network is tagged as a usual hiking relation with network=lwn.
I would also like to introduce a Required? column to the tables, like it is often done on other wiki pages.
Tag Required? tourism=information required information=guidepost required name=* optional if there is one ele=* optional if there is one hiking=yes optional image=* optional
Tag Required? type=route required route=hiking required network=lwn required symbol=* optional osmc:symbol=* optional operator=* optional osmc:name=* optional
The route name tag:
That seems a bit disputed. I feel this tag was forced by a particular renderer, the "OSMC Reit- und Wanderkarte". There are two tags, name= and osmc:name and I see that the name tag was added to the wiki page in 2018, which I seem to have missed. I would like to remove name again, but add from= and to= to the table, hopefully a better way to help mappers to identify relations.
Michael _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch