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
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
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
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
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
On Sun, Jun 20, 2021 at 11:08:41PM +0200, René Buffat wrote:
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
The current wiki page was written in 2009 before the very first route relation was every created. It was a theoretical proposal of what seemed reasonable. It has changed so little that it even still has the warning about being preliminary.
The wiki does not correctly reflect what then later became common practise. I surely can tell you that the author of the proposal has never mapped hiking routes to the exact letter of what is written there. Michael's new proposal reflects much better the actual tagging that developped over time.
That's just to say that there is no point in citing the wiki as authoritive source in this discussion because the author of the page is very much aware that what she wrote then is not quite correct now.
Sarah
Michael's new proposal reflects much better the
actual tagging that developped over time.
I strongly disagree that using unnamed guideposts as nodes is the actual tagging. Hiking routes are by a vast majority mapped between named guideposts (=Ways can be part of multiple lwn relations). In most of the cases the relations have a name=tag including the guidepost label at the start and the end of the relation. This is easily verifiable using hiking.waymarkedtrails.org
On Mon, 21 Jun 2021 at 16:13, Sarah Hoffmann lonvia@denofr.de wrote:
On Sun, Jun 20, 2021 at 11:08:41PM +0200, René Buffat wrote:
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
The current wiki page was written in 2009 before the very first route relation was every created. It was a theoretical proposal of what seemed reasonable. It has changed so little that it even still has the warning about being preliminary.
The wiki does not correctly reflect what then later became common practise. I surely can tell you that the author of the proposal has never mapped hiking routes to the exact letter of what is written there. Michael's new proposal reflects much better the actual tagging that developped over time.
That's just to say that there is no point in citing the wiki as authoritive source in this discussion because the author of the page is very much aware that what she wrote then is not quite correct now.
Sarah _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Hallo zusammen, danke an Michael für das lostreten der Diskussion.
Aus Sicht des Wanderweg*netzes* in den Alpen bedarf die Mapping-Direktive ein update, in Richtung Michaels Vorschlag. Weite Teile Graubündens, des Tessins, des Wallis und des Berner Oberlandes sind mit der geltenden Vorgabe einfach nicht kartiert worden [1]. Einer der Gründe dafür ist, dass dort auf eine relativ hohe Maschendichte eine relativ kleine Zahl benannter Wegweiser trifft.
Gerne illustiere ich euch dass mit einem Beispiel aus dem Raum Davos. Der Kanton Graubünden hat uns für einen Testballon für das BAV Projekt Door2Peak [2] neben dem Wanderwegnetz (inkl. Klassierung) auch die Wegweiser-Standorte (aus dem Raum Lenzerheide bis Davos) zur Verfügung gestellt. So wissen wir jetzt, dass der Wegweiser am Standort *Davos Dorf 1559m *aufgrund der Vielzahl an unbenannten Knoten*mit**mindestens 44**benannten Knoten* (=benannte Wegweiserstandorte) [3] *direkt* *verbunden* ist (ohne benannte Zwischenstation). Effektiv sind es noch mehr als die 44, da das Netz Richtung Klosters an mehreren Punkten noch offen ist. Lassen wir einfach beiseite, dass für die meisten dieser 44+ Verbindungen verschiedene Routen-Varianten möglich wären... es sind auch schon so zuviele "Routen" die nach geltender Direktive von einem einzigen Wegweiserstandort aus gemappt werden müssten.
Eine deutliche Entflechtung zwischen "Netz" und "Route" wie sie auch BAK365 aufzeigt und Michael vorgeschlagen hat, brächte im Gegensatz zu der geltenden inpraktiablen Direktive zumindest für den Alpenraum eine deutliche Verbesserung.
lg. Martin Lerjen // lm@Door2Peak & landscapemapper
[1] https://hiking.waymarkedtrails.org/#?map=10!46.416!8.3779 (Bem. Raum Lenzerheide -Davos durch lm@Door2Peak) [2] https://wiki.openstreetmap.org/wiki/Organised_Editing/Activities/Door2Peak [3] Meierhof, Seehorn 1567, Wolfgang 1629 und 1630, Landhaus Laret, Unter-Laret, Schwarzseealp, Stützalp, Parsennhütte, Parsennfurgga, Casannapass, Wasserscheid, Parsennsee, Haltestelle Panoramaweg, Station Höhenweg, Schiahorn, Strelapass, Büschalp, Strelaalp, Schatzalp, Schönboden, Lochalp, Grüeni Alp, Usser Erb, Davos Platz 1540 und 1558, Alberti, Islen, Clavadel, Clavadeler Alp, Ischalp, Duchlisage, Stillberg, Teufi, Alp Rüedischtäli, Am Rhin, Inschlag, Wägerhus, Alpenrose, Dörfji, Chaltboden, Seehorn 2237, Stilli und Drusatscha.
On 21.06.2021 17:15, René Buffat wrote:
Michael's new proposal reflects much better the
actual tagging that developped over time.
I strongly disagree that using unnamed guideposts as nodes is the actual tagging. Hiking routes are by a vast majority mapped between named guideposts (=Ways can be part of multiple lwn relations). In most of the cases the relations have a name=tag including the guidepost label at the start and the end of the relation. This is easily verifiable using hiking.waymarkedtrails.org http://hiking.waymarkedtrails.org
On Mon, 21 Jun 2021 at 16:13, Sarah Hoffmann <lonvia@denofr.de mailto:lonvia@denofr.de> wrote:
On Sun, Jun 20, 2021 at 11:08:41PM +0200, René Buffat wrote: > 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 The current wiki page was written in 2009 before the very first route relation was every created. It was a theoretical proposal of what seemed reasonable. It has changed so little that it even still has the warning about being preliminary. The wiki does not correctly reflect what then later became common practise. I surely can tell you that the author of the proposal has never mapped hiking routes to the exact letter of what is written there. Michael's new proposal reflects much better the actual tagging that developped over time. That's just to say that there is no point in citing the wiki as authoritive source in this discussion because the author of the page is very much aware that what she wrote then is not quite correct now. Sarah _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch> http://lists.openstreetmap.ch/mailman/listinfo/talk-ch <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch>
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
The signposts of Graubünden look extremely old. Maybe this is just their chosen style. But if they are old they might have been planned by hand without any GIS.
From my experience, hiking routes in the Bernese Oberland and Ticino fit
reasonably well into the current tagging scheme. I can't comment on Valais, as I didn't hiked there in the past few years.
Einer der Gründe dafür ist, dass dort auf eine relativ hohe Maschendichte
eine relativ kleine Zahl benannter Wegweiser trifft.
I assume that the lack of mapped hiking routes in these region has more to do with the lack of OSM mapper hiking in these regions.
lg rene
On Mon, 21 Jun 2021 at 21:37, Martin Lerjen mlerjen@ubol.ch wrote:
Hallo zusammen, danke an Michael für das lostreten der Diskussion.
Aus Sicht des Wanderweg*netzes* in den Alpen bedarf die Mapping-Direktive ein update, in Richtung Michaels Vorschlag. Weite Teile Graubündens, des Tessins, des Wallis und des Berner Oberlandes sind mit der geltenden Vorgabe einfach nicht kartiert worden [1]. Einer der Gründe dafür ist, dass dort auf eine relativ hohe Maschendichte eine relativ kleine Zahl benannter Wegweiser trifft.
Gerne illustiere ich euch dass mit einem Beispiel aus dem Raum Davos. Der Kanton Graubünden hat uns für einen Testballon für das BAV Projekt Door2Peak [2] neben dem Wanderwegnetz (inkl. Klassierung) auch die Wegweiser-Standorte (aus dem Raum Lenzerheide bis Davos) zur Verfügung gestellt. So wissen wir jetzt, dass der Wegweiser am Standort *Davos Dorf 1559m *aufgrund der Vielzahl an unbenannten Knoten* mit** mindestens 44** benannten Knoten* (=benannte Wegweiserstandorte) [3] *direkt* *verbunden* ist (ohne benannte Zwischenstation). Effektiv sind es noch mehr als die 44, da das Netz Richtung Klosters an mehreren Punkten noch offen ist. Lassen wir einfach beiseite, dass für die meisten dieser 44+ Verbindungen verschiedene Routen-Varianten möglich wären... es sind auch schon so zuviele "Routen" die nach geltender Direktive von einem einzigen Wegweiserstandort aus gemappt werden müssten.
Eine deutliche Entflechtung zwischen "Netz" und "Route" wie sie auch BAK365 aufzeigt und Michael vorgeschlagen hat, brächte im Gegensatz zu der geltenden inpraktiablen Direktive zumindest für den Alpenraum eine deutliche Verbesserung.
lg. Martin Lerjen // lm@Door2Peak & landscapemapper
[1] https://hiking.waymarkedtrails.org/#?map=10!46.416!8.3779 (Bem. Raum Lenzerheide -Davos durch lm@Door2Peak) [2] https://wiki.openstreetmap.org/wiki/Organised_Editing/Activities/Door2Peak [3] Meierhof, Seehorn 1567, Wolfgang 1629 und 1630, Landhaus Laret, Unter-Laret, Schwarzseealp, Stützalp, Parsennhütte, Parsennfurgga, Casannapass, Wasserscheid, Parsennsee, Haltestelle Panoramaweg, Station Höhenweg, Schiahorn, Strelapass, Büschalp, Strelaalp, Schatzalp, Schönboden, Lochalp, Grüeni Alp, Usser Erb, Davos Platz 1540 und 1558, Alberti, Islen, Clavadel, Clavadeler Alp, Ischalp, Duchlisage, Stillberg, Teufi, Alp Rüedischtäli, Am Rhin, Inschlag, Wägerhus, Alpenrose, Dörfji, Chaltboden, Seehorn 2237, Stilli und Drusatscha.
On 21.06.2021 17:15, René Buffat wrote:
Michael's new proposal reflects much better the
actual tagging that developped over time.
I strongly disagree that using unnamed guideposts as nodes is the actual tagging. Hiking routes are by a vast majority mapped between named guideposts (=Ways can be part of multiple lwn relations). In most of the cases the relations have a name=tag including the guidepost label at the start and the end of the relation. This is easily verifiable using hiking.waymarkedtrails.org
On Mon, 21 Jun 2021 at 16:13, Sarah Hoffmann lonvia@denofr.de wrote:
On Sun, Jun 20, 2021 at 11:08:41PM +0200, René Buffat wrote:
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
The current wiki page was written in 2009 before the very first route relation was every created. It was a theoretical proposal of what seemed reasonable. It has changed so little that it even still has the warning about being preliminary.
The wiki does not correctly reflect what then later became common practise. I surely can tell you that the author of the proposal has never mapped hiking routes to the exact letter of what is written there. Michael's new proposal reflects much better the actual tagging that developped over time.
That's just to say that there is no point in citing the wiki as authoritive source in this discussion because the author of the page is very much aware that what she wrote then is not quite correct now.
Sarah _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing listtalk-ch@openstreetmap.chhttp://lists.openstreetmap.ch/mailman/listinfo/talk-ch
-- ---- Neue Adresse: Martin Lerjen, Giblenstrasse 55, 8049 Zürich, 076 201 89 89
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Hi Michael,
I mostly agree with your suggestions. As I mentioned on one of the Talk pages I would also explicitly tag unnamed guideposts with noname=yes to distinguish them from those where the name just hasn't been added yet.
However, I don't see any need for a requirement for each way to be only in a single base network relation. It seems better to map all relations up to a named guidepost, especially because that's how the base network routes are signposted. The only potential issue (the one already mentioned: https://github.com/waymarkedtrails/waymarked-trails-site/issues/312) is when (base network) routes with different difficulty share one section. The signage must already mark them as a (white-red-white) mountain hiking trail even if an initial section is shared with a (yellow) hiking trail, but a renderer might want to show only the easiest base network marking available for each section.
For QA, we might also want to consider integrating with Knooppuntnet ( https://knooppuntnet.nl/en/map/hiking, https://github.com/vmarc/knooppuntnet) which should make it easier to identify broken relations. They are working on support for networks with named nodes: https://github.com/vmarc/knooppuntnet/issues/102, https://wiki.openstreetmap.org/wiki/Proposed_features/Named_nodes_in_node_ne...
Best, Enno
On Mon, Jun 21, 2021 at 4:13 PM Sarah Hoffmann lonvia@denofr.de wrote:
On Sun, Jun 20, 2021 at 11:08:41PM +0200, René Buffat wrote:
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
The current wiki page was written in 2009 before the very first route relation was every created. It was a theoretical proposal of what seemed reasonable. It has changed so little that it even still has the warning about being preliminary.
The wiki does not correctly reflect what then later became common practise. I surely can tell you that the author of the proposal has never mapped hiking routes to the exact letter of what is written there. Michael's new proposal reflects much better the actual tagging that developped over time.
That's just to say that there is no point in citing the wiki as authoritive source in this discussion because the author of the page is very much aware that what she wrote then is not quite correct now.
Sarah _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Hi Enno
Well so much for uncontested. I am surprised by the love for many lwn relations for a single way.
I don't think knooppuntnet is a good fit. There, practically every junction has its number. And if not, it's only a few meters to the next numbered one. Indeed the Netherlands was the inspiration for the Swiss wiki page, but in Switzerland, in some places, almost no junction is named. At least there, the Swiss network has no emphasis on the nodes. No need to cling to this initial proposal. What you describe sound more like mapping of destination signs as described here: https://wiki.openstreetmap.org/wiki/Relation:destination_sign I would be ok with those, and those will use large amounts of relations if that is a consolation :)
On 21.06.21 17:41, Enno Hermann wrote:
It seems better to map all relations up to a named guidepost, especially because that's how the base network routes are signposted.
It does not seem that way to me from experience and also from the documentation linked from BAK365. The near destination could be before or after the next named guide post. A solution that maps the destinations locally to the guidepost seems favorable.
As for the difficulty, that is mapped on the way itself. I don't see the connection to the route relations? I have observed that they are quite inconsistently signed if you are on a lower difficulty segment, and look at destinations which are only reachable vie a higher difficulty level later on the way. So that might even be difficult to consistently map with destination sign mapping
Best regards Michael
Hi Michael,
On 21.06.21 17:41, Enno Hermann wrote:
It seems better to map all relations up to a named guidepost, especially because that's how the base network routes are signposted.
It does not seem that way to me from experience and also from the documentation linked from BAK365. The near destination could be before or after the next named guide post.
No, the documentation makes it clear that the base network is signposted in the form of routes between two named guideposts, with several other named guideposts in-between. While the nearest indicated place might not always correspond to the next guidepost, the Routenziel at the bottom is marked quite consistently from what I have observed so far. Urs has also just explained this very well.
This is not about using as many relations as possible by creating one for every possible path between two named guideposts. Only the actually signposted base network routes need to be mapped. I don't think this will lead to more relations than creating short stub relations between every possible junction. But the difference is that the former can have clear from= and to= tags that can be used to easily verify the relation automatically or from a distance. I fully agree with René here, the Swiss hiking network is so extensive and very few people are mapping it that I think it is very important to consider how we can apply automated tools for QA. Once knooppuntnet fully supports named node networks I don't think it would need major adjustments to use it in Switzerland. This seems more sensible than coming up with our own way of mapping and hoping someone will develop tools for that.
Regarding the at least 44 named guideposts mentioned by Martin that can be reached directly from Davos Dorf. Actually only 17 destinations are shown on the guidepost (https://www.openstreetmap.org/node/5750170421) and possibly fewer relations than that are necessary if some of them overlap up to the next guidepost. For example, while Landhaus Laret and Unter-Laret could be reached indirectly along other routes avoiding any named guideposts, they are not marked from Davos Dorf and one would get there by following one of the 2 routes to Wolfgang, from where Laret is then probably indicated.
Best, Enno
Another aspect,
If you see the hiking network more as an infrastructure (marked and maintained trails) allowing own route planning rather than a set of given routes, you might have one focus on the trails difficulty (yellow/red-white/blue-white). As you can see, the routes outgoing from Davos Dorf seem to be rated by their highest overall difficulty and would though assign the higher rating even on the easier parts of the route. At least in the case of the Davos Region, changes in the difficulty rating are not tied to labeled guideposts but occur regularly at unlabeled guideposts.
Best regards, Martin lm@Door2Peek landscapemapper
On 22.06.2021 14:09, Enno Hermann wrote:
Hi Michael,
On 21.06.21 17:41, Enno Hermann wrote: > It seems better to map all relations > up to a named guidepost, especially because that's how the base network > routes are signposted. It does not seem that way to me from experience and also from the documentation linked from BAK365. The near destination could be before or after the next named guide post.No, the documentation makes it clear that the base network is signposted in the form of routes between two named guideposts, with several other named guideposts in-between. While the nearest indicated place might not always correspond to the next guidepost, the Routenziel at the bottom is marked quite consistently from what I have observed so far. Urs has also just explained this very well.
This is not about using as many relations as possible by creating one for every possible path between two named guideposts. Only the actually signposted base network routes need to be mapped. I don't think this will lead to more relations than creating short stub relations between every possible junction. But the difference is that the former can have clear from= and to= tags that can be used to easily verify the relation automatically or from a distance. I fully agree with René here, the Swiss hiking network is so extensive and very few people are mapping it that I think it is very important to consider how we can apply automated tools for QA. Once knooppuntnet fully supports named node networks I don't think it would need major adjustments to use it in Switzerland. This seems more sensible than coming up with our own way of mapping and hoping someone will develop tools for that.
Regarding the at least 44 named guideposts mentioned by Martin that can be reached directly from Davos Dorf. Actually only 17 destinations are shown on the guidepost (https://www.openstreetmap.org/node/5750170421 https://www.openstreetmap.org/node/5750170421) and possibly fewer relations than that are necessary if some of them overlap up to the next guidepost. For example, while Landhaus Laret and Unter-Laret could be reached indirectly along other routes avoiding any named guideposts, they are not marked from Davos Dorf and one would get there by following one of the 2 routes to Wolfgang, from where Laret is then probably indicated.
Best, Enno
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Michael's new proposal reflects much better the
actual tagging that developped over time.
I strongly disagree that using unnamed guideposts as nodes is the actual tagging. Hiking routes are by a vast majority mapped between named guideposts (=Ways can be part of multiple lwn relations). In most of the cases the relations have a name=tag including the guidepost label at the start and the end of the relation. This is easily verifiable using hiking.waymarkedtrails.org
It's worth noting that the Swiss hiking network in its current state is pretty much 100% the result of undiscussed mass edits by user hecktor. I have a hard time finding any relation that he has not touched in Switzerland. He has singlehandedly added name and osmc:name tags to all the relations and it looks like he was also involved in mapping many of the overlapping relations that exist.
Sarah
Hi,
ich habe das Gefühl, dass wir das Problem mal noch etwas auseinander nehmen müssen, um sicher zu gehen, dass wir hier vom gleiche reden.
Zuerst einmal: es geht in dieser diskussion nicht um die touristischen Wanderrouten, also die Routen von SchweizMobil oder die Rundrouten, die manche Gemeinden ausschildern. Ich denke, dass wir uns da relativ einig sind, dass die als klassische route=hiking mit entsprechenden Namen, ref-Tag und network=lwn/rwn/nwn, je nach Art zu taggen sind. Falls es da Unklarheiten gibt, sollten wir das extra diskutieren.
Hier geht es einzig um das Netz gelb, rot und blau markierter Wege, welches sich über die ganze Schweiz zieht und dem Fussgänger helfen soll, gute Wege von einem Ort zum anderen zu wählen.
Was man draussen in diesem Netz beobachten kann ist genau das: manche Wege des Strassensystems sind mit Markierungen versehen und diese markierten Wege ergeben ein Fusswegenetz. An strategischen Stellen stehen Wegweiser, die dem Fussgänger sagen, wohin der markierte Weg führt.
In diesem Sinne funktioniert das Netz nicht anders als das Strassennetz: es gibt Strassen, die alle Orte im Land netzartig verbinden und an Kreuzungen stehen Richtungswegweiser, die einem sagen, wohin jede Strasse führt. Ich denke, dass jetzt bei den Strassen niemand auf die Idee kommen würde auf Grundlage der Richtungswegweiser irgend- welche künstlichen route=road zu erfinden. Wir haben uns da in OSM geeinigt, dass die Strassen gemappt werden und separate die Richtungsanzeiger mit ihren Beschriftungen.
Und genau das gleiche sollte eben für das Wanderwegenetz gelten. Wir müssen es mit Relationen mappen, weil es auf das bestehende Strassenwegenetz aufsetzt, aber ansonsten besteht es im Grunde aus einzelnen markierten Wegen, die sich zu einem Netz verbinden.
Das genau ist die Idee hinter der Regel, dass man die zugehörigen Relationen so anlegt, dass a) kein OSM-Weg in zwei Relationen des Wegenetzes ist, b) jede Relation einen linearen Weg bildet und c) nur Wege mit der gleiche Markierung enthält. Damit entsteht ein Netz, das zum Strassennetz analog ist. Und das bildet imho die Realität am ehesten ab.
Ich habe das immer so gehalten, dass die Relationen möglichst von benannten zu benannten Wegweiser gehen. Aber wenn ein markierter Weg dann an einem unbenannten Wegweiser abzeigt, dann fängt die Relation eben an diesem Wegweiser an. Ich denke auch, dass die genaue Aufteilung in Relationen durchaus im Ermessen des Mappers liegen kann, solange die drei Regeln oben eingehalten bleiben.
Die 'technischen Routen' des Wegehandbuchs abzubilden, macht meiner Meinung nach keinen Sinn. Zum einen ist das ein riesiger zusätzlicher Aufwand für den Mapper, der im Prinzip erst alle Wegweiser der Region besuchen muss, um dann diese technischen Routen im Reverse- Engineering-Verfahren zu ermitteln. Zum anderen sagt auch das Handbuch, dass diese Routen einzig und allein dafür da sind, eine konsistente Ausschilderung zu bekommen. Nirgendwo gibt es die Annahme, dass diese Routen technischen Routen gleichzustellen sind im den Sinne, dass man erwartet, dass Wanderer ihnen vom Anfang zum Ende folgen.
Gruss
Sarah
Hallo Sarah, hallo zusammen
Ich bin hier voll und ganz einverstanden. Ich finde es auch sinnvoller, mit den Routenrelationen das Wanderwegnetz abzubilden und nicht die 'technischen Routen'. Das lässt sich viel einfacher mappen und unterhalten.
Wir kennen bei OSM nicht viele strikte Regeln, aber hier wäre mir ein Grundsatzentscheid am liebsten. Das Mappen von Wanderwegen würde das ungemein erleichern. Falls wir das als Proposal sehen: meine Stimme hat es.
Ich füge ein paar Beispiele an, wo man sieht, wie sich die Regel - wie von dir beschrieben unter a), b) und c) - auswirkt:
Beispiel 1: https://hiking.waymarkedtrails.org/#routelist?map=17!47.1253!9.0528 Niederurnen Bahnhof - Gerbi Niederurnen Bahnhof - Niederurnen Niederurnen - Gerbi
Bei der Kirche kreuzen sich die Wanderwege. Es hat dort einen Wegweiser, aber einen ohne weisses Standortschild. Die bestehenden drei Routenrelationen wären ein Beispiel für "how not to". Die Routen müssten bei der Kirche enden bzw. beginnen.
Nebenfrage: wie machen wir das mit den Namen? Name=* und note=* ganz weglassen?
Beispiel 2: https://hiking.waymarkedtrails.org/#routelist?map=17!47.1268!9.0516 Niederurnen - Luftseilbahn Talstation Luftseilbahn Talstation - Eschen
Bei der Kreuzung ennet dem Dorfbach hat es keinen beschrifteten Wegweiser. Bei 'Luftseilbahn Talstation' hat es einen Wegweiser mit weissem Standortschild, aber keine Wegkreuzung. Ich habe die Route dort trotzdem unterbrochen. Das wäre ein Beispiel dafür, "dass die genaue Aufteilung in Relationen durchaus im Ermessen des Mappers liegen kann, solange die drei Regeln oben eingehalten bleiben". Die Route 'Niederurnen - Luftseilbahn Talstation' müsste aber bei der Dorfbach-Kreuzung aufgesplittet werden.
Beispiel 3: https://hiking.waymarkedtrails.org/#routelist?map=16!46.991!9.1619 Mülibachtal (Engi)
Hier werden die drei Regeln praktisch überall eingehalten. Aber viele unschöne fixmes. Name=* und note=* ganz weglassen?
Liebe Grüsse BAK365
----Ursprüngliche Nachricht---- Von : lonvia@denofr.de Datum : 23/06/2021 - 11:54 (MS) An : talk-ch@openstreetmap.ch Betreff : Re: [talk-ch] Changes to HikingNetwork wiki page
Hi,
ich habe das Gefühl, dass wir das Problem mal noch etwas auseinander nehmen müssen, um sicher zu gehen, dass wir hier vom gleiche reden.
Zuerst einmal: es geht in dieser diskussion nicht um die touristischen Wanderrouten, also die Routen von SchweizMobil oder die Rundrouten, die manche Gemeinden ausschildern. Ich denke, dass wir uns da relativ einig sind, dass die als klassische route=hiking mit entsprechenden Namen, ref-Tag und network=lwn/rwn/nwn, je nach Art zu taggen sind. Falls es da Unklarheiten gibt, sollten wir das extra diskutieren.
Hier geht es einzig um das Netz gelb, rot und blau markierter Wege, welches sich über die ganze Schweiz zieht und dem Fussgänger helfen soll, gute Wege von einem Ort zum anderen zu wählen.
Was man draussen in diesem Netz beobachten kann ist genau das: manche Wege des Strassensystems sind mit Markierungen versehen und diese markierten Wege ergeben ein Fusswegenetz. An strategischen Stellen stehen Wegweiser, die dem Fussgänger sagen, wohin der markierte Weg führt.
In diesem Sinne funktioniert das Netz nicht anders als das Strassennetz: es gibt Strassen, die alle Orte im Land netzartig verbinden und an Kreuzungen stehen Richtungswegweiser, die einem sagen, wohin jede Strasse führt. Ich denke, dass jetzt bei den Strassen niemand auf die Idee kommen würde auf Grundlage der Richtungswegweiser irgend- welche künstlichen route=road zu erfinden. Wir haben uns da in OSM geeinigt, dass die Strassen gemappt werden und separate die Richtungsanzeiger mit ihren Beschriftungen.
Und genau das gleiche sollte eben für das Wanderwegenetz gelten. Wir müssen es mit Relationen mappen, weil es auf das bestehende Strassenwegenetz aufsetzt, aber ansonsten besteht es im Grunde aus einzelnen markierten Wegen, die sich zu einem Netz verbinden.
Das genau ist die Idee hinter der Regel, dass man die zugehörigen Relationen so anlegt, dass a) kein OSM-Weg in zwei Relationen des Wegenetzes ist, b) jede Relation einen linearen Weg bildet und c) nur Wege mit der gleiche Markierung enthält. Damit entsteht ein Netz, das zum Strassennetz analog ist. Und das bildet imho die Realität am ehesten ab.
Ich habe das immer so gehalten, dass die Relationen möglichst von benannten zu benannten Wegweiser gehen. Aber wenn ein markierter Weg dann an einem unbenannten Wegweiser abzeigt, dann fängt die Relation eben an diesem Wegweiser an. Ich denke auch, dass die genaue Aufteilung in Relationen durchaus im Ermessen des Mappers liegen kann, solange die drei Regeln oben eingehalten bleiben.
Die 'technischen Routen' des Wegehandbuchs abzubilden, macht meiner Meinung nach keinen Sinn. Zum einen ist das ein riesiger zusätzlicher Aufwand für den Mapper, der im Prinzip erst alle Wegweiser der Region besuchen muss, um dann diese technischen Routen im Reverse- Engineering-Verfahren zu ermitteln. Zum anderen sagt auch das Handbuch, dass diese Routen einzig und allein dafür da sind, eine konsistente Ausschilderung zu bekommen. Nirgendwo gibt es die Annahme, dass diese Routen technischen Routen gleichzustellen sind im den Sinne, dass man erwartet, dass Wanderer ihnen vom Anfang zum Ende folgen.
Gruss
Sarah _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Hallo zusammen,
Die 'technischen Routen' des Wegehandbuchs abzubilden, macht meiner
Meinung nach keinen Sinn. Zum einen ist das ein riesiger zusätzlicher Aufwand für den Mapper, der im Prinzip erst alle Wegweiser der Region besuchen muss, um dann diese technischen Routen im Reverse- Engineering-Verfahren zu ermitteln.
Einen grossen Nutzen in der Zusammenfassung einzelner Abschnitte in Super-Relationen, die die gesamte Länge der technischen Route abbilden, sehe ich auch nicht. Aber ich denke die Abschnitte zwischen zwei benannten Wegweisern zu erfassen erfordert meistens keinen grösseren Aufwand und wird bis jetzt ja regelmässig auch so durchgeführt.
Beispiel 1:
https://hiking.waymarkedtrails.org/#routelist?map=17!47.1253!9.0528 Niederurnen Bahnhof - Gerbi Niederurnen Bahnhof - Niederurnen Niederurnen - Gerbi
Bei der Kirche kreuzen sich die Wanderwege. Es hat dort einen Wegweiser, aber einen ohne weisses Standortschild. Die bestehenden drei Routenrelationen wären ein Beispiel für "how not to". Die Routen müssten bei der Kirche enden bzw. beginnen.
Die Relation "Niederurnen Bahnhof - Gerbi" scheint mir eine unnötige Doppelung zu sein da die Zwischenabschnitte bereits einzeln erfasst sind. Die anderen beiden würde ich so lassen, der kurze Abschnitt von Kirche zum Wegweiser Niederurnen ist dann in zwei Relationen aber ich verstehe die Problematik dabei nicht. Ansonsten hätten wir einmal "Niederurnen Bahnhof - Niederurnen" und "'Kirche südlich vom Wegweiser Niederurnen' - Gerbi" (oder was würde man dann als note= oder from/to= nehmen?). Die jetzige Version kann man meiner Meinung nach später viel leichter überprüfen.
Wenn dies in manchen Gegenden wirklich aus irgendwelchen Gründen nicht gehen sollte (kenne die Region Davos nicht), könnte man von mir aus behelfsmässig auch unbenannte Wegweiser als Knoten nehmen. Das ist immer noch besser als das Wandernetz nicht zu erfassen. Aber ich sehe keinen Grund vorzuschreiben, dass die Wanderrelationen jetzt generell oder präferenziell an jeder Wegekreuzung gesplittet werden sollen, wenn das bisherige System wie hier im Glarus doch super funktioniert und angewandt wurde.
Liebe Grüsse, Enno
On Wed, Jun 23, 2021 at 02:55:38PM +0200, Enno Hermann wrote:
Beispiel 1:
https://hiking.waymarkedtrails.org/#routelist?map=17!47.1253!9.0528 Niederurnen Bahnhof - Gerbi Niederurnen Bahnhof - Niederurnen Niederurnen - Gerbi
Bei der Kirche kreuzen sich die Wanderwege. Es hat dort einen Wegweiser, aber einen ohne weisses Standortschild. Die bestehenden drei Routenrelationen wären ein Beispiel für "how not to". Die Routen müssten bei der Kirche enden bzw. beginnen.
Die Relation "Niederurnen Bahnhof - Gerbi" scheint mir eine unnötige Doppelung zu sein da die Zwischenabschnitte bereits einzeln erfasst sind. Die anderen beiden würde ich so lassen, der kurze Abschnitt von Kirche zum Wegweiser Niederurnen ist dann in zwei Relationen aber ich verstehe die Problematik dabei nicht. Ansonsten hätten wir einmal "Niederurnen Bahnhof - Niederurnen" und "'Kirche südlich vom Wegweiser Niederurnen' - Gerbi" (oder was würde man dann als note= oder from/to= nehmen?). Die jetzige Version kann man meiner Meinung nach später viel leichter überprüfen.
Was genau möchtest du prüfen?
Sarah
On Wed, Jun 23, 2021 at 5:28 PM Sarah Hoffmann lonvia@denofr.de wrote:
Was genau möchtest du prüfen?
Siehe bereits die Beispiele von René in http://lists.openstreetmap.ch/pipermail/talk-ch/2021-June/010989.html oder mögliche automatische Analysen die möglich wären: https://knooppuntnet.nl/en/analysis/hiking/de/facts
Wenn ich weiss, wo ein Wanderweg starten und enden soll, kann ich Relationen viel leichter überprüfen, vervollständigen oder reparieren. Nur zwei weitere Beispiele der letzten Tage: - Die Relationen 2407581, 2407588 und 2407583 sind Abschnitte die von der Grossen Scheidegg starten. Es war dort aber auch Wege 141033408 und 963976707 mit drin, die zum Erstellungszeitpunkt der Relationen nur ein kurzes Stück auf der Passhöhe verliefen und später verlängert wurden. Dank der Metadaten und der Beschilderung vor Ort konnte ich leicht sehen, dass der Weg dort nicht reingehört, ohne ihn selber abgehen zu müssen um zu schauen ob dort ein Wanderweg verläuft. Man könnte so theoretisch auch automatisch schauen ob Start und Ziel am richtigen Wegweiser liegen. - Der Wegverlauf des Abschnittes Alpiglen - Schwarzwaldalp (Relation 2407577) wurde kurz vor der Schwarzwaldalp geändert, Schweizmobil zeigt noch den alten Verlauf, in OSM war eine Mischung aus alt und neu. Ich bin der Beschilderung gefolgt und konnte so dann nachher eindeutig die alten Wege die nicht mehr zu diesem Abschnitt gehören aus der Relation entfernen. Wäre jetzt nur der unbenannte Wegweiser (Knoten 293121938), an dem der alte Verlauf auf andere Wanderwege traf, als Endpunkt eingetragen gewesen (mit welchem Namen/Beschreibung dann?), wäre eventuell eine genauere Begehung der Wege erforderlich um einen neuen Endpunkt zu finden. Aber das eigentliche, ausgeschilderte Start und Ziel haben sich ja nicht verändert, nur der Verlauf dazwischen.
Dies ist auch nicht sonderlich kompliziert einzutragen, solange man etwas Erfahrung mit Relationen hat, und braucht keine Tageswanderungen wie einige behaupten. Die Abschnitte zwischen zwei benannten Wegweisern dauern selten länger als 1h30.
Gruss, Enno
Lieber Enno
Nur kurz nochmals: Die vorgeschlagene Änderung macht Wanderweg-Routing und Analysen erst möglich und lässt dabei genügend Spielraum für "benannte Routen" und Relationen.
Der inzwischen überfällige und dringende Verbesserungsvorschlag kommt von erfahrenen Mappern der ersten Stunde (und wird vom Vorstand SOSM unterstützt).
Die Erklärungen von Michael (wie ich Mitglied des Vorstands von SOSM) zu Beginn dieses Threads und im Wiki sind eigentlich schon recht ausführlich. Jedoch ist das Thema zugegebenermassen recht komplex und bedarf daher noch etwas Erklärung.
Um die Diskussion zu beschleunigen, lade ich dich und alle weiteren Interessierten darum gerne an den OSM-Stammtisch vom morgen Do. oder übermorgen Fr. ein. Es läuft noch eine Terminabstimmung hier: https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen
Beste Grüsse, Stefan
Am Mi., 14. Juli 2021 um 10:23 Uhr schrieb Enno Hermann enno.hermann@gmail.com:
On Wed, Jun 23, 2021 at 5:28 PM Sarah Hoffmann lonvia@denofr.de wrote:
Was genau möchtest du prüfen?
Siehe bereits die Beispiele von René in http://lists.openstreetmap.ch/pipermail/talk-ch/2021-June/010989.html oder mögliche automatische Analysen die möglich wären: https://knooppuntnet.nl/en/analysis/hiking/de/facts
Wenn ich weiss, wo ein Wanderweg starten und enden soll, kann ich Relationen viel leichter überprüfen, vervollständigen oder reparieren. Nur zwei weitere Beispiele der letzten Tage:
- Die Relationen 2407581, 2407588 und 2407583 sind Abschnitte die von der Grossen Scheidegg starten. Es war dort aber auch Wege 141033408 und 963976707 mit drin, die zum Erstellungszeitpunkt der Relationen nur ein kurzes Stück auf der Passhöhe verliefen und später verlängert wurden. Dank der Metadaten und der Beschilderung vor Ort konnte ich leicht sehen, dass der Weg dort nicht reingehört, ohne ihn selber abgehen zu müssen um zu schauen ob dort ein Wanderweg verläuft. Man könnte so theoretisch auch automatisch schauen ob Start und Ziel am richtigen Wegweiser liegen.
- Der Wegverlauf des Abschnittes Alpiglen - Schwarzwaldalp (Relation 2407577) wurde kurz vor der Schwarzwaldalp geändert, Schweizmobil zeigt noch den alten Verlauf, in OSM war eine Mischung aus alt und neu. Ich bin der Beschilderung gefolgt und konnte so dann nachher eindeutig die alten Wege die nicht mehr zu diesem Abschnitt gehören aus der Relation entfernen. Wäre jetzt nur der unbenannte Wegweiser (Knoten 293121938), an dem der alte Verlauf auf andere Wanderwege traf, als Endpunkt eingetragen gewesen (mit welchem Namen/Beschreibung dann?), wäre eventuell eine genauere Begehung der Wege erforderlich um einen neuen Endpunkt zu finden. Aber das eigentliche, ausgeschilderte Start und Ziel haben sich ja nicht verändert, nur der Verlauf dazwischen.
Dies ist auch nicht sonderlich kompliziert einzutragen, solange man etwas Erfahrung mit Relationen hat, und braucht keine Tageswanderungen wie einige behaupten. Die Abschnitte zwischen zwei benannten Wegweisern dauern selten länger als 1h30.
Gruss, Enno _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Hallo Stefan,
On Wed, Jul 14, 2021 at 12:55 PM Stefan Keller sfkeller@gmail.com wrote:
Nur kurz nochmals: Die vorgeschlagene Änderung macht Wanderweg-Routing und Analysen erst möglich und lässt dabei genügend Spielraum für "benannte Routen" und Relationen.
In der Diskussion geht es doch um die unbenannten Routen des Basisnetzes.
Inwiefern die Änderungen Routing und Analysen ermöglichen, ist mir aus der Diskussion bisher leider nicht ersichtlich. Es gab nur einige Beispiele, wie sie dies möglicherweise erschweren, auf die dann aber nicht weiter eingegangen wurde. Aber ich werde gerne zum Stammtisch kommen und dort hoffentlich mehr erfahren.
Gruss, Enno
On Wed, Jul 14, 2021 at 10:23:03AM +0200, Enno Hermann wrote:
On Wed, Jun 23, 2021 at 5:28 PM Sarah Hoffmann lonvia@denofr.de wrote:
Was genau möchtest du prüfen?
Siehe bereits die Beispiele von René in http://lists.openstreetmap.ch/pipermail/talk-ch/2021-June/010989.html oder
Im ersten Beispiel beisst sich die Katze ein wenig in den Schwanz: wir benötigen Routen, die von benannten Wegweiser zu benanntem Wegweiser gehen, damit man überprüfen kann, dass die Route auch wirklich zwischen den benannten Wegweisern verläuft?
In beiden Beispielen muss man vor Ort gucken, wie die Markierung in der Realität verläuft. Ob man das dann mit überlappenden Routen einträgt oder nicht, ändert daran erst einmal nichts.
Wenn ich weiss, wo ein Wanderweg starten und enden soll, kann ich Relationen viel leichter überprüfen, vervollständigen oder reparieren. Nur zwei weitere Beispiele der letzten Tage:
- Die Relationen 2407581, 2407588 und 2407583 sind Abschnitte die von der
Grossen Scheidegg starten. Es war dort aber auch Wege 141033408 und 963976707 mit drin, die zum Erstellungszeitpunkt der Relationen nur ein kurzes Stück auf der Passhöhe verliefen und später verlängert wurden. Dank der Metadaten und der Beschilderung vor Ort konnte ich leicht sehen, dass der Weg dort nicht reingehört, ohne ihn selber abgehen zu müssen um zu schauen ob dort ein Wanderweg verläuft. Man könnte so theoretisch auch automatisch schauen ob Start und Ziel am richtigen Wegweiser liegen.
Du hast hier die Annahme gemacht, dass Anfang- und Endpunkt in der Relation korrekt sind und die Members falsch. Und nicht anders herum. Aufgrund dieser Annahme ist es klar, wie die Relationen zu fixen sind. Ich teile deine Einschätzung hier 100%, aber trotzdem hat es wenig damit zu tun, ob die Relationen sich auf dem letzten Stück überlappen. Würden die Relationen für zwei der drei Relationen schon am Wegweiser vorher aufhören, wärst du vermutlich zu genau dem gleichen Schluss gekommen, hättest aber nur eine Relation fixen müssen.
- Der Wegverlauf des Abschnittes Alpiglen - Schwarzwaldalp (Relation
- wurde kurz vor der Schwarzwaldalp geändert, Schweizmobil zeigt
noch den alten Verlauf, in OSM war eine Mischung aus alt und neu. Ich bin der Beschilderung gefolgt und konnte so dann nachher eindeutig die alten Wege die nicht mehr zu diesem Abschnitt gehören aus der Relation entfernen. Wäre jetzt nur der unbenannte Wegweiser (Knoten 293121938), an dem der alte Verlauf auf andere Wanderwege traf, als Endpunkt eingetragen gewesen (mit welchem Namen/Beschreibung dann?), wäre eventuell eine genauere Begehung der Wege erforderlich um einen neuen Endpunkt zu finden. Aber das eigentliche, ausgeschilderte Start und Ziel haben sich ja nicht verändert, nur der Verlauf dazwischen.
Das scheint mir doch recht kompliziert gedacht. So eine Relation hätte ich vorher wie nachher als from=Alpigen/to=Schwarzwaldalp eingetragen und nur die Members entsprechend dem Wegverlauf geändert. Vorher hätte sie halt am Wegweiser am Bach geendet, neu am Wegweiser an der Strasse.
from/to sind ja nur grobe Orientierungshinweise für den Mapper bzw. wenn man Relationen anders als auf einer Karte listet. Als solche sind sie enorm nützlich. Das heisst aber nicht, dass sie exakt an den angegebenen Nodes enden müssen. Können sie ja auch nicht, weil wir schon seit vielen Jahren Wegweiser an ihrer echten Position mappen und nicht auf den Kreuzungspunkten.
Hier Beispiele für Fehler, die ich gerne gefunden und entfernt hätte:
* https://hiking.waymarkedtrails.org/#routelist?ids=5936757,5936783 Auf der Via Forestale verläuft eine gelbe und rot-weiss-rote Relation. Was ist richtig? Es wird wohl kaum beide Markierungen geben. * https://hiking.waymarkedtrails.org/#routelist?ids=2407576,2407590,2407591,24... auf dem Parkplatz überlappen sich Routen, die von Süden und Norden kommen, anstatt am gleichen Punkt aufzuhören. * https://hiking.waymarkedtrails.org/#route?id=1107961 ist komplett in https://hiking.waymarkedtrails.org/#route?id=3146564 enthalten und damit überflüssig.
Dies ist auch nicht sonderlich kompliziert einzutragen, solange man etwas Erfahrung mit Relationen hat, und braucht keine Tageswanderungen wie einige behaupten. Die Abschnitte zwischen zwei benannten Wegweisern dauern selten länger als 1h30.
Das hast du falsch verstanden. Mir geht es darum, dass jemand, der einen Tagesausflug macht (nicht zum Mappen, sondern zum Wandern), sein GPS mitlaufen lassen kann und die Wegweiser fotografieren. Aus diesen Angaben sollte er abends die Wege, die er/sie gegangen ist, einfach in OSM aufnehmen können. Oder mal etwas reparieren, wenn sich die Lage vor Ort geändert hat.
Wenn das Mappingschema aber voraussetzt, dass man die Gegend systematisch begeht, dann verlieren wir diese Resource an Mappern.
Sarah
Gruss, Enno
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
In beiden Beispielen muss man vor Ort gucken, wie die Markierung in der
Realität verläuft. Ob man das dann mit überlappenden Routen einträgt oder nicht, ändert daran erst einmal nichts.
Having relations with metadata allow to detect if there is something fishy going on without being at the present location. The elephant in the room is that the vast majority of the base network have meaningful names. Which could be interpreted as that the community prefers to have metadata of hiking relations.
Das hast du falsch verstanden. Mir geht es darum, dass jemand, der einen
Tagesausflug macht (nicht zum Mappen, sondern zum Wandern), sein GPS mitlaufen lassen kann und die Wegweiser fotografieren. Aus diesen Angaben sollte er abends die Wege, die er/sie gegangen ist, einfach in OSM aufnehmen können. Oder mal etwas reparieren, wenn sich die Lage vor Ort geändert hat
This is exactly what I'm doing and I did not have any issues with the current way of mapping. If there is metadata available you can even fix more as you can infer certain things. E.g. that he whole relation is no longer existing and not just that the relation does not terminate anymore at the location that was visited.
[1] https://map.geo.admin.ch/?lang=en&topic=ech&bgLayer=ch.swisstopo.pix...
On Wed, 14 Jul 2021 at 16:20, Sarah Hoffmann lonvia@denofr.de wrote:
On Wed, Jul 14, 2021 at 10:23:03AM +0200, Enno Hermann wrote:
On Wed, Jun 23, 2021 at 5:28 PM Sarah Hoffmann lonvia@denofr.de wrote:
Was genau möchtest du prüfen?
Siehe bereits die Beispiele von René in http://lists.openstreetmap.ch/pipermail/talk-ch/2021-June/010989.html
oder
Im ersten Beispiel beisst sich die Katze ein wenig in den Schwanz: wir benötigen Routen, die von benannten Wegweiser zu benanntem Wegweiser gehen, damit man überprüfen kann, dass die Route auch wirklich zwischen den benannten Wegweisern verläuft?
In beiden Beispielen muss man vor Ort gucken, wie die Markierung in der Realität verläuft. Ob man das dann mit überlappenden Routen einträgt oder nicht, ändert daran erst einmal nichts.
Wenn ich weiss, wo ein Wanderweg starten und enden soll, kann ich Relationen viel leichter überprüfen, vervollständigen oder reparieren.
Nur
zwei weitere Beispiele der letzten Tage:
- Die Relationen 2407581, 2407588 und 2407583 sind Abschnitte die von der
Grossen Scheidegg starten. Es war dort aber auch Wege 141033408 und 963976707 mit drin, die zum Erstellungszeitpunkt der Relationen nur ein kurzes Stück auf der Passhöhe verliefen und später verlängert wurden.
Dank
der Metadaten und der Beschilderung vor Ort konnte ich leicht sehen, dass der Weg dort nicht reingehört, ohne ihn selber abgehen zu müssen um zu schauen ob dort ein Wanderweg verläuft. Man könnte so theoretisch auch automatisch schauen ob Start und Ziel am richtigen Wegweiser liegen.
Du hast hier die Annahme gemacht, dass Anfang- und Endpunkt in der Relation korrekt sind und die Members falsch. Und nicht anders herum. Aufgrund dieser Annahme ist es klar, wie die Relationen zu fixen sind. Ich teile deine Einschätzung hier 100%, aber trotzdem hat es wenig damit zu tun, ob die Relationen sich auf dem letzten Stück überlappen. Würden die Relationen für zwei der drei Relationen schon am Wegweiser vorher aufhören, wärst du vermutlich zu genau dem gleichen Schluss gekommen, hättest aber nur eine Relation fixen müssen.
- Der Wegverlauf des Abschnittes Alpiglen - Schwarzwaldalp (Relation
- wurde kurz vor der Schwarzwaldalp geändert, Schweizmobil zeigt
noch den alten Verlauf, in OSM war eine Mischung aus alt und neu. Ich bin der Beschilderung gefolgt und konnte so dann nachher eindeutig die alten Wege die nicht mehr zu diesem Abschnitt gehören aus der Relation
entfernen.
Wäre jetzt nur der unbenannte Wegweiser (Knoten 293121938), an dem der
alte
Verlauf auf andere Wanderwege traf, als Endpunkt eingetragen gewesen (mit welchem Namen/Beschreibung dann?), wäre eventuell eine genauere Begehung der Wege erforderlich um einen neuen Endpunkt zu finden. Aber das eigentliche, ausgeschilderte Start und Ziel haben sich ja nicht
verändert,
nur der Verlauf dazwischen.
Das scheint mir doch recht kompliziert gedacht. So eine Relation hätte ich vorher wie nachher als from=Alpigen/to=Schwarzwaldalp eingetragen und nur die Members entsprechend dem Wegverlauf geändert. Vorher hätte sie halt am Wegweiser am Bach geendet, neu am Wegweiser an der Strasse.
from/to sind ja nur grobe Orientierungshinweise für den Mapper bzw. wenn man Relationen anders als auf einer Karte listet. Als solche sind sie enorm nützlich. Das heisst aber nicht, dass sie exakt an den angegebenen Nodes enden müssen. Können sie ja auch nicht, weil wir schon seit vielen Jahren Wegweiser an ihrer echten Position mappen und nicht auf den Kreuzungspunkten.
Hier Beispiele für Fehler, die ich gerne gefunden und entfernt hätte:
- https://hiking.waymarkedtrails.org/#routelist?ids=5936757,5936783 Auf der Via Forestale verläuft eine gelbe und rot-weiss-rote Relation. Was ist richtig? Es wird wohl kaum beide Markierungen geben.
https://hiking.waymarkedtrails.org/#routelist?ids=2407576,2407590,2407591,24... auf dem Parkplatz überlappen sich Routen, die von Süden und Norden kommen, anstatt am gleichen Punkt aufzuhören.
- https://hiking.waymarkedtrails.org/#route?id=1107961 ist komplett in https://hiking.waymarkedtrails.org/#route?id=3146564 enthalten und damit überflüssig.
Dies ist auch nicht sonderlich kompliziert einzutragen, solange man etwas Erfahrung mit Relationen hat, und braucht keine Tageswanderungen wie
einige
behaupten. Die Abschnitte zwischen zwei benannten Wegweisern dauern
selten
länger als 1h30.
Das hast du falsch verstanden. Mir geht es darum, dass jemand, der einen Tagesausflug macht (nicht zum Mappen, sondern zum Wandern), sein GPS mitlaufen lassen kann und die Wegweiser fotografieren. Aus diesen Angaben sollte er abends die Wege, die er/sie gegangen ist, einfach in OSM aufnehmen können. Oder mal etwas reparieren, wenn sich die Lage vor Ort geändert hat.
Wenn das Mappingschema aber voraussetzt, dass man die Gegend systematisch begeht, dann verlieren wir diese Resource an Mappern.
Sarah
Gruss, Enno
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
On Wed, Jul 14, 2021 at 04:53:01PM +0200, René Buffat wrote:
In beiden Beispielen muss man vor Ort gucken, wie die Markierung in der
Realität verläuft. Ob man das dann mit überlappenden Routen einträgt oder nicht, ändert daran erst einmal nichts.
Having relations with metadata allow to detect if there is something fishy going on without being at the present location. The elephant in the room is that the vast majority of the base network have meaningful names. Which could be interpreted as that the community prefers to have metadata of hiking relations.
Niemand bezweifelt, dass es nützlich ist, grobe Angaben zu haben, von wo nach wo die Relation führt. Deshalb ja der Vorschlag mit den from und to- Tags, um das ganze noch etwas 'offizieller' zu machen.
Wogegen ich mich verwehre ist, die Argumentation umzudrehen: weil from und to eingetragen werden sollen, wird daraus geschlossen, dass die Relationen an einem benannten Wegweiser anfangen und Ende müssen. Das ist einfach nicht so. Ich habe Dutzende Relationen gemappt, die nicht an benannten Wegweisern angefangen haben und trotzdem eine entsprechende note=<from>-<to> hatten. Das war nie ein Problem und hat der Nützlichkeit der Information keinen Abbruch getan. Das war übrigens auch der Grund, warum diese Information in den 'note'-Tag kam bevor hecktor alles umgetagt hat. Es war immer ganz klar eine Information für den Mapper und kein Name.
Sarah
On Wed, Jul 14, 2021 at 4:20 PM Sarah Hoffmann lonvia@denofr.de wrote:
Du hast hier die Annahme gemacht, dass Anfang- und Endpunkt in der Relation korrekt sind und die Members falsch. Und nicht anders herum. Aufgrund dieser Annahme ist es klar, wie die Relationen zu fixen sind. Ich teile deine Einschätzung hier 100%, aber trotzdem hat es wenig damit zu tun, ob die Relationen sich auf dem letzten Stück überlappen. Würden die Relationen für zwei der drei Relationen schon am Wegweiser vorher aufhören, wärst du vermutlich zu genau dem gleichen Schluss gekommen, hättest aber nur eine Relation fixen müssen.
Das die Grosse Scheidegg der Anfang dieser 3 Routen ist, war keine Annahme, sondern vor Ort überprüft [1].
Aber ich denke ich verstehe die Differenzen jetzt besser:
from/to sind ja nur grobe Orientierungshinweise für den Mapper bzw. wenn
man Relationen anders als auf einer Karte listet. Als solche sind sie enorm nützlich. Das heisst aber nicht, dass sie exakt an den angegebenen Nodes enden müssen. Können sie ja auch nicht, weil wir schon seit vielen Jahren Wegweiser an ihrer echten Position mappen und nicht auf den Kreuzungspunkten.
Der Wegweiser steht ja meist nicht fern vom Kreuzungspunkt. Als Werte für from=A/to=B würde ich, genau wie bisher bei note=A - B, nur die vor Ort überprüfbaren Wegweisernamen zulassen, aber das wird anscheinend nicht von allen geteilt. Wenn ich jetzt also zwei der drei Routen am unbenannten Wegweiser davor beende, gäbe es nichts belegbares für from/to, ich kann ja nicht einfach irgendwelche Namen erfinden. Wie sollten z.B. Start und Ziel dieser neuen Relation identifiziert werden: https://hiking.waymarkedtrails.org/#route?id=12904718&map=17!46.8075!9.8...
Hier Beispiele für Fehler, die ich gerne gefunden und entfernt hätte:
- https://hiking.waymarkedtrails.org/#routelist?ids=5936757,5936783 Auf der Via Forestale verläuft eine gelbe und rot-weiss-rote Relation. Was ist richtig? Es wird wohl kaum beide Markierungen geben.
Das ist wahrscheinlich schon so. In Caslano wird eine gelbe und rote Route zum Monte Caslano ausgeschildert sein [2]. Eine Zeit lang laufen diese gleich, dann teilen sich gelb und rot an einem unbenannten Wegweiser [3]. Die Wegmarkierung entspricht immer der leichtesten Route, ist also anfangs gelb. Soweit ich es sehe mappen wir in OSM bisher nur die Routenmarkierungen, die Wegemarkierungen ergeben sich automatisch. Falls die obere Via Forestale jetzt auf einmal verschwinden würde, gäbe es nur noch rote Routen, was die Betreiber dann auch unten so markieren müssten.
https://hiking.waymarkedtrails.org/#routelist?ids=2407576,2407590,2407591,24... auf dem Parkplatz überlappen sich Routen, die von Süden und Norden kommen, anstatt am gleichen Punkt aufzuhören.
Ja, es ist auch sicher mindestens ein Wegweiser zu viel. Bin leider nicht über den Parkplatz gegangen, weiß also nicht wie es wirklich ausschaut. Aber es lässt sich sicher überprüfen, dass die Kreuzungspunkte von Relationen mit gleichem Start/Ziel stimmig sind.
- https://hiking.waymarkedtrails.org/#route?id=1107961 ist komplett in https://hiking.waymarkedtrails.org/#route?id=3146564 enthalten und damit überflüssig.
1107961 endet nicht an einem Wegweiser "Maighelspass", das deutet also auf ein Problem hin. Entweder der Name ist noch nicht eintragen, dann müsste 3146564 gekürzt werden. Oder der Wegweiser ist wirklich unbenannt (noname=yes), dann ist die Relation in der Tat überflüssig.
Das hast du falsch verstanden. Mir geht es darum, dass jemand, der einen Tagesausflug macht (nicht zum Mappen, sondern zum Wandern), sein GPS mitlaufen lassen kann und die Wegweiser fotografieren. Aus diesen Angaben sollte er abends die Wege, die er/sie gegangen ist, einfach in OSM aufnehmen können. Oder mal etwas reparieren, wenn sich die Lage vor Ort geändert hat.
Genauso mache ich das, meistens wandere ich nicht speziell fürs Mappen. Aber normalerweise folgt man ja für eine gewisse Zeit den ausgeschilderten Wanderwegen und kommt so von einem benannten Wegweiser zum nächsten. Diese Abschnitte kommen dann in je eine Relation und evtl. noch zusätzliche fixme-Relationen mit Angabe des nächsten Routenziels, falls sich doch jemand ungemappte Wege raussuchen möchte.
[1] https://commons.wikimedia.org/wiki/File:Fingerpost_Grosse_Scheidegg_(1962m)_... [2] https://pacer-note-images.pacer.cc/230246602_793255A4-CBAB-4927-A4B9-7D2DAB5... [3] https://pacer-note-images.pacer.cc/230246602_BB1FAE70-FA39-4CF7-8E1F-BF3B8B0...
Enno
On Wed, Jul 14, 2021 at 06:13:00PM +0200, Enno Hermann wrote:
On Wed, Jul 14, 2021 at 4:20 PM Sarah Hoffmann lonvia@denofr.de wrote:
- https://hiking.waymarkedtrails.org/#routelist?ids=5936757,5936783 Auf der Via Forestale verläuft eine gelbe und rot-weiss-rote Relation. Was ist richtig? Es wird wohl kaum beide Markierungen geben.
Das ist wahrscheinlich schon so. In Caslano wird eine gelbe und rote Route zum Monte Caslano ausgeschildert sein [2]. Eine Zeit lang laufen diese gleich, dann teilen sich gelb und rot an einem unbenannten Wegweiser [3]. Die Wegmarkierung entspricht immer der leichtesten Route, ist also anfangs gelb. Soweit ich es sehe mappen wir in OSM bisher nur die Routenmarkierungen, die Wegemarkierungen ergeben sich automatisch.
Nein. Die Idee war immer, dass der osmc:symbol-Wert der Wegmarkierung entspricht. Steht eigentlich auch genau so im Wiki: "machine-readable description of the way marker"
Sarah
Hallo zusammen
Zuerst möchte ich noch auf den online "Stammtisch" heute Abend hinweisen, ab 18:30 Uhr auf https://pub.digitale-gesellschaft.ch/b/pat-6h2-rqy Kommt doch auch, gewisse Sachen lassen sich vielleicht einfacher im Gespräch Lösen.
Ich habe heute Morgen viel Zeit damit verbracht, die verschiedenen Beiträge zu lesen und nachzuvollziehen.
Ich bin trotzdem nach wie vor der Überzeugung, dass wir unterscheiden sollten zwischen dem Netz und den technischen Routen/Wegweiser Zielen. Ich verweise hier auf das, was BAK365 und Sarah sehr gut dargelegt haben. Alles andere wird in gewissen Fällen zu einem Knobelspiel. Wo es viele benannte Wegweiser hat, macht es keinen unterschied. An den Stellen, wo es zum Knobelspiel würde, wird es einfach: jeder Abschnitt ist in einer Relation. Die Relation kann auch mal bis zur übernächsten Verzweigung gehen, wenn das gerade passt.
Zum name tag sehe ich, dass ein paar den Vorschlag mit from=/to= aufgenommen haben, andere (René und Urs) haben das bis jetzt ignoriert. Ich verstehe den Bedarf an "Metadaten", wie es René nennt. Das einzige, was sich ändert, ist ein anderes tag. Genügt das from=/to= als Ersatz? Den name tag so zu gebrauchen steht einfach quer zum Rest von OSM. Dies hat immer wieder zu Konflikten geführt und das wird nicht weg gehen. Ich sehe keine Chance für den name tag.
Grüsse Michael
Hallo zusammen
Die Info zum Stammtisch habe ich jetzt zu spät gelesen. Vielleicht beim nächsten Mal.
Ich sehe die Routen nicht sls technische Routen, sondern als offizielle Routen. Warum sonst gibt es auf den Wegweisern Endziele mit Zeitangaben und von einigen Wegweiserstandorten aus Routen über verschiedene Wege zum selben Ziel. Dies wäre oftmals gar nicht nötig, um das ganze Netz abzubilden, da schon andere Routen die selben Streckenabschnitte abdecken.
Wenn das Wanderwegnetz nur als Netz ohne Routen verstanden wird, dann sollten, wie ich es schon in einem vorherigen Mail beschrieben habe, einzig die lcn=yes zu den highway=* dazugetagt werden. In OSM sollten nur echte Routen als Relationen gemapt werden. Die from/to-tags werde ich künftig gerne berücksichtigen.
Einen wunderschönen Abend euch allen Urs
Am 23. Juni 2021 16:19:14 MESZ schrieb michael spreng mailinglist@osm.datendelphin.net:
Hallo zusammen
Zuerst möchte ich noch auf den online "Stammtisch" heute Abend hinweisen, ab 18:30 Uhr auf https://pub.digitale-gesellschaft.ch/b/pat-6h2-rqy Kommt doch auch, gewisse Sachen lassen sich vielleicht einfacher im Gespräch Lösen.
Ich habe heute Morgen viel Zeit damit verbracht, die verschiedenen Beiträge zu lesen und nachzuvollziehen.
Ich bin trotzdem nach wie vor der Überzeugung, dass wir unterscheiden sollten zwischen dem Netz und den technischen Routen/Wegweiser Zielen. Ich verweise hier auf das, was BAK365 und Sarah sehr gut dargelegt haben. Alles andere wird in gewissen Fällen zu einem Knobelspiel. Wo es viele benannte Wegweiser hat, macht es keinen unterschied. An den Stellen, wo es zum Knobelspiel würde, wird es einfach: jeder Abschnitt ist in einer Relation. Die Relation kann auch mal bis zur übernächsten Verzweigung gehen, wenn das gerade passt.
Zum name tag sehe ich, dass ein paar den Vorschlag mit from=/to= aufgenommen haben, andere (René und Urs) haben das bis jetzt ignoriert. Ich verstehe den Bedarf an "Metadaten", wie es René nennt. Das einzige, was sich ändert, ist ein anderes tag. Genügt das from=/to= als Ersatz? Den name tag so zu gebrauchen steht einfach quer zum Rest von OSM. Dies hat immer wieder zu Konflikten geführt und das wird nicht weg gehen. Ich sehe keine Chance für den name tag.
Grüsse Michael _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Hallo zusammen,
ein weiterer Aspekt:
Wenn man "lokale Routen" ab Wegweisern kartiert (z.B. Davos Dorf - Seehorn) dan sollte man den osmc:symbol tag nicht dazu benutzen, die Schwierigkeit dieser Route zu charakterisieren. Der osmc tag ist dazu da eine spezifische Routenmarkierung wiederzugeben. Folgt man der Markierung kommt man ans Ziel. Dies ist hierzulande zum Beispiel bei den Helsana Trails mit grün, blau und gelb markierten Runden der Fall. Dagegen haben unsere "lokalen Routen" keine spezifische Markierung. Folge ich z.B. den gelben Markierungen, dann kann problemlos ich irgendwo am Bodensee enden. :-)
Dass Routenmarkierung und Schwierigkeit nicht synoym sind zeigt sich v.a. in den Übergangsbereichen. Im Beispiel vom Wanderweg zum Seehorn wäre der Weg zuerst gelb markiert, dann weiss-rot-weiss. Teilt man der Route jetzt aufgrund ihrer Schwierigkeit "rot-weiss-rot"-markiert zu, dann stimmt das nicht mit der realen Welt überein. [1] Wenn gleichzeitig eine zweite lokale Route zum Wolfgang "gelb"-markiert angelegt wird, dann haben wir dann den Salat. :-)
Dagegen stimmten Markierung auf Karte und Gelände bei der Verwendung der osmc:symbol tags nach der Erfassung des Wandeswegnetzes mittels Relationen von Knoten zu Knoten (=Wanderweg-Basisnetz) überein . Das spezifische Symbol leitet die WandererIn vom Anfang zum Schluss des Segments.
Ich schlage darum folgende Punkte vor:
* Die Schwierigkeit einer Route wird grundsätzlich auf den darunterliegenen highways mittels SAC Berg-und Alpinwanderskala erfasst. [2] * Etwas redundant dazu aber möglicherweise sinnvoll: Für die maximale Schwierigkeit einer "lokalen Route" wird ein neuer tag "SAC_difficulty" auf der Relation eingeführt. * Die Markierung im Gelände wird strikt auf dem Wanderweg-Basisnetz gemappt. * Dagegen haben alle übergelagerten lokalen, regionalen, nationalen und internationalen Routen nur einen osmc:symbol tag, wenn sie auch effektiv eine eigene Symbolik aufweisen. (z.B. Weisse Tafeln mit grünen Routennummern). Sind die Routen dagegen nur Wandervorschläge/Varianten auf dem Wanderweg-Basisnetz bleibt der osmc:symbol tag dieser Relation leer.
Na? Stehe ich total im Schilf?
Beste Grüsse, Martin Landscapemapper & lm@Door2Peak
[1] https://s.geo.admin.ch/916e25552f [2] https://www.sac-cas.ch/fileadmin/Ausbildung_und_Wissen/Tourenplanung/Schwier... On 23.06.2021 20:02, Flips wrote:
Hallo zusammen
Die Info zum Stammtisch habe ich jetzt zu spät gelesen. Vielleicht beim nächsten Mal.
Ich sehe die Routen nicht sls technische Routen, sondern als offizielle Routen. Warum sonst gibt es auf den Wegweisern Endziele mit Zeitangaben und von einigen Wegweiserstandorten aus Routen über verschiedene Wege zum selben Ziel. Dies wäre oftmals gar nicht nötig, um das ganze Netz abzubilden, da schon andere Routen die selben Streckenabschnitte abdecken.
Wenn das Wanderwegnetz nur als Netz ohne Routen verstanden wird, dann sollten, wie ich es schon in einem vorherigen Mail beschrieben habe, einzig die lcn=yes zu den highway=* dazugetagt werden. In OSM sollten nur echte Routen als Relationen gemapt werden. Die from/to-tags werde ich künftig gerne berücksichtigen.
Einen wunderschönen Abend euch allen Urs
Am 23. Juni 2021 16:19:14 MESZ schrieb michael spreng mailinglist@osm.datendelphin.net:
Hallo zusammen Zuerst möchte ich noch auf den online "Stammtisch" heute Abend hinweisen, ab 18:30 Uhr auf https://pub.digitale-gesellschaft.ch/b/pat-6h2-rqy <https://pub.digitale-gesellschaft.ch/b/pat-6h2-rqy> Kommt doch auch, gewisse Sachen lassen sich vielleicht einfacher im Gespräch Lösen. Ich habe heute Morgen viel Zeit damit verbracht, die verschiedenen Beiträge zu lesen und nachzuvollziehen. Ich bin trotzdem nach wie vor der Überzeugung, dass wir unterscheiden sollten zwischen dem Netz und den technischen Routen/Wegweiser Zielen. Ich verweise hier auf das, was BAK365 und Sarah sehr gut dargelegt haben. Alles andere wird in gewissen Fällen zu einem Knobelspiel. Wo es viele benannte Wegweiser hat, macht es keinen unterschied. An den Stellen, wo es zum Knobelspiel würde, wird es einfach: jeder Abschnitt ist in einer Relation. Die Relation kann auch mal bis zur übernächsten Verzweigung gehen, wenn das gerade passt. Zum name tag sehe ich, dass ein paar den Vorschlag mit from=/to= aufgenommen haben, andere (René und Urs) haben das bis jetzt ignoriert. Ich verstehe den Bedarf an "Metadaten", wie es René nennt. Das einzige, was sich ändert, ist ein anderes tag. Genügt das from=/to= als Ersatz? Den name tag so zu gebrauchen steht einfach quer zum Rest von OSM. Dies hat immer wieder zu Konflikten geführt und das wird nicht weg gehen. Ich sehe keine Chance für den name tag. Grüsse Michael ------------------------------------------------------------------------ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch>
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Hallo Urs
On 23.06.21 20:02, Flips wrote:
Die Info zum Stammtisch habe ich jetzt zu spät gelesen. Vielleicht beim nächsten Mal.
Also um 20:00 Uhr waren wir noch lange nicht fertig :)
Ich sehe die Routen nicht sls technische Routen, sondern als offizielle Routen. Warum sonst gibt es auf den Wegweisern Endziele mit Zeitangaben und von einigen Wegweiserstandorten aus Routen über verschiedene Wege zum selben Ziel. Dies wäre oftmals gar nicht nötig, um das ganze Netz abzubilden, da schon andere Routen die selben Streckenabschnitte abdecken.
Wenn das Wanderwegnetz nur als Netz ohne Routen verstanden wird, dann sollten, wie ich es schon in einem vorherigen Mail beschrieben habe, einzig die lcn=yes zu den highway=* dazugetagt werden. In OSM sollten nur echte Routen als Relationen gemapt werden. Die from/to-tags werde ich künftig gerne berücksichtigen.
Das würde technisch verhindern, dass eine way mehrmals vor kommt. Aber: Es gibt einen starken Bruch zwischen Regionen, wo es keine "referenz" (Name, Nummer, was auch immer) gibt für die Komponenten des Basisnetz (CH), und Regionen, wo es das eben gibt. Sarah hat da am Stammtisch ein Beispiel gezeigt für letzteres. Und man verliert die Möglichkeit, das from/to zu tagen für den Unterhalt, was ein grosses Anliegen zu sein scheint.
Grüsse Michael
Dear Michael, dear all
Thanks, Michael, for your proposal and the changes in the Wiki [1]. I just wanted to support these changes as you announced in this thread. We really need a base network for hiking which is routable! These changes don't exclude the many named routes mappers are eager to add (as relations) on top of that proper base network.
~Stefan
[1] https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork
Am Sa., 26. Juni 2021 um 11:32 Uhr schrieb michael spreng mailinglist@osm.datendelphin.net:
Hallo Urs
On 23.06.21 20:02, Flips wrote:
Die Info zum Stammtisch habe ich jetzt zu spät gelesen. Vielleicht beim nächsten Mal.
Also um 20:00 Uhr waren wir noch lange nicht fertig :)
Ich sehe die Routen nicht sls technische Routen, sondern als offizielle Routen. Warum sonst gibt es auf den Wegweisern Endziele mit Zeitangaben und von einigen Wegweiserstandorten aus Routen über verschiedene Wege zum selben Ziel. Dies wäre oftmals gar nicht nötig, um das ganze Netz abzubilden, da schon andere Routen die selben Streckenabschnitte abdecken.
Wenn das Wanderwegnetz nur als Netz ohne Routen verstanden wird, dann sollten, wie ich es schon in einem vorherigen Mail beschrieben habe, einzig die lcn=yes zu den highway=* dazugetagt werden. In OSM sollten nur echte Routen als Relationen gemapt werden. Die from/to-tags werde ich künftig gerne berücksichtigen.
Das würde technisch verhindern, dass eine way mehrmals vor kommt. Aber: Es gibt einen starken Bruch zwischen Regionen, wo es keine "referenz" (Name, Nummer, was auch immer) gibt für die Komponenten des Basisnetz (CH), und Regionen, wo es das eben gibt. Sarah hat da am Stammtisch ein Beispiel gezeigt für letzteres. Und man verliert die Möglichkeit, das from/to zu tagen für den Unterhalt, was ein grosses Anliegen zu sein scheint.
Grüsse Michael _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
The recent changes of the wiki do not reflect how currently hiking routes are tagged and do not reflect the status of the discussion here on the mailing list. I will revert them at the end of this week, but I hope the author of the changes will do it earlier.
lg rene
On Sun, 11 Jul 2021 at 14:13, Stefan Keller sfkeller@gmail.com wrote:
Dear Michael, dear all
Thanks, Michael, for your proposal and the changes in the Wiki [1]. I just wanted to support these changes as you announced in this thread. We really need a base network for hiking which is routable! These changes don't exclude the many named routes mappers are eager to add (as relations) on top of that proper base network.
~Stefan
[1] https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork
Am Sa., 26. Juni 2021 um 11:32 Uhr schrieb michael spreng mailinglist@osm.datendelphin.net:
Hallo Urs
On 23.06.21 20:02, Flips wrote:
Die Info zum Stammtisch habe ich jetzt zu spät gelesen. Vielleicht beim nächsten Mal.
Also um 20:00 Uhr waren wir noch lange nicht fertig :)
Ich sehe die Routen nicht sls technische Routen, sondern als offizielle Routen. Warum sonst gibt es auf den Wegweisern Endziele mit Zeitangaben und von einigen Wegweiserstandorten aus Routen über verschiedene Wege zum selben Ziel. Dies wäre oftmals gar nicht nötig, um das ganze Netz abzubilden, da schon andere Routen die selben Streckenabschnitte
abdecken.
Wenn das Wanderwegnetz nur als Netz ohne Routen verstanden wird, dann sollten, wie ich es schon in einem vorherigen Mail beschrieben habe, einzig die lcn=yes zu den highway=* dazugetagt werden. In OSM sollten nur echte Routen als Relationen gemapt werden. Die from/to-tags werde ich künftig gerne berücksichtigen.
Das würde technisch verhindern, dass eine way mehrmals vor kommt. Aber: Es gibt einen starken Bruch zwischen Regionen, wo es keine "referenz" (Name, Nummer, was auch immer) gibt für die Komponenten des Basisnetz (CH), und Regionen, wo es das eben gibt. Sarah hat da am Stammtisch ein Beispiel gezeigt für letzteres. Und man verliert die Möglichkeit, das from/to zu tagen für den Unterhalt, was ein grosses Anliegen zu sein scheint.
Grüsse Michael _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Dear René, lieber René
Bitte mach das nicht. Dem Edit ist einige Diskussion vorausgegangen u.a. mit denjenigen, die die Wiki-Seite erstellt haben. Pls. don't do that because the way currently hiking routes are tagged is broken. Let's talk in person in order to explain the reasons e.g. at next Zürcher OSM-Treffen? . Are you available this thursday or friday? See https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#1...
Liebe Grüsse, Stefan
Am Di., 13. Juli 2021 um 20:41 Uhr schrieb René Buffat buffat@gmail.com:
The recent changes of the wiki do not reflect how currently hiking routes are tagged and do not reflect the status of the discussion here on the mailing list. I will revert them at the end of this week, but I hope the author of the changes will do it earlier.
lg rene
On Sun, 11 Jul 2021 at 14:13, Stefan Keller sfkeller@gmail.com wrote:
Dear Michael, dear all
Thanks, Michael, for your proposal and the changes in the Wiki [1]. I just wanted to support these changes as you announced in this thread. We really need a base network for hiking which is routable! These changes don't exclude the many named routes mappers are eager to add (as relations) on top of that proper base network.
~Stefan
[1] https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork
Am Sa., 26. Juni 2021 um 11:32 Uhr schrieb michael spreng mailinglist@osm.datendelphin.net:
Hallo Urs
On 23.06.21 20:02, Flips wrote:
Die Info zum Stammtisch habe ich jetzt zu spät gelesen. Vielleicht beim nächsten Mal.
Also um 20:00 Uhr waren wir noch lange nicht fertig :)
Ich sehe die Routen nicht sls technische Routen, sondern als offizielle Routen. Warum sonst gibt es auf den Wegweisern Endziele mit Zeitangaben und von einigen Wegweiserstandorten aus Routen über verschiedene Wege zum selben Ziel. Dies wäre oftmals gar nicht nötig, um das ganze Netz abzubilden, da schon andere Routen die selben Streckenabschnitte abdecken.
Wenn das Wanderwegnetz nur als Netz ohne Routen verstanden wird, dann sollten, wie ich es schon in einem vorherigen Mail beschrieben habe, einzig die lcn=yes zu den highway=* dazugetagt werden. In OSM sollten nur echte Routen als Relationen gemapt werden. Die from/to-tags werde ich künftig gerne berücksichtigen.
Das würde technisch verhindern, dass eine way mehrmals vor kommt. Aber: Es gibt einen starken Bruch zwischen Regionen, wo es keine "referenz" (Name, Nummer, was auch immer) gibt für die Komponenten des Basisnetz (CH), und Regionen, wo es das eben gibt. Sarah hat da am Stammtisch ein Beispiel gezeigt für letzteres. Und man verliert die Möglichkeit, das from/to zu tagen für den Unterhalt, was ein grosses Anliegen zu sein scheint.
Grüsse Michael _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Dear Stefan
Can you elaborate on what exactly is broken that should have been fixed by the recent changes?
For me, it seems as the recent changes of the wiki are pushed by people not involved, or only recently involved in mapping hiking routes.
I think everyone agrees that the current state of the Wiki is not optimal. But before significant changes are made these should be discussed with the community that is actively mapping hiking routes. It is pointless to change the wiki when the active contributors are not aware of the changes or were not involved in these discussions.
As far as I'm aware is the person that created the wiki entry has not been actively involved in mapping hiking routes since at least a few years ago.
lg rene
On Wed, 14 Jul 2021 at 00:51, Stefan Keller sfkeller@gmail.com wrote:
Dear René, lieber René
Bitte mach das nicht. Dem Edit ist einige Diskussion vorausgegangen u.a. mit denjenigen, die die Wiki-Seite erstellt haben. Pls. don't do that because the way currently hiking routes are tagged is broken. Let's talk in person in order to explain the reasons e.g. at next Zürcher OSM-Treffen? . Are you available this thursday or friday? See https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#1...
Liebe Grüsse, Stefan
Am Di., 13. Juli 2021 um 20:41 Uhr schrieb René Buffat buffat@gmail.com:
The recent changes of the wiki do not reflect how currently hiking
routes are tagged and do not reflect the status of the discussion here on the mailing list. I will revert them at the end of this week, but I hope the author of the changes will do it earlier.
lg rene
On Sun, 11 Jul 2021 at 14:13, Stefan Keller sfkeller@gmail.com wrote:
Dear Michael, dear all
Thanks, Michael, for your proposal and the changes in the Wiki [1]. I just wanted to support these changes as you announced in this thread. We really need a base network for hiking which is routable! These changes don't exclude the many named routes mappers are eager to add (as relations) on top of that proper base network.
~Stefan
[1] https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork
Am Sa., 26. Juni 2021 um 11:32 Uhr schrieb michael spreng mailinglist@osm.datendelphin.net:
Hallo Urs
On 23.06.21 20:02, Flips wrote:
Die Info zum Stammtisch habe ich jetzt zu spät gelesen. Vielleicht
beim
nächsten Mal.
Also um 20:00 Uhr waren wir noch lange nicht fertig :)
Ich sehe die Routen nicht sls technische Routen, sondern als
offizielle
Routen. Warum sonst gibt es auf den Wegweisern Endziele mit
Zeitangaben
und von einigen Wegweiserstandorten aus Routen über verschiedene
Wege
zum selben Ziel. Dies wäre oftmals gar nicht nötig, um das ganze
Netz
abzubilden, da schon andere Routen die selben Streckenabschnitte
abdecken.
Wenn das Wanderwegnetz nur als Netz ohne Routen verstanden wird,
dann
sollten, wie ich es schon in einem vorherigen Mail beschrieben habe, einzig die lcn=yes zu den highway=* dazugetagt werden. In OSM
sollten
nur echte Routen als Relationen gemapt werden. Die from/to-tags werde ich künftig gerne berücksichtigen.
Das würde technisch verhindern, dass eine way mehrmals vor kommt.
Aber:
Es gibt einen starken Bruch zwischen Regionen, wo es keine "referenz" (Name, Nummer, was auch immer) gibt für die Komponenten des Basisnetz (CH), und Regionen, wo es das eben gibt. Sarah hat da am Stammtisch
ein
Beispiel gezeigt für letzteres. Und man verliert die Möglichkeit, das from/to zu tagen für den Unterhalt, was ein grosses Anliegen zu sein scheint.
Grüsse Michael _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Rene,
On Wed, Jul 14, 2021 at 06:31:24AM +0200, René Buffat wrote:
I think everyone agrees that the current state of the Wiki is not optimal. But before significant changes are made these should be discussed with the community that is actively mapping hiking routes. It is pointless to change the wiki when the active contributors are not aware of the changes or were not involved in these discussions.
So how can we get in touch with you to get a personal discussion going? The mailing list has not proved to be a very effective so far.
Sarah
Hi René
You are setting a lot of pressure on me personally. I humbly started out to tackle this topic as an all-round mapper. A kind of moderator. Having mapped hiking routes as I encountered them since quite a few years. But of course nothing compared to you.
Your hand hovering above the nuclear button of a revert is duly noted.
I also get the impression that the mailing list is now only turning around each individual with roundabout statements. While the initial discussion was fruitful and informative, I now get nothing of substance that I could use to improve the situation further, especially on such short notice.
I like the proposal to discuss this in a meeting, and encourage everyone to participate
https://cloud.sosm.ch/index.php/apps/polls/s/Oi42HVw6gsR6L0mD https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#1...
Michael
On 14.07.21 06:31, René Buffat wrote:
Dear Stefan
Can you elaborate on what exactly is broken that should have been fixed by the recent changes?
1: Name tag, 2: It was self contradicting for named guide posts
For me, it seems as the recent changes of the wiki are pushed by people not involved, or only recently involved in mapping hiking routes.
I think everyone agrees that the current state of the Wiki is not optimal. But before significant changes are made these should be discussed with the community that is actively mapping hiking routes. It is pointless to change the wiki when the active contributors are not aware of the changes or were not involved in these discussions.
As far as I'm aware is the person that created the wiki entry has not been actively involved in mapping hiking routes since at least a few years ago.
lg rene
On Wed, 14 Jul 2021 at 00:51, Stefan Keller <sfkeller@gmail.com mailto:sfkeller@gmail.com> wrote:
Dear René, lieber René Bitte mach das nicht. Dem Edit ist einige Diskussion vorausgegangen u.a. mit denjenigen, die die Wiki-Seite erstellt haben. Pls. don't do that because the way currently hiking routes are tagged is broken. Let's talk in person in order to explain the reasons e.g. at next Zürcher OSM-Treffen? . Are you available this thursday or friday? See https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#130._OSM-Stammtisch_Juli_.28tbd..29_2021 <https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#130._OSM-Stammtisch_Juli_.28tbd..29_2021> Liebe Grüsse, Stefan Am Di., 13. Juli 2021 um 20:41 Uhr schrieb René Buffat <buffat@gmail.com <mailto:buffat@gmail.com>>: > > The recent changes of the wiki do not reflect how currently hiking routes are tagged and do not reflect the status of the discussion here on the mailing list. I will revert them at the end of this week, but I hope the author of the changes will do it earlier. > > lg rene > > On Sun, 11 Jul 2021 at 14:13, Stefan Keller <sfkeller@gmail.com <mailto:sfkeller@gmail.com>> wrote: >> >> Dear Michael, dear all >> >> Thanks, Michael, for your proposal and the changes in the Wiki [1]. >> I just wanted to support these changes as you announced in this thread. >> We really need a base network for hiking which is routable! >> These changes don't exclude the many named routes mappers are eager to >> add (as relations) on top of that proper base network. >> >> ~Stefan >> >> [1] https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork <https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork> >> >> Am Sa., 26. Juni 2021 um 11:32 Uhr schrieb michael spreng >> <mailinglist@osm.datendelphin.net <mailto:mailinglist@osm.datendelphin.net>>: >> > >> > Hallo Urs >> > >> > On 23.06.21 20:02, Flips wrote: >> > > Die Info zum Stammtisch habe ich jetzt zu spät gelesen. Vielleicht beim >> > > nächsten Mal. >> > >> > Also um 20:00 Uhr waren wir noch lange nicht fertig :) >> > >> > > >> > > Ich sehe die Routen nicht sls technische Routen, sondern als offizielle >> > > Routen. Warum sonst gibt es auf den Wegweisern Endziele mit Zeitangaben >> > > und von einigen Wegweiserstandorten aus Routen über verschiedene Wege >> > > zum selben Ziel. Dies wäre oftmals gar nicht nötig, um das ganze Netz >> > > abzubilden, da schon andere Routen die selben Streckenabschnitte abdecken. >> > > >> > > Wenn das Wanderwegnetz nur als Netz ohne Routen verstanden wird, dann >> > > sollten, wie ich es schon in einem vorherigen Mail beschrieben habe, >> > > einzig die lcn=yes zu den highway=* dazugetagt werden. In OSM sollten >> > > nur echte Routen als Relationen gemapt werden. >> > > Die from/to-tags werde ich künftig gerne berücksichtigen. >> > >> > Das würde technisch verhindern, dass eine way mehrmals vor kommt. Aber: >> > Es gibt einen starken Bruch zwischen Regionen, wo es keine "referenz" >> > (Name, Nummer, was auch immer) gibt für die Komponenten des Basisnetz >> > (CH), und Regionen, wo es das eben gibt. Sarah hat da am Stammtisch ein >> > Beispiel gezeigt für letzteres. Und man verliert die Möglichkeit, das >> > from/to zu tagen für den Unterhalt, was ein grosses Anliegen zu sein >> > scheint. >> > >> > Grüsse >> > Michael >> > _______________________________________________ >> > talk-ch mailing list >> > talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch> >> > http://lists.openstreetmap.ch/mailman/listinfo/talk-ch <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch> >> _______________________________________________ >> talk-ch mailing list >> talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch> >> http://lists.openstreetmap.ch/mailman/listinfo/talk-ch <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch> > > _______________________________________________ > talk-ch mailing list > talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch> > http://lists.openstreetmap.ch/mailman/listinfo/talk-ch <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch> _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch> http://lists.openstreetmap.ch/mailman/listinfo/talk-ch <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch>
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
I would suggest to contact the most active mappers (that contributed during the last 1-2 years to the hiking network) with direct messages. I assume most of these mappers are not necessarily subscribed to this mailing list or present at a Stammtisch.
lg rene
On Wed, 14 Jul 2021 at 14:41, michael spreng < mailinglist@osm.datendelphin.net> wrote:
Hi René
You are setting a lot of pressure on me personally. I humbly started out to tackle this topic as an all-round mapper. A kind of moderator. Having mapped hiking routes as I encountered them since quite a few years. But of course nothing compared to you.
Your hand hovering above the nuclear button of a revert is duly noted.
I also get the impression that the mailing list is now only turning around each individual with roundabout statements. While the initial discussion was fruitful and informative, I now get nothing of substance that I could use to improve the situation further, especially on such short notice.
I like the proposal to discuss this in a meeting, and encourage everyone to participate
https://cloud.sosm.ch/index.php/apps/polls/s/Oi42HVw6gsR6L0mD
https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#1...
Michael
On 14.07.21 06:31, René Buffat wrote:
Dear Stefan
Can you elaborate on what exactly is broken that should have been fixed by the recent changes?
1: Name tag, 2: It was self contradicting for named guide posts
For me, it seems as the recent changes of the wiki are pushed by people not involved, or only recently involved in mapping hiking routes.
I think everyone agrees that the current state of the Wiki is not optimal. But before significant changes are made these should be discussed with the community that is actively mapping hiking routes. It is pointless to change the wiki when the active contributors are not aware of the changes or were not involved in these discussions.
As far as I'm aware is the person that created the wiki entry has not been actively involved in mapping hiking routes since at least a few years ago.
lg rene
On Wed, 14 Jul 2021 at 00:51, Stefan Keller <sfkeller@gmail.com mailto:sfkeller@gmail.com> wrote:
Dear René, lieber René Bitte mach das nicht. Dem Edit ist einige Diskussion vorausgegangen u.a. mit denjenigen, die die Wiki-Seite erstellt haben. Pls. don't do that because the way currently hiking routes are tagged is broken. Let's talk in person in order to explain the reasons e.g. at next Zürcher OSM-Treffen? . Are you available this thursday or friday? Seehttps://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#1...
<https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#1...
Liebe Grüsse, Stefan Am Di., 13. Juli 2021 um 20:41 Uhr schrieb René Buffat <buffat@gmail.com <mailto:buffat@gmail.com>>: > > The recent changes of the wiki do not reflect how currently hiking routes are tagged and do not reflect the status of the discussion here on the mailing list. I will revert them at the end of this week, but I hope the author of the changes will do it earlier. > > lg rene > > On Sun, 11 Jul 2021 at 14:13, Stefan Keller <sfkeller@gmail.com <mailto:sfkeller@gmail.com>> wrote: >> >> Dear Michael, dear all >> >> Thanks, Michael, for your proposal and the changes in the Wiki[1].
>> I just wanted to support these changes as you announced in this thread. >> We really need a base network for hiking which is routable! >> These changes don't exclude the many named routes mappers are eager to >> add (as relations) on top of that proper base network. >> >> ~Stefan >> >> [1] https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork <https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork> >> >> Am Sa., 26. Juni 2021 um 11:32 Uhr schrieb michael spreng >> <mailinglist@osm.datendelphin.net <mailto:mailinglist@osm.datendelphin.net>>: >> > >> > Hallo Urs >> > >> > On 23.06.21 20:02, Flips wrote: >> > > Die Info zum Stammtisch habe ich jetzt zu spät gelesen. Vielleicht beim >> > > nächsten Mal. >> > >> > Also um 20:00 Uhr waren wir noch lange nicht fertig :) >> > >> > > >> > > Ich sehe die Routen nicht sls technische Routen, sondern als offizielle >> > > Routen. Warum sonst gibt es auf den Wegweisern Endziele mit Zeitangaben >> > > und von einigen Wegweiserstandorten aus Routen über verschiedene Wege >> > > zum selben Ziel. Dies wäre oftmals gar nicht nötig, um das ganze Netz >> > > abzubilden, da schon andere Routen die selben Streckenabschnitte abdecken. >> > > >> > > Wenn das Wanderwegnetz nur als Netz ohne Routen verstanden wird, dann >> > > sollten, wie ich es schon in einem vorherigen Mail beschrieben habe, >> > > einzig die lcn=yes zu den highway=* dazugetagt werden. In OSM sollten >> > > nur echte Routen als Relationen gemapt werden. >> > > Die from/to-tags werde ich künftig gerne berücksichtigen. >> > >> > Das würde technisch verhindern, dass eine way mehrmals vor kommt. Aber: >> > Es gibt einen starken Bruch zwischen Regionen, wo es keine "referenz" >> > (Name, Nummer, was auch immer) gibt für die Komponenten des Basisnetz >> > (CH), und Regionen, wo es das eben gibt. Sarah hat da am Stammtisch ein >> > Beispiel gezeigt für letzteres. Und man verliert die Möglichkeit, das >> > from/to zu tagen für den Unterhalt, was ein grosses Anliegen zu sein >> > scheint. >> > >> > Grüsse >> > Michael >> > _______________________________________________ >> > talk-ch mailing list >> > talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch> >> > http://lists.openstreetmap.ch/mailman/listinfo/talk-ch <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch> >> _______________________________________________ >> talk-ch mailing list >> talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch> >> http://lists.openstreetmap.ch/mailman/listinfo/talk-ch <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch> > > _______________________________________________ > talk-ch mailing list > talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch> > http://lists.openstreetmap.ch/mailman/listinfo/talk-ch <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch> _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch> http://lists.openstreetmap.ch/mailman/listinfo/talk-ch <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch>
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
This has been done from the start of this whole discussion, with exception of those who were already known to be active recently on the mailinglist.
Michael
On 14.07.21 22:34, René Buffat wrote:
I would suggest to contact the most active mappers (that contributed during the last 1-2 years to the hiking network) with direct messages. I assume most of these mappers are not necessarily subscribed to this mailing list or present at a Stammtisch.
lg rene
On Wed, 14 Jul 2021 at 14:41, michael spreng <mailinglist@osm.datendelphin.net mailto:mailinglist@osm.datendelphin.net> wrote:
Hi René You are setting a lot of pressure on me personally. I humbly started out to tackle this topic as an all-round mapper. A kind of moderator. Having mapped hiking routes as I encountered them since quite a few years. But of course nothing compared to you. Your hand hovering above the nuclear button of a revert is duly noted. I also get the impression that the mailing list is now only turning around each individual with roundabout statements. While the initial discussion was fruitful and informative, I now get nothing of substance that I could use to improve the situation further, especially on such short notice. I like the proposal to discuss this in a meeting, and encourage everyone to participate https://cloud.sosm.ch/index.php/apps/polls/s/Oi42HVw6gsR6L0mD <https://cloud.sosm.ch/index.php/apps/polls/s/Oi42HVw6gsR6L0mD> https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#130._OSM-Stammtisch_Juli_.28tbd..29_2021 <https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#130._OSM-Stammtisch_Juli_.28tbd..29_2021> Michael On 14.07.21 06:31, René Buffat wrote: > Dear Stefan > > Can you elaborate on what exactly is broken that should have been fixed > by the recent changes? 1: Name tag, 2: It was self contradicting for named guide posts > > For me, it seems as the recent changes of the wiki are pushed by people > not involved, or only recently involved in mapping hiking routes. > > I think everyone agrees that the current state of the Wiki is not > optimal. But before significant changes are made these should be > discussed with the community that is actively mapping hiking routes. It > is pointless to change the wiki when the active contributors are not > aware of the changes or were not involved in these discussions. > > As far as I'm aware is the person that created the wiki entry has not > been actively involved in mapping hiking routes since at least a few > years ago. > > lg rene > > > On Wed, 14 Jul 2021 at 00:51, Stefan Keller <sfkeller@gmail.com <mailto:sfkeller@gmail.com> > <mailto:sfkeller@gmail.com <mailto:sfkeller@gmail.com>>> wrote: > > Dear René, lieber René > > Bitte mach das nicht. Dem Edit ist einige Diskussion vorausgegangen > u.a. mit denjenigen, die die Wiki-Seite erstellt haben. > Pls. don't do that because the way currently hiking routes are > tagged is broken. > Let's talk in person in order to explain the reasons e.g. at next > Zürcher OSM-Treffen? . > Are you available this thursday or friday? > See > https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#130._OSM-Stammtisch_Juli_.28tbd..29_2021 <https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#130._OSM-Stammtisch_Juli_.28tbd..29_2021> > <https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#130._OSM-Stammtisch_Juli_.28tbd..29_2021 <https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#130._OSM-Stammtisch_Juli_.28tbd..29_2021>> > > Liebe Grüsse, Stefan > > Am Di., 13. Juli 2021 um 20:41 Uhr schrieb René Buffat > <buffat@gmail.com <mailto:buffat@gmail.com> <mailto:buffat@gmail.com <mailto:buffat@gmail.com>>>: > > > > The recent changes of the wiki do not reflect how currently hiking > routes are tagged and do not reflect the status of the discussion > here on the mailing list. I will revert them at the end of this > week, but I hope the author of the changes will do it earlier. > > > > lg rene > > > > On Sun, 11 Jul 2021 at 14:13, Stefan Keller <sfkeller@gmail.com <mailto:sfkeller@gmail.com> > <mailto:sfkeller@gmail.com <mailto:sfkeller@gmail.com>>> wrote: > >> > >> Dear Michael, dear all > >> > >> Thanks, Michael, for your proposal and the changes in the Wiki [1]. > >> I just wanted to support these changes as you announced in this > thread. > >> We really need a base network for hiking which is routable! > >> These changes don't exclude the many named routes mappers are > eager to > >> add (as relations) on top of that proper base network. > >> > >> ~Stefan > >> > >> [1] https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork <https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork> > <https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork <https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork>> > >> > >> Am Sa., 26. Juni 2021 um 11:32 Uhr schrieb michael spreng > >> <mailinglist@osm.datendelphin.net <mailto:mailinglist@osm.datendelphin.net> > <mailto:mailinglist@osm.datendelphin.net <mailto:mailinglist@osm.datendelphin.net>>>: > >> > > >> > Hallo Urs > >> > > >> > On 23.06.21 20:02, Flips wrote: > >> > > Die Info zum Stammtisch habe ich jetzt zu spät gelesen. > Vielleicht beim > >> > > nächsten Mal. > >> > > >> > Also um 20:00 Uhr waren wir noch lange nicht fertig :) > >> > > >> > > > >> > > Ich sehe die Routen nicht sls technische Routen, sondern als > offizielle > >> > > Routen. Warum sonst gibt es auf den Wegweisern Endziele mit > Zeitangaben > >> > > und von einigen Wegweiserstandorten aus Routen über > verschiedene Wege > >> > > zum selben Ziel. Dies wäre oftmals gar nicht nötig, um das > ganze Netz > >> > > abzubilden, da schon andere Routen die selben > Streckenabschnitte abdecken. > >> > > > >> > > Wenn das Wanderwegnetz nur als Netz ohne Routen verstanden > wird, dann > >> > > sollten, wie ich es schon in einem vorherigen Mail > beschrieben habe, > >> > > einzig die lcn=yes zu den highway=* dazugetagt werden. In OSM > sollten > >> > > nur echte Routen als Relationen gemapt werden. > >> > > Die from/to-tags werde ich künftig gerne berücksichtigen. > >> > > >> > Das würde technisch verhindern, dass eine way mehrmals vor > kommt. Aber: > >> > Es gibt einen starken Bruch zwischen Regionen, wo es keine > "referenz" > >> > (Name, Nummer, was auch immer) gibt für die Komponenten des > Basisnetz > >> > (CH), und Regionen, wo es das eben gibt. Sarah hat da am > Stammtisch ein > >> > Beispiel gezeigt für letzteres. Und man verliert die > Möglichkeit, das > >> > from/to zu tagen für den Unterhalt, was ein grosses Anliegen zu > sein > >> > scheint. > >> > > >> > Grüsse > >> > Michael > >> > _______________________________________________ > >> > talk-ch mailing list > >> > talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch> <mailto:talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch>> > >> > http://lists.openstreetmap.ch/mailman/listinfo/talk-ch <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch> > <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch>> > >> _______________________________________________ > >> talk-ch mailing list > >> talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch> <mailto:talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch>> > >> http://lists.openstreetmap.ch/mailman/listinfo/talk-ch <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch> > <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch>> > > > > _______________________________________________ > > talk-ch mailing list > > talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch> <mailto:talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch>> > > http://lists.openstreetmap.ch/mailman/listinfo/talk-ch <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch> > <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch>> > _______________________________________________ > talk-ch mailing list > talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch> <mailto:talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch>> > http://lists.openstreetmap.ch/mailman/listinfo/talk-ch <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch> > <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch>> > > > _______________________________________________ > talk-ch mailing list > talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch> > http://lists.openstreetmap.ch/mailman/listinfo/talk-ch <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch> > _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch> http://lists.openstreetmap.ch/mailman/listinfo/talk-ch <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch>
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Guten Abend, Nun ich bin ja der Hauptschuldige am jetzigen Zustand wie die Wanderwege gemappt sind. "Äxgüsi" Und ehrlich gesagt verstehe ich nicht ganz warum der Name tag durch from - to ersetzt werden muss. Ich habe es immer als logisch empfunden dass eine Relation den Namen erhält so wie es auf den Wegweisern steht. Und das Teilstücke doppelt vorkommen, entsteht dadurch das beim abzweigenden Wegweiser kein name+ele drauf steht. Jeder der Wanderwege mappt weiss dass das so ist. Frage: warum wird das eigentlich erst jetzt gross Diskutiert? Der bestehende Zustand existiert doch schon Jahre.
Wie gesagt, das ist meine rein persönliche Meinung, habe kein Problem das anders zu machen wenn dann einmal Klar ist wie.
Schönen Abend Ernst Lehmann
Am 15.07.2021 08:44, schrieb michael spreng:
This has been done from the start of this whole discussion, with exception of those who were already known to be active recently on the mailinglist.
Michael
On 14.07.21 22:34, René Buffat wrote:
I would suggest to contact the most active mappers (that contributed during the last 1-2 years to the hiking network) with direct messages. I assume most of these mappers are not necessarily subscribed to this mailing list or present at a Stammtisch.
lg rene
On Wed, 14 Jul 2021 at 14:41, michael spreng <mailinglist@osm.datendelphin.net mailto:mailinglist@osm.datendelphin.net> wrote:
Hi René You are setting a lot of pressure on me personally. I humblystarted out to tackle this topic as an all-round mapper. A kind of moderator. Having mapped hiking routes as I encountered them since quite a few years. But of course nothing compared to you.
Your hand hovering above the nuclear button of a revert is dulynoted.
I also get the impression that the mailing list is now onlyturning around each individual with roundabout statements. While the initial discussion was fruitful and informative, I now get nothing of substance that I could use to improve the situation further, especially on such short notice.
I like the proposal to discuss this in a meeting, and encourageeveryone to participate
https://cloud.sosm.ch/index.php/apps/polls/s/Oi42HVw6gsR6L0mD <https://cloud.sosm.ch/index.php/apps/polls/s/Oi42HVw6gsR6L0mD>https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#1...
Michael On 14.07.21 06:31, René Buffat wrote: > Dear Stefan > > Can you elaborate on what exactly is broken that should havebeen fixed > by the recent changes? 1: Name tag, 2: It was self contradicting for named guide posts > > For me, it seems as the recent changes of the wiki are pushed by people > not involved, or only recently involved in mapping hiking routes. > > I think everyone agrees that the current state of the Wiki is not > optimal. But before significant changes are made these should be > discussed with the community that is actively mapping hiking routes. It > is pointless to change the wiki when the active contributors are not > aware of the changes or were not involved in these discussions. > > As far as I'm aware is the person that created the wiki entry has not > been actively involved in mapping hiking routes since at least a few > years ago. > > lg rene > > > On Wed, 14 Jul 2021 at 00:51, Stefan Keller <sfkeller@gmail.com mailto:sfkeller@gmail.com > <mailto:sfkeller@gmail.com mailto:sfkeller@gmail.com>> wrote: > > Dear René, lieber René > > Bitte mach das nicht. Dem Edit ist einige Diskussion vorausgegangen > u.a. mit denjenigen, die die Wiki-Seite erstellt haben. > Pls. don't do that because the way currently hiking routes are > tagged is broken. > Let's talk in person in order to explain the reasons e.g. at next > Zürcher OSM-Treffen? . > Are you available this thursday or friday? > See >
https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#1...
<https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#1...
https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#130._OSM-Stammtisch_Juli_.28tbd..29_2021> > > Liebe Grüsse, Stefan > > Am Di., 13. Juli 2021 um 20:41 Uhr schrieb René Buffat > <buffat@gmail.com mailto:buffat@gmail.com <mailto:buffat@gmail.com mailto:buffat@gmail.com>>: > > > > The recent changes of the wiki do not reflect how currently hiking > routes are tagged and do not reflect the status of the discussion > here on the mailing list. I will revert them at the end of this > week, but I hope the author of the changes will do it earlier. > > > > lg rene > > > > On Sun, 11 Jul 2021 at 14:13, Stefan Keller <sfkeller@gmail.com mailto:sfkeller@gmail.com > <mailto:sfkeller@gmail.com mailto:sfkeller@gmail.com>> wrote: > >> > >> Dear Michael, dear all > >> > >> Thanks, Michael, for your proposal and the changes in the Wiki [1]. > >> I just wanted to support these changes as you announced in this > thread. > >> We really need a base network for hiking which is routable! > >> These changes don't exclude the many named routes mappers are > eager to > >> add (as relations) on top of that proper base network. > >> > >> ~Stefan > >> > >> [1] https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork > <https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork> > >> > >> Am Sa., 26. Juni 2021 um 11:32 Uhr schrieb michael spreng > >> <mailinglist@osm.datendelphin.net mailto:mailinglist@osm.datendelphin.net > <mailto:mailinglist@osm.datendelphin.net mailto:mailinglist@osm.datendelphin.net>>: > >> > > >> > Hallo Urs > >> > > >> > On 23.06.21 20:02, Flips wrote: > >> > > Die Info zum Stammtisch habe ich jetzt zu spät gelesen. > Vielleicht beim > >> > > nächsten Mal. > >> > > >> > Also um 20:00 Uhr waren wir noch lange nicht fertig :) > >> > > >> > > > >> > > Ich sehe die Routen nicht sls technische Routen, sondern als > offizielle > >> > > Routen. Warum sonst gibt es auf den Wegweisern Endziele mit > Zeitangaben > >> > > und von einigen Wegweiserstandorten aus Routen über > verschiedene Wege > >> > > zum selben Ziel. Dies wäre oftmals gar nicht nötig, um das > ganze Netz > >> > > abzubilden, da schon andere Routen die selben > Streckenabschnitte abdecken. > >> > > > >> > > Wenn das Wanderwegnetz nur als Netz ohne Routen verstanden > wird, dann > >> > > sollten, wie ich es schon in einem vorherigen Mail > beschrieben habe, > >> > > einzig die lcn=yes zu den highway=* dazugetagt werden. In OSM > sollten > >> > > nur echte Routen als Relationen gemapt werden. > >> > > Die from/to-tags werde ich künftig gerne berücksichtigen. > >> > > >> > Das würde technisch verhindern, dass eine way mehrmals vor > kommt. Aber: > >> > Es gibt einen starken Bruch zwischen Regionen, wo es keine > "referenz" > >> > (Name, Nummer, was auch immer) gibt für die Komponenten des > Basisnetz > >> > (CH), und Regionen, wo es das eben gibt. Sarah hat da am > Stammtisch ein > >> > Beispiel gezeigt für letzteres. Und man verliert die > Möglichkeit, das > >> > from/to zu tagen für den Unterhalt, was ein grosses Anliegen zu > sein > >> > scheint. > >> > > >> > Grüsse > >> > Michael > >> > _______________________________________________ > >> > talk-ch mailing list > >> > talk-ch@openstreetmap.ch mailto:talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch mailto:talk-ch@openstreetmap.ch> > >> > http://lists.openstreetmap.ch/mailman/listinfo/talk-ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch > <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch> > >> _______________________________________________ > >> talk-ch mailing list > >> talk-ch@openstreetmap.ch mailto:talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch mailto:talk-ch@openstreetmap.ch> > >> http://lists.openstreetmap.ch/mailman/listinfo/talk-ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch > <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch> > > > > _______________________________________________ > > talk-ch mailing list > > talk-ch@openstreetmap.ch mailto:talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch mailto:talk-ch@openstreetmap.ch> > > http://lists.openstreetmap.ch/mailman/listinfo/talk-ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch > <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch> > _______________________________________________ > talk-ch mailing list > talk-ch@openstreetmap.ch mailto:talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch mailto:talk-ch@openstreetmap.ch> > http://lists.openstreetmap.ch/mailman/listinfo/talk-ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch > <http://lists.openstreetmap.ch/mailman/listinfo/talk-ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch> > > > _______________________________________________ > talk-ch mailing list > talk-ch@openstreetmap.ch mailto:talk-ch@openstreetmap.ch > http://lists.openstreetmap.ch/mailman/listinfo/talk-ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch > _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch mailto:talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Ixh bitte euch alle sich etwas zurückzunehmen und morgen wenn immer es geht an Talk teilzunehmen. Aussenstehende wie ich sind wohl etwas irritiert über die asynchrone Kommunikation, die sicher sehr ungeeignet ist einen Konsens zu finden. Deshalb viel Erfolg am Onlinemeeting.
Liebe Grüsse
Peter
Von meinem iPhone gesendet
Am 15.07.2021 um 19:46 schrieb hecktor@ziknet.ch:
Guten Abend, Nun ich bin ja der Hauptschuldige am jetzigen Zustand wie die Wanderwege gemappt sind. "Äxgüsi" Und ehrlich gesagt verstehe ich nicht ganz warum der Name tag durch from - to ersetzt werden muss. Ich habe es immer als logisch empfunden dass eine Relation den Namen erhält so wie es auf den Wegweisern steht. Und das Teilstücke doppelt vorkommen, entsteht dadurch das beim abzweigenden Wegweiser kein name+ele drauf steht. Jeder der Wanderwege mappt weiss dass das so ist. Frage: warum wird das eigentlich erst jetzt gross Diskutiert? Der bestehende Zustand existiert doch schon Jahre.
Wie gesagt, das ist meine rein persönliche Meinung, habe kein Problem das anders zu machen wenn dann einmal Klar ist wie.
Schönen Abend Ernst Lehmann
Am 15.07.2021 08:44, schrieb michael spreng:
This has been done from the start of this whole discussion, with exception of those who were already known to be active recently on the mailinglist. Michael
On 14.07.21 22:34, René Buffat wrote: I would suggest to contact the most active mappers (that contributed during the last 1-2 years to the hiking network) with direct messages. I assume most of these mappers are not necessarily subscribed to this mailing list or present at a Stammtisch. lg rene On Wed, 14 Jul 2021 at 14:41, michael spreng <mailinglist@osm.datendelphin.net mailto:mailinglist@osm.datendelphin.net> wrote: Hi René You are setting a lot of pressure on me personally. I humbly started out to tackle this topic as an all-round mapper. A kind of moderator. Having mapped hiking routes as I encountered them since quite a few years. But of course nothing compared to you. Your hand hovering above the nuclear button of a revert is duly noted. I also get the impression that the mailing list is now only turning around each individual with roundabout statements. While the initial discussion was fruitful and informative, I now get nothing of substance that I could use to improve the situation further, especially on such short notice. I like the proposal to discuss this in a meeting, and encourage everyone to participate https://cloud.sosm.ch/index.php/apps/polls/s/Oi42HVw6gsR6L0mD https://cloud.sosm.ch/index.php/apps/polls/s/Oi42HVw6gsR6L0mD https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#1... https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#130._OSM-Stammtisch_Juli_.28tbd..29_2021 Michael
On 14.07.21 06:31, René Buffat wrote: Dear Stefan
Can you elaborate on what exactly is broken that should have been
fixed
by the recent changes?
1: Name tag, 2: It was self contradicting for named guide posts
For me, it seems as the recent changes of the wiki are pushed by
people
not involved, or only recently involved in mapping hiking routes.
I think everyone agrees that the current state of the Wiki is not optimal. But before significant changes are made these should be discussed with the community that is actively mapping hiking
routes. It
is pointless to change the wiki when the active contributors are not aware of the changes or were not involved in these discussions.
As far as I'm aware is the person that created the wiki entry has not been actively involved in mapping hiking routes since at least a few years ago.
lg rene
On Wed, 14 Jul 2021 at 00:51, Stefan Keller <sfkeller@gmail.com
<mailto:sfkeller@gmail.com mailto:sfkeller@gmail.com>> wrote:
Dear René, lieber René Bitte mach das nicht. Dem Edit ist einige Diskussionvorausgegangen
u.a. mit denjenigen, die die Wiki-Seite erstellt haben. Pls. don't do that because the way currently hiking routes are tagged is broken. Let's talk in person in order to explain the reasons e.g. at next Zürcher OSM-Treffen? . Are you available this thursday or friday? Seehttps://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#130._OSM-Stammtisch_Juli_.28tbd..29_2021<https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#130._OSM-Stammtisch_Juli_.28tbd..29_2021Liebe Grüsse, Stefan Am Di., 13. Juli 2021 um 20:41 Uhr schrieb René Buffat <buffat@gmail.com <mailto:buffat@gmail.com><mailto:buffat@gmail.com mailto:buffat@gmail.com>>:
> > The recent changes of the wiki do not reflect how currentlyhiking
routes are tagged and do not reflect the status of the discussion here on the mailing list. I will revert them at the end of this week, but I hope the author of the changes will do it earlier. > > lg rene > > On Sun, 11 Jul 2021 at 14:13, Stefan Keller<sfkeller@gmail.com mailto:sfkeller@gmail.com
<mailto:sfkeller@gmail.com <mailto:sfkeller@gmail.com>>> wrote: >> >> Dear Michael, dear all >> >> Thanks, Michael, for your proposal and the changes in theWiki [1].
>> I just wanted to support these changes as you announced in this thread. >> We really need a base network for hiking which is routable! >> These changes don't exclude the many named routes mappers are eager to >> add (as relations) on top of that proper base network. >> >> ~Stefan >> >> [1]https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork
<https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetworkhttps://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork>
>> >> Am Sa., 26. Juni 2021 um 11:32 Uhr schrieb michael spreng >> <mailinglist@osm.datendelphin.netmailto:mailinglist@osm.datendelphin.net
<mailto:mailinglist@osm.datendelphin.netmailto:mailinglist@osm.datendelphin.net>>:
>> > >> > Hallo Urs >> > >> > On 23.06.21 20:02, Flips wrote: >> > > Die Info zum Stammtisch habe ich jetzt zu spät gelesen. Vielleicht beim >> > > nächsten Mal. >> > >> > Also um 20:00 Uhr waren wir noch lange nicht fertig :) >> > >> > > >> > > Ich sehe die Routen nicht sls technische Routen,sondern als
offizielle >> > > Routen. Warum sonst gibt es auf den Wegweisern Endziele mit Zeitangaben >> > > und von einigen Wegweiserstandorten aus Routen über verschiedene Wege >> > > zum selben Ziel. Dies wäre oftmals gar nicht nötig, um das ganze Netz >> > > abzubilden, da schon andere Routen die selben Streckenabschnitte abdecken. >> > > >> > > Wenn das Wanderwegnetz nur als Netz ohne Routen verstanden wird, dann >> > > sollten, wie ich es schon in einem vorherigen Mail beschrieben habe, >> > > einzig die lcn=yes zu den highway=* dazugetagt werden.In OSM
sollten >> > > nur echte Routen als Relationen gemapt werden. >> > > Die from/to-tags werde ich künftig gerne berücksichtigen. >> > >> > Das würde technisch verhindern, dass eine way mehrmals vor kommt. Aber: >> > Es gibt einen starken Bruch zwischen Regionen, wo es keine "referenz" >> > (Name, Nummer, was auch immer) gibt für die Komponenten des Basisnetz >> > (CH), und Regionen, wo es das eben gibt. Sarah hat da am Stammtisch ein >> > Beispiel gezeigt für letzteres. Und man verliert die Möglichkeit, das >> > from/to zu tagen für den Unterhalt, was ein grossesAnliegen zu
sein >> > scheint. >> > >> > Grüsse >> > Michael >> > _______________________________________________ >> > talk-ch mailing list >> > talk-ch@openstreetmap.chmailto:talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch mailto:talk-ch@openstreetmap.ch>
>> > http://lists.openstreetmap.ch/mailman/listinfo/talk-chhttp://lists.openstreetmap.ch/mailman/listinfo/talk-ch
<http://lists.openstreetmap.ch/mailman/listinfo/talk-chhttp://lists.openstreetmap.ch/mailman/listinfo/talk-ch>
>> _______________________________________________ >> talk-ch mailing list >> talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch><mailto:talk-ch@openstreetmap.ch mailto:talk-ch@openstreetmap.ch>
>> http://lists.openstreetmap.ch/mailman/listinfo/talk-chhttp://lists.openstreetmap.ch/mailman/listinfo/talk-ch
<http://lists.openstreetmap.ch/mailman/listinfo/talk-chhttp://lists.openstreetmap.ch/mailman/listinfo/talk-ch>
> > _______________________________________________ > talk-ch mailing list > talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch><mailto:talk-ch@openstreetmap.ch mailto:talk-ch@openstreetmap.ch>
> http://lists.openstreetmap.ch/mailman/listinfo/talk-chhttp://lists.openstreetmap.ch/mailman/listinfo/talk-ch
<http://lists.openstreetmap.ch/mailman/listinfo/talk-chhttp://lists.openstreetmap.ch/mailman/listinfo/talk-ch>
_______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch <mailto:talk-ch@openstreetmap.ch><mailto:talk-ch@openstreetmap.ch mailto:talk-ch@openstreetmap.ch>
http://lists.openstreetmap.ch/mailman/listinfo/talk-chhttp://lists.openstreetmap.ch/mailman/listinfo/talk-ch
<http://lists.openstreetmap.ch/mailman/listinfo/talk-chhttp://lists.openstreetmap.ch/mailman/listinfo/talk-ch>
talk-ch mailing list talk-ch@openstreetmap.ch mailto:talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch mailto:talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Was ist jetzt mit dem Online-Stammtisch zu den Wanderwegen? Es ist ja kein Mensch da. Oder benutze ich einen falschen Link? Ich habe bei der ganzen E-mail-Flut der letzten Tage die Übersicht verloren.
Liebe Grüsse Urs
Hallo Urs
Bin auch reingefallen. Die Sache war gestern 15. Juli.
Liebe Grüsse
Peter
Von meinem iPhone gesendet
Am 16.07.2021 um 20:08 schrieb Flips Flips@gmx.ch:
Was ist jetzt mit dem Online-Stammtisch zu den Wanderwegen? Es ist ja kein Mensch da. Oder benutze ich einen falschen Link? Ich habe bei der ganzen E-mail-Flut der letzten Tage die Übersicht verloren.
Liebe Grüsse Urs _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Lieber Flips, lieber Peter
Tut mir leid, dass ihr euch gefreut und gewartet habt. Ich habe den definitiven Termin hier auf talk-ch noch gepostet und auf [1] aktualisiert. Ich muss zugeben, dass war eine sehr spontane und kurzfristige Sache und entschuldige mich nochmals dafür. Der Abend ist übrigens positiv und in Minne verlaufen! Später mehr dazu.
Der nächste Stammtisch findet regulär am üblichen 11. des Monats August: siehe [1]. Dieser ist in-person geplant - was natürlich die Frage aufwirft, was wir mit denjenigen machen, die nur online dabei sein wollen. Ich frage mal herum, was wir da machen können.
Beste Grüsse, Stefan
[1] https://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen
Am Fr., 16. Juli 2021 um 20:52 Uhr schrieb Peter Berger peter.berger@bluewin.ch:
Hallo Urs
Bin auch reingefallen. Die Sache war gestern 15. Juli.
Liebe Grüsse
Peter
Von meinem iPhone gesendet
Am 16.07.2021 um 20:08 schrieb Flips Flips@gmx.ch:
Was ist jetzt mit dem Online-Stammtisch zu den Wanderwegen? Es ist ja kein Mensch da. Oder benutze ich einen falschen Link? Ich habe bei der ganzen E-mail-Flut der letzten Tage die Übersicht verloren.
Liebe Grüsse Urs _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Hallo Ernst
Danke für deinen Beitrag.
Zum Namen hier nochmals die Kurzversion, falls du nicht die ganze Diskussion nachgelesen hast
On 15.07.21 19:46, hecktor@ziknet.ch wrote:
Ich habe es immer als logisch empfunden dass eine Relation den Namen erhält so wie es auf den Wegweisern steht.
Aber das steht ja nicht so auf dem Wegweiser. Der enthält Ziele. Die Zielorte, die haben Namen. Aber der Weg führt erstens zu mehreren Zielen, und zu unterschiedlichen je nach Richtung. Ansonsten sei auf https://wiki.openstreetmap.org/wiki/DE:Names#name_ist_nur_der_Name und das dort verlinkte Taggen für den Renderer verwiesen.
Sarah hat die Problematik erklärt: Durch diesen Missbrauch des name tags kann man die Namen von Routen aktuell nicht such bar machen. Weil sonst bei einer Suche nach "Grünwil Bahnhof" lauter Wanderrouten als Resultate kommen. Darum können leider Routen, die wirklich einen Namen haben, nicht gefunden werden.
Frage: warum wird das eigentlich erst jetzt gross Diskutiert? Der bestehende Zustand existiert doch schon Jahre.
Hier ist die erste Diskussion, die ich gefunden habe: https://www.openstreetmap.org/changeset/53724311 Vielleicht hätte ich dich damals mehr nötigen sollen. Aber ich hatte halt auch keine Lust der zu sein, der andere anschwärzt (Wir haben es ihm gesagt aber jetzt macht er es immer noch...)
Grüsse Michael
Hoi zusammen,
ich möchte vorschlagen, dass anstelle von Ortsbezeichnungen auch Höhenkoten in den from und to tags einer Relation des Wanderwegnetzes angewendet werden können.
Kann ich via Höhenmesser oder in gewissen Kantonen via offenem Höhenmodell eine verlässsliche Höhe eines Knotens eruieren, trage ich diesen unter dem ele-tags des Wegweisers ein [1]. Unter from resp. to beziehe ich mich dann diese Höhenkoten als "P.xxxx" (z.B. P.1674) In der Regel sind diese Werte in ihrer näheren Umgebung eindeutig.
Ein Vorteil dieses Vorgehens läge darin, dass Segmente des Wanderwegnetzes zwischen zwei Knoten als abgeschlossene Relation leicht identifizierbar wären, ohne dass für unbenannte Knoten lokale Namen "erfunden" werden müssten. Als positiver Nebeneffekt würde die Repräsentation von Steigung resp. Gefälle im Wanderwegnetz deutlich verbessert [2].
Beste Grüsse,
Martin Lerjen
[1] Hier erwarte ich von Seiten SOSM eine Klärung, was erlaubt ist und was nicht. Meine Vision wäre, dass wir ein Open Elevation Modell unterhalten würden von dem einerseits bessere Höhenkurven, aber auch Höhenkoten oder Linienprofile abgeleitet werden könnten.
[2] Wanderwegnetz Region Arosa mit ele-tags auf unbenannten Wegweisern (Die Höhenwerte wurden uns von Bündner Wanderwege zur Verfüngung gestellt.) https://hiking.waymarkedtrails.org/#?map=16!46.7777!9.7033 https://hiking.waymarkedtrails.org/#route?id=8908889&map=16!46.7776!9.7042
Hallo Martin
Ich finde das keine gute Idee, auf den Wegweiser-Knoten die Höhe einzutragen. Es soll ja nur das eingetragen werden, was vor Ort auch zu sehen ist. Im Kanton Zürich ist seit einigen Jahren bei allen ersetzten oder neu aufgestellten Wegweisern klein eine 8-stellige Nummer aufgedruckt. Die Nummer bezieht sich auf das schweizer Koordinatensystem. Eine Nummer sieht dann zB. so aus 69026902. Diese könnte also bei uns und eventuell in den anderen Kantonen benutzt werden.
Liebe Grüsse Urs
Am 28. Juli 2021 09:37:55 MESZ schrieb Martin Lerjen mlerjen@ubol.ch:
Hoi zusammen,
ich möchte vorschlagen, dass anstelle von Ortsbezeichnungen auch Höhenkoten in den from und to tags einer Relation des Wanderwegnetzes angewendet werden können.
Kann ich via Höhenmesser oder in gewissen Kantonen via offenem Höhenmodell eine verlässsliche Höhe eines Knotens eruieren, trage ich diesen unter dem ele-tags des Wegweisers ein [1]. Unter from resp. to beziehe ich mich dann diese Höhenkoten als "P.xxxx" (z.B. P.1674) In der Regel sind diese Werte in ihrer näheren Umgebung eindeutig.
Ein Vorteil dieses Vorgehens läge darin, dass Segmente des Wanderwegnetzes zwischen zwei Knoten als abgeschlossene Relation leicht identifizierbar
wären, ohne dass für unbenannte Knoten lokale Namen "erfunden" werden müssten. Als positiver Nebeneffekt würde die Repräsentation von Steigung resp. Gefälle im Wanderwegnetz deutlich verbessert [2].
Beste Grüsse,
Martin Lerjen
[1] Hier erwarte ich von Seiten SOSM eine Klärung, was erlaubt ist und was nicht. Meine Vision wäre, dass wir ein Open Elevation Modell unterhalten würden von dem einerseits bessere Höhenkurven, aber auch Höhenkoten oder Linienprofile abgeleitet werden könnten.
[2] Wanderwegnetz Region Arosa mit ele-tags auf unbenannten Wegweisern (Die Höhenwerte wurden uns von Bündner Wanderwege zur Verfüngung gestellt.) https://hiking.waymarkedtrails.org/#?map=16!46.7777!9.7033 https://hiking.waymarkedtrails.org/#route?id=8908889&map=16!46.7776!9.7042
Hallo Zusammen
Die Höhe ist ja wie die Koordinaten, das kann man Messen. Wir verwenden ja meist GPS, und leider ist bei GPS die Höhe um einen Faktor 3 ungenauer wie die Lage. Darum macht es Sinn, ein Höhenmodell mit ein zu beziehen, wie Martin das vorschlägt.
Eine ref Nummer kann natürlich auch erfasst und verwendet werden für from/to. Falls es eine gibt.
Hier noch ein Beispiel von letzter Woche. Ich bin an diesem Punkt entlang gekommen https://www.openstreetmap.org/node/8939660582 An einem unbenannten Wegweiser zweigt der Alpine weg ab. Ich habe mit Hilfe von Ortsnamen.ch einen Flurnamen in unmittelbarer Nähe gefunden, eingetragen, und als from in der Relation verwendet.
Ich denke Martin gibt sich hier viel Mühe, auf die Wünsche der Community einzugehen. Wenn der Vorschlag keinen Anklang findet, gibts halt einfach ein paar Routen ohne from oder to. Auch nicht so schlimm.
Grüsse Michael
On 28.07.21 10:59, Flips wrote:
Hallo Martin
Ich finde das keine gute Idee, auf den Wegweiser-Knoten die Höhe einzutragen. Es soll ja nur das eingetragen werden, was vor Ort auch zu sehen ist. Im Kanton Zürich ist seit einigen Jahren bei allen ersetzten oder neu aufgestellten Wegweisern klein eine 8-stellige Nummer aufgedruckt. Die Nummer bezieht sich auf das schweizer Koordinatensystem. Eine Nummer sieht dann zB. so aus 69026902. Diese könnte also bei uns und eventuell in den anderen Kantonen benutzt werden.
Liebe Grüsse Urs
Am 28. Juli 2021 09:37:55 MESZ schrieb Martin Lerjen mlerjen@ubol.ch:
Hoi zusammen, ich möchte vorschlagen, dass anstelle von Ortsbezeichnungen auch Höhenkoten in den from und to tags einer Relation des Wanderwegnetzes angewendet werden können. Kann ich via Höhenmesser oder in gewissen Kantonen via offenem Höhenmodell eine verlässsliche Höhe eines Knotens eruieren, trage ich diesen unter dem ele-tags des Wegweisers ein [1]. Unter from resp. to beziehe ich mich dann diese Höhenkoten als "P.xxxx" (z.B. P.1674) In der Regel sind diese Werte in ihrer näheren Umgebung eindeutig. Ein Vorteil dieses Vorgehens läge darin, dass Segmente des Wanderwegnetzes zwischen zwei Knoten als abgeschlossene Relation leicht identifizierbar wären, ohne dass für unbenannte Knoten lokale Namen "erfunden" werden müssten. Als positiver Nebeneffekt würde die Repräsentation von Steigung resp. Gefälle im Wanderwegnetz deutlich verbessert [2]. Beste Grüsse, Martin Lerjen [1] Hier erwarte ich von Seiten SOSM eine Klärung, was erlaubt ist und was nicht. Meine Vision wäre, dass wir ein Open Elevation Modell unterhalten würden von dem einerseits bessere Höhenkurven, aber auch Höhenkoten oder Linienprofile abgeleitet werden könnten. [2] Wanderwegnetz Region Arosa mit ele-tags auf unbenannten Wegweisern (Die Höhenwerte wurden uns von Bündner Wanderwege zur Verfüngung gestellt.) https://hiking.waymarkedtrails.org/#?map=16!46.7777!9.7033 <https://hiking.waymarkedtrails.org/#route?id=8908889&map=16!46.7776!9.7042>
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Hallo zusammen,
die Höhe der Wegweiser einzutragen finde ich gut. ele muss ja nicht eine vor Ort angeschriebene Höhenangabe sein, auch wenn dies bei Wegweisern in der Schweiz bisher so üblich ist. Ich würde nur vorschlagen in diesen Fällen dann über source:ele= auf die Datenquelle zu verweisen (default wäre source:ele=guidepost).
Ausserdem finde ich noname=yes hier sinnvoll. Dadurch dass bisher Höhenangaben fast nur auf benannten Wegweisern eintragen sind, ist so klarer dass diese Wegweiser wirklich unbenannt sind (siehe auch die Diskussion hier: https://www.openstreetmap.org/changeset/108526613).
Grüsse, Enno
On Thu, Jul 29, 2021 at 7:54 AM michael spreng < mailinglist@osm.datendelphin.net> wrote:
Hallo Zusammen
Die Höhe ist ja wie die Koordinaten, das kann man Messen. Wir verwenden ja meist GPS, und leider ist bei GPS die Höhe um einen Faktor 3 ungenauer wie die Lage. Darum macht es Sinn, ein Höhenmodell mit ein zu beziehen, wie Martin das vorschlägt.
Eine ref Nummer kann natürlich auch erfasst und verwendet werden für from/to. Falls es eine gibt.
Hier noch ein Beispiel von letzter Woche. Ich bin an diesem Punkt entlang gekommen https://www.openstreetmap.org/node/8939660582 An einem unbenannten Wegweiser zweigt der Alpine weg ab. Ich habe mit Hilfe von Ortsnamen.ch einen Flurnamen in unmittelbarer Nähe gefunden, eingetragen, und als from in der Relation verwendet.
Ich denke Martin gibt sich hier viel Mühe, auf die Wünsche der Community einzugehen. Wenn der Vorschlag keinen Anklang findet, gibts halt einfach ein paar Routen ohne from oder to. Auch nicht so schlimm.
Grüsse Michael
On 28.07.21 10:59, Flips wrote:
Hallo Martin
Ich finde das keine gute Idee, auf den Wegweiser-Knoten die Höhe einzutragen. Es soll ja nur das eingetragen werden, was vor Ort auch zu sehen ist. Im Kanton Zürich ist seit einigen Jahren bei allen ersetzten oder neu aufgestellten Wegweisern klein eine 8-stellige Nummer aufgedruckt. Die Nummer bezieht sich auf das schweizer Koordinatensystem. Eine Nummer sieht dann zB. so aus 69026902. Diese könnte also bei uns und eventuell in den anderen Kantonen benutzt werden.
Liebe Grüsse Urs
Am 28. Juli 2021 09:37:55 MESZ schrieb Martin Lerjen mlerjen@ubol.ch:
Hoi zusammen, ich möchte vorschlagen, dass anstelle von Ortsbezeichnungen auch Höhenkoten in den from und to tags einer Relation des Wanderwegnetzes angewendet werden können. Kann ich via Höhenmesser oder in gewissen Kantonen via offenem Höhenmodell eine verlässsliche Höhe eines Knotens eruieren, trage ich diesen unter dem ele-tags des Wegweisers ein [1]. Unter from resp. to beziehe ich mich dann diese Höhenkoten als "P.xxxx" (z.B. P.1674) In der Regel sind diese Werte in ihrer näheren Umgebung eindeutig. Ein Vorteil dieses Vorgehens läge darin, dass Segmente des Wanderwegnetzes zwischen zwei Knoten als abgeschlossene Relation leicht identifizierbar wären, ohne dass für unbenannte Knoten lokale Namen "erfunden" werdenmüssten.
Als positiver Nebeneffekt würde die Repräsentation von Steigung resp. Gefälle im Wanderwegnetz deutlich verbessert [2]. Beste Grüsse, Martin Lerjen [1] Hier erwarte ich von Seiten SOSM eine Klärung, was erlaubt ist und was nicht. Meine Vision wäre, dass wir ein Open Elevation Modell unterhalten würden von dem einerseits bessere Höhenkurven, aber auch Höhenkoten oder Linienprofile abgeleitet werden könnten. [2] Wanderwegnetz Region Arosa mit ele-tags auf unbenanntenWegweisern
(Die Höhenwerte wurden uns von Bündner Wanderwege zur Verfüngung gestellt.) https://hiking.waymarkedtrails.org/#?map=16!46.7777!9.7033 <https://hiking.waymarkedtrails.org/#route?id=8908889&map=16!46.7776!9.70...
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Dear all,
I also disagree with these wiki edits.
On Wed, Jul 14, 2021 at 12:51 AM Stefan Keller sfkeller@gmail.com wrote:
Dem Edit ist einige Diskussion vorausgegangen u.a. mit denjenigen, die die Wiki-Seite erstellt haben. Pls. don't do that because the way currently hiking routes are tagged is broken.
Yes, there has been a lot of discussion and from this it should have been clear that there is no unanimous support for the proposed changes and many questions were left unanswered. What is it that is currently broken?
One argument was that in regions with few named guideposts, too many relations would have to be created with the established guidelines. But now a lot of base network hiking routes have been imported in Graubünden based on these "new" guidelines with an extreme fragmentation of relations that often consist only of a single way of a few hundred meters [1]. How is that an improvement? It's easy to create data this way when copying from the cantonal GIS, but this is difficult to maintain through on-the-ground surveys because of the lack of metadata.
It also shows a contradiction of the proposal: from= and to= tags were proposed to identify the start and end point of a route, which I support. But how would these be used in the case of the stub relations in Graubünden [1]? Should names be invented and how would these then be distinguished from actual guidepost names? If the proposal was strictly followed, routes would almost never start at a named guidepost because it is very common that multiple routes start at a named guidepost and then split off shortly after that at an unnamed one as we saw in Glarus [2]. Something mentioned again and again is that a way should not be in more than one base network relation, so I ask once more, why is that a problem? Ways can be members of many other relations anyway and if multiple routes follow that way it can certainly be mapped like that.
As I said before, I'm not strictly against adapting the tagging guidelines for regions in which the signposting is not yet done according to the federal guidelines [3], e.g. Graubünden. But this must not involve invalidating the current tagging for other regions where it works and is widely applied already.
If some of you prefer to have a personal discussion on this topic, we can arrange a time for that, although I'd prefer decisions to be made publicly through the mailing list or wiki.
[1] https://hiking.waymarkedtrails.org/#routelist?map=17!46.8068!9.8499 [2] https://hiking.waymarkedtrails.org/#routelist?map=18!47.1253!9.0534 [3] https://www.schweizer-wanderwege.ch/de/wanderwegmitarbeiter/handbuechermerkb...
Best, Enno
I don't think that this region was mapped according to the recent changes of the wiki. Or at least not consistent. E.g. see https://hiking.waymarkedtrails.org/#route?id=12854777
I guess for the Door2Peak project there was pressure to map the area as fast as possible without having too much thought on long-term maintainability.
To be fair, this is also a herculean task for only a limited number of mappers: - Until recently, there was no high quality imagery for this region available - And the region has a low population density, thus the chances of missing or not accurate ways is quite high - A lot of hiking routes are in forests, and a useful dtm hillshade will only be available next year, so probably the quality of existing ways in forests is not ideal - It is a large region and there is quite a dense hiking network combined with that nearly nothing was mapped previously
On Wed, 14 Jul 2021 at 10:04, Enno Hermann enno.hermann@gmail.com wrote:
Dear all,
I also disagree with these wiki edits.
On Wed, Jul 14, 2021 at 12:51 AM Stefan Keller sfkeller@gmail.com wrote:
Dem Edit ist einige Diskussion vorausgegangen u.a. mit denjenigen, die die Wiki-Seite erstellt haben. Pls. don't do that because the way currently hiking routes are tagged is broken.
Yes, there has been a lot of discussion and from this it should have been clear that there is no unanimous support for the proposed changes and many questions were left unanswered. What is it that is currently broken?
One argument was that in regions with few named guideposts, too many relations would have to be created with the established guidelines. But now a lot of base network hiking routes have been imported in Graubünden based on these "new" guidelines with an extreme fragmentation of relations that often consist only of a single way of a few hundred meters [1]. How is that an improvement? It's easy to create data this way when copying from the cantonal GIS, but this is difficult to maintain through on-the-ground surveys because of the lack of metadata.
It also shows a contradiction of the proposal: from= and to= tags were proposed to identify the start and end point of a route, which I support. But how would these be used in the case of the stub relations in Graubünden [1]? Should names be invented and how would these then be distinguished from actual guidepost names? If the proposal was strictly followed, routes would almost never start at a named guidepost because it is very common that multiple routes start at a named guidepost and then split off shortly after that at an unnamed one as we saw in Glarus [2]. Something mentioned again and again is that a way should not be in more than one base network relation, so I ask once more, why is that a problem? Ways can be members of many other relations anyway and if multiple routes follow that way it can certainly be mapped like that.
As I said before, I'm not strictly against adapting the tagging guidelines for regions in which the signposting is not yet done according to the federal guidelines [3], e.g. Graubünden. But this must not involve invalidating the current tagging for other regions where it works and is widely applied already.
If some of you prefer to have a personal discussion on this topic, we can arrange a time for that, although I'd prefer decisions to be made publicly through the mailing list or wiki.
[1] https://hiking.waymarkedtrails.org/#routelist?map=17!46.8068!9.8499 [2] https://hiking.waymarkedtrails.org/#routelist?map=18!47.1253!9.0534 [3] https://www.schweizer-wanderwege.ch/de/wanderwegmitarbeiter/handbuechermerkb...
Best, Enno _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Am Mi., 14. Juli 2021 um 17:27 Uhr schrieb René Buffat buffat@gmail.com:
I guess for the Door2Peak project there was pressure to map the area as fast as possible without having too much thought on long-term maintainability.
The contrary was the case: The preparations of this task have been a catalysator to get a (Swiss) base network of hiking paths which is maintainable and analyzable.
~Stefan
Am Mi., 14. Juli 2021 um 17:27 Uhr schrieb René Buffat buffat@gmail.com:
I don't think that this region was mapped according to the recent changes of the wiki. Or at least not consistent. E.g. see https://hiking.waymarkedtrails.org/#route?id=12854777
I guess for the Door2Peak project there was pressure to map the area as fast as possible without having too much thought on long-term maintainability.
To be fair, this is also a herculean task for only a limited number of mappers:
- Until recently, there was no high quality imagery for this region available
- And the region has a low population density, thus the chances of missing or not accurate ways is quite high
- A lot of hiking routes are in forests, and a useful dtm hillshade will only be available next year, so probably the quality of existing ways in forests is not ideal
- It is a large region and there is quite a dense hiking network combined with that nearly nothing was mapped previously
On Wed, 14 Jul 2021 at 10:04, Enno Hermann enno.hermann@gmail.com wrote:
Dear all,
I also disagree with these wiki edits.
On Wed, Jul 14, 2021 at 12:51 AM Stefan Keller sfkeller@gmail.com wrote:
Dem Edit ist einige Diskussion vorausgegangen u.a. mit denjenigen, die die Wiki-Seite erstellt haben. Pls. don't do that because the way currently hiking routes are tagged is broken.
Yes, there has been a lot of discussion and from this it should have been clear that there is no unanimous support for the proposed changes and many questions were left unanswered. What is it that is currently broken?
One argument was that in regions with few named guideposts, too many relations would have to be created with the established guidelines. But now a lot of base network hiking routes have been imported in Graubünden based on these "new" guidelines with an extreme fragmentation of relations that often consist only of a single way of a few hundred meters [1]. How is that an improvement? It's easy to create data this way when copying from the cantonal GIS, but this is difficult to maintain through on-the-ground surveys because of the lack of metadata.
It also shows a contradiction of the proposal: from= and to= tags were proposed to identify the start and end point of a route, which I support. But how would these be used in the case of the stub relations in Graubünden [1]? Should names be invented and how would these then be distinguished from actual guidepost names? If the proposal was strictly followed, routes would almost never start at a named guidepost because it is very common that multiple routes start at a named guidepost and then split off shortly after that at an unnamed one as we saw in Glarus [2]. Something mentioned again and again is that a way should not be in more than one base network relation, so I ask once more, why is that a problem? Ways can be members of many other relations anyway and if multiple routes follow that way it can certainly be mapped like that.
As I said before, I'm not strictly against adapting the tagging guidelines for regions in which the signposting is not yet done according to the federal guidelines [3], e.g. Graubünden. But this must not involve invalidating the current tagging for other regions where it works and is widely applied already.
If some of you prefer to have a personal discussion on this topic, we can arrange a time for that, although I'd prefer decisions to be made publicly through the mailing list or wiki.
[1] https://hiking.waymarkedtrails.org/#routelist?map=17!46.8068!9.8499 [2] https://hiking.waymarkedtrails.org/#routelist?map=18!47.1253!9.0534 [3] https://www.schweizer-wanderwege.ch/de/wanderwegmitarbeiter/handbuechermerkb...
Best, Enno _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Zur Ergänzung,
* *Die Arbeiten am Wanderwegnetz für die Region Lenzerheide - Arosa - Davos sind nicht abgeschlossen.* Informationen wie from und to sowie die guideposts werden - wo vorhanden - in einem zweiten Schritt bis Ende Monat ergänzt. Allerdings: Wenn es wenig benannte Knoten hat, dann gibt es auch viele Abschnitte, die nicht klar einem From-To Paar zugeordnet werden können.
* *Im Testgebiet Lenzerheide-Davos fehlen geschätzt kaum 2% der Wege auf denen die Wanderwege verlaufen.* Es hat also genug Mapper vor Ort, es wurden trotzdem kaum Wanderwege kartiert. An den Beispielen Engadin[1] und Zermatt [2] sieht man, dass sogar Wegweiser gemappt wurden, aber auch hier praktisch keine Wanderwege kartiert sind. Es ist ja schön, wenn es in anderen Regionen an jedem Knoten ein Namenschild hat. Gesucht ist aber eine allgemein praktikable Direktive. Der hier vertretene Anspruch in diesen Regionen fehlende benannte Knoten durch die Rekonstruktion der technischen Routen anhand der Tafeln zu kompensieren bring keine Verbesserung der Situation. Der angedrohte UNDO natürlich auch nicht. Eine klarere Trennung von Wanderwegnetzwerk und technischen Routen auf welche Michaels edit herausläuft und welche z.B. im Kt.ZH schon via superrouten praktiziert wird [3] dagegen schon. Der gemeine Mapper kartiert das Wanderwegnetz (=markierte Wege), der ambitionierte baut darauf die technischen Routen.
* *Die Bewilligung der Nutzung der GIS Daten für die Testregion von Seiten des Kt.GR liegt vor.* Der entsprechenden wiki Seite [4] könnt ihr entnehmen, nach welchen Ansätzen die Daten übernommen werden. Geometrien werden dabei nicht telquel übernommen, sondern die bestehende OSM Kartierung anhand der verfügbaren Informationen ab Strava und SwissImage ergänzt und justiert. Bereits gemappte Routen wurden in ihrer Gesamtheit belassen und höchstens der Verlauf und deutliche Fehler der Klassierung (z.B. path bei track) mit Hilfe von SwissImage korrigiert.
Gruss, Martin /landscapemapper
[1] https://hiking.waymarkedtrails.org/#?map=13!46.4387!9.8417 [2] https://hiking.waymarkedtrails.org/#?map=14!46.0019!7.756 [3] https://www.openstreetmap.org/relation/12397819 [4] https://wiki.openstreetmap.org/wiki/Organised_Editing/Activities/Door2Peak
On 14.07.2021 10:04, Enno Hermann wrote:
Dear all,
I also disagree with these wiki edits.
On Wed, Jul 14, 2021 at 12:51 AM Stefan Keller <sfkeller@gmail.com mailto:sfkeller@gmail.com> wrote:
Dem Edit ist einige Diskussion vorausgegangen u.a. mit denjenigen, die die Wiki-Seite erstellt haben. Pls. don't do that because the way currently hiking routes are tagged is broken.Yes, there has been a lot of discussion and from this it should have been clear that there is no unanimous support for the proposed changes and many questions were left unanswered. What is it that is currently broken?
One argument was that in regions with few named guideposts, too many relations would have to be created with the established guidelines. But now a lot of base network hiking routes have been imported in Graubünden based on these "new" guidelines with an extreme fragmentation of relations that often consist only of a single way of a few hundred meters [1]. How is that an improvement? It's easy to create data this way when copying from the cantonal GIS, but this is difficult to maintain through on-the-ground surveys because of the lack of metadata.
It also shows a contradiction of the proposal: from= and to= tags were proposed to identify the start and end point of a route, which I support. But how would these be used in the case of the stub relations in Graubünden [1]? Should names be invented and how would these then be distinguished from actual guidepost names? If the proposal was strictly followed, routes would almost never start at a named guidepost because it is very common that multiple routes start at a named guidepost and then split off shortly after that at an unnamed one as we saw in Glarus [2]. Something mentioned again and again is that a way should not be in more than one base network relation, so I ask once more, why is that a problem? Ways can be members of many other relations anyway and if multiple routes follow that way it can certainly be mapped like that.
As I said before, I'm not strictly against adapting the tagging guidelines for regions in which the signposting is not yet done according to the federal guidelines [3], e.g. Graubünden. But this must not involve invalidating the current tagging for other regions where it works and is widely applied already.
If some of you prefer to have a personal discussion on this topic, we can arrange a time for that, although I'd prefer decisions to be made publicly through the mailing list or wiki.
[1] https://hiking.waymarkedtrails.org/#routelist?map=17!46.8068!9.8499 https://hiking.waymarkedtrails.org/#routelist?map=17!46.8068!9.8499 [2] https://hiking.waymarkedtrails.org/#routelist?map=18!47.1253!9.0534 https://hiking.waymarkedtrails.org/#routelist?map=18!47.1253!9.0534 [3] https://www.schweizer-wanderwege.ch/de/wanderwegmitarbeiter/handbuechermerkb... https://www.schweizer-wanderwege.ch/de/wanderwegmitarbeiter/handbuechermerkblaetter
Best, Enno
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Liebe Community vom Nachbarland!
Die Diskussion habe ich mit großem Interesse verfolgt, da mir diese Thematik in Österreich für Fahrradnetze relevant erscheint. Den Vorschlag im Wiki halte ich für sehr vernünftig und gut umsetzbar.
Auch in Deutschland wird aktuell eine ähnliche Diskussion geführt: [1]"Proposal: Wander-/Radweg ggü. anderen Wege mit Wegweisern hervorheben?“ https://forum.openstreetmap.org/viewtopic.php?id=72458 [2]Das Proposal dazu ist im Entstehen: https://wiki.openstreetmap.org/wiki/User:JochenB/proposed_feature/basic_netw...
Es wäre sehr fein, die Ideen auszutauschen und die Proposals zu harmonisieren. Einen ähnlichen Text habe ich auch auf der Diskussionsseite von JochenB zum Proposal hinterlassen. Falls ohnehin Kommunikationskanäle bestehen, betrachtet bitte dieses Mail als gegenstandslos.
Beste Grüße aus Österreich Robert
(En français ci-dessous)
Hallo zusammen
Bitte entschuldigt, dass ich mich erst spät in die Diskussion einmische.
Den Vorschlag, die Wanderwege nur von Verzweigung zu Verzweigung einzuzeichnen, finde ich ziemlich befremdlich, vor allem weil es dann für mein Verständnis keine Routen, also `route=hiking`, mehr sind. Auch kann man bei diesen Routen-Bruchstücken die auf den Wegweisern angegebene Wanderzeit nicht mehr erfassen. Dass sich die auf den Wegweisern vorgeschlagenen Routen teilweise überlappen, bevor sie sich trennen, oder auch kreuzen ist normal und meines Erachtens kein Problem.
Wenn ihr jedoch der Meinung seid, dass die unbenannten und nicht nummerierten Wanderwege keine Routen sind (was ich durchaus nachvollziehen kann), oder wenn es tatsächlich Regionen gibt, die mit dem bisherigen Mapping-Schema nicht wirklich erfassbar sind, fände ich es logischer und einfacher, wie von Urs vorgeschlagen die Wege mit `lwn=yes` o. ä. zu markieren anstatt `route=hiking`-Relationen zu erstellen.
Hingegen finde ich den Vorschlag gut, das `name`-Tag nur für benannte Wanderrouten zu verwenden. Meiner Meinung nach ist `name` auch auf `information=guidepost` unpassend; besser wäre z. B. `title`.
Beste Grüsse
Raphael (dafadllyn)
----
Bonjour à tous
Je vous prie de m'excuser d'intervenir tardivement dans la discussion.
Je trouve la suggestion de dessiner les chemins de randonnée uniquement de branche à branche plutôt étrange, surtout parce que pour moi, ce ne sont plus des routes, c'est-à-dire des `route=hiking`. De plus, avec ces fragments d'itinéraire, le temps de randonnée indiqué sur les panneaux indicateurs ne peut plus être enregistré. Le fait que les itinéraires proposés sur les panneaux indicateurs se chevauchent parfois avant de se séparer ou même de se croiser est normal et, à mon avis, ne pose pas de problème.
Cependant, si vous êtes d'avis que les sentiers de randonnée non nommés et non numérotés ne sont pas des itinéraires (ce que je peux tout à fait comprendre), ou s'il y a effectivement des régions qui ne peuvent pas vraiment être capturées avec le schéma cartographique actuel, je trouverais plus logique et plus facile de marquer les sentiers avec `lwn=yes` ou similaire, comme suggéré par Urs, au lieu de créer des relations `route=hiking`.
Par contre, je pense que la proposition d'utiliser la balise `name` uniquement pour les itinéraires pédestres nommés est bonne. À mon avis, `name` est également inapproprié pour `information=guidepost` ; il vaudrait mieux utiliser par ex. `title`.
Meilleures salutations
Raphael (dafadllyn)
Hi all,
I'm new to this list, so let me start with a small introduction: I'm a Dutch mapper, but I visit Switzerland every now and then (my brother lives in Rieden SG) and I like to do some hiking and mapping here. In the Netherlands, I've done some mapping on the cycle node networks, and in Switzerland I like to work on the wanderwegen network (though I have not mapped much, so treat my input accordingly).
I've been involved on the wiki page discussion section before, and from the wiki page history found a link to this thread, which I have read with much interest. Hopefully I can add something to the discussion in this thread.
From reading this discussion, it seems that there are still some matters where no consensus has been reached (in particular the matter of overlapping or non-overlapping routes). But it also seems that there has been some discussion about this off-list. Maybe some consensus has been reached elsewhere?
In case you have not seen it yet: there has been some effort (initiated by Peter Elderson AFAIU) to document current practices and rationale about node networks. This is mostly based on the numbered cycle/walking networks in NL/BE, but explicit effort has been made to also include named networks like Germany and Switzerland uses. AFAIU there has already been some experiments involving parts of the german network.
The current state of this documentation can be found here:
https://wiki.openstreetmap.org/wiki/Node_Networks
If this has not been done already, I would suggest considering to make the Swiss tagging scheme either conform to that page, or modify/generalize that page to also apply to the Swiss tagging.
I just read through the page, and here's some notable observations from the current Swiss practice: - The primary goal of the model specified is to facilitate routing and rendering of node networks. For example, the knooppuntnet.nl website allows entering a starting and ending node, and calculates a route between them using only routes part of the network, and produces a list of node numbers to follow (support for names instead of numbers is nearly complete, I believe). For the Swiss case, this could work the same, but produce a list of named nodes/guideposts the route passes (so you could walk the route without bringing an actual map, just follow signs to each of the names in turn). - That page specifies to tag the actual junctions (as part of the ways they connect), instead of (or in addition to) the physical guideposts (besides the way they connect), which is a significant difference from the current Swiss practice. I believe the goal is to simplify routing, since you can then know which named junctions you pass exactly, without needing to find guideposts based on nearness. It can also help with network consistency checks (especially when combined with the expected_STn_route_relations attribute). - That page also talks about junctions without a number or name, and specifies to create multiple partially overlapping routes in that case (and tagging the unnamed nodes with `xxn_ref=*`). Note that for the Dutch case, unnumbered junctions are very rare and almost always in the near vicinity of a numbered node, so in the Swiss case in regions that have more unnamed junctions, overlapping routes might have additional downsides (such as a potential explosion of possible routes when multiple unnamed guideposts exist between named routes, and the extra difficulty mapping partial routes). - That page specifies to use `name=from-to` for named node networks (numbered networks use `ref=from-to`), while discussion on this list was moving towards not using the name anymore. However, it might be that that page specifies this to match current practice and could be changed without problems. - That page specifies a "network" relation (not strictly required, though), that collects all the routes and nodes belonging to a specific node network, to allow semantically grouping routes and specifying e.g. the operator once for the entire network. In the Swiss case, I think this could amount to one network relation for each Canton. - That page specifies a `network:type=node_network` attribute for nodes, routes and networks, to help distinguish them from regular routes.
Some earlier discussion about supporting named node networks has been done here: https://github.com/vmarc/knooppuntnet/issues/102 https://wiki.openstreetmap.org/wiki/Proposed_features/Named_nodes_in_node_ne...
Then, reading the wiki page in its current state, it seems to better reflect current and intended practice, which is good. However, I think there are still some things that could be clarified. In particular: - How to tag unnamed guideposts? Common practice seems to be to just omit name, maybe that should be explicit on the wiki? - How to handle numbered guideposts? For example in Graubünden (I walked in the area around Trin), I've seen guideposts (named and unnamed) that have a three-digit number that were already mapped with the number in the `ref` attribute, maybe that would be good to add to the wiki? For an example (with photo) see: https://www.openstreetmap.org/node/6100531211 Similarly, I understand that newer guideposts have a 6-digit unique number. - Would it make sense to put these guideposts numbers in the relations? Especially when using the "non-overlapping routes between junctions" approach, putting these numbers in the from and to attributes could help diagnose issues. OTOH, they are mostly meaningless to users, in the sense that the signing does not point *to* these numbers, you can only see them when you are at a particular guidepost. - How to tag from/to with unnamed guideposts? Should we invent names? Just omit the tag? I think no full consensus might have been reached here? - Maybe make explicit that name= was used with from-to before, since a lot of existing routes still have that. If it is explicit that this is no longer recommended, that will be less confusing for new mappers. - Is it ok to copy routes from the cantonal GIS systems? If not, or only from some, maybe make this explicit?
Gr.
Matthijs
Hi Matthijs, hi everyone
It seems that a consensus hasn't been reached yet - at least not on this list.
The Swiss hiking network is a bit peculiar. It's not a typical node network as the intersections (or nodes) aren't numbered and very often are unnamed. On the other hand the hiking trails (not including the routes from SchweizMobil) aren't typical routes as they are unnamed, unnumbered, have countless possible starts and ends and often have multiple variants from one named place to the next.
In my opinion, the simplest way to map the Swiss hiking trails is by adding a tag to the corresponding paths (maybe trail=hiking or hiking=designated) and using route=hiking routes only for the "real" SchweizMobil routes.
Best regards
Raphael (dafadllyn)
On Mon, 23 Aug 2021 at 20:21, Matthijs Kooijman matthijs@stdin.nl wrote:
Hi all,
I'm new to this list, so let me start with a small introduction: I'm a Dutch mapper, but I visit Switzerland every now and then (my brother lives in Rieden SG) and I like to do some hiking and mapping here. In the Netherlands, I've done some mapping on the cycle node networks, and in Switzerland I like to work on the wanderwegen network (though I have not mapped much, so treat my input accordingly).
I've been involved on the wiki page discussion section before, and from the wiki page history found a link to this thread, which I have read with much interest. Hopefully I can add something to the discussion in this thread.
From reading this discussion, it seems that there are still some matters where no consensus has been reached (in particular the matter of overlapping or non-overlapping routes). But it also seems that there has been some discussion about this off-list. Maybe some consensus has been reached elsewhere?
In case you have not seen it yet: there has been some effort (initiated by Peter Elderson AFAIU) to document current practices and rationale about node networks. This is mostly based on the numbered cycle/walking networks in NL/BE, but explicit effort has been made to also include named networks like Germany and Switzerland uses. AFAIU there has already been some experiments involving parts of the german network.
The current state of this documentation can be found here:
https://wiki.openstreetmap.org/wiki/Node_NetworksIf this has not been done already, I would suggest considering to make the Swiss tagging scheme either conform to that page, or modify/generalize that page to also apply to the Swiss tagging.
I just read through the page, and here's some notable observations from the current Swiss practice:
- The primary goal of the model specified is to facilitate routing and rendering of node networks. For example, the knooppuntnet.nl website allows entering a starting and ending node, and calculates a route between them using only routes part of the network, and produces a list of node numbers to follow (support for names instead of numbers is nearly complete, I believe). For the Swiss case, this could work the same, but produce a list of named nodes/guideposts the route passes (so you could walk the route without bringing an actual map, just follow signs to each of the names in turn).
- That page specifies to tag the actual junctions (as part of the ways they connect), instead of (or in addition to) the physical guideposts (besides the way they connect), which is a significant difference from the current Swiss practice. I believe the goal is to simplify routing, since you can then know which named junctions you pass exactly, without needing to find guideposts based on nearness. It can also help with network consistency checks (especially when combined with the expected_STn_route_relations attribute).
- That page also talks about junctions without a number or name, and specifies to create multiple partially overlapping routes in that case (and tagging the unnamed nodes with `xxn_ref=*`). Note that for the Dutch case, unnumbered junctions are very rare and almost always in the near vicinity of a numbered node, so in the Swiss case in regions that have more unnamed junctions, overlapping routes might have additional downsides (such as a potential explosion of possible routes when multiple unnamed guideposts exist between named routes, and the extra difficulty mapping partial routes).
- That page specifies to use `name=from-to` for named node networks (numbered networks use `ref=from-to`), while discussion on this list was moving towards not using the name anymore. However, it might be that that page specifies this to match current practice and could be changed without problems.
- That page specifies a "network" relation (not strictly required, though), that collects all the routes and nodes belonging to a specific node network, to allow semantically grouping routes and specifying e.g. the operator once for the entire network. In the Swiss case, I think this could amount to one network relation for each Canton.
- That page specifies a `network:type=node_network` attribute for nodes, routes and networks, to help distinguish them from regular routes.
Some earlier discussion about supporting named node networks has been done here: https://github.com/vmarc/knooppuntnet/issues/102 https://wiki.openstreetmap.org/wiki/Proposed_features/Named_nodes_in_node_ne...
Then, reading the wiki page in its current state, it seems to better reflect current and intended practice, which is good. However, I think there are still some things that could be clarified. In particular:
- How to tag unnamed guideposts? Common practice seems to be to just omit name, maybe that should be explicit on the wiki?
- How to handle numbered guideposts? For example in Graubünden (I walked in the area around Trin), I've seen guideposts (named and unnamed) that have a three-digit number that were already mapped with the number in the `ref` attribute, maybe that would be good to add to the wiki? For an example (with photo) see: https://www.openstreetmap.org/node/6100531211 Similarly, I understand that newer guideposts have a 6-digit unique number.
- Would it make sense to put these guideposts numbers in the relations? Especially when using the "non-overlapping routes between junctions" approach, putting these numbers in the from and to attributes could help diagnose issues. OTOH, they are mostly meaningless to users, in the sense that the signing does not point *to* these numbers, you can only see them when you are at a particular guidepost.
- How to tag from/to with unnamed guideposts? Should we invent names? Just omit the tag? I think no full consensus might have been reached here?
- Maybe make explicit that name= was used with from-to before, since a lot of existing routes still have that. If it is explicit that this is no longer recommended, that will be less confusing for new mappers.
- Is it ok to copy routes from the cantonal GIS systems? If not, or only from some, maybe make this explicit?
Gr.
Matthijs _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Why not just osmc:symbols=yellow_diamond on the ways? *=designated would be more for acces rights. Yves
Le 3 septembre 2021 21:09:24 GMT+02:00, Raphael dafadllyn@gmail.com a écrit :
Hi Matthijs, hi everyone
It seems that a consensus hasn't been reached yet - at least not on this list.
The Swiss hiking network is a bit peculiar. It's not a typical node network as the intersections (or nodes) aren't numbered and very often are unnamed. On the other hand the hiking trails (not including the routes from SchweizMobil) aren't typical routes as they are unnamed, unnumbered, have countless possible starts and ends and often have multiple variants from one named place to the next.
In my opinion, the simplest way to map the Swiss hiking trails is by adding a tag to the corresponding paths (maybe trail=hiking or hiking=designated) and using route=hiking routes only for the "real" SchweizMobil routes.
Best regards
Raphael (dafadllyn)
On Mon, 23 Aug 2021 at 20:21, Matthijs Kooijman matthijs@stdin.nl wrote:
Hi all,
I'm new to this list, so let me start with a small introduction: I'm a Dutch mapper, but I visit Switzerland every now and then (my brother lives in Rieden SG) and I like to do some hiking and mapping here. In the Netherlands, I've done some mapping on the cycle node networks, and in Switzerland I like to work on the wanderwegen network (though I have not mapped much, so treat my input accordingly).
I've been involved on the wiki page discussion section before, and from the wiki page history found a link to this thread, which I have read with much interest. Hopefully I can add something to the discussion in this thread.
From reading this discussion, it seems that there are still some matters where no consensus has been reached (in particular the matter of overlapping or non-overlapping routes). But it also seems that there has been some discussion about this off-list. Maybe some consensus has been reached elsewhere?
In case you have not seen it yet: there has been some effort (initiated by Peter Elderson AFAIU) to document current practices and rationale about node networks. This is mostly based on the numbered cycle/walking networks in NL/BE, but explicit effort has been made to also include named networks like Germany and Switzerland uses. AFAIU there has already been some experiments involving parts of the german network.
The current state of this documentation can be found here:
https://wiki.openstreetmap.org/wiki/Node_NetworksIf this has not been done already, I would suggest considering to make the Swiss tagging scheme either conform to that page, or modify/generalize that page to also apply to the Swiss tagging.
I just read through the page, and here's some notable observations from the current Swiss practice:
- The primary goal of the model specified is to facilitate routing and rendering of node networks. For example, the knooppuntnet.nl website allows entering a starting and ending node, and calculates a route between them using only routes part of the network, and produces a list of node numbers to follow (support for names instead of numbers is nearly complete, I believe). For the Swiss case, this could work the same, but produce a list of named nodes/guideposts the route passes (so you could walk the route without bringing an actual map, just follow signs to each of the names in turn).
- That page specifies to tag the actual junctions (as part of the ways they connect), instead of (or in addition to) the physical guideposts (besides the way they connect), which is a significant difference from the current Swiss practice. I believe the goal is to simplify routing, since you can then know which named junctions you pass exactly, without needing to find guideposts based on nearness. It can also help with network consistency checks (especially when combined with the expected_STn_route_relations attribute).
- That page also talks about junctions without a number or name, and specifies to create multiple partially overlapping routes in that case (and tagging the unnamed nodes with `xxn_ref=*`). Note that for the Dutch case, unnumbered junctions are very rare and almost always in the near vicinity of a numbered node, so in the Swiss case in regions that have more unnamed junctions, overlapping routes might have additional downsides (such as a potential explosion of possible routes when multiple unnamed guideposts exist between named routes, and the extra difficulty mapping partial routes).
- That page specifies to use `name=from-to` for named node networks (numbered networks use `ref=from-to`), while discussion on this list was moving towards not using the name anymore. However, it might be that that page specifies this to match current practice and could be changed without problems.
- That page specifies a "network" relation (not strictly required, though), that collects all the routes and nodes belonging to a specific node network, to allow semantically grouping routes and specifying e.g. the operator once for the entire network. In the Swiss case, I think this could amount to one network relation for each Canton.
- That page specifies a `network:type=node_network` attribute for nodes, routes and networks, to help distinguish them from regular routes.
Some earlier discussion about supporting named node networks has been done here: https://github.com/vmarc/knooppuntnet/issues/102 https://wiki.openstreetmap.org/wiki/Proposed_features/Named_nodes_in_node_ne...
Then, reading the wiki page in its current state, it seems to better reflect current and intended practice, which is good. However, I think there are still some things that could be clarified. In particular:
- How to tag unnamed guideposts? Common practice seems to be to just omit name, maybe that should be explicit on the wiki?
- How to handle numbered guideposts? For example in Graubünden (I walked in the area around Trin), I've seen guideposts (named and unnamed) that have a three-digit number that were already mapped with the number in the `ref` attribute, maybe that would be good to add to the wiki? For an example (with photo) see: https://www.openstreetmap.org/node/6100531211 Similarly, I understand that newer guideposts have a 6-digit unique number.
- Would it make sense to put these guideposts numbers in the relations? Especially when using the "non-overlapping routes between junctions" approach, putting these numbers in the from and to attributes could help diagnose issues. OTOH, they are mostly meaningless to users, in the sense that the signing does not point *to* these numbers, you can only see them when you are at a particular guidepost.
- How to tag from/to with unnamed guideposts? Should we invent names? Just omit the tag? I think no full consensus might have been reached here?
- Maybe make explicit that name= was used with from-to before, since a lot of existing routes still have that. If it is explicit that this is no longer recommended, that will be less confusing for new mappers.
- Is it ok to copy routes from the cantonal GIS systems? If not, or only from some, maybe make this explicit?
Gr.
Matthijs _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
On Fri, Sep 03, 2021 at 11:12:14PM +0200, Yves wrote:
Why not just osmc:symbols=yellow_diamond on the ways? *=designated would be more for acces rights.
Because using anything but relations creates an exception that data users have to know about and handle.
Sarah
Yves
Le 3 septembre 2021 21:09:24 GMT+02:00, Raphael dafadllyn@gmail.com a écrit :
Hi Matthijs, hi everyone
It seems that a consensus hasn't been reached yet - at least not on this list.
The Swiss hiking network is a bit peculiar. It's not a typical node network as the intersections (or nodes) aren't numbered and very often are unnamed. On the other hand the hiking trails (not including the routes from SchweizMobil) aren't typical routes as they are unnamed, unnumbered, have countless possible starts and ends and often have multiple variants from one named place to the next.
In my opinion, the simplest way to map the Swiss hiking trails is by adding a tag to the corresponding paths (maybe trail=hiking or hiking=designated) and using route=hiking routes only for the "real" SchweizMobil routes.
Best regards
Raphael (dafadllyn)
On Mon, 23 Aug 2021 at 20:21, Matthijs Kooijman matthijs@stdin.nl wrote:
Hi all,
I'm new to this list, so let me start with a small introduction: I'm a Dutch mapper, but I visit Switzerland every now and then (my brother lives in Rieden SG) and I like to do some hiking and mapping here. In the Netherlands, I've done some mapping on the cycle node networks, and in Switzerland I like to work on the wanderwegen network (though I have not mapped much, so treat my input accordingly).
I've been involved on the wiki page discussion section before, and from the wiki page history found a link to this thread, which I have read with much interest. Hopefully I can add something to the discussion in this thread.
From reading this discussion, it seems that there are still some matters where no consensus has been reached (in particular the matter of overlapping or non-overlapping routes). But it also seems that there has been some discussion about this off-list. Maybe some consensus has been reached elsewhere?
In case you have not seen it yet: there has been some effort (initiated by Peter Elderson AFAIU) to document current practices and rationale about node networks. This is mostly based on the numbered cycle/walking networks in NL/BE, but explicit effort has been made to also include named networks like Germany and Switzerland uses. AFAIU there has already been some experiments involving parts of the german network.
The current state of this documentation can be found here:
https://wiki.openstreetmap.org/wiki/Node_NetworksIf this has not been done already, I would suggest considering to make the Swiss tagging scheme either conform to that page, or modify/generalize that page to also apply to the Swiss tagging.
I just read through the page, and here's some notable observations from the current Swiss practice:
- The primary goal of the model specified is to facilitate routing and rendering of node networks. For example, the knooppuntnet.nl website allows entering a starting and ending node, and calculates a route between them using only routes part of the network, and produces a list of node numbers to follow (support for names instead of numbers is nearly complete, I believe). For the Swiss case, this could work the same, but produce a list of named nodes/guideposts the route passes (so you could walk the route without bringing an actual map, just follow signs to each of the names in turn).
- That page specifies to tag the actual junctions (as part of the ways they connect), instead of (or in addition to) the physical guideposts (besides the way they connect), which is a significant difference from the current Swiss practice. I believe the goal is to simplify routing, since you can then know which named junctions you pass exactly, without needing to find guideposts based on nearness. It can also help with network consistency checks (especially when combined with the expected_STn_route_relations attribute).
- That page also talks about junctions without a number or name, and specifies to create multiple partially overlapping routes in that case (and tagging the unnamed nodes with `xxn_ref=*`). Note that for the Dutch case, unnumbered junctions are very rare and almost always in the near vicinity of a numbered node, so in the Swiss case in regions that have more unnamed junctions, overlapping routes might have additional downsides (such as a potential explosion of possible routes when multiple unnamed guideposts exist between named routes, and the extra difficulty mapping partial routes).
- That page specifies to use `name=from-to` for named node networks (numbered networks use `ref=from-to`), while discussion on this list was moving towards not using the name anymore. However, it might be that that page specifies this to match current practice and could be changed without problems.
- That page specifies a "network" relation (not strictly required, though), that collects all the routes and nodes belonging to a specific node network, to allow semantically grouping routes and specifying e.g. the operator once for the entire network. In the Swiss case, I think this could amount to one network relation for each Canton.
- That page specifies a `network:type=node_network` attribute for nodes, routes and networks, to help distinguish them from regular routes.
Some earlier discussion about supporting named node networks has been done here: https://github.com/vmarc/knooppuntnet/issues/102 https://wiki.openstreetmap.org/wiki/Proposed_features/Named_nodes_in_node_ne...
Then, reading the wiki page in its current state, it seems to better reflect current and intended practice, which is good. However, I think there are still some things that could be clarified. In particular:
- How to tag unnamed guideposts? Common practice seems to be to just omit name, maybe that should be explicit on the wiki?
- How to handle numbered guideposts? For example in Graubünden (I walked in the area around Trin), I've seen guideposts (named and unnamed) that have a three-digit number that were already mapped with the number in the `ref` attribute, maybe that would be good to add to the wiki? For an example (with photo) see: https://www.openstreetmap.org/node/6100531211 Similarly, I understand that newer guideposts have a 6-digit unique number.
- Would it make sense to put these guideposts numbers in the relations? Especially when using the "non-overlapping routes between junctions" approach, putting these numbers in the from and to attributes could help diagnose issues. OTOH, they are mostly meaningless to users, in the sense that the signing does not point *to* these numbers, you can only see them when you are at a particular guidepost.
- How to tag from/to with unnamed guideposts? Should we invent names? Just omit the tag? I think no full consensus might have been reached here?
- Maybe make explicit that name= was used with from-to before, since a lot of existing routes still have that. If it is explicit that this is no longer recommended, that will be less confusing for new mappers.
- Is it ok to copy routes from the cantonal GIS systems? If not, or only from some, maybe make this explicit?
Gr.
Matthijs _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Hello Sarah, Just a quick look at taginfo and you are informed. Hear me, I'm no specialist on the subject, but having given up reading the extensive documentation that is currently building up on the nodes network concept, I wonder how Joe mapper can handle it. From two extremes, I'd prefer a simple way to map. After all, it's not so hard to build a network from elements sharing a same set of tags automatically if the data consumer has a need for it. For rendering, the user eyes and brain is sufficient when reading a map. However this does not mean higher level concepts as routed or network should be excluded from the data when it fits. Regards, Yves
Le 4 septembre 2021 00:19:25 GMT+02:00, Sarah Hoffmann lonvia@denofr.de a écrit :
On Fri, Sep 03, 2021 at 11:12:14PM +0200, Yves wrote:
Why not just osmc:symbols=yellow_diamond on the ways? *=designated would be more for acces rights.
Because using anything but relations creates an exception that data users have to know about and handle.
Sarah
Yves
Le 3 septembre 2021 21:09:24 GMT+02:00, Raphael dafadllyn@gmail.com a écrit :
Hi Matthijs, hi everyone
It seems that a consensus hasn't been reached yet - at least not on this list.
The Swiss hiking network is a bit peculiar. It's not a typical node network as the intersections (or nodes) aren't numbered and very often are unnamed. On the other hand the hiking trails (not including the routes from SchweizMobil) aren't typical routes as they are unnamed, unnumbered, have countless possible starts and ends and often have multiple variants from one named place to the next.
In my opinion, the simplest way to map the Swiss hiking trails is by adding a tag to the corresponding paths (maybe trail=hiking or hiking=designated) and using route=hiking routes only for the "real" SchweizMobil routes.
Best regards
Raphael (dafadllyn)
On Mon, 23 Aug 2021 at 20:21, Matthijs Kooijman matthijs@stdin.nl wrote:
Hi all,
I'm new to this list, so let me start with a small introduction: I'm a Dutch mapper, but I visit Switzerland every now and then (my brother lives in Rieden SG) and I like to do some hiking and mapping here. In the Netherlands, I've done some mapping on the cycle node networks, and in Switzerland I like to work on the wanderwegen network (though I have not mapped much, so treat my input accordingly).
I've been involved on the wiki page discussion section before, and from the wiki page history found a link to this thread, which I have read with much interest. Hopefully I can add something to the discussion in this thread.
From reading this discussion, it seems that there are still some matters where no consensus has been reached (in particular the matter of overlapping or non-overlapping routes). But it also seems that there has been some discussion about this off-list. Maybe some consensus has been reached elsewhere?
In case you have not seen it yet: there has been some effort (initiated by Peter Elderson AFAIU) to document current practices and rationale about node networks. This is mostly based on the numbered cycle/walking networks in NL/BE, but explicit effort has been made to also include named networks like Germany and Switzerland uses. AFAIU there has already been some experiments involving parts of the german network.
The current state of this documentation can be found here:
https://wiki.openstreetmap.org/wiki/Node_NetworksIf this has not been done already, I would suggest considering to make the Swiss tagging scheme either conform to that page, or modify/generalize that page to also apply to the Swiss tagging.
I just read through the page, and here's some notable observations from the current Swiss practice:
- The primary goal of the model specified is to facilitate routing and rendering of node networks. For example, the knooppuntnet.nl website allows entering a starting and ending node, and calculates a route between them using only routes part of the network, and produces a list of node numbers to follow (support for names instead of numbers is nearly complete, I believe). For the Swiss case, this could work the same, but produce a list of named nodes/guideposts the route passes (so you could walk the route without bringing an actual map, just follow signs to each of the names in turn).
- That page specifies to tag the actual junctions (as part of the ways they connect), instead of (or in addition to) the physical guideposts (besides the way they connect), which is a significant difference from the current Swiss practice. I believe the goal is to simplify routing, since you can then know which named junctions you pass exactly, without needing to find guideposts based on nearness. It can also help with network consistency checks (especially when combined with the expected_STn_route_relations attribute).
- That page also talks about junctions without a number or name, and specifies to create multiple partially overlapping routes in that case (and tagging the unnamed nodes with `xxn_ref=*`). Note that for the Dutch case, unnumbered junctions are very rare and almost always in the near vicinity of a numbered node, so in the Swiss case in regions that have more unnamed junctions, overlapping routes might have additional downsides (such as a potential explosion of possible routes when multiple unnamed guideposts exist between named routes, and the extra difficulty mapping partial routes).
- That page specifies to use `name=from-to` for named node networks (numbered networks use `ref=from-to`), while discussion on this list was moving towards not using the name anymore. However, it might be that that page specifies this to match current practice and could be changed without problems.
- That page specifies a "network" relation (not strictly required, though), that collects all the routes and nodes belonging to a specific node network, to allow semantically grouping routes and specifying e.g. the operator once for the entire network. In the Swiss case, I think this could amount to one network relation for each Canton.
- That page specifies a `network:type=node_network` attribute for nodes, routes and networks, to help distinguish them from regular routes.
Some earlier discussion about supporting named node networks has been done here: https://github.com/vmarc/knooppuntnet/issues/102 https://wiki.openstreetmap.org/wiki/Proposed_features/Named_nodes_in_node_ne...
Then, reading the wiki page in its current state, it seems to better reflect current and intended practice, which is good. However, I think there are still some things that could be clarified. In particular:
- How to tag unnamed guideposts? Common practice seems to be to just omit name, maybe that should be explicit on the wiki?
- How to handle numbered guideposts? For example in Graubünden (I walked in the area around Trin), I've seen guideposts (named and unnamed) that have a three-digit number that were already mapped with the number in the `ref` attribute, maybe that would be good to add to the wiki? For an example (with photo) see: https://www.openstreetmap.org/node/6100531211 Similarly, I understand that newer guideposts have a 6-digit unique number.
- Would it make sense to put these guideposts numbers in the relations? Especially when using the "non-overlapping routes between junctions" approach, putting these numbers in the from and to attributes could help diagnose issues. OTOH, they are mostly meaningless to users, in the sense that the signing does not point *to* these numbers, you can only see them when you are at a particular guidepost.
- How to tag from/to with unnamed guideposts? Should we invent names? Just omit the tag? I think no full consensus might have been reached here?
- Maybe make explicit that name= was used with from-to before, since a lot of existing routes still have that. If it is explicit that this is no longer recommended, that will be less confusing for new mappers.
- Is it ok to copy routes from the cantonal GIS systems? If not, or only from some, maybe make this explicit?
Gr.
Matthijs _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
On Sat, Sep 04, 2021 at 07:18:28AM +0200, Yves wrote:
Hello Sarah, Just a quick look at taginfo and you are informed.
Alas, that's not how it works because taginfo just tells you what is used not how it is used. And taginfo is only useful if you already know what tags to look out for.
The problems start when each small community (or worse: a single mapper) decides mapping after their own fashion without any look at the global picture. Yes, it's not a problem to do it differently in Switzerland. But if a data user wants to use that they have to first be aware that Switzerland is doing it differently. And Switzerland is not the only country on earth. And that's the point where you force the data user to spend hundreds of hours on research for local tagging schemas.
I've been throught that for admin boundaries in the last year. It involves reading through the Wiki, mailing lists, forums, Matrix, Slack and Telegram channels etc. (many of them in languages that you don't speak) to find out what is going on. In addition you'll need background information on the country and it's special system, so more research via Wikipedia, news articles, blogs etc. Or you write to the communities directly but usually leads to even longer discussion threads that you then have to follow.
So, yes, tagging the waymarking on the ways would be better for Switzerland. But if you want to do that then be prepared to start a campaign for a globally usable second scheme of describing waymarkings on ways or live with the fact that these trails will never show up in pretty much any of the known hiking apps.
Hear me, I'm no specialist on the subject, but having given up reading the extensive documentation that is currently building up on the nodes network concept, I wonder how Joe mapper can handle it.
The waymarked trails system in Switzerland has been mapped for years with relations and it wasn't a huge problem. It still isn't. We have the current discussion because a single mapper decided a couple of years ago to singlehandedly change the system without any discussion. The result is two competing tagging schemas (both based on relations): the 'oldtimers' use the original one, mappers that came later following what that user has decided. This needed sorting out at some point and it's good that it's being done now.
Long story short: mapping the waymarkings on ways is another dimension here and I'm not sure it is a good idea to bring it into the discussion right now. The same is true for the node network mapping schema.
Sarah
From two extremes, I'd prefer a simple way to map. After all, it's not so hard to build a network from elements sharing a same set of tags automatically if the data consumer has a need for it. For rendering, the user eyes and brain is sufficient when reading a map. However this does not mean higher level concepts as routed or network should be excluded from the data when it fits. Regards, Yves
Le 4 septembre 2021 00:19:25 GMT+02:00, Sarah Hoffmann lonvia@denofr.de a écrit :
On Fri, Sep 03, 2021 at 11:12:14PM +0200, Yves wrote:
Why not just osmc:symbols=yellow_diamond on the ways? *=designated would be more for acces rights.
Because using anything but relations creates an exception that data users have to know about and handle.
Sarah
Yves
Le 3 septembre 2021 21:09:24 GMT+02:00, Raphael dafadllyn@gmail.com a écrit :
Hi Matthijs, hi everyone
It seems that a consensus hasn't been reached yet - at least not on this list.
The Swiss hiking network is a bit peculiar. It's not a typical node network as the intersections (or nodes) aren't numbered and very often are unnamed. On the other hand the hiking trails (not including the routes from SchweizMobil) aren't typical routes as they are unnamed, unnumbered, have countless possible starts and ends and often have multiple variants from one named place to the next.
In my opinion, the simplest way to map the Swiss hiking trails is by adding a tag to the corresponding paths (maybe trail=hiking or hiking=designated) and using route=hiking routes only for the "real" SchweizMobil routes.
Best regards
Raphael (dafadllyn)
On Mon, 23 Aug 2021 at 20:21, Matthijs Kooijman matthijs@stdin.nl wrote:
Hi all,
I'm new to this list, so let me start with a small introduction: I'm a Dutch mapper, but I visit Switzerland every now and then (my brother lives in Rieden SG) and I like to do some hiking and mapping here. In the Netherlands, I've done some mapping on the cycle node networks, and in Switzerland I like to work on the wanderwegen network (though I have not mapped much, so treat my input accordingly).
I've been involved on the wiki page discussion section before, and from the wiki page history found a link to this thread, which I have read with much interest. Hopefully I can add something to the discussion in this thread.
From reading this discussion, it seems that there are still some matters where no consensus has been reached (in particular the matter of overlapping or non-overlapping routes). But it also seems that there has been some discussion about this off-list. Maybe some consensus has been reached elsewhere?
In case you have not seen it yet: there has been some effort (initiated by Peter Elderson AFAIU) to document current practices and rationale about node networks. This is mostly based on the numbered cycle/walking networks in NL/BE, but explicit effort has been made to also include named networks like Germany and Switzerland uses. AFAIU there has already been some experiments involving parts of the german network.
The current state of this documentation can be found here:
https://wiki.openstreetmap.org/wiki/Node_NetworksIf this has not been done already, I would suggest considering to make the Swiss tagging scheme either conform to that page, or modify/generalize that page to also apply to the Swiss tagging.
I just read through the page, and here's some notable observations from the current Swiss practice:
- The primary goal of the model specified is to facilitate routing and rendering of node networks. For example, the knooppuntnet.nl website allows entering a starting and ending node, and calculates a route between them using only routes part of the network, and produces a list of node numbers to follow (support for names instead of numbers is nearly complete, I believe). For the Swiss case, this could work the same, but produce a list of named nodes/guideposts the route passes (so you could walk the route without bringing an actual map, just follow signs to each of the names in turn).
- That page specifies to tag the actual junctions (as part of the ways they connect), instead of (or in addition to) the physical guideposts (besides the way they connect), which is a significant difference from the current Swiss practice. I believe the goal is to simplify routing, since you can then know which named junctions you pass exactly, without needing to find guideposts based on nearness. It can also help with network consistency checks (especially when combined with the expected_STn_route_relations attribute).
- That page also talks about junctions without a number or name, and specifies to create multiple partially overlapping routes in that case (and tagging the unnamed nodes with `xxn_ref=*`). Note that for the Dutch case, unnumbered junctions are very rare and almost always in the near vicinity of a numbered node, so in the Swiss case in regions that have more unnamed junctions, overlapping routes might have additional downsides (such as a potential explosion of possible routes when multiple unnamed guideposts exist between named routes, and the extra difficulty mapping partial routes).
- That page specifies to use `name=from-to` for named node networks (numbered networks use `ref=from-to`), while discussion on this list was moving towards not using the name anymore. However, it might be that that page specifies this to match current practice and could be changed without problems.
- That page specifies a "network" relation (not strictly required, though), that collects all the routes and nodes belonging to a specific node network, to allow semantically grouping routes and specifying e.g. the operator once for the entire network. In the Swiss case, I think this could amount to one network relation for each Canton.
- That page specifies a `network:type=node_network` attribute for nodes, routes and networks, to help distinguish them from regular routes.
Some earlier discussion about supporting named node networks has been done here: https://github.com/vmarc/knooppuntnet/issues/102 https://wiki.openstreetmap.org/wiki/Proposed_features/Named_nodes_in_node_ne...
Then, reading the wiki page in its current state, it seems to better reflect current and intended practice, which is good. However, I think there are still some things that could be clarified. In particular:
- How to tag unnamed guideposts? Common practice seems to be to just omit name, maybe that should be explicit on the wiki?
- How to handle numbered guideposts? For example in Graubünden (I walked in the area around Trin), I've seen guideposts (named and unnamed) that have a three-digit number that were already mapped with the number in the `ref` attribute, maybe that would be good to add to the wiki? For an example (with photo) see: https://www.openstreetmap.org/node/6100531211 Similarly, I understand that newer guideposts have a 6-digit unique number.
- Would it make sense to put these guideposts numbers in the relations? Especially when using the "non-overlapping routes between junctions" approach, putting these numbers in the from and to attributes could help diagnose issues. OTOH, they are mostly meaningless to users, in the sense that the signing does not point *to* these numbers, you can only see them when you are at a particular guidepost.
- How to tag from/to with unnamed guideposts? Should we invent names? Just omit the tag? I think no full consensus might have been reached here?
- Maybe make explicit that name= was used with from-to before, since a lot of existing routes still have that. If it is explicit that this is no longer recommended, that will be less confusing for new mappers.
- Is it ok to copy routes from the cantonal GIS systems? If not, or only from some, maybe make this explicit?
Gr.
Matthijs _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Hi all,
the suggestions from Raphael and Yves, to just tag the highways with something and omit the route relations entirely seems like an clean approach here, if you primarily want to be able to know which ways are part of the hiking network (e.g. to color them), and the actual routes themselves are less of interest (as I think is the case).
However, it does seem that by omitting the routes, you are making things more fragile and are omitting some valuable information, though I find it hard to translate that intuition into actual examples.
One advantage of adding route relations, I think, is that it allows more powerful automated checking of the network, to detect cases where a route was accidentally deleted, a way was removed from a route, etc. One example of such checking (which I forgot to point out in my earlier post), is done by knooppuntnet.nl, see https://knooppuntnet.nl/en/analysis/ for some examples. I think support for named nodes is still in progress, though.
Of course there is a potential fallacy here: If adding routes enables automated checking, but that checking only exposes problems that would not exist in a tagging scheme without the routes, then the "allows-analysis" argument by itself is moot. However, I suspect there are still some problems that can be detected more easily/reliably with relations (e.g. distinguishing a dead-end route to a viewpoint from a broken route).
Also, Sarah makes a good point about consistency toward data consumers, which expect route relations currently.
On Sat, Sep 04, 2021 at 09:28:45AM +0100, Sarah Hoffmann wrote:
Long story short: mapping the waymarkings on ways is another dimension here and I'm not sure it is a good idea to bring it into the discussion right now. The same is true for the node network mapping schema.
I'm not sure I agree with the latter entirely. Your argument about using route relations for consistency towards data consumer seems to apply to using the node network mapping schema as well. That is a documented (though still in-progress) schema for networks such as these, so supporting it (maybe with some changes to the schema, maybe making some things optional, like tagged junction nodes) would make it easier for data consumers to consistently use the data. One could argue that this should be a separate discussion, but I'm not sure if there's much point in settling on a schema for Switzerland first, and then afterwards starting to think about the node networks separately.
In any case, like I mentioned above, having automated analysis tools like knooppuntnet.nl support the Swiss network would, IMHO, be quite useful. Whether that means adapting the Swiss tagging scheme, or adapting knooppuntnet.nl (and/or the documented node network tagging scheme) is to be determined, IMHO.
Gr.
Matthijs
Hi
The effort on other hiking tagging was mentioned by Robert now over a month ago, but unfortunately I didn't find time to read those discussions yet.
I think consensus has been reached for the names. And you are right, documenting what has been previously done as an info box explanation is a good idea.
As mentioned, The Swiss network has no focus on nodes. It is planned as routes. Navigating with only a list of guidepost names will probably fail often, because that is not considered by the maintainers when destinations are chosen for each guidepost. Assembling navigation instructions as a list of intermediate destinations would need destination sign mapping.
Putting the guidepost besides the way, between the correct ways, is a help for orientation, so that is probably why this won over putting the guide post on the intersection. I would question that it is necessary for building a router that those guide posts are on the intersection, and would not like to tag for a router.
With overlapping and non overlapping: It does not matter much for data consumers, and both ways are acceptable, with mutual respect. Documentation is under way, thanks to René.
I feel no consensus has been reached for how to handle from/to for starting/ending on unnamed junctions. However, I think we can take a lot of liberty there, as the tags are intended specifically for the mapper, like the note tag. So if one uses the closest field name or the elevation of the guide post, it should work somehow. And maybe we will converge in the future on something that prove the most useful.
Relations are not categories. operator should be tagged on the routes and/or guide posts.
I have never seen those numbers on guide posts, seems to be a cantonal thing. A ref tag seems perfectly fine, as well as the usage in from/to if there is no name.
Cantonal Data: I think the https://wiki.openstreetmap.org/wiki/Switzerland/Datasources is currently the best place to look which ones are available.
Have fun with the hiking route mapping Michael
On 23.08.21 20:20, Matthijs Kooijman wrote:
Hi all,
I'm new to this list, so let me start with a small introduction: I'm a Dutch mapper, but I visit Switzerland every now and then (my brother lives in Rieden SG) and I like to do some hiking and mapping here. In the Netherlands, I've done some mapping on the cycle node networks, and in Switzerland I like to work on the wanderwegen network (though I have not mapped much, so treat my input accordingly).
I've been involved on the wiki page discussion section before, and from the wiki page history found a link to this thread, which I have read with much interest. Hopefully I can add something to the discussion in this thread.
From reading this discussion, it seems that there are still some matters where no consensus has been reached (in particular the matter of overlapping or non-overlapping routes). But it also seems that there has been some discussion about this off-list. Maybe some consensus has been reached elsewhere?
In case you have not seen it yet: there has been some effort (initiated by Peter Elderson AFAIU) to document current practices and rationale about node networks. This is mostly based on the numbered cycle/walking networks in NL/BE, but explicit effort has been made to also include named networks like Germany and Switzerland uses. AFAIU there has already been some experiments involving parts of the german network.
The current state of this documentation can be found here:
https://wiki.openstreetmap.org/wiki/Node_Networks
If this has not been done already, I would suggest considering to make the Swiss tagging scheme either conform to that page, or modify/generalize that page to also apply to the Swiss tagging.
I just read through the page, and here's some notable observations from the current Swiss practice:
- The primary goal of the model specified is to facilitate routing and rendering of node networks. For example, the knooppuntnet.nl website allows entering a starting and ending node, and calculates a route between them using only routes part of the network, and produces a list of node numbers to follow (support for names instead of numbers is nearly complete, I believe). For the Swiss case, this could work the same, but produce a list of named nodes/guideposts the route passes (so you could walk the route without bringing an actual map, just follow signs to each of the names in turn).
- That page specifies to tag the actual junctions (as part of the ways they connect), instead of (or in addition to) the physical guideposts (besides the way they connect), which is a significant difference from the current Swiss practice. I believe the goal is to simplify routing, since you can then know which named junctions you pass exactly, without needing to find guideposts based on nearness. It can also help with network consistency checks (especially when combined with the expected_STn_route_relations attribute).
- That page also talks about junctions without a number or name, and specifies to create multiple partially overlapping routes in that case (and tagging the unnamed nodes with `xxn_ref=*`). Note that for the Dutch case, unnumbered junctions are very rare and almost always in the near vicinity of a numbered node, so in the Swiss case in regions that have more unnamed junctions, overlapping routes might have additional downsides (such as a potential explosion of possible routes when multiple unnamed guideposts exist between named routes, and the extra difficulty mapping partial routes).
- That page specifies to use `name=from-to` for named node networks (numbered networks use `ref=from-to`), while discussion on this list was moving towards not using the name anymore. However, it might be that that page specifies this to match current practice and could be changed without problems.
- That page specifies a "network" relation (not strictly required, though), that collects all the routes and nodes belonging to a specific node network, to allow semantically grouping routes and specifying e.g. the operator once for the entire network. In the Swiss case, I think this could amount to one network relation for each Canton.
- That page specifies a `network:type=node_network` attribute for nodes, routes and networks, to help distinguish them from regular routes.
Some earlier discussion about supporting named node networks has been done here: https://github.com/vmarc/knooppuntnet/issues/102 https://wiki.openstreetmap.org/wiki/Proposed_features/Named_nodes_in_node_ne...
Then, reading the wiki page in its current state, it seems to better reflect current and intended practice, which is good. However, I think there are still some things that could be clarified. In particular:
- How to tag unnamed guideposts? Common practice seems to be to just omit name, maybe that should be explicit on the wiki?
- How to handle numbered guideposts? For example in Graubünden (I walked in the area around Trin), I've seen guideposts (named and unnamed) that have a three-digit number that were already mapped with the number in the `ref` attribute, maybe that would be good to add to the wiki? For an example (with photo) see: https://www.openstreetmap.org/node/6100531211 Similarly, I understand that newer guideposts have a 6-digit unique number.
- Would it make sense to put these guideposts numbers in the relations? Especially when using the "non-overlapping routes between junctions" approach, putting these numbers in the from and to attributes could help diagnose issues. OTOH, they are mostly meaningless to users, in the sense that the signing does not point *to* these numbers, you can only see them when you are at a particular guidepost.
- How to tag from/to with unnamed guideposts? Should we invent names? Just omit the tag? I think no full consensus might have been reached here?
- Maybe make explicit that name= was used with from-to before, since a lot of existing routes still have that. If it is explicit that this is no longer recommended, that will be less confusing for new mappers.
- Is it ok to copy routes from the cantonal GIS systems? If not, or only from some, maybe make this explicit?
Gr.
Matthijs
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
Hi Michael,
Thanks for your answers! I'll respond to some below.
As mentioned, The Swiss network has no focus on nodes. It is planned as routes. Navigating with only a list of guidepost names will probably fail often, because that is not considered by the maintainers when destinations are chosen for each guidepost. Assembling navigation instructions as a list of intermediate destinations would need destination sign mapping.
Yeah, to allow fail-safe navigation instructions, you would indeed need destination sign mapping, but it seems also reasonably safe to assume that from each named guidepost, the closest named guideposts are always indicated, which means that a list of all named guideposts should always result in a navigatable list. Of course I'm unsure how much people would actually want to use the data in this way...
Putting the guidepost besides the way, between the correct ways, is a help for orientation, so that is probably why this won over putting the guide post on the intersection. I would question that it is necessary for building a router that those guide posts are on the intersection, and would not like to tag for a router.
Right, I think the idea is not to put the guideposts on the intersection (that would not reflect reality properly). Instead, the idea is to tag the junctions as (logical) nodes in a network, and optionally tag the guideposts *as well* in their actual positions (in the Dutch cycle system, the guideposts are usually omitted since there is little value, but for the Swiss system I think mapping them separately can be more valuable).
See also https://wiki.openstreetmap.org/wiki/Proposed_features/Named_nodes_in_node_ne...
You are then partially mapping for ther router, which I agree is something to be skeptical about. However, an additional benefit of this approach is that it is easier to also apply automated checking on the network, since you're not just mapping the route itself, but also the endpoints of these routes (which might introduce a little information duplication, but that allows detecting situations where a route got detached from its intended endpoint).
I feel no consensus has been reached for how to handle from/to for starting/ending on unnamed junctions. However, I think we can take a lot of liberty there, as the tags are intended specifically for the mapper, like the note tag. So if one uses the closest field name or the elevation of the guide post, it should work somehow. And maybe we will converge in the future on something that prove the most useful.
Under the assumption that from/to are really just for the mapper, I agree that there is a lot of liberty. Still, some consistency would be useful (i.e. to help interpret these tags, am I looking for a ref, elevation, name on a guidepost, or is the name invented, or something completely different?). I can imagine making this explicit, e.g. `from=ele 123` or `from=near Kirche Niederurnen`, things like that?
Also, is from/to really mapper-only territory? It seems that for regular routes, from/to is not strictly defined, but there is some ad-hoc usage of it: https://wiki.openstreetmap.org/wiki/Key:from Similary, the named node network proposal also mentions using them (without stating they are mapper-use only), see https://wiki.openstreetmap.org/wiki/Proposed_features/Named_nodes_in_node_ne...
I might be overthinking this, though...
Cantonal Data: I think the https://wiki.openstreetmap.org/wiki/Switzerland/Datasources is currently the best place to look which ones are available.
Ah, indeed. Might be good to link to that page from the hiking network page, then.
Gr.
Matthijs
Hallo zusammen,
Vielen Dank für das Gespräch gestern. Ich habe versucht, mal einen besseren Überblick über die Datenlage zu bekommen.
Wir haben in der Schweiz: - 14266 Basisnetz-Wanderrouten (route=hiking, network=lwn, osmc:symbol=yellow::yellow_diamond/red:white:red_bar/blue:white:blue_bar) - 10436 davon haben ein Start und Ziel (über from/to, osmc:name, note oder name) das nicht "fixme" oder "?" heisst und auch sonst kein fixme-Tag, d.h. sind "fertig" gemappt - von den restlichen haben 1786 ein fixme in irgendeiner Form und ca. 950 sind in den letzten Wochen über #door2peak hinzugekommen (ohne Start/Ziel) - 10764 benannte Wegweiser - Für 16403 der 20782 Routenstarts und -ziele existiert irgendwo ein Wegweiser mit demselben Namen (Schreibfehler habe ich nicht berücksichtigt oder zahlreiche Fälle mit Ziel "Ort" und Wegweiser "Ort/Bahnhof" o.ä.) - 15425 dieser 16403 Wegweiser sind näher als 100m (15264 näher als 50m) an einem Start-/Endknoten von irgendeinem Weg in der Route
Also ist zumindest bisher ein grosser Teil der Basisnetzrouten zwischen benannten Wegweisern gemappt. Bei grober Durchsicht einiger Routen wo die Wegweiser weiter entfernt sind finden sich auch leicht welche die höchstwahrscheinlich nicht vollständig oder kaputt sind, z.B. https://www.openstreetmap.org/relation/136457, https://www.openstreetmap.org/relation/145797
Falls sonst jemand schauen möchte: https://gist.github.com/eginhard/fed591b71febd48b964300f63f20d2c2 (1. Versuch mit Pyosmium, also Fehler sind möglich)
Grüsse, Enno
On Sun, Jul 11, 2021 at 2:13 PM Stefan Keller sfkeller@gmail.com wrote:
Dear Michael, dear all
Thanks, Michael, for your proposal and the changes in the Wiki [1]. I just wanted to support these changes as you announced in this thread. We really need a base network for hiking which is routable! These changes don't exclude the many named routes mappers are eager to add (as relations) on top of that proper base network.
~Stefan
[1] https://wiki.openstreetmap.org/wiki/Switzerland/HikingNetwork
Am Sa., 26. Juni 2021 um 11:32 Uhr schrieb michael spreng mailinglist@osm.datendelphin.net:
Hallo Urs
On 23.06.21 20:02, Flips wrote:
Die Info zum Stammtisch habe ich jetzt zu spät gelesen. Vielleicht beim nächsten Mal.
Also um 20:00 Uhr waren wir noch lange nicht fertig :)
Ich sehe die Routen nicht sls technische Routen, sondern als offizielle Routen. Warum sonst gibt es auf den Wegweisern Endziele mit Zeitangaben und von einigen Wegweiserstandorten aus Routen über verschiedene Wege zum selben Ziel. Dies wäre oftmals gar nicht nötig, um das ganze Netz abzubilden, da schon andere Routen die selben Streckenabschnitte
abdecken.
Wenn das Wanderwegnetz nur als Netz ohne Routen verstanden wird, dann sollten, wie ich es schon in einem vorherigen Mail beschrieben habe, einzig die lcn=yes zu den highway=* dazugetagt werden. In OSM sollten nur echte Routen als Relationen gemapt werden. Die from/to-tags werde ich künftig gerne berücksichtigen.
Das würde technisch verhindern, dass eine way mehrmals vor kommt. Aber: Es gibt einen starken Bruch zwischen Regionen, wo es keine "referenz" (Name, Nummer, was auch immer) gibt für die Komponenten des Basisnetz (CH), und Regionen, wo es das eben gibt. Sarah hat da am Stammtisch ein Beispiel gezeigt für letzteres. Und man verliert die Möglichkeit, das from/to zu tagen für den Unterhalt, was ein grosses Anliegen zu sein scheint.
Grüsse Michael _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
-
BAK365 -
Enno Hermann -
Flips -
Flips
-
hecktor＠ziknet.ch -
Martin Lerjen -
Matthijs Kooijman -
michael spreng -
michael spreng (datendelphin)
-
Peter Berger -
Raphael -
René Buffat -
Robert Grübler -
Sarah Hoffmann -
Stefan Keller -
Yves