Hello,
As I read in the Wiki, the "to" member of a "destination_sign" tag can contain a way or a node.
In my current review of hiking trails, I would like to put a relation inside. Here is a real example :
I've created a hiking route between 2 guideposts :
https://www.openstreetmap.org/relation/13273890
I've also created a destination_sign to indicate the destination and time. I use the first point of the way to indicate the "to" :
https://www.openstreetmap.org/relation/13276408
When I display the map, I can only seen 2 circles. That will not really help users. In the destination_sign I could indicate the first way, it will be little more explicit. But if I could enter the relation to the destination in the "to", there would be a great gain of information.
Do you know why the "to" member is not accepting a relation ? Is it possible to change it ?
Thank you
Raphael Terrettaz
Hi Raphaël
On Mon, 20 Dec 2021 at 15:39, Raphaël Terrettaz r.terrettaz@gmail.com wrote:
When I display the map, I can only seen 2 circles. That will not really help users. In the destination_sign I could indicate the first way, it will be little more explicit. But if I could enter the relation to the destination in the "to", there would be a great gain of information.
Do you know why the "to" member is not accepting a relation ? Is it possible to change it ?
The purpose of the `type=destination_sign` relation is to record the information that is written on a direction sign (signpost) as well as its direction. Therefore a node with a `intersection` role and a node or way with a `to` role are sufficient, see also [^1] and [^2].
I don't see much benefit in adding the hiking route relation to a `type=destination_sign` relation. Instead this would likely make it much more complex for applications that use OSM data to support it.
[^1]: https://hiking.waymarkedtrails.org/#guidepost?id=983522585 [^2]: https://osm.mueschelsoft.de/destinationsign/example/index.htm#node=983522585
By the way, guideposts are usually mapped at its real position next to a `highway=*` way and it seems that most mappers agree that the `name=*` of a hiking route should be reserved for real route names (e.g. the Via Alpina or the Alpine Passes Trail).
Best regards from a namesake :)
Raphael (dafadllyn)
Hello and happy new year !
My idea is to be able to visualize together on a map the indications of a panel and the corresponding paths. For the moment this is not possible, because the 2 relations are not linked.
There are also signs that offer several routes to reach another point. In this case, it wille be easy to visualize the various proposal. For example, this sign shows 3 different routes to reach "Col de la Forclaz":
https://commons.wikimedia.org/wiki/File:Chemin_p%C3%A9destre_-_Poteau_induct...
Best regards
Raphaël
Le lun. 20 déc. 2021 à 22:30, Raphael dafadllyn@gmail.com a écrit :
Hi Raphaël
On Mon, 20 Dec 2021 at 15:39, Raphaël Terrettaz r.terrettaz@gmail.com wrote:
When I display the map, I can only seen 2 circles. That will not really
help users. In the destination_sign I could indicate the first way, it will be little more explicit. But if I could enter the relation to the destination in the "to", there would be a great gain of information.
Do you know why the "to" member is not accepting a relation ? Is it
possible to change it ?
The purpose of the `type=destination_sign` relation is to record the information that is written on a direction sign (signpost) as well as its direction. Therefore a node with a `intersection` role and a node or way with a `to` role are sufficient, see also [^1] and [^2].
I don't see much benefit in adding the hiking route relation to a `type=destination_sign` relation. Instead this would likely make it much more complex for applications that use OSM data to support it.
By the way, guideposts are usually mapped at its real position next to a `highway=*` way and it seems that most mappers agree that the `name=*` of a hiking route should be reserved for real route names (e.g. the Via Alpina or the Alpine Passes Trail).
Best regards from a namesake :)
Raphael (dafadllyn) _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
On Fri, Jan 07, 2022 at 09:43:10AM +0100, Raphaël Terrettaz wrote:
Hello and happy new year !
My idea is to be able to visualize together on a map the indications of a panel and the corresponding paths. For the moment this is not possible, because the 2 relations are not linked.
This can be computed via the node/way from the to member of the destination_sign relation.
There are also signs that offer several routes to reach another point. In this case, it wille be easy to visualize the various proposal. For example, this sign shows 3 different routes to reach "Col de la Forclaz":
https://commons.wikimedia.org/wiki/File:Chemin_p%C3%A9destre_-_Poteau_induct...
The destination_sing relation documents a via point to use for that.
Kind regards
Sarah
On Sun, 9 Jan 2022 at 12:01, Sarah Hoffmann lonvia@denofr.de wrote:
https://commons.wikimedia.org/wiki/File:Chemin_p%C3%A9destre_-_Poteau_induct...
The destination_sing relation documents a via point to use for that.
Correct URL: https://commons.wikimedia.org/wiki/File:Chemin_p%C3%A9destre_-_Poteau_indica...
A `via` role isn't needed in the above example because Col de la Forclaz points to the same direction three times. The guidepost indicates three possibilities to reach Col de la Forclaz and gives their hiking time. That is, the three possible routes to reach Col de la Forclaz begin with the same path and branch off at another place (that certainly has another guidepost).
By the way, the `via` role isn't supported by both [Waymarked Trails](https://waymarkedtrails.org/) and Mueschelsoft's [destination sign tool](https://osm.mueschelsoft.de/destinationsign/). However, even in situations where a guidepost doesn't point in the direction of a path that begins at the intersection next to the guidepost – like in the example below –, it's direction can correctly be represented by adding a node with the role `to` of the more distant path to the `destination_sign` relation. Thus, there is no need for `via` role.
https://www.openstreetmap.org/relation/13347671
Best regards
Raphael
Hello,
Thanks for those comments! I see that it is not useful to modify the "to" of the relation.
But for my own control tools, I will still add all the paths between the guidepost and the destination. I added them with the "route" tag. I make a first test :
https://www.openstreetmap.org/relation/13659646
And, who knows, these information may be used by other engines in the future.
Best regards
Raphaël
Le dim. 9 janv. 2022 à 17:22, Raphael dafadllyn@gmail.com a écrit :
On Sun, 9 Jan 2022 at 12:01, Sarah Hoffmann lonvia@denofr.de wrote:
https://commons.wikimedia.org/wiki/File:Chemin_p%C3%A9destre_-_Poteau_induct...
The destination_sing relation documents a via point to use for that.
Correct URL: https://commons.wikimedia.org/wiki/File:Chemin_p%C3%A9destre_-_Poteau_indica...
A `via` role isn't needed in the above example because Col de la Forclaz points to the same direction three times. The guidepost indicates three possibilities to reach Col de la Forclaz and gives their hiking time. That is, the three possible routes to reach Col de la Forclaz begin with the same path and branch off at another place (that certainly has another guidepost).
By the way, the `via` role isn't supported by both [Waymarked Trails](https://waymarkedtrails.org/) and Mueschelsoft's [destination sign tool](https://osm.mueschelsoft.de/destinationsign/). However, even in situations where a guidepost doesn't point in the direction of a path that begins at the intersection next to the guidepost – like in the example below –, it's direction can correctly be represented by adding a node with the role `to` of the more distant path to the `destination_sign` relation. Thus, there is no need for `via` role.
https://www.openstreetmap.org/relation/13347671
Best regards
Raphael _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
-
Raphael -
Raphaël Terrettaz -
Sarah Hoffmann