2.2 Organized OSM Editing

This section provides:

  • Considerations for managing and sourcing mappers for an organized editing project
  • Overview of the OSM Organized Editing Guidelines and compliance
  • Step-by-step guide for complying with the OSM Organized Editing Guidelines

Overview

Before starting any mapping project, it is important to assess, and if necessary, update the OpenStreetMap basemap through remote mapping. This remote mapping process helps ensure that the buildings and roads used during a field mapping phase are up to date, improving the quality and effectiveness of field mapping efforts. For example, using remote mapping, your team can identify buildings or entire villages that might have been missed otherwise.

While the anticipated project workflow influences the area to be remotely mapped, it is important to note that the budget and time available may place restrictions on what is feasible to be digitized. In this way, remote mapping can also influence the workflow, making the remote mapping plan an important part of the planning process.

No matter the scope of your project you will need to determine:

Sourcing your remote mappers

Remote mapping takes time and effort. This process can take several different forms ranging from being quickly completed with a few volunteer mappers for a small area to an organized, paid team working for several months to complete a region. The resources and time needed to map your area of interest depends on:

  • Size of your area of interest: Are you mapping one city or an entire district?
  • Timeline: Does the area need to be mapped in a few weeks? Months?
  • Resources needed: Does your project have budget to pay digitizers and validators?
  • Quality: What are your resources for ensuring that the mapped data is high quality? Does the data need to be immediately high quality, or is there room for new mappers to make mistakes?
  • Features and attributes: Does your project require only buildings to be mapped? Roads? Will any features (such as roof:material) be added by remote mappers?

Sourcing Options

The following a few recommendations on how to organize and source your mappers based on our best experiences.

  • Global HOT/OSM Community: The global community is a wonderful and FREE source of remote mappers. As of September 2019, 180,000 volunteers from around the world have mapped over 2 million tasks on HOT’s Tasking Manager to support mapping efforts around the world. Here are some considerations to make when utilizing the Global HOT/OSM Community for remote mapping efforts:

    • Size of AOI: With a large pool of individuals to choose from, the global community can cover any size of digitization efforts, from a neighborhood to entire countries.
    • Timeline: While the global community is known for it’s rapid response in the wake of disasters and immediate humanitarian needs, other types of projects should not rely on the community to map areas within a controlled timeframe. Relying on the global community to map a district in Liberia, could take a week or several months depending on interest in the project and other urgent mapping needs.
    • Quality: The disadvantage of using the global community for remote mapping efforts is that it can be more difficult to control the quality of data being immediately mapped. While all remote mapping should be validated, the wide range of skills and experience (as well as understanding of the project needs) could mean that additional efforts will be required to review and fix any mistakes made by remote mappers.
    • Resources needed: As already stated, using the global community for mapping has the great advantage of being completely free!
    • Features and attributes: Tasks best suited for the larger community are those that are simplest. Additional instructions beyond tracing buildings is feasible, but extra checks will be necessary for coverage as some mappers may miss detailed instructions.
  • Dedicated team of digitizers (5+ people): Some projects may find that the best way to meet the needs of their project is to hire a small team of dedicated digitizers to systematically map an area. Typically this dedicated team works together in-person, which allows for consistent training and quality assurance. However, it is possible to use a paid team of mappers working remotely if mappers are experienced and do not require extensive training. We do recommend that when looking to hire a team of mappers that you reach out to the local OSM community with these opportunities. Here are some considerations to make when utilizing a dedicated team of digitizers for remote mapping efforts:

    • Size of AOI: Like the global community, digitization teams can cover any amount of area with enough time. As team members are dedicated to the mapping task, digitization teams can handle larger areas over a shorter period than the global community.
    • Timeline: For meeting tight deadlines, a dedicated team of digitizers can be the best option as it ensures that the mapping task can be effectively planned and executed. Meeting that timeline does depend on the number of digitizers hired and their experience. HOT has found that newly trained teams of digitizers can map 500-1000 buildings a day depending on the imagery quality and density of mapping.
    • Quality: Having a dedicated and paid team means that it’s easier to train and manage the data quality of the mapping efforts.
    • Resources needed: Budget for paying digitizers is required. Also recommended is providing a dedicated workspace and consistent internet connection, as well as laptops where needed if working with mappers on location.
    • Features and attributes: By working directly with individuals, you can ensure that all special features and attributes your remote mapping campaign requires are consistently added. Having local context (such as recognizing roof material) is also extremely helpful for adding unique features and attributes.
  • Mixed approach: paid digitizers and global community: When there are timelines in place but the scope of the work is too large for your team, one option is to have a mix of paid digitizers and the global community. Here are some considerations to make when taking a mixed approach for sourcing remote mapping efforts:

    • Size of AOI: If you have a small team, combining efforts with the global community can help you achieve a much larger area.
    • Timeline: By including some paid digitizers, this method can help keep the project in development while relying on the global community.
    • Quality: Additionally, by including paid digitizers, your team can choose to focus on validating the efforts of the global community and increase the consistency of quality mapping edits.
    • Resources needed: Smaller budget than a full team, but will still likely need to provide a dedicated workspace and consistent internet connection.
    • Features and attributes: If there are unique features and attributes that rely on local context, you can rely on the global community to develop the basemap and then your paid team can add those features later. Or, you can use your small team to validate the special features and attributes added by the global community.
  • Hosting Mapathons: Another option that blends utilizing volunteers with some of the benefits of a dedicated team is hosting a series of Mapathons. These mapathons typically bring together groups of volunteers (ranging from university students to corporate volunteer events) to map a task together in person. Here are some considerations to make when hosting mapathons for remote mapping efforts:

    • Size of AOI: The amount of area that can be covered depends on the number of people attending the mapathons, the number of mapathons hosted, and the skill level of volunteers. In general, this option is only recommended for smaller areas.
    • Timeline: This option can be faster than relying solely on the global community, but slower than having a dedicated team of volunteers. Again, the speed of mapping depends on the skill level of the mappers, frequency and number of events, if the same mappers attend each event, and how much training will be required.
    • Quality: Since mapathons generally bring new or inexperienced mappers together, mapathons have the possibility of requiring more effort on the validation side of mapping. However, if the same attendees regularly participate, this data quality will increase.
    • Resources needed: Smaller budget than a dedicated in-person team, but event space, internet, and refreshments will need to be covered.
    • Features and attributes: If your mapping project requires unique features and attributes, mapathons allow for better training and management of volunteers adding that information. However, similar to data quality, this will still require a heavier lift in validation than using a dedicated team.

