OpenStreetMap

Responding to suspicious changes

Posted by manoharuss on 17 August 2016 in English.

Following up on a recent series of posts that summarized the suspicious changes on the map, an interesting question that we bring to the community - what is a good amount of time to wait for a response from an inexperienced mapper before fixing or reverting their edit?

You can see examples of such changesets that do not seem right on these posts:

Observations from last week

  • User added unexplained nodes with alphanumeric names: 1, 2. A community member commented on these changesets and reverted them.

The community is great at responding to mapping issues but there are few issues lying under the rug. When we see unexplained edits without a clear comment or source, we do not go and fix them immediately, but let the user know the best practice and try and encourage them to to become a better mapper.

During the last 3 months the data team at Mapbox has commented on around 78 changesets and fixed only around 10 changesets. Over the course of last 1 year we have commented on around 250 changesets that did not get a reply from the user (quick map of these changesets).

It is a very subjective question to ask how long do we wait before we take the plunge into fixing or reverting changesets like these which may be suspicious, but is difficult to verify from the original mapper. Happy to hear how you approach this issue.

Discussion

Comment from Andy Allan on 17 August 2016 at 11:45

Of the 250 changesets where you didn’t get a reply, how many of the users involved have made further edits? It might be reasonable to expect a response from mappers who are continuing to be involved in the project, but you might be waiting for mappers who never contribute again.

Comment from BushmanK on 17 August 2016 at 16:21

Since there are more and more users, who have no understanding of (often - unwritten) principles of OSM, certain paradigm shift becomes more and more justified - correction without any waiting period, but with more or less detailed explanation of what’s wrong with this edit.

Waiting certain period serves for teaching newbies by allowing them to fix their mistakes by themselves. This approach is based on assumption, that every contributor wants to be involved in further editing and wants to develop himself into a better contributor, which isn’t necessarily a case - some people just want to try editing, or to “add a couple of things”. But data quality is still a primary objective of OSM, so, there is no much sense in assuming it automatically anymore, because leaving the whole bunch of wrong objects makes map data worse, while actual users of data (third-party companies, rendering style maintainers, etc) don’t really care about wrong data, kept for the purpose of education.

Comment from SomeoneElse on 17 August 2016 at 19:11

For brand new local mappers, I tend to wait a week or so before commenting on any minor issues that they’ve caused (although if it’s something major, like the deletion of a major road, it tends to make sense to fix it immediately and let them know that “something went wrong” in their edit). A large number of new note-adders and editors are mobile apps users (not just MAPS.ME) who may not know that they’re updating a shared map at all; in those cases it makes sense to me to react more quickly. Basically, let new mappers make mistakes, and let them find and fix them too.

However after any comment I absolutely don’t think that you should “plunge into fixing” (to use your words) if you don’t get a reply from a new OSMer. By necessity Mapbox editors are mostly remote mappers - in many cases the best action will be to add a note so that someone who’s actually local can resolve the issue. I tend to wait a week or two between a non-answer to a question and taking the next step (usually adding a note).

Comment from Tomas Straupis on 17 August 2016 at 20:18

Do not make simple problem larger. After ten years of practice:

  • If the change brakes something seriously - you revert or fix it straight away and notify the user.
  • If it is a small bug, you fix it and notify a user.
  • If it is something with little impact - just notify a user (and take appropriate action after a day or so if the user does not react).

That is: QUALITY of the map is the priority and then you want a mapper to understand what he/she did wrong and why.

P.S. With one exception. If the change comes from CRAPS.ME user - revert the change and don’t even try contacting the user because its pointless. CRAPS.ME users do not realise they are changing OSM maps, they think they are changing “CRAPS.ME” “offline” maps, so they ignore messages from OSM as “irrelevant”.

Mapbox reacting to 78 changesets in 3 months!!!! only means they do not understand which changesets are good and which ones are damaging ones.

Comment from Tomas Straupis on 17 August 2016 at 20:30

And one more point. Subjective “checks” are pointless. Please add an objective and clear description (rules) what makes a change “bad”. HOW do you decide if a change is good or bad (and how do you decide it is “good”). Is it the error rule like one in keepright.at or osmose, is it a simple rule like “user=Komяpa” (actual rule which was used to find crap) or something else? Otherwise your findings are pointless.

