[OSM-talk] Pedestrian crossings and barriers

Peter Miller peter.miller at itoworld.com
Sun Jul 29 18:55:58 BST 2007

Comments in-line

> Message: 6
> Date: Sun, 29 Jul 2007 11:06:19 +0100
> From: Mike Collinson <mike at ayeltd.biz>
> Subject: Re: [OSM-talk] Pedestrian crossings and barriers
> To: <talk at openstreetmap.org>
> Message-ID: <200707291008.l6TA8Rv2022181 at ayeltd.biz>
> Content-Type: text/plain; charset="us-ascii"
> At 09:34 AM 29/07/2007, Peter Miller wrote:
> >
> >The new cycle mapping is throwing up questions about crossing points
> along roads which we are going to need to sort out.
> >
> >On the Map Features page there is only a single sort of crossing
> available: highway=crossing. On the GravityStorm page there is a
> proposed tag crossing=toucan, which makes sense but I dont believe it
> has been voted on (forgive me if I am wrong).
> ><http://www.gravitystorm.co.uk/shine/cycle-
> info/>http://www.gravitystorm.co.uk/shine/cycle-info/
> >
> >There are actually a number of different types of crossing that need to
> be accommodated and also, we should avoid UK-centric language (Toucan
> is a UK name for a signalised crossing for pedestrians and cyclists).
> >
> >Note: I am only talking about methods of crossing from one side of a busy
> road to another. If there is a more elaborate set of paths and tunnels
> required then footways and bridges etc should be encoded. An underpass for
> a dual carriageway will need to be encoded as two tunnels and a footway
> etc. For single carriageway roads we need to be able to encode for the
> following:
> >
> >A zebra crossing (white lines on the road to help pedestrians cross)
> >A pelican/puffin crossing (an automatic signal controlled crossing for
> pedestrians)
> >A toucan crossing (a signal controlled crossing for pedestrians and
> cyclists)
> >A An underpass for pedestrians
> >An underpass (for pedestrians and/or cyclists)
> >A footbridge (for pedestrians and/or cyclists)
> >A refuge in the middle of the road
> >A lollipop crossing
> >A Pegasus crossing (a signal controlled crossing for pedestrians,
> cyclists and also horses)
> >
> >
> >There is a technical difference between a Pelican crossing and a Puffin
> crossing (where did all those birds come from!) but I dont think we need
> this at the top level. All these sorts of crossing are described here:
> ><http://www.edu.dudley.gov.uk/roadsafety/puffin.htm>http://www.edu.dudley
> .gov.uk/roadsafety/puffin.htm
> >
> >As well as all these crossing types we need a way of indicating that
> there is actually some sort of barrier to pedestrians and cyclists
> crossing the road wherever you feel like it, which might be a physical
> barrier in the middle of the road, a barrier at the side of the pavement,
> or shear traffic volumes.
> >
> >It may be appropriate to make the assumption that on primary, trunk and
> motorways that crossing is not possible (unless tagged to the contrary),
> and the for all other road classes it is (unless there is tagging to the
> contrary).
> >
> >Any thoughts; and any suggestions about how we should tag this lot?
> I think I'm echoing Tom Chance's reply here, so I'll keep it short.  I
> generally map outside the UK and I'd suggest using current tags where
> possible, I generally use the underlying or connecting way (footway,
> cycleway) to indicate whether a crossing, bridge, underpass (tunnel) is
> pedestrian or cycleway.

To be clear, these crossing often occur away from junctions. A pelican
crossing will often be offset 20 meters from the junction, so there won't
necessarily be any clue as to whether it is for a cycleway (where a cycleway
crosses a highway at a cross-roads). Sure that will sometimes happen, but it
is not reliable.

> The only big gap I see is that it is not possible
> to explicitly distinguish between a signalled and unsignalled crossing -
> from the pedestrian/cyclist POV for safety and from a motorist's POV for
> route speed planning and navigation.  So far I ignore highway=crossing at
> signalled road junctions and just put highway=traffic_signals for
> crossings away from junctions.  highway=crossing;traffic_signals would be
> good but would choke current renderers(?).
> A zebra crossing (white lines on the road to help pedestrians cross)  -
> highway[node]=crossing

I guess that would work, but a renderer would not have the information to
paint it properly on the road. Crossing=zebra can be converted to
highway[node]=crossing but not the other way round. Also, it isn't clear
which more tags if it is suitable for a pedestrian only or also a cyclist. A
zebra crossing in the UK is only for pedestrians and cyclists on foot.

> A pelican/puffin crossing (an automatic signal controlled crossing for
> pedestrians) - highway[node]=traffic_signals

Sure. But one needs to identify the type of user it is for (see above). If
you added pedestrian=yes it would help, but that is two tags.

> A toucan crossing (a signal controlled crossing for pedestrians and
> cyclists)  - highway[node]=traffic_signals

I guess you would add the tag 'bicycle=yes' as well. Personally it is two
tags rather than one and there is again a loss of information.

> A An underpass for pedestrians - highway=footway, tunnel=yes

I assume you are again using this on a node on the highway: highway[node]
'highway=footway', 'tunnel=yes'. Sounds good, again two tags not one which
is tedious with the josm, but it can be done.

> An underpass (for pedestrians and/or cyclists)  - highway=cycleway,
> tunnel=yes

I like the way you get the most out of the tags, but again it is two tags
not one.

> A footbridge (for pedestrians and/or cyclists) - highway=cycleway,
> bridge=yes

As above

> A refuge in the middle of the road  - hmm, no ideas on that one

I think this is where the lack of semantic level shows up. A refuge is no
different from the zebra in the low level model, but it is different for
both the pedestrian and the vehicle (the vehicle has to stop at a zebra, but
doesn't at a refuge') and for a pedestrian the zebra is much safer So there
is important information lost for both user-bases.

> A lollipop crossing - UK-centric?,  you mean a school crossing manned by
> a person with a sign at certain times?

That's correct. All these terms are described by the link on the original

> A Pegasus crossing (a signal controlled crossing for pedestrians, cyclists
> and also horses)   - highway[node]=traffic_signals 

I assume there would also be a tag 'highway[node]=bridleway' which ends up
feeling very tortuous.

On balance I think I will always encourage use of higher semantic
descriptions, especially for features of which there are millions of
occurrences around the world. I will also encourage explicitly saying how
these higher level features can be devolved to simpler features and tags (as
you propose above), so a vehicle navigation system does have to worry about
the subtle high-level distinctions needed for other purposes, but just sees
'traffic_signal' or even 'potential delay' for all of the above except for
the refuge. A map for the wall of a primary school will have an entirely
different perspective and will see 'safe crossing point' 'poor crossing
point' and 'crossing not possible'. In the UK the terms Toucan, Pelican and
zebra are the right terms for this and fit with safety training within
schools and with the highway code.

I suggest that we get on with it for a few weeks and then come back to a
review, consultation and hopefully some voting; but by then we can then
hopefully do the voting for a job-lot of Map Features that have some common
logic and theme and can be seen in action.

To summarise: I will tag highway nodes as follows:


Regarding barriers, I will assume that motorways/trunk roads and primary
roads have a default of 'barrier=true' and all other roads have a default of

So, if I want to indicate that a secondary road should not be crossed except
at a crossing point I will add a tag to the link of 'barrier=yes' or that a
primary road can be safely crossed 'barrier=no'. We might like to play with
tags such as 'barrier=traffic' or 'barrier=physical' to indicate to a
renderer how to represent the feature.



More information about the talk mailing list