I’ve noticed a few edits pedestrian crossings with refuge islands in London mapped with both a highway=crossing node and a highway=footway + footway=crossing way. Most of these seem to have taken place around September 2025.
In most cases, these were originally mapped as a single crossing way with a crossing node in the middle, both tagged with crossing:island=yes.
Several of Meta’s mappers (PedestrianMapping_* and VLD* user names) have split some of the crossing ways into three parts: footway=crossing + footway=traffic_island + footway=crossing, with the road intersecting the traffic island way at a single highway=crossing node.
If a data consumer looks at the footways only, that gives a more complete description of the crossing, particularly where there are different kerb heights and tactile paving at the side of the road and on the crossing island. However, this doesn’t seem to be documented anywhere and I have no idea how data consumers might handle crossing ways without a crossing node, or traffic island ways which have an unexpected crossing node.
The PedestrianMapping_* users have so far ignored changeset comments and have made unrelated pedestrian edits which strongly suggest that they fail the “know and care what you’re doing” test needed for their edits to be useful.
@RVR015 Is there anywhere I may have missed where this style of mapping crossings is documented, or where this part of Meta’s organised editing in London was discussed?
Please provide a link to the location or changeset in question.
Splitting crossings with islands into three separate footways is good practice, but should (probably ‘must’?) be paired with splitting the roadway into the dual-carriageway mapping model because of the physical separation. In that case, there would be the two highway=crossing nodes, one per crossing way, as usual. The pictured mapping looks incorrect to me.
It’s yet another symptom of large US tech companies deciding that it’s absolutely fine to use a tasking manager to unleash inexperienced, untrained and unsupervised mappers on London, without bothering to follow the organised editing guidelines.
It’s okay to map at a lower level of detail (single road per approach, single crossing per approach), and it’s good to map at a higher level of detail (two roads per approach, two crossings per approach), but if one wants to map the pedestrian infrastructure in detail (a very good thing!) then for these situations I think the roads need to be updated as well in order to properly model the situation.
And note, I’m generally not an “If you edit an element, you are obligated to make sure everything about that element is correct!” kind of person
In its guidance to mappers, Meta should make clear that, when traffic island footways are mapped separately, the roadway geometry (and the associated things like route relations using those roads) should be updated too.
Once I’ve finished eliminating almost all of Uber’s unwanted sidewalks in London, I’ll make another proposal for the removal of separate sidewalks on minor roads added by anyone using a tasking manager.
Pedestrian mapping isn’t a suitable task for novice mappers. It’s quite fiddly and if you don’t actually use OSM-based pedestrian routing and aren’t familiar with the city in question, even with the best intentions, you will mess it up. As locals are more likely to respond with brickbats than with bouquets, OSM potentially loses people who might have become useful contributors, just because they didn’t start with suitable projects.
There are also a few mappers we should be happy to lose, like those who want to complete a tasking manager square as quickly as possible and draw sidewalks straight through physical features. They’re just [expletive deleted]s.
I’d say we should be happy to lose bad mappers who don’t respond to feedback, not all those who map badly. A tasking manager is just a tool. How it may be used is part of the problem, how the projects and mappers are managed is another. The relationship with a paid mapper is different from a volunteer mapper, so that can be an important consideration too.
As you are one of those mappers who is more likely to throw brickbats, how might you instead find ways to encourage mappers to stick around and improve, rather than delete their work and discourage them?
Giving good feedback is hard. Really hard when it gets repetitive. However getting responses back from mappers based on your feedback is good for the soul.
They either don’t respond to changeset comments, or if they do, they don’t offer to fix their broken mapping or ask how to do it. The paid Uber mappers aren’t being paid to fix their mistakes, so most of their contributions need to be removed.
I’m not going to put up with broken pedestrian routing indefinitely in the vague and woolly hope that someone might eventually decide to give a toss.
So, something else I’ve asked in the past that got lost in the chaff. Can you link to some good examples of pedestrian mapping, hopefully in London, that meet your standards?
Is that not a requirement for organized editing? I feel like it should be.
I doubt Uber wants bad data in the maps they rely on any more than we do, so if they aren’t currently paying mappers to fix mistakes they make then that seems like a good opportunity for a process improvement that would benefit both them and us.
Discussing the edits before starting to make them is also a requirement of organised editing and Uber didn’t follow that either.
Uber’s private hire and delivery vehicles don’t rely on pedestrian routing, so doing it badly has no adverse effects on them. I suspect that this may have been intended as a spot of greenwashing: “Look, we helped pedestrians and the disabled in London!” If they’d discussed it beforehand and adequately trained and supervised their staff, that could even have been the outcome.
When Uber have added things like missing service and access roads, I haven’t had a problem with it. In these cases They’re adding data which they want to use in the future, and have driver feedback, GNSS traces and possibly imagery to help.
[…] large US tech companies deciding that it’s absolutely fine to use a tasking manager to unleash inexperienced, untrained and unsupervised mappers […]
I guess we should be ‘thankful’ it’s not agents… yet.