Comment from Tomas Straupis on 17 August 2016 at 20:44

Check the image in this blog post: https://blog.openmap.lt/2016/03/25/klaidos-baltijos-juros-regione/

You can clearly see the contours of Lithuania. That is because people in Lithuania take care and TAKE ACTION fixing errors instead of bragging or enjoying statistics of “increased contribution” which only increase the number of errors much more than increase the amount of useful data (like CRAPS.ME does).

That is there is already enough of QA done with results ignored. Fix that before doing other arbitrary “observations”.

Comment from Warin61 on 17 August 2016 at 21:40

How Long to Wait?

Maximum: 4 weeks - this allows for holidays …

If the mapper is active during that time period .. then less time needs to be allowed.

If the mapper has made few edits with long time gaps between the edits then they are an ‘infrequent mapper’ and may be unresponsive.

Note that contact with them should be respectfull and express a view point rather than a ‘rule’.

Comment from BushmanK on 17 August 2016 at 21:52

@Tomas Straupis,

I’d say, that after ten years things are changing - quantity transforms into quality (lack of quality, actually). If there is, say, one person who did some nonsense edit per square kilometer per week, it’s 0.001% of data in the same area, so it’s okay to allow this person to learn by fixing his edit by himself. And it was the case for a long period. But if there are twenty people doing the same per square kilometer per week, it’s already 0.02% and so on. Nothing new, except the scale of situation. While number of active, experienced and responsible mappers doesn’t grow equally fast.

Comment from BushmanK on 17 August 2016 at 22:06

@Warin61,

OSM principles are not “view points” or “opinions” by definition. There are, indeed, certain cases with some space for interpretation. Mistakes are often understandable, but OSM does have rules. Like, value of contact:phone key must be in international format (including country code); opening_hours key has it’s own format and must not contain stuff like “from five to three”; streets on different levels (going by and under the bridge) must not have common node. If someone needs to be addressed with “Dear Sir, …” instead of receiving brief quotes from documentation not to feel offended or addressed in rude manner, that’s just immature and oversensitive. (To learn, what’s “rude”, go read some comments to pull requests from Linux kernel developers.)

Comment from PlaneMad on 18 August 2016 at 14:04

@BushmanK if there are indeed rules on the map, we should ideally enforce it in the software end rather than poking newbies, which would get out of hand as more and more new contributors come in through new tools and not necessarily a mapping party like the old days. It feels like the system is way too liberal in allowing data to break which could otherwise be prevented at the source if the editors or the API rejected any changes which breaks the rules.

Comment from BushmanK on 18 August 2016 at 15:49

@PlaneMad,

First of all, how did you turn “quoting some documentation” into “poking”?

Mapper (including a newbie) always bears the responsibility. It is possible to enforce certain rules and to implement some pre-upload validation (just like it’s working in JOSM). But it is impossible to completely replace mapper’s responsibility (at least until we can’t replace mapper himself with an artificial intellect completely).

Good example of it is usage of wrong tags to map certain objects - syntax is perfectly correct in this case, but wrong tag is used instead of proper one (I mean, amenity=waste_disposal instead of amenity=recycling or otherwise, for example). You can not fix this problem with validation.

And speaking of (mapping) parties - since mapping is among those “highly structured occupations”, drawing attention of people with autistic spectrum disorders, it’s correct to assume, that there is certain amount of people among mappers, who, due to their psychological condition, do not really like when totally unknown person tries to sound like he’s a friend or to invite them to participate in any group activity. In this case, neutral logical explanation with documentation references work way better than “friendly atmosphere”. As I said before, socially mature responsible person usually does understand neutral comments, so it should work for almost everybody.

So, your argument doesn’t sound strong at all.

Comment from DaveF on 26 August 2016 at 11:01

Mapbox mappers complaining about “suspicious changes”?

Oh, the hypocrisy.

Mapbox needs to concentrate on improving their own editing before criticizing others. I’ve spent far to much of my OSM time contacting them about their dubious edits.

Log in to leave a comment