Utilities to create ODK assets for field mapping

Campaign managers select an Area of Interest (AOI) and organize field mappers to go out and collect data. They need to:

• Select an AOI polygon by creating a GeoJSON or by tracing a polygon in a Web map
• Choose a task division scheme (number of features or area per task, and possibly variations on what features to use as the preffered splitting lines)
• Provide specific instructions and guidance for field mappers on the project.
• Provide a URL to a mobile-friendly Web page where field mappers can, from their mobile phone, select an task that is not already "checked out" (or possibly simply allocate areas to the field mappers).
• See the status of tasks (open, "checked out", completed but not validated, requires rework, validated, etc) in the Web browser on their computer

Field mappers select (or are allocated) individual tasks within a project AOI and use ODK Collect to gather data in those areas. They need to:

• Visit a mobile-friendly Web page where they can see available tasks on a map
• Choose an area and launch ODK Collect with the form corresponding to their allocated area pre-loaded

Validators review the data collected by field mappers and assess its quality. If the data is good, the validators merge the portion of the data that belongs in OpenStreetMap to OSM. If it requires more work, the validators either fix it themselves (for minor stuff like spelling or capitalization mistakes that don't seem to be systematic) or inform the field mappers that they need to fix it. They need to:

• Access completed data sets of "submissions" as Comma Separated Values and/or OSM XML so that they can review it.
• Mark areas as validated or requiring rework
• Communicate with field mappers if rework is necessary
• Merge good-quality data into OSM (probably from JOSM).
• Mark areas as completed and merged.

The basic setup here is:

A mobile data collection tool that functions on almost all Android phones. Field mappers use ODK Collect to select features such as buildings or amenities, and fill out forms with survey questions to collect attributes or data about those features (normally at least some of these attributes are intended to become OSM tags associated with those features).

The ODK Collect app connects to a back-end server (in this case ODK Central), which provides the features to be mapped and the survey form definitions.

An ODK Central server which functions as the back end for the field data collectors' ODK Collect apps on their Android phones. Devs must have access to an ODK Central server with a username and password granting admin credentials.

Here are the instructions for setting up an ODK Central server on Digital Ocean (it's very similar on AWS or whatever)

The FMTM web app is a Python/Flask/Leaflet app that serves as a front end for the ODK Central server, using the ODK Central API to allocate specific areas/features to individual mappers, and receive their data submissions.

A computer-screen-optimized web app that allows Campaign Managers to:

• Select AOIs
• Choose task-splitting schemes
• Provide instructions and guidance specific to the project
• View areas that are at various stages of completion
• Provide a project-specific URL that field mappers can access from their mobile phones to select and map tasks.

A back end that converts the project parameters entered by the Campaign Manager in the Manager Web Interface into a corresponding ODK Central project. Its functions include:

• Convert the AOI into a bounding box and corresponding Overpass API query
• Download (using the Overpass API) the OSM features that will be mapped in that bounding box (buildings and/or amenities) as well as the OSM line features that will be used as cutlines to subdivide the area
• Trim the features within the bounding box but outside the AOI polygon
• Convert the polygon features into centroid points (needed because ODK select from map doesn't yet deal with polygons; this is likely to change in the future but for now we'll work with points only)
• Use line features as cutlines to create individual tasks (squares don't make sense for field mapping, neighborhoods delineated by large roads, watercourses, and railways do)
• Split the AOI into those tasks based on parameters set in the Manager Web Interface (number of features or area per task, splitting strategy, etc).
• Use the ODK Central API to create, on the associated ODK Central server:
  • A project for the whole AOI
  • One survey form for each split task (neighborhood)
    • This might require modifying the xlsforms (to update the version ID of the forms and change the name of the geography file being referred to). This is pretty straightforward using OpenPyXL, though we have to be careful to keep the location within the spreadsheet of these two items consistent.
  • GeoJSON feature collections for each form (the buildings/amenities or whatever)
  • An App User for each form, which in turn corresponds to a single task. When the ODK Collect app on a user's phone is configured to function as that App User, they have access to only the form and features/area of that task.
  • A set of QR Codes and/or configuration files/strings for ODK Collect, one for each App User

• Ideally with a link that opens ODK Collect directly from the browser, but if that's hard, the fallback is downloading a QR code and importing it into ODK Collect.