Whenever possible, we recommend sourcing local mappers to be part of the digitization efforts. And remember, it is critical that no matter what plan you choose, that it includes a validation and quality control plan!

Managing your digitization efforts

Once you decide how you will source your team of mappers (paid or unpaid, local or remote), you will need to set up a plan and gather resources. Here’s a checklist of some questions to consider:

  • What will be your team structure? We recommend having one dedicated validator for every five digitizers.
  • Have you trained validators? Our training materials for validators are available here.
  • How will you track the progress of your mapping? When setting up a large number of mapping tasks, it helps to set up a tracker to monitor the progress of all tasks.

Organised Editing Compliance Procedures

The OSM Foundation has set up Organised Editing Guidelines for documenting organized editing efforts. While it is not a requirement or policy, HOT highly encourages all groups to comply with these procedures when applicable. For simplicity and ease of understanding these guidelines, HOT has developed the following guide, however, HOT does not take responsibility for compliance.

The following is based on HOT’s suggested procedures for complying with the Organised Editing Guidelines (OEG) - as of June 2019

Purpose

What problem(s) does the OEG aim to address, and how can we best comply with, and address, these concerns?

  • Transparency - the OEG attempts to make it easier for local mappers to know what organizations are editing in their area.
  • Communication - the OEG attempts to make it easier for local mappers to communicate with organized editors and editing teams.
  • Conflict Resolution - the OEG attempts to provide a basis for coordinating, as well as a mechanism for local communities to form a complaint against an organized editing activity.

Documentation

Requirements

What exactly is required by the Organized Editing Guidelines (OEG)?

  1. Project Documentation on the OSM Wiki:
    • Organisation and contact info
      • description and link to organization
      • a way to contact the project manager or team
    • Project details
      • the goal and purpose of the activity
      • the timeframe for the activity
      • any non-standard tools and data sources used, and their usage conditions
      • links where the community can access any non-standard tools or data sources
    • Standard changeset comment
      • specific hashtag for tracking
      • link to related organized editing activity
    • Team information
      • the accounts of participating persons that wish to be identified, with any details they wish to include
      • if participants will receive training material or written instructions, a copy of, or link to, these materials
        1. links to organized editing organization(s) and activity(ies) on user profile
        2. sufficient training for project (i.e. local tagging schemas, etc.)
      • if the success or performance of participants will be measured in any way, a description of the metrics used for this
  2. Project Execution and Follow-up
    • Communication with the local community
      • 2 week notice for non-emergency projects, open forum/mailing list
      • 2 working day response for community inquiries throughout project
    • Plans for a “post-event clean up” to validate edits, especially if the activity introduces new contributors to OpenStreetMap.
    • After the activity has completed, or at least once a month for ongoing efforts, a description of the results.

Does this apply to me?

Common Elements:

Common elements of projects can be jointly-documented among projects.

For HOT, most projects fall under OEG compliance, and will share the following:

  • The organization and contact information
  • Instructions to a certain degree, i.e. basic mapping covered with LearnOSM materials
  • A somewhat standard validation process; of course be explicit about any ground truthing
  • Somewhat standardized tool set(s) (i.e. TM for Remote, ODK/OMK for ground)
  • Reports/descriptions/news at a central location (i.e. HOT website)

Step-by-Step Process:

  1. Project Pre-launch
    • Have at least a skeleton wiki/web-page ready to share with local community
    • Local contact made a minimum of 2 weeks prior of launch; through their open mailing-list, or forum, most likely to contact the key leaders in the community
    • Set-up OSM User Profiles:
      • Consider registering team on OSM with designated usernames
        1. Can still be personalized, such as JaneDoe_Validator, JohnDoe_Mapper, etc.
      • Consider also using organization email account(s) 2. Ideally, the Project Manager or Team Lead should get, or be able to access all messaging. If a mapper leaves, but then gets messages from the community, you will want to be able to reply
      1. All profiles should at least have a link to the OEG project page, organizations website, or (for HOT) preferably a link to the individual’s profile on the website
  2. Project Launch
    • Ensure the project has an entry in OEG activities page
    • Have the required details of your plan in a wiki-page or (for HOT) a hotosm.org website project-page
    • Appoint one or two people that will handle rapid replying to all community traffic (2 business day max)
    • Periodic Reports are typically handled through blog (for HOT), but can also consider posting results on wiki’s, etc.
  3. Project Completion
    • Make sure there is a plan to finish any remaining validation and that is communicated to the local community.
    • With constant communication with the local community throughout the project, it should be fairly easy and straightforward to determine when the project will be done and the Community is back on their own, with conduits to project org(s).
    • Before closing your project out, make sure there is a final blog-post or report documenting the closure.
      • Doc/report does not need to be full report requested by a donor, as example, but generally the results: successful or not, lessons learned
      • Last, move your row in the OEG Activities table from Active to Previous

Additional Resources