[OSM-talk] Pedestrian crossings and barriers

David Earl david at frankieandshadow.com
Sun Jul 29 20:54:45 BST 2007

On 29/07/2007 20:07, Peter Miller wrote:
> This seems to be one of those threads connected to a can of worms, and ok we
> also can't upload anything today so we have got time to talk.
> Would it not be reasonable to mark the central node of a simple junction
> with 'highway=traffic_signal'. The simulator, router and renderer will all
> assume that there is a column and a stop line on each approach and will
> assume that pedestrians will be able to cross at certain times of the cycle.
> For more complex junctions should we not put a node in the highway at the
> stop line on each approach? A rendered might show an actual signal column
> offset a little to the side of the road and appropriate road markings; a
> vehicle routing program will add in a delay, and pedestrian routing engine
> will assume someone can cross.
 > ...

Well, I haven't modelled any junction in Cambridge as more than one node 
other than roundabouts and links across dual carriageways which are 
usually two, so the point is moot from my pov.

But if you want junction modelling I think there is _much_ more to it 
than just the signals on the approaches. If you look at what Simon 
Nuttall has done (via Google maps) on the Cambridge Cycling Campaign 
route planner, you'll see he has junctions to the level of every 
approach lane (some of which have advance stop lines on them and some 
don't), the multiple ways a cycle gets across a junction and so on.

I think the way to handle this is to have a separate junction modelling 
structure which the simple node refers to, so you can get a complex 
junction model if you want it.

But I also think it would be better use of our time at the moment to be 
broadening the mapped area than to concentrate on this level of detail. 
Later perhaps.

But if you do want each signal head etc, how about using a separate tag 
for that, so we can just plop a simple icon on the junction in response 
to one tag, but model the junction in more detail via others. Let's make 
it easy on the renderers while still allowing for richness of data.


More information about the talk mailing list