OpenStreetMap
At least some versions of Maps.me editor (for example, MAPS.ME ios 7.0.4) have a bug, that makes it adding a banner_url= key with a value, that contains a shortened link to some pages, related to Maps.me advertising system.
@Zverik (Ilya Zverev, OSMF Board member, who works for Mail.ru/Maps.me) have assured us in his message on the Russian OSM forum, that it’s a known bug and so on. However, nobody knows, how long some users will keep that buggy version and how long these tags will continue to appear.
Using a simple Overpass query and JOSM, I already have removed about two hundred banner_url= keys from objects, recently added or edited by Maps.me users. It doesn’t take much time, but I’m curious - is there a way to automate it and run a cleanup script, say, once per day?
Another question is more of a moral kind. Indeed, Maps.me developers (@Zverik himself) have provided a supervision tool for changesets created by Maps.me app. However, it puts the whole burden of supervision on volunteering mappers, while there is no way to reliably detect some anomalies automatically, it is understandable. But this exact case with banner_url= might not have a large impact (about five wrong tags per day), but it is known for a long time and for anyone familiar with a scripting language, it shouldn’t take much time to develop an automated cleanup tool. But nobody of Maps.me developers did that. That doesn’t seem like a responsible manner of working with OSM data. Keeping in mind, how pushy @Zverik (as a moderator) is about being nice and respectful to others on Russian OSM forum, this situation seems like a significant hypocrisy.
Discussion
Comment from Alan Trick on 31 January 2017 at 19:28
Zverik did say he would remove the tags. I imagine the reason an automated tool isn’t being used is because of the general hate for them, and the fact that they can due really stupid things. Also,
banner_urlisn’t a standard tag, and has no semantics, so it’s temporary presence isn’t terribly harmful.This does remind me of something else though. Has anyone given much thought to rejecting changesets with nonsensical data (e.g. nodes that have no tags and are not part of a way)? Ideally the editors would flag these errors before allowing a changeset to be submitted, but that isn’t always the case.
Comment from BushmanK on 31 January 2017 at 20:25
@Alan Trick,
Since we don’t have any objective criteria to measure, how harmful is any particular piece of obviously wrong data, I don’t see any sense in “measuring” an amount of harm. That tag, obviously, should not be in OSM database. So, it has to be removed. The only question is who is responsible for that. This problem was identified a month ago. A promise to fix that was made two weeks ago. Since then, Zverik has found some time to argue about that on the Russian OSM forum and even to ban one person who unreasonably accused Mail.ru/Maps.me in doing that intentionally.
Indeed, that’s not the only issue and it’s not the worse one. However, there are cases, where it is impossible to implement any universal fix or solution, as well as cases, where an issue is caused by multiple parties (many different mappers). While here, the issue is absolutely clear, the responsible party is well-known, the solution is simple. If that would be an import, according to OSM import guidelines, author of that import is completely responsible for any required cleanup. But somehow, not in this case, while it is not different from imports.
Comment from Alan Trick on 31 January 2017 at 21:12
I think it is worthwhile to distinguish between data that is contrary to ground-truth (or in the case of the
sourcetag, contrary to standardized practice), and data that has no standardized semantics and is just noise.Noise kinda sucks for editors, and it should certainly be removed, but apart from the annoyance of it, it causes little practical harm. Also, it’s generally easy to remove, both manually and automatically.
As for incorrect data in a tag that has a standardized meaning, well that’s quite bad for (I think) obvious reasons.
Comment from Alan Trick on 31 January 2017 at 21:14
Also, there is certainly an argument to make for not having noise there to begin with (i.e. strictly validating all tags to make sure they are approved) but that’s a whole other ball of wax.