Modify the XLSForm used for the Ruwa-Niger project used to collect data on markets. These changes involve 2 things. The primary one is improving the efficiency of collecting map data. The secondary is to modify the XLSForm name column in the survey and choices sheets to be a closer match to approved OSM tags/values to make it easier to convert them from ODK to OSM.

odk_client.py does a lot of admin tasks for the ODK Central server. It's current command line arguments aren't very intuitive, they mostly exist for testing the code during development. The command line arguments should probably be grouped differently, better choices, etc... As odk_client is the only remote admin program for Central that exists, if should be improved so others can work on it.

Modify the XLSForm used for the Ruwa-Niger project used to collect data on public toilets. These
changes involve 2 things. The primary one is improving the efficiency of collecting map data. The secondary is to modify the XLSForm name column in the survey and choices sheets to be a closer match to approved OSM tags/values to make it easier to convert them from ODK to OSM.

Modify the XLSForm used for the Ruwa-Niger project used to collect data on waste disposal. These changes involve 2 things. The primary one is improving the efficiency of collecting map data. The secondary is to modify the XLSForm name column in the survey and choices sheets to be a closer match to approved OSM tags/values to make it easier to convert them from ODK to OSM.

There is currently no XLSForm for the Urban Landscape Cultural Sites in the data models, so one will have to be created.

Modify the XLSForm used for the Ruwa-Niger project used to collect data on religious facilities These changes involve 2 things. The primary one is improving the efficiency of collecting map data. The secondary is to modify the XLSForm name column in the survey and choices sheets to be a closer match to approved OSM tags/values to make it easier to convert them from ODK to OSM.

A UI would be nice for ODK -> OSM file format conversion.

• Kivy is a small, simple web framework for Python.
• We could use a Kivy UI to create a mobile interface for functions in osm-fieldwork.
• We could link the important functions to buttons with a few select / input fields.
• This would make data collection in the field easier.
• The app would compile to Android (and possibly iOS too).

Additional info:

• Many users only have a phone or tablet, no laptop.
• Phones often have a longer battery life too, which is useful for the field.
• XML data could be converted directly from the phone storage, so no internet would be needed (limited connectivity in the field).
• Optional extra: also upload data to OSM.

Currently there is no XLSForm for emergency features, so one will have to be created.

Modify the XLSForm used for the Ruwa-Niger project used to collect data on cemeteries. These changes involve 2 things. The primary one is improving the efficiency of collecting map data. The secondary is to modify the XLSForm name column in the survey and choices sheets to be a closer match to approved OSM tags/values to make it easier to convert them from ODK to OSM.

Create a tutorial on using the osm-fieldwork tools, which are terminal based. Osm-fieldwork is also part of the FMTM project, and handles all communication with ODK Central, and converts ODK data files into OSM XML. There is also some background information here: https://www.senecass.com/projects/Mapping/tech/.

This is a very simple XLSForm for place. I has only 1 set of choices, and only a few questions.

Currently when using Overpass for the data extract, the tags don't make it to the data file. They are in the result data from the query, so just need to be processed into the OGR Feature.

ODK supports loading data from an external file, that can be selected and edited based on the XForm.
in our case this these are existing POIs or buildings in OSM. Odkconvert needs to be able to preserve the tags from the existing OSM data as the data is converted to OSM. Since the tags in this case are already in OSM syntax, they don't need to be converted.

The draft data models document specifies the types of humanitarian data, as well as the data points to collect. Not all of the models are map oriented. For the models that do have map data, there may be required data points not in the XLSForm. All the XLSForms in this library will need to be enhanced to support these models where possible.

Modify the XLSForm used for the Ruwa-Niger project used to collect data on water points. The changes involve 2 things. The primary one is improving the efficiency of collecting map data. The secondary is to modify the XLSForm name column in the survey and choices sheets to be a closer match to approved OSM tags/values to make it easier to convert them from ODK to OSM.

It would be useful to have a CLI program to access the ODK Central server emote REST API for basic operations. It is inefficient to frequently upload XForms with attachments when developing the XForm. A simple CLI to upload the XForm and the attachments, as well as down the submissions, would be much more efficient, and allow other scripts or cron jobs to access the server.

