[HOT] Improving data quality of Maperthons

Pete Masters pedrito1414 at googlemail.com
Thu Oct 20 02:14:18 UTC 2016


I think this makes a lot of sense. We don't necessarily stop after a
certain time period, but validators do point out common mistakes and issues
and someone does a quick 'intervention' at the front reminding people to
square corners or join roads...

Also, maybe we need to include clear instructions in the task in the
project to start in the north. That way, remote validators and mappers also
know what's going on.

Really appreciate this discussion!

Pete

On 19 Oct 2016 7:09 p.m., "Eduardo Gonzalez" <eglatorre at gmail.com> wrote:

> hi!
> we have been running some mapathons (you call them maperthons, seems like
> :) ) in Finland for a year now and we have been strugling on how to get
> better results, specially from novices.
>
> I think Johns idea hasn't been quite understood... what he says (and what
> I understand) is a group advice giving soon enough in the mapping event.
> Not at all incompatible with the approach mentioned in the London
> maperthon, which we have been applying too (last time we had 50 mappers vs
> at least 4 experienced people roaming around... not enough I can tell you!).
>
> In my opinion Johns idea is a great addition to the, IMHO, obligatory
> introduction on how to map and the few experienced people helping and
> checking on the work.
>
> The main point Johns makes is that having the mappers map a certain region
> (say the Northen region of a project) makes it easier to make a quick
> general review of the work (instead of square by square!)... so you can
> catch on the general issues that are happening in the mapathon. Lets forget
> about getting the names of the people in a paper ;) (could we not get that
> using overpass-turbo?)
>
> How I would interpret Johns idea in combination with London approach,
> correct me if I am wrong guys: 1) you do the introductions to the project,
> area and basic editing (combined with project specific editing) 2) GO
> mapping and the experienced ones roam around helping and checking for
> obvious errors (London) then 3) after a half an hour, STOP mapping, lets
> have a quick look at the work being done... then someone with experience
> has checked the area being mapped (say the Northen region) and presents the
> common problems to everyone so people can start making corrections to those
> problems and avoids making them again.
>
> This is all about feedback! London approach = instant and personal
> feedback; Jonh's idea = virtual instant and group feedback. Jonh's idea
> about taking the names on paper = quick/medium term (like within days) and
> personal feedback. In my opinion, and seems the general opinion too, many
> new mappers in mapathons will only be reachable during the mapathon, so any
> feedback after that is not so efficient, but if even within days or a
> couple of weeks could be enough to get them back. The more feedback, the
> more meaning added to the work done, the more chances to get mappers on
> board :)
>
> Hope this helps :)
>
> Cheers,
>
> Eduardo
>
>
>
> On Mon, Oct 3, 2016 at 6:42 PM, john whelan <jwhelan0112 at gmail.com> wrote:
>
>> Unfortunately most projects and mapathons are not as well organised as
>> the London ones and I don't think they ever will be.  Often a mapathon is
>> organised by someone with no or little experience in mapping heading up an
>> enthusiastic group of none mappers.  The lone mappers are easier to deal
>> with, there is time to give them feedback as they map, but twenty new
>> mappers and you know many will be doing something else next Friday night
>> are more difficult to deal with.
>>
>> If you take a quick skim through the HOT projects most tiles have not
>> been validated and even where they are the validation is inconsistent.
>>
>> When I'm validating a project I'll validate the tiles marked done but its
>> rare that a project gets completed and there is a fair bit of mapping done
>> across the project on tiles that aren't marked done.
>>
>> All I'm suggesting is if the mapathons can group their mapping together
>> then we stand more chance of catching more of the mistakes.
>>
>> If all mapathons could be as well organised as the London ones with their
>> own validators that would be ideal but then I'd have to find something else
>> to moan about and recently the local bus service has been particularly on
>> time.
>>
>> Cheerio John
>>
>> On 3 October 2016 at 10:44, Ralph Aytoun <ralph.aytoun at ntlworld.com>
>> wrote:
>>
>>> I believe we can limit the amount of beginner problems by doing a bit
>>> more preparation work in advance.
>>>
>>> We are trying to alleviate the plight of the beginner by making each
>>> task less and less.... i.e. buildings only or highways and residential
>>> areas. I do not believe that we do ourselves any favours by limiting the
>>> work like this. This in itself indicates that we all accept that beginners
>>> do have a limited ability to map correctly. But we let them loose to map
>>> buildings only and then complain when they do not quite comprehend what it
>>> is to map roads.
>>>
>>> My proposal is to the creator of each task. It is not possible to
>>> classify roads above tertiary level when you are faced with a whole series
>>> of tiles in a small corner of a country where there may not even be a city
>>> or major town in existence. Anything higher than tertiary needs to be done
>>> at province or country level mapping and needs to be done before the
>>> beginners are let loose on the map. I would suggest therefore that the
>>> major connecting highways down to tertiary level should be mapped before
>>> setting up the project. Then mappers have that framework to work inside and
>>> any highways they map will be unclassified/ track/ residential/ path. A lot
>>> easier for them to relate to and understand and a lot easier to explain to
>>> them as well.
>>>
>>> At the London Mapathon we have introduced a new step for the validator
>>> group that helps with the overall validating and the standard of mapping.
>>> Instead of the validators starting to validate at the beginning of a
>>> Mapathon before the new mappers have got to the stage of completing tiles,
>>> the validators move round the room and look at the work being done by the
>>> mappers and helping them with any problems they see being done by the
>>> individuals before they have mapped too much. It means having people at the
>>> event who will go round looking over the shoulders of mappers to see what
>>> they have on their screens and whether it is being done correctly or not.
>>> This method alleviates some of the problems at a live event.
>>>
>>> It does not solve the problem of new mappers starting on their own or
>>> Remote Mapathons where you cannot see what is being mapped until it reaches
>>> validation stage. It also does not solve the problem of mappers who have
>>> completed 20 or 30 tiles and starting to validate other people’s work when
>>> they are still making inexperienced errors themselves.
>>>
>>> The very nature of Openstreetmap means that there is no way that this
>>> can be prevented or stopped, but as validators our task is made easier by
>>> experience and the tools available to identify the errors. I have attached
>>> three screen shots – the task showing 70% validated (2164 – Masisi TM) –
>>> The same area on OSM (2164 – Masisi OSM) - and a slippy map download of the
>>> whole area showing what it looks like in JOSM (2164 – Masisi JOSM). The
>>> task was for major road network. My point being that without the overall
>>> picture it is difficult for anyone to understand what the person two tiles
>>> away is doing.
>>>
>>
>>
>> _______________________________________________
>> HOT mailing list
>> HOT at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/hot
>>
>>
>
> _______________________________________________
> HOT mailing list
> HOT at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/hot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/hot/attachments/20161020/6bfced11/attachment.html>


More information about the HOT mailing list