Kobo for OpenStreetMap

[tinok]

Hi @mikelmaron, thanks for the many great ideas in this post! Some of them could probably be separate feature suggestions.

Regarding this item of matching OSM-expected output with KoBo output:

@mikelmaron

• There are columns that are irrelevant for OSM, both as part of the survey and as metadata (start, username, deviceid). For OSM output, drop the metadata and have a way to filter out questions.
• Kobo has a length limitation of in data values (14 characters I believe). Some tag’s values are longer than this (ex “amenity=place_of_worship” for a religious facility).
• “Data Column Name” prohibits the “:” character. “:” is frequently used in Tag keys

• Exporting only the fields you are interested in is possible, though only via the API at the moment.
• The length of the response name issue is only for using the formbuilder, not when importing from XLS. So setting the response name to amenity=place_of_worship should be no problem if you design your form in XLS.
• The XML question name can’t include :, but you could use the proper OSM-compatible name in another language (e.g. label::OSM) and then export your data to that language. This could also be a workaround to the previous issue.

@mikelmaron

Single question, multiple tags
…
To address this in Kobo, I think would take adding settings for each value. This could be a simple check box adjacent to the value field which if clicked would treat the value as a Tag (or multiple tags). The Tag key/value pairs would be of the form “natural=spring” or for multiple. “water_way=dam;dam:type=earth_dam”.

Do you have an example on how this work at the moment and how it could be done differently?

@mikelmaron

Multiple questions, single tag key

A related issue is that some OSM Tag keys cover a huge number of different kinds of features, particularly “amenity” which can represent everything from a school to a hospital to a bar. This means that the “amenity” data column name is used multiple times throughout the form, and Kobo automatically assigns a suffix (“amenity_001”).

I think this could also be handled by adding an additional ‘language’ to your form, which would allow having multiple amenity columns.

@mikelmaron

Export format of GeoJSON and/or OSM XML will allow direct use in JOSM.

GeoJSON is already possible, though only to export points, lines, and polygons created with these question types. The entire dataset could be formatted in a way to allow importing, but we would need much more details to guide the conversion.