On occasion a single value in the ODK XML data can generate multiple OSM output tags. For example using power=solar would become "generator::source=solar,power=generator". The Yaml syntax in the config file needs to supports this using a comma as the delimiter.

The logger needs to be instantiated using:
log = logging.getLogger(__name__)
in all modules, to allow this to be hooked by upstream loggers.

The logging still needs to work when odkconvert is used standalone and when it's incorporated into fmtm.

The code above will make it work with upstream fmtm, but to make it work standalone we need to create a basicLogger (https://github.com/hotosm/fmtm/blob/14a917952596cab53a7cb8bfc426551dd4a0068c/src/backend/main.py#L44) instance in the modules that will be called.

CSVDump.py and odk_client.py are called standalone and need the logger defined first. I will need to check if there are any other modules. Input from @rsavoye would be great if possible!

There is a Landuse category in the data model, but there isn't an existing XLSForm for this, so one will have to be created.

Modify the XLSForm used for the Ruwa-Niger project used to collect data on waterways. The changes involve 2 things. The primary one is improving the efficiency of collecting map data. The secondary is to modify the XLSForm name column in the survey and choices sheets to be a closer match to approved OSM tags/values to make it easier to convert them from ODK to OSM.

There is currently no XLSForm for tourism, so one will have to be created.

Now that this XLSForm supports the data model, it needs to be extended to support editing existing OSM data. This will let mappers edit this feature to be tag complete.

There are a lot of building data in the data models. This varies from healthcare facilities, shops, etc... There is currently no XLSForm for buildings, but I have several older ones I can base this on. Rather than create separate XLSForms for each type of building, this one starts with the function of the building, and using conditionals, changes the survey questions. So much building data is shared between the types, having multiple XLSForms would have a lot of duplication.

When using an external data file, in our case one that contains existing OSM data, the XLSXForms need to extract the tag/values from the existing data and use those to populate the default values when using ODK or Kobo Collect. Otherwise the existing data values needs to be reentered manually.

As HOT and other humanitarian mappers often collect the same data, like water points, it would be more efficient to have a library of template XLSForms that are designed for easy of use and mapper efficiency. These would also implement the HOT data models as close as possible.

When using an external dataset with ODK Collect that contains existing OSM data, the existing tags need to be conflated with the tags from ODK Collect. This would be after the ODK data is converted to OSM format. Often the existing OSM data may have a few tags already, but ODK is adding more values, so they need to be merged.

Each XLSForm needs to be able to convert the submissions to OSM XML.

Currently there is no XLSForm for Healthcare, so one will have to be created. There are a few older XLSForms for health facilities I'll use as a start.

Tags on points or polygons?

As Kristen and Ivan prepared to test the FMTM for building tagging in Boulder, we realized that there's an inconsistency in the way that tags are applied to buildings.

In many cases, the building polygon (the 'way') is tagged with building=<something, often 'yes'> a name, number of levels, etc. This makes it straightforward to add tags to the building.

However, in other cases, the building polygon has few or no tags (not much more than building=yes) but there's a point (standalone OSM node) that is tagged with most of the useful information about the building: the name, the opening hours, etc.

A particularity of the situation along Pearl Street in Boulder is that restaurants appear to be tagged with amenity=restaurant, while shops appear to be tagged with the key shop (as in shop=fabric or shop=gift). So simply pulling all of the amenities from OSM along with the buildings wouldn't catch shops, and we're not sure what other important types would also be missed.

What is the implication for building tagging?

The old OMK workflow generally assumed that it would often be appropriate for building polygons to be directly tagged. This doesn't work well when a building contains multiple amenities (a mall, or a multi-story building with a different business on each floor; that being said, a pile of 2D points doesn't do much better for the multi-story situation either). The current situation requires that we either choose between polygons and points, in which case we'll certainly fail to see/load information from one of the two layers, or bring in both, which seems likely to result in a messy, cluttered task for which it's more difficult to decide if it's properly completed.

There are a few possible approaches to this:

1. Ignore it and tag the building polygons without looking at the tags on the points
2. Import amenities, shops, and whatever other keys refer to points that contain information about the buildings we're visiting, and select those points rather than the building polygon centroids
3. Integrate the tags from the points into the polygons using JOSM or other before starting work on a project
4. Other?

