Talk:Proposed features/traffic signals set
This relation can be more complex then just a group of traffic lights. It would be great to add more detailed roles like car_signal/pedestrian_signal/cycle_signal/stop_line etc.
- I'll add that --Sanderd17 12:46, 8 January 2011 (UTC)
- I don't think that a destinction in car/pedestrian/cycle signals would be useful, because they are often combined, or one on each side for the respective direction. If you want to do extreme micro mapping, you would need set many signals beside the way, making it impossible for routers to take them into account unless you include the ways in the relation too. --Fkv 07:21, 11 May 2011 (BST)
- There are stop lines on uncontrolles crossings too. First of all, we need to define how stop positions are mapped in general. I am not happy with the existing proposals and would prefer something like stop=forward/backward/both, defining the actual stop position and direction instead of the signs. --Fkv 07:21, 11 May 2011 (BST)
This proposal is something I was always looking for. However, it only defines which traffic signals belong together. It does not define the crossing itself, or which roads meet at that crossing. In the long run, we will need to do that, and then a type=crossing_signals_group would be misnamed. Therefore, I made a draft here for a general crossing relation. --Fkv 07:21, 11 May 2011 (BST)
A smart router will likely discount the effect of signals within a certain radius. Thus two or three signals in a tight cluster will be assumed coordinated, and incur one penalty. Brycenesbitt (talk) 06:29, 26 February 2015 (UTC)
- Routers cannot derive waiting times from coordinated signals. Pedestrians and cyclists (on cycleways) you often have to wait 3 times on one junction, because when you have a green light, the next one switches to red. --Fkv (talk) 06:59, 26 February 2015 (UTC)