[Tagging] Using destination_sign relations for pedestrian navigation

[Jan Michel]

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