The fourth UK Quarterly Project of 2024 (October, November, December) is on pedestrian crossings and traffic lights. While adding more crossings and traffic lights will help car routers better estimate times, this data is truly helpful for pedestrians.
See the wiki page at UK Quarterly Project/2024/2024 Q4 Project: Crossings - OpenStreetMap Wiki for further details of tagging to consider and suggested tools to use.
It looks like I’ve made an early start, before finding out what the quarterly project was.
A couple of things which might be worth looking at and eradicating:
Someone in Cardiff helpfully decided that crossing=traffic_signals would be better off changed to crossing=marked + crossing:markings=yes. I’m sure VI users will be delighted to be deprived of the information that the marked crossing (which is marked) is a signalised crossing and might have sound and tactile indicators.
Good to see this. Crossing information is vital for pedestrian routing. I’ve added a link to osmwiki:Crossings, which has a nice table of which node tag goes with which tags the crossing way should get, if there is one.
Some task ideas:
Round here, a lot of crossing:* tags that should be on the intersection node have been duplicated to the highway=footway+footway=crossing, or only exist there. That’s probably an error that can be searched for.
Ways tagged as the bit-that-crosses-something that aren’t attached to a crossing node shared with something that can be crossed? Not sure how much of a problem that is.
It’d be nice to link an Overpass query for stray footway=crossings which don’t join sidewalks or any kind of highway=footway. We have loads of those around here too 
I guess they should probably be quietly removed if they’re over a certain age? If they’ve not had a separate sidewalk attached after a few years, it’s probably safe to assume that the mapper that created them hasn’t been able to keep up with the necessary sidewalk additions for that level of detail. Perhaps the sidewalks are represented with tags on the road, in which case these go-nowhere crossing way stubs are probably just purely wrong.
I think crossing:markings:* probably does have an excuse to be on the way as well, as it’s a property of the whole way. It’s when people copy all the tags that problems could arise, as tactile_paving=yes has a slightly different meaning on nodes compared to ways.
Agreed, with one possible exception. If the crossing way end nodes record information about asymmetric kerbs or tactile paving, they could be worth keeping as that is hard to record on the crossing node itself.
Prompted by this project, I’ve been having a look at some of the tags we have to add information about crossings. I’m a bit confused by two options:
The wiki page above for crossing=uncontrolled talks about the absence of traffic signals, and suggests zebra crossings are an example of an uncontrolled crossing. But lower down, there’s a specific bit about the UK, that says that most types of markings on the road (including zebra crossings) make it a controlled crossing in the UK. But then lower down there’s a picture of what appears to be a UK zebra crossing with the suggested tagging crossing=uncontrolled. To possibly resolve some of the inconsistency, perhaps the Belisha beacons on UK zebra crossings are considered “traffic signals”? Or is the whole “Teminology” section just raising some issues, rather than defining how crossing=uncontrolled should be used in those regions? The page really doesn’t seem very clear.
If UK zebra crossings are “controlled”, then what’s the difference between crossing=uncontrolled and crossing=unmarked in the UK? (I could have seen the latter being used for cases where there isn’t even a dropped kerb or any other indication of a crossing, but that’s not what the wiki page for crossing=unmarked says.)
Given all the different tagging options, and the fact that there are only a few different types of crossings in official use in the UK, I think it would be helpful to have a list of the standard UK crossing types, and the appropriate tagging for them. Does that exist anywhere already?
I prefer to use crossing=marked rather than uncontrolled for zebra and parallel crossings, because DfT guidance on tactile paving considers them to be controlled crossings. While DfT and OSM meanings don’t need to align, I’d rather avoid the tag with potentially contradictory meanings.
I’m not sure if there’s a list, but what I currently use for normal crossings (and which is hopefully uncontroversial) is:
Pelican
crossing=traffic_signals + crossing_ref=pelican + crossing:signals=yes + crossing:markings=dots
Puffin
crossing=traffic_signals + crossing_ref=puffin + crossing:signals=yes + crossing:markings=dots
Toucan
crossing=traffic_signals + crossing_ref=toucan + crossing:signals=yes + crossing:markings=dots + bicycle=yes
Pegasus
crossing=traffic_signals + crossing_ref=toucan + crossing:signals=yes + crossing:markings=dots + horse=yes
Zebra
crossing=marked + crossing_ref=zebra + crossing:markings=zebra;dots
“Copenhagen crossing”
crossing=unmarked + crossing:continuous=yes
All the parallel crossings in London have probably already been mapped by @MacLondon, so I haven’t really had to think too much about them.
I’m not a great fan of crossing:signals=yes, but include it to protect information from future iD-isms. iD has done so much to skunk crossing=* in the past and is now cheerfully devaluing crossing:markings=* by encouraging mappers to “upgrade” the tags with the useless crossing:markings=yes instead of actually looking at the imagery and tagging something useful.
As someone who doesn’t have an in-depth knowledge of this sort of thing but occasionally answers questions in StreetComplete - what will I get wrong? What tags from there won’t match what is suggested above?
iD now has the ability to limit presets to specific countries/regions.
Would it make sense to add a set of UK-specific crossing presets for some or all of the above to the iD tagging scheme? The generic crossing preset that tags crossing:markings=yes could then even be disabled for the UK.
StreetComplete doesn’t touch crossing_ref=* at all. It would be nice to have a quest for it, perhaps initially in SCEE if it can be made sufficiently country-specific.
StreetComplete’s Specify whether pedestrian crossings have traffic signals quest will add crossing:signals=yes for highway=crossing nodes with either crossing=* unset or crossing=island. I’m not sure why it doesn’t set crossing=traffic_signals as well, but this doesn’t conflict with the tagging above.
The Specify whether pedestrian crossings have markings quest currently adds crossing:markings=yes for highway=crossing nodes with either crossing=* unset or crossing=island, and with crossing:markings=* unset and crossing:signals=* unset/no. I think there’s an intention to improve that in SC and there’s an extension in SCEE to add specific markings.
The quests for additional features (button_operated=* , traffic_signals:sound=* and traffic_signals:vibration=*) at signalised crossings are active for both crossing=traffic_signals and crossing:signals=yes
I noticed that wiki page suggested using crossing=marked in place of crossing=traffic_signals for pelican, puffin, toucan and pegasus crossings. That change was introduced by @Minh_Nguyen and supposedly based on two proposals, an inactive one from 2018 (suggested replacing crossing=zebra and crossing=uncontrolled with crossing=marked) and an abandoned one from 2019 (suggested replacing crossing=traffic_signals with crossing:signals=yes). Neither of those actually suggested changing crossing=traffic_signals to crossing=marked, so I have revised the page.
https://wiki.openstreetmap.org/w/index.php?title=Crossings&oldid=2764777
I wonder if this is why Cardiff had a few hundred mis-tagged crossings?
This table just summarizes what the proposals stated at the time; they aren’t necessarily tagging recommendations. For simplicity, I combined the 2018 and 2019 proposals in a single column, since they were essentially the same proposal. Later, someone jammed the 2022 proposal into the same column, noting its approval. Unfortunately, that gives the impression that this column supersedes the ones to the left, but that wasn’t my original intention.
The 2019 proposal consisted of multiple “sub-proposals”. One called for deprecating crossing=traffic_signals, while another called for applying crossing=marked to any marked crossing, regardless of signalization. You can see in the examples that these proposals envisioned using crossing=marked for signal-controlled crossings too.
In the interest of clarity, I’d suggest restoring the previous version of the 2018/2019 column, and maybe splitting out another column for 2022. If there’s another commonplace tagging style that isn’t properly represented in this table, consider filling out that currently blank “Newer” column with that style.
The 5 years old inactive and now irrelevant proposal Proposal:Crossing:signals claimed that “crossing=traffic_signals forces mappers to choose between markings and signalization”. As we now have an approved and relevant proposal for crossing:markings=*, I think we can safely disregard that.
I would suggest we simply delete the 2018/2019 policy column, instead of pretending legitimacy for inactive and abandoned proposals.
I am not sure why you decided there was any reason to drop the crossing_ref=* values. The difference between a pelican and a puffin crossing in particular is relevant.
If you want to deprecate crossing=traffic_signals, please go through the process of RFC, proposal and a vote.
Getting back to the UK Q4 project, so far this week I have restored ~300 crossing=traffic_signals nodes in Cardiff which were either dubiously tagged as crossing=marked (without crossing:markings=*) or tagged entirely incorrectly as crossing=uncontrolled. I still have 461 crossing nodes to review in order to find out what sort of crossing they are.
I see that @Hungerburg raised iD issue #10474 Gratuitous crossing:markings=yes about 3 weeks ago.
Thanks. From the perspective of iD, these are two slightly separate issues, but both related to the crossing presets in the iD tagging schema.
If there’s community support for the idea of having UK-specific crossing presets - and agreement which tags to use - I can start working on it.
There’s one possible issue I can think of: if there’s a preset called “zebra crossing” and selecting that preset sets the tags crossing=marked + crossing_ref=zebra + crossing:markings=zebra;dots, then will mappers accidentally set those tags for “zebra crossings” across cycle tracks that don’t actually have dots? What about private roads e.g. supermarket car parks and airports?
I think presets for pelican, puffin, toucan and pegasus crossings could be quite helpful if others in the UK community support the idea.
You’re quite right that zebra crossings are a bit more complicated than just the representation of a normal zebra crossing over a road.
For the zebra-like-crossings on private roads, I’ve used crossing:markings=zebra + the rather messy kludge of not:crossing_ref=zebra. If we could decide on something better than that, I’d love to get rid of those. Maybe something like crossing_ref=informal_zebra to make it clear that the legal rules do not apply?
We also have parallel crossings, which are sometimes mapped as a single crossing and sometimes with separate ways and crossing nodes for the footway and cycleway.
I like the ideas from @Minh_Nguyen’s Proposal:Crossing_signalization to give more useful values to crossing:signals=* . I think we would need separate values for:
I would definitely support the idea of having presets that match the crossing defined in the Highway Code. The easier we can make it to identify and assign, the more are likely to be registered consistently.
You’re reading way too much into the table on that page. I only meant to very literally summarize the various interconnected proposals and tagging schemes over the years, because this information had been scattered about inconsistently throughout the wiki, mixed in with rumormongering about iD.
I have opinions on the evolution of crossing tagging, but I tried to leave that out of the page. I even omitted my own proposal, because I hadn’t had the time to put it through an RfC yet.
The whole table is only there for historical interest, to get everyone on the same page about this complex situation. Part of the approved 2008 proposal was obsoleted by the 2011 approval of crossing=unmarked. The crossing:markings=* proposal explicitly avoided wading into the issue of signalization, so it’s irrelevant to both crossing=traffic_signals and crossing:signals=*. The 2018/2019 proposal ignored crossing_ref=* while the 2022 proposal deprecated some usage of it.
When I compiled the table a couple years ago, there was still so much mistrust and disagreement that it wasn’t possible to make any tagging recommendations at all. If the situation has improved, then by all means we should document the new consensus.
Regardless, this page is not very useful for the UK. Unlike the rest of the world, you’ve always had a good reason to tag zebra, toucan, and pelican. Full tagging recommendations for the UK should go in a UK-specific guideline page. Otherwise, if you try to discuss them in the global “Crossings” overview page, mappers in other countries like Germany and the U.S. will once again co-opt the zoo animals for other purposes.
Interesting, is the location at the near side, far side, or both a significant distinction? I know that ordinary traffic signals in some countries can be positioned in different places, but it usually makes no difference in terms of traffic laws. If this does matter, I could definitely add it to the proposal, though I need help coming up with less confusing keywords.
The older ones use something closer to a normal traffic light to signal the pedestrian (from across the road) and have instructions on the button box. The button box has a light up “WAIT” instruction.
The newer ones have the pedestrian stop/go lights integrated into the box with the button. I assume this is cheaper and easier to see for visually impaired users (although they also tend to have the spinning cone thing too). Sometimes these have a similar button less version a little bit higher, I think this is for ones expected to be crowded.
The difference for the vehicular traffic is that the newer puffin style crossings are meant to have sensors to detect whether pedestrians are still crossing or waiting to cross and will change the lights for vehicles to suit while I think the older ones are based on the time elapsed and will show a flashing amber light after a while drivers can go during this period only if the crossing is clear.
In theory Puffin crossings should be more efficient for all involved and shouldn’t even activate if someone has pushed the button and then crossed before the lights told them they can.
I think it would be great to agree and setup iD presets for the main crossing types that we have in the UK. The traffic regulations we have mean that there’s only a small number of standard crossing types on public roads, which makes it idea for presets.
I’d like to see presets for the formal types: zebra, pelican, puffin, toucan, pegasus, and parallel, and probably also for the generic cases “unmarked by with drop curbs”, and “raised table / continuous”. As has already been suggested above, I think it would also be good to have a second zebra type for the informal cases of zebra stipes that you often see in retail park car parks that don’t have the Belisha beacons.
Apart from agreeing on the precise tagging detail for each one, there’s the issue of how to deal with the new-style “parallel” zebra crossings, which have a zebra crossing for pedestrians and a parallel cycle crossing (marked but not by zebra stripes) between the beacons. Should this be mapped as a single cycle/footpath (with segregated=yes) crossing the road or two separate crossings next to each other? Or do we need to cater for both styles of mapping?
I’ve just been playing with Overpass Turbo, and thought it might be useful to see details of crossing in my local area that don’t have a basic categorisation defined.
So I ran the following query to see what it would find:
[out:xml][timeout:240];
(node["highway"="crossing"]
["crossing_ref"!="zebra"]
["crossing_ref"!="pelican"]
["crossing_ref"!="puffin"]
["crossing_ref"!="toucan"]
["crossing_ref"!="pegasus"]
["crossing_ref"!="parallel"]
["crossing"!="unmarked"]({{bbox}}););
out meta;
There’s lots of drop-curb only side-road crossings that don’t currently have crossing=unmarked, which could easily be fixed if needed (but perhaps having crossing:markings=no is sufficient instead). The other big group is where there are pedestrian crossings that are integrated with traffic signals for a junction. Does anyone know if these are regarded as being pelican/puffin/toucan crossings or something different?
I’m not sure there’s any local to me, but is it possible for crossings at a signalised junction to not have a pedestrian call button but to just work as part of the phasing of the traffic flow signals? If so, is there a special name/category for this, it feels it might not be standard pelican/puffin/toucan crossing in that case.