Get a basic understanding of the terms and definitions we use for the analysis. This section covers Tasking Manager and OpenStreetMap sides and provides related literature for further research.
We refer to projects as defined by the Tasking Manager. A project is usually set up by an organisation (e.g. American Red Cross) and defined by a number of tasks, which will be generated from a polygon geometry depicting the area of interest. Per project, project managers add information on what should be mapped, which imagery should be used and also provide context for what purpose data is collected. Some projects are restricted to specific mappers, although most are open to be mapped by everyone.
Tasks are a central concept of the Tasking Manager. For each project the overall area is split into many smaller areas (usually squares) which are defined as tasks. Some projects also use arbitrary task geometries (e.g. if they are created from MapSwipe data). Tasks have a status, which shows if a task has already been mapped or validated or if it still needs mapping. If tasks are too big (e.g. because there are many objects to map within) they can be divided into smaller ones. For each task users can also leave comments and discuss mapping problems.
It's common that several users will work on a task (e.g. user A maps it and user B validates it), but two users will never work on the same tasks at the same time in the Tasking Manager. Hence, after a user selected a task it is locked (for maximum 2 hours). This minimizes the risk of two users editing the same area in OSM and thus this mechanism aims to reduce OSM data conflicts. Nevertheless, due to the usually squared shape of a task, some conflicts might happen at the border to other tasks, which need to be cleaned by the validators.
The volunteers using the Tasking Manager (by signing up with their OSM account) are referred to as users. A user will select a project to work on and then chooses a task to contribute data to OSM. Since the OSM account is used for login the actions performed by a users in the Tasking Manager can be linked to the contributions of this user in OSM using the OSM user id.
In the Tasking Manager users can have specific roles (e.g. advanced mapper) which will allow them to perform advanced actions such as validating a task. Ideally, users will contribute to several projects by several organisations in the Tasking Manager.
We measure the activity in the Tasking Manager based on the concept of sessions. A session is defined by a user performing an action on a task. The action performed can be one out of the following: unfinished, mapped, validated, invalidated, split or bad imagery.
For each session there is a start time (e.g. the time the users selects the task to map in the Tasking Manager) and end time (e.g. the time the user finished mapping and sets the status to mapped in the Tasking Manager). Usually, the user will contribute data to OSM using an editor such as JOSM or iD between start time and end time.
Users can mark a task as mapped at the end of a session. This action should be performed once every object that is requested by this project has been added into OSM. There is no direct mechanism to make sure that this is actually the case. That's why tasks should be validated after they have been mapped.
Experience users can mark tasks as validated after a task has been mapped. During this step the users either directly fix mistakes (e.g. add missing buildings or correct tagging for highways in OSM) or request that this task should be mapped again by invalidating a task. Once, a task has been validated, all data requested by this project should have been completely added to OSM in a correct way.
Organisations set up projects in the Tasking Manager. The organisations are rather diverse and can be local OSM communities (e.g. OSM RDC), international humanitarian organisations (e.g. German Red Cross) or wider communities such as Missing Maps or YouthMappers. Usually, the project managers of an organisation take care of a project and help users in case of questions or problems. Some organisations further organise mapathon events to foster mapping for their project.
Filtering for Organisations
We use different approaches to filter for the various organisations. The easiest case is to select all projects in the Tasking Manager created by the defined organisation. However this does not work for all projects. Hence we apply a key word filtering for some (e.g. Missing Maps). In these cases we filter for defined key words in the project title and further information such as the mapping instructions.
A key component of our analysis lies in the evaluation of the data contributed to OSM. A contributions is defined as any change in an OSM element and can be assessed based on OSM full-history data. We use OSHDB a high-performance spatio-temporal data analysis platform for OpenStreetMap full-history data developed by HeiGIT for this analysis.
Our analysis currently covers contributions related to the following tag-value combinations and respective feature types in OSM: building=* (ways), highway=* (ways), landuse=residential (ways). For all objects we derive the number of contributions (count) and the payload (area in square meter for building and landuse keys, length in meter for highway tag). We further distinguish different types of contributions as listed below.
Whenever a users creates a new object in OSM (e.g. draws a polygon, sets the key-value pair to building=yes and uploads to OSM) this will be referred to as an object added to OSM.
Modified Tag (TAG_CHANGE)
Users can modify existing objects in OSM. If the tag of an object is adjusted (e.g. change value of highway=unclassified into highway=residential) or new tags are added or existing ones are removed this is referred to as a modification of the tags.
Modified Geometry (GEOMETRY_CHANGE)
Users can also modify the geometry of existing objects in OSM. The geometry can be changed by moving nodes (for all feature types node, way and relation) or by adding or removing nodes (for feature types way and relation). A change in the geometry will most likely cause a change (increase or decrease) in derived statistics such as length or area.
Whenever an object is removed from the OSM database this is referred to as a deleted object.