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”.
. 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.