Hi Antoine,

I think your suggestions are all valid, but it seems some make tagging and using data more complicated than necessary.


On 05.09.19 09:29, Antoine Riche via Tagging wrote:
In order to improve the user experience, we want to provide walking instructions such as "take the exit 'Rue de Londres'" or "Walk through the gate labelled 'Northern lines'" rather than "Walk 75 metres then turn left". Our problem is that such waypoints may have a different name depending on the direction you cross them. The solution we used is to create, when there is such an ambiguity, two destination_sign relations pointing to the same 'intersection' member, one for each direction with the 'from' and 'to' members swapped. Here is an example at Juvisy station : the entrance named 'Accès Danton' when walking in (https://www.osm.org/relation/9471596) is named 'Quartier Seine' when walking out (https://www.osm.org/relation/9471597).
That's correct and how it's done usually. In such a simple case, the same information can also be added to the way passing through the entrance using the tags 'destination:forward' and 'destination:backward'. I think this carries all the information you need for the routing. The additional information the relation is able to handle (location of the sign, colours etc.) are not needed here. Adding tags to a (short) way is much less effort and serves the purpose very well here. In addition, the 'destination' tag is already used by some routing tools.


I wish to amend the Wiki to explain that destination_sign relations can also be used for pedestrian and indoor routing, not just at "crossroads". Does that require opening a discussion in the discussion page, or may I just go ahead ?

A huge amount of these relations are already used on paths like hiking trails, so this tagging scheme is definitely not limited to road signs. So there is no redefinition needed, maybe the description needs to be refined a bit.


Now since the routing engine supports area routing, we need to loosen some constraints on the members, that are documented on the wiki and enforced by the JOSM validator : 1/ allow areas for the 'from' and 'to' members, as in this example : https://www.osm.org/relation/9722912
This seems to be fine - you have to note that many data users (me included) are not actually able to handle areas well with respect to routing.

2/ allow multiple 'intersection' members, so that multiple doors can be referenced by a single relation – example in Gare Montparnasse : https://www.osm.org/relation/9823029
This looks fine to me - but the destinations should be tagged using 'destination' and not using 'name' - that would be the name of the sign (which is unlikely to exist).

3/ allow multiple 'to' members, so that the same relation can point to both a line and an area, and cover linear and area routing (no example but I could create one).
In my opinion, the area should not be included here. The 'to' member of the relation is not meant to be the final destination, but just a way or node you need to pass through to get to your destination. That would be a node directly after the 'intersection'. Having both makes it difficult for the data user to find which one is the correct one in the current context. The decision might not always be as simple as 'area' vs. 'way'.


FYI, I'm working a bit on displaying destination signs, mostly in the context of hiking guideposts, but yours can be displayed as well, e.g.
http://osm.janmichel.eu/destinationsign/example/index.htm#zoom=18&lat=48.993567&lon=2.2349&node=6079938675
This is currently very much "work in progress" and far from being finalized, but you might find it helpful.


Are there objections to this proposal ? Do you recommend to open this subject on the Discussion page or is it best discussing it on this list ?

Regards,
Antoine.


Jan


_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Reply via email to