[OSM-talk] Pedestrian crossings and barriers
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.
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