Get a basic understanding of the terms and definitions we use for the analysis. This section covers HOT's Tasking Manager and OpenStreetMap sides and provides related literature for further research.
Please note that our insights about humanitarian mapping in OSM only provide an incomplete picture which lacks an on-the-ground perspective and neglects other remote mapping tools, since we considered only the mapping that was organized through the HOT Tasking Manager. For instance, humanitarian mapping that has been organized by local residents on the ground is not considered here.
We are aware of the fact that our definition of humanitarian mapping is therefore oversimplified and the results must be taken with a grain of salt. In many regions of the world there is no clear distinctive line between humanitarian and non-humanitarian mapping activities as the humanitarian and non-humanitarian OSM communities are not disjoint.
HOT'S Tasking Manager (HOT-TM)
We refer to projects as defined by HOT's 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 HOT's 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 HOT-TM users can also leave comments and discuss mapping problems.
It's common that several HOT-TM users will work on a task (e.g. HOT-TM users A maps it and HOT-TM users B validates it), but two HOT-TM users will never work on the same tasks at the same time in HOT's Tasking Manager. Hence, after a HOT-TM user selected a task it is locked (for maximum 2 hours). This minimizes the risk of two HOT-TM 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 HOT's Tasking Manager (by signing up with their OSM account) are referred to as HOT-TM users. A HOT-TM 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 HOT-TM users in HOT's Tasking Manager can be linked to the contributions of this user in OSM using the OSM user id.
In HOT's Tasking Manager HOT-TM users can have specific roles (e.g. advanced mapper) which will allow them to perform advanced actions such as validating a task. Ideally, HOT-TM users will contribute to several projects by several organisations in HOT's Tasking Manager.
We measure the activity in HOT's Tasking Manager based on the concept of sessions. A session is defined by a HOT-TM 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 HOT-TM users selects the task to map in HOT's Tasking Manager) and end time (e.g. the time the HOT-TM user finished mapping and sets the status to mapped in HOT's Tasking Manager). Usually, the HOT-TM user will contribute data to OSM using an editor such as JOSM or iD between start time and end time.
2021 HOT Tasking Manager Sustainability Model
The HOT Tasking Manager Sustainability Model is based on the concept of ‘sessions’. Be aware that HOT only considers sessions for which the action is either mapped or validated in their model. Other sessions (e.g. where the HOT-TM users just locked a task without finishing it) are not included in your Tasking Manager usage numbers.
HOT-TM 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.
Comment: Please note that the term "mapped" can be questioned here. This term has been introduced in HOT's Tasking Manager several years ago although this only constitutes the first of two steps in the overall HOT-TM mapping workflow. Some people might argue that you should consider an area as "mapped" only once it has been mapped AND validated in HOT's Tasking Manager. Others might even argue that you should only call an area as mapped, once further features beyond roads and buildings have been added to OSM.
Experienced HOT-TM users can mark tasks as validated after a task has been mapped. During this step the HOT-TM 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 HOT's 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 HOT-TM 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 HOT's 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 HOT-TM user 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)
HOT-TM 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)
HOT-TM 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.
People living in an area mapped via HOT's Tasking Manager
This refers to the number of people living in an area where buildings and roads have been mapped and validated on HOT's Tasking Manager. A detailed description of the workflow is shown in the figure below. Population information is based on Global Human Settlement Layer (GHS-POP).
HOT Priority Countries
HOT's vision is to mobilise or support one million volunteers to map an area home to one billion people living in poverty and at high risk of disaster in 94 countries. These 94 countries have been grouped into 4 regions. For each region a regional "hub" will facilitate exchange of ideas and expertise across countries and provide financial and technical support to OSM communities
We use the term "all priority countries" when referring to statistics for all 94 countries. You can also check this OSM Wiki page for more details.
Americas (22 countries): Antigua and Barb., Belize, Bolivia, Brazil, Chile, Costa Rica, Dominica, Dominican Rep., Ecuador, El Salvador, Guatemala, Guyana, Haiti, Honduras, Jamaica, Mexico, Nicaragua, Panama, Peru, Trinidad and Tobago, Uruguay, Venezuela
Asia and Pacific (26 countries): Afghanistan, Bangladesh, Bhutan, Brunei, Cambodia, Fiji, India, Indonesia, Kiribati, Laos, Malaysia, Mauritius, Micronesia, Myanmar, Nepal, Pakistan, Papua New Guinea, Philippines, Solomon Is., Sri Lanka, Timor-Leste, Tonga, Uzbekistan, Vanuatu, Vietnam, Yemen
West and Northern Africa (24 countries): Algeria, Benin, Burkina Faso, Cabo Verde, Cameroon, Central African Rep., Chad, Côte d'Ivoire, Djibouti, Eq. Guinea, Gambia, Ghana, Guinea, Guinea-Bissau, Liberia, Mali, Mauritania, Morocco, Niger, Nigeria, São Tomé and Principe, Senegal, Sierra Leone, Togo
East and Southern Africa (22 countries): Angola, Burundi, Comoros, Congo, Dem. Rep. Congo, Egypt, eSwatini, Ethiopia, Kenya, Lesotho, Madagascar, Malawi, Mozambique, Namibia, Rwanda, Somalia, S. Sudan, Sudan, Tanzania, Uganda, Zambia, Zimbabwe
A mapper is a person who has made an edit to OpenStreetMap. A map edit is considered an edit to OSM within a priority country no matter which tool or platform the edit was made.
When using the term all OSM we always refer to the entire OSM community or data available in OSM for a particular country or region.
To help identify HOT’s more direct contribution to overall OSM map edits, we use the terms HOT TM or via HOT's Tasking Manager when referring to mappers who have made an edit to OSM through HOT's Tasking Manager. Accordingly, we use this term for all buildings and highways added to OSM via HOT's Tasking Manager.
An active mapper is defined as a remote or local mapper who has edited OSM at least once within three months. The number of times they have edited or what they have edited is not relevant but rather that they have done it within a time period. If they do not map within a three-month time period of their last edit they can no longer be considered active contributors.
This definition echoes the OSMF definition here.
The definition of the mapper's experience is inspired by research work done by Pascal Neis and Alexander Zipf. In this work they categorize OSM mapper into four groups using the number of edits they have made. We've adjusted their method and use the following groups and thresholds:
- Newcomers: first edit made in the past month
- Beginners: between 0-1,000 edits made prior to the last full calendar month
- Experts: between 1,001-10,000 edits made prior to the latest full calendar month
- Powermappers: more than 10,000 made prior to the latest full calendar month
Our proxy for local knowledge is defined by adding additional information to OSM beyond buildings and roads. These attributes go beyond roads and buildings to include village, city and neighborhood names, through to facilities and other micro level data on services provided. We assume that this additional information cannot be added to the map without local knowledge of that area.
Comment: The approach here has limitations. Iit only covers a small section of what can be considered local knowledge mapped in OSM. Thus, the categories used here might be too broad considering the heterogeneity of OSM mapping in various locations.
This covers overall mapping in OSM and is not necessarily linked to HOT Tasking Manager mapping. Using the filters below you can also derive some interactive charts using the ohsome dashboard.
We use the following filter to query the ohsome API to retrieve information on the number of healthcare related features in OSM:
(healthcare in (doctors,clinic,midwife,nurse,center,health_post,hospital) or amenity in (doctors,clinic,hospital,health_post)) and (type:way or type:node)
We use the following filter to query the ohsome API to retrieve information on the number of amenities in OSM:
amenity=* and (type:way or type:node)
We use the following filter to query the ohsome API to retrieve information on the number of villages, cities or neighborhood names in OSM:
place in (isolated_dwelling, hamlet, village, neighbourhood, suburb, town, city) and (type:way or type:node)