It seems likely that different approaches will make sense for different contexts; wherever a particular style of mapping seems to predominate and the local community seems to be happy with it we probably shouldn't mess with it.

However, we should probably have a think about the various possible strategies, and maybe have a conversation with the data model and data quality people!

The draft data models document specifies the types of humanitarian data, as well as the data points to collect. Not all of the models are map oriented. For the models that do have map data, there may be required data points not in the XLSForm. All the XLSForms in this library will need to be enhanced to support these models where possible.

Modify the XLSForm used for the Ruwa-Niger project used to collect data on schools. These changes involve 2 things. The primary one is improving the efficiency of collecting map data. The secondary is to modify the XLSForm name column in the survey and choices sheets to be a closer match to approved OSM tags/values to make it easier to convert them from ODK to OSM.

In mid Sept, the organization that maintains the ODK Central server release an open source python module to use the REST API of the server. Currently odkconvert has it's own python module, but it would be preferred to use something with more community support. The new code should be investigated for Endpoint completeness.

When FMTM creates the data extracts, for some features, like public toilets, there not be any data in most of the data files. For an XLSForm though, it's expecting to access several fields like title and id. If these don't exist, ODK Collect will crash. There are two workaround for now. One is to extend the empty feature collection to have 1 entry with the minimal keywords in it. There would be no display of existing data in Collect, but it won't crash. The other workaround is to edit the the XLSForm to not use a data extract from OSM, and upload it as a custom XLS to FMTM.

While using the OSM tag in the name column of the survey and choices sheets becomes the OSM tag/value, not everything can be handled this way. Usually there is some tweaking of the YAML config file. This task is to make the conversion to OSM is good.

To support the select_one_from_file functionality of ODK, a GeoJson data file of existing buildings is required. To create that data file requires either extracting it from a postgres database, or using Overpass Turbo. Both of those tasks has a learning curve, and this needed to be automated for FMTM too. This script uses either Overpass or postgres to extract all existing buildings in the user supplied boundary so not it's really easy.

Now that it's possible to load OSM data into ODK Collect and use that to set the default values for all questions. While the data extract file will need to be generated for different mapping projects, that's also been automated.

We are using these modules in FMTM, but running standalone would be easier with a CLI.

• odk_client is a CLI for odkcentral. It is more of a debugging tool, but its direct access into the DB lets you clean up mistakes that you can't do through the UI, like deleting projects.
• CSVDump.py is used to extract data for going to remote / offline mapping areas. Most OSM software requires an internet connection, so this is useful for those that regularly map offline.

I propose we add a CLI for these two modules using Click (https://pypi.org/project/click/), to install into a users bin after pip installing, allowing them to run something like:
odkconvert client function --flag
odkconvert dump --flag

Odkconvert has minimal documentation, it should be expanded, and include more examples.

Modify the XLSForm used for the Ruwa-Niger project used to collect data on road networks. These changes involve 2 things. The primary one is improving the efficiency of collecting map data. The secondary is to modify the XLSForm name column in the survey and choices sheets to be a closer match to approved OSM tags/values to make it easier to convert them from ODK to OSM.

If possible, use OpenArialMap as the imagery source for the basemapper.py program.

Epic for all the XLSForm library issues.

Currently there is no XLSForm for the Place category in the data models, so one will have to be created.

• Related to PR #46.
• First we need to decide on how to manage version control.
• I personally recommend commitizen, it would allow for bumping versions in multiple files, plus auto-changelogs based on 'conventional commit' messages.

We could then include a section in pyproject.toml:

[tool.commitizen]
name = "cz_conventional_commits"
version = "0.1.0"
version_files = [
    "pyproject.toml:version",
    "odkconvert/__version__.py",
    "Makefile:VERSION",
]

• Once version control is handled, we could automatically push versions to pypi based on git tags.

The data models have a category of drainage, which is different from water point, so a new XLSForm, will have to be created.

• We need a home page and sidebar + links to individual pages.
• Plus a gitlab action to publish to the repo wiki.

This is to support using ODK Collect to edit OSM data, in this case, toilets. This requires support for making the data extract, and using that data as defaults in ODK Collect.

There is a road network XLSForm, but collects few details about the highways. Using an enhanced version of an XLSForm already in use at HOT, and modifying it to support the new data models.