User apgosm is going about making changes, mostly to kerbs and crossings, based on aerial images and ‘geo json files’. Setting aside whether it’s possible to determine kerb height from an aerial image, this user’s changes to crossings are incorrect (at least sometimes) because the images being used are out of date, and the map was up to date.
The user is affiliated with Uber. However, the Uber contributors page Uber - OpenStreetMap Wiki makes no reference to using aerial images in this way. It also highlights that their contributors are expected to respond to changeset comments promptly. This user is not doing so.
I plan to resurvey the Pool Street and Carpenters Road area for crossing locations and get some streetside imagery made. I’ll revert these (and other) changes following that.
However a lot of changes are being made all over the place, and it seems plausible that good up-to-date map data is getting replaced by data derived from old images in other places too, by this user or his/her colleagues.
What other action is appropriate? Should I (or someone)
Try to confirm with Uber if this user is making changes they’re happy with and following their policies?
It seems to be part of an Uber initiative to inflict even more suboptimal separate sidewalks on London, whether they make any sense for pedestrian routing or not
They’ve done a few other “interesting” things, like replacing surveyed barrier=kerb ways with highway=footway + footway=sidewalk.
I tried suggesting that they change sidewalk=both to sidewalk:both=separate on the parent street, so they added it to the sidewalks instead, because obviously sidewalks would themselves have separate sidewalks on both sides …
I’ve decided that I have neither the time nor the crayons and I’m strongly disinclined to use anything other than the delete key as an unpaid volunteer to fix poor quality work by paid and inadequately trained “mappers” (see also the TfLCID fiasco).
I have created “[Ticket#2026032010000407]” for this. Email data@openstreetmap.org with that at the start of the subject line if you would like to append to the ticket.
It links to it, yes . I just forwarded your initial post (which I got by email) to create a ticket. As you’ve no doubt seen, the block messages asks the user to engage here, so hopefully most of the discussion can be public.
Another example of two Uber “mappers” inflicting poor quality separate sidewalks on central London:
The first mapper added a separate sidewalk on Elizabeth Bridge over the Chatham Main line out of London Victoria station without bothering to add layer=1 + bridge=yes.
The second mapper came along and blindly accepted iD’s suggestion to add railway=crossing nodes, because obviously we’d have pedestrian level crossings adjacent to a road bridge over multiple tracks of a major passenger rail line. They also added some useless crossing:markings=yes tags to nearby informal zebra crossings (on private service roads). Changeset #181024886
crossing:markings=yes is not useless. In fact, it’s the tag that will be added when surveying crossings with Streetcomplete. It’s a lower level or detail, but it’s definitely not wrong or something to be complained about.
It can even be argued that in some cases this less specific value might be preferable. Sometimes the style of markings can change when the crossing is repainted. In an area with many active mappers continuously updating the type of markings, the more specific values are definitely better than a general yes. But in an area with few mappers and infrequent updates crossing:markings=ladder, for example, could end up being slightly incorrect for years after a crossing is repainted from ladder to zebra markings if nobody notices the change. The broader meaning of crossing:markings=yes would have covered both types and would have remained correct after the repaint.
When StreetComplete adds it, that’s one thing. It would be nice if the SCEE update to select the actual markings used found its way into SC.
On the other hand, if you’re working from aerial or street side imagery in iD and you can see that the markings are unambiguously zebra stripes, then there’s no excuse not to add crossing:markings=zebra. If you can see markings and aren’t sure how to tag them, then that’s a good reason to use crossing:markings=yes.
I’m admitted unfamiliar with the density of mappers in central London who are sufficiently interested in differentiating the type of markings on crossings to keep them up to date . If there are plenty, I wouldn’t be surprised. If most of the mappers there are interested in other things, I also would not be surprised.
Can you please drop an email to data@openstreetmap.org with a subject line of “[Ticket#2026032010000407] [Communities/United Kingdom] Two other Uber mappers” with details of the usernames and their edits to specific OSM objects that were a problem? You’ve linked one changeset but not provided more detail than that.
For info, a different Uber account deleted a section of a connecting road in Rotherhithe. I reverted that change and ran JOSM’s validator across the result, and patched up the broken LDP that flagged the issue up in the first place. I’ve asked them to get into contact. A number of other Uber accounts have continued on editing despite being previously told that Uber must abide by the OEG. These have been blocked until they promise to do that.
Edit: A comment by an Uber mapper on the changeset says “We understand the guidelines and will make sure to fully follow them before resuming editing. We will review the details and take the necessary steps to avoid any further issues”.
That, alas, turned out to be just empty words. After a few days they carried on anyway, hence this block.
Separately to that Uber have been in contact with the DWG and we have pointed them to the OEG saying what they need to do, and giving examples of how what they are doing currently is not good enough.
Recently, I emailed Uber (OSM@uber.com) to ask for clarification regarding this matter. Here is their reply.
Hi,
Thank you for reaching out and for offering Uber the opportunity to respond before publication. We appreciate WeeklyOSM’s commitment to balanced reporting and welcome the chance to provide context.
We want to be transparent: we acknowledge that there were genuine shortcomings in how we managed our organised editing activities in London, and we are actively working to address them. Below is an accurate account of the situation.
What happened: Our editing team (apgosm) conducted sidewalk and road network mapping edits in the UK using aerial imagery as the primary evidence source. We subsequently learned — through community feedback — that several of those areas already had accurate, recently ground-truth-verified data contributed by local community members. Our edits inadvertently introduced regressions in those areas, and we take full responsibility.
On community responsiveness: A contributing factor to the delayed responses was an internal communication gap—not all active Uber OSM editors were subscribed to our shared distribution list, which meant OSM community notification emails went unnoticed by the relevant editors. This was not intentional disregard for the community, and we have since taken steps to ensure all editors are properly set up to receive and act on community feedback.
Actions already taken:
We contacted the OSM Data Working Group directly on April 22nd to acknowledge the issues, explain our methodology, and commit to compliance with the Organised Editing Guidelines.
We are actively engaging with DWG’s latest guidance to create specific, region-level activity pages (starting with London) on the OSM wiki, including defined scope, start/end dates, links to local community discussions, and documentation of any objections raised — as required by the guidelines.
We have paused all organised editing in the affected areas until the proper documentation is in place and local community discussions have run their course.
We have established an internal review process pre-editing to assess existing data quality, source recency, and recent community contributions before making changes. We have also implemented additional validations to ensure we exclude already existing well-mapped areas based on recency and avoid any overriding or duplication.
We have committed to responding to all changeset comments and community messages within 3 business days going forward.
We recognise the importance of high quality map data for the OSM community and partners consuming this map data, and well-documented map editing can be a meaningful contribution to OSM not only in London but also in other areas where Uber operates. We are committed to rebuilding trust with the community through our actions, not just our words.
If you require any further information or clarification before publication, please do not hesitate to reach out. We are happy to help ensure the reporting is accurate and fair.
I wonder if Uber and OSM would be better off if Uber mappets work from any Uber driver dashcam video instead of aerial imagery?
Is there anything in available aerial imagery of London that is good enough to use as evidence of highway and footway relationships and change to them?
Well, reading between the , some of that is true… The apgosm issue is what got this issue raised with the DWG this time, but it is not the only one, and this is by no means a new issue. A number of Uber mappers were reported to the DWG for poor mapping (and reverted) just over a year ago.
The assurances we got on 21/04/2025 included (emphasis is as in Uber’s email):
Committed to announcing mapping activities on the Community Forum before initiating any future projects.
Reiterated internally that all editing activity must strictly follow OSM’s SOPs and community expectations.
Clearly that didn’t happen. Here’s hoping that this time it might.
Clearly there’s a typo there; I couldn’t begin to speculate of what!
To be fair to Uber, some recent changesets suggest that they have been using (to quote a changeset comment) “field observations - ground truth, and driver GPS data #Uber”, which is a step in the right direction.
These companies specialise in ‘crisis management’ and deal with the public opinion. Now, they will have unfortunately the chance to lie to a wider audience.
. I just forwarded your initial post (which I got by email) to create a ticket. As you’ve no doubt seen, the block messages asks the user to engage here, so hopefully most of the discussion can be public.
. If there are plenty, I wouldn’t be surprised. If most of the mappers there are interested in other things, I also would not be surprised.
, some of that is true… The 
Clearly there’s a typo there; I couldn’t begin to speculate of what!
Portmanteau of mapper and muppet? Fun word, but perhaps not in the spirit of assuming good faith?