OpenStreetMap
To be fair, we were validating. We validated 5% of the tasks and invalidated 4%. So we went over 9% of the tasks. In 2 hours. With the group of 5 people. And one of us was validating for the first time.
The point is that the validation is not fixing. The validation is approving.
I would like to note our small contribution from Prague. Inspired by London Missing Maps mappers, we started small mapathons this summer. These mapathons are for advanced mappers, we use JOSM, and this time, it was a validation time. I went over multiple sources describing how to validate. I used OSM wiki as a primary source. Then LearnOSM, MissingMaps, and browsed multiple links pointed out by these sources. I attended HOT validation training webinar. I found out these pieces of information bloated, so I stripped them and picked up what I consider helpful.
There are fewer validators than mappers. If validators want to keep up with mappers, they need to validate faster than the mappers are mapping.
Our group was validating buildings with the following workflow:
-
Find out if you are going to invalidate task, usually because of not-orthogonalized buildings, missing buildings, lousy geometry, or buildings mapped with bad imagery.
-
Orthogonalize all the buildings with 4 nodes:
Ctrl + Fand findbuildings nodes:4 inview.- Press
Q.
-
Upload changes and invalidate task with the comment why.
Of course, if there is no problem and everything is mapped as described in instructions, just browse the square and find out if everything is really ok. MarkSeen plugin can help here. If there is one building with wrong dimensions or bad rotation, fix it (Utilsplugin2 and X for resizing help here a lot). If you find out the second one, invalidate. Validating is approving, remember?
When you are tagging mapper within the message in Tasking Manager (in JOSM, you can see the list of authors with their % of contribution), do it only once. Probably, you will validate multiple squares of that mapper. He or she does not have to read 20 messages from you saying: “Please, orthogonalize buildings.”
The last thing is that this is not the validation guide. Every validator is an individual. Each square needs a different approach. Find out what works for you. But remember:
There is always more mappers than validators. Therefore, validation must be much faster than mapping.
During validation, you are not fixing. You are approving.
Discussion
Comment from russdeffner on 16 August 2019 at 20:32
I respectfully disagree. I believe validating is about making both the mapper, and the map, better.
Comment from Kathyaus on 16 August 2019 at 23:50
For me, I will also consider what sort of task it is. If it’s disaster management response, I am much more likely to fix things where it’s less than a quarter of what has been done in the tile so that I can validate it and get the project finished. If it’s not a DM related project, I am more inclined to invalidate something that has things needing to be fixed or missing.
Definitely agree with @russdeffner that it’s about educating, improving and community contribution. As a validator I want to help mappers understand how to improve their contribution, but still complete DM tasks in an efficient manner.
Comment from qeef on 17 August 2019 at 13:45
@russdeffner I believe that for making mapper better, the feedback is important. For making the map better, the quality assurance is needed. May I ask with what you disagree? Because I don’t see the conflict between my understanding and your comment.
@Kathyaus I got the point regarding disaster mapping and I do agree. I didn’t consider that as I am usually mapping Missing Maps projects.
I am thinking about invalidate fast approach during the mapathons where the small group of validators tries to validate as many beginner mappers as possible. I have to agree that when the task is old or disaster response, including mapping to validation is beneficial.
Comment from russdeffner on 25 August 2019 at 18:11
Quality Assurance and Control will be a topic discussed thoroughly at the HOT Summit, maybe we can have a Birds of a Feather on this specifically, or just over drinks? What I disagree with is the mindset/methodology of approve/disapprove in general. I understand that at some level that is what we are doing during validation; but I’ve always taken, and taught, the methodology of improve/improve – meaning that whether or not you eventually decide to validate or invalidate a task, you should have taken the time to explain, in enough detail for a new mapper to grasp, what needs/you fixed in the task. And often, it seems easier and more effective to take time to fix things, so the mapper can learn from you, rather than rapidly concluding ‘this needs more work’. Unfortunate truth is it just rubs a lot of people the wrong way to get the ‘your task has been invalidated’ message. However, if/when we do change “invalidated” to something like ‘needs more work’ on the Tasking Manager, then I would be a little more ok with the rapid approve/disapprove approach. Although personally will always give more of my time to helping a mapper than focusing on data quality.
Comment from qeef on 28 August 2019 at 14:22
@russdeffner I like your mindset. It’s the mindset of a mentor, I think. Which is great. But I can’t agree that validators should be mentors. There are two reasons:
Mappers can be mentors, too. No need to be validator to help novice mappers.
Validation must be binary (valid/invalid) to achieve quality, IMHO.
I must agree that every validator should provide at least why invalidating message. That’s for feedback. Any other help is mentoring, which is greatly appreciated. But I wouldn’t blame validators for not being mentors. I think that it can be beneficial to distinguish between validators and mentors.
I think that needs more work is a definitely better message. I don’t understand, why these basic things were not considered in GUI design of TM.