Scoping out OMK priorities for an upcoming sprint

[smit1678]

HOT has several upcoming projects that will look to leverage OpenMapKit Server. In advance, let's start a thread here that outlines some of priorities as well as nice-to-haves. This is just a start, mainly to the question of:

What are some existing workflow challenges with OpenMapKit that can be address in 4-6 weeks of development?

I've chatted briefly with a few people including @mataharimhairi @mojodna and @danbjoseph but want to open it up further as we hone in on a list. Some of these are also currently captured in a few places and from this thread we'll move items into their appropriate repos (OpenMapKitServer, OpenMapKitAndroid).

Breaking this into two overarching categories:

1. OMK Server improvements
2. OMK mobile app improvements

Depending on the technical lift, some of these may or may not be able to be addresses without some significant rewrites of either application so that should be flagged now and considered.

@mberg - how far ahead or perpendicular is the Ona fork for the Android app? What are the improvements that have been made in relation to the mSpray work? Is it worth considering how to get some of the improvements made back into the core app?

---

OMK Server improvement ideas

• improve auth and login. Make it easier to deploy with auth enabled plus consider user accounts or admin + data collector access.
• look to enable deployment on Heroku (or similar), back with S3 or alternative (still keep the file based structure to match other ODK tools)
• improve data management
  • sort, filter, export by day and user
  • update, delete forms
  • consider some features that other ODK-based tools do
• UI for creating deployments (currently a web hook triggered with GeoJSON from a Field Papers atlas)
• incorporate MapFilter or similar project to visualize results

OMK mobile app improvement ideas

• map renderer - tile styles + potential shift to Mapbox Vector Tiles
• editing lines (@mataharimhairi this is correct, right?)

[mataharimhairi]

@smit1678 thanks for getting this started. having the above improvements will definitely assist with data collection efforts on the ground, and managing it for quality check afterwards.

in regards to the OMK mobile app improvement, yes, the ability to edit and add attribute information to polyline features would greatly help our data entry specialists on the ground.

[smit1678]

From @PaulUithol:

Requests from teams:

• Per form, have the ability to filter submissions by date (start/end), author, OSM id
• As some teams have a large number of distinct forms, finding/downloading new submissions can be tricky and time consuming. Proposal: have an "all submissions" view across forms that also has the ability to filter submissions by date (start/end), author, OSM id

[PaulUithol]

^ these relate to what we find is the main bottleneck at the moment to enable use of OMKServer in field situations; management and processing of form submissions

[PaulUithol]

To expand a bit on the OMK Mobile app improvement ideas/renderer:

Currently, there are quite some setup steps involved in preparing for deployment of a project. We'd like to ease/simplify setup/deployment. Right now, the minimum steps are to:

1. Create (xls) forms, satisfy both ODK+OMK
2. Create OMK constraints files (global + per form)
3. Create mbtiles for basemap (if expected to be in area with decreased network coverage)
4. Pull .osm xml, scoped to the subset of features we'd like to appear/be editable to data collectors (for example, we'd only want water point POIs to appear and not mobile money agents, or vice versa)

If we replace the current renderer to enable direct usage of vector data (can that/MapboxGL use .osm xml somehow?), that would allow us to:

• Improve performance drastically, which is definitely a bottleneck right now
• Remove one time consuming step (3) in preparing deployments
• Render the data procured in 4 as the base map (using MapCSS or something else?), and also enable editing of that same data

[PaulUithol]

(on type of file to use for 3/4 - GeoPackage may also be pretty cool?)

[bgirardot]

I +100 to all the items that make deployment and form creation easier

And documentation? Does that exist? We should make sure there is a LearnOSM module for it if there is not one already. I can look into that.

[PaulUithol]

Definitely! On docs, there's a bunch at http://www.openmapkit.org/docs.html

[danbjoseph]

Would be nice to review updates to the main ODK project since OMKServer was first created and make sure that it can handle all data from all standard questions as well as OpenMapKit type questions?

[danbjoseph]

@PaulUithol - the docs could use an overhaul/refresh. and also would benefit from a different publishing format. i'm not really a fan of theDocs being used right now.

[mataharimhairi]

Here is some additional recommendations from the HOT team in Indonesia, following our Tech WG meeting:

OpenMapKit App

• Access Mapbox as a satellite baselayer in OMK app
• Export Tool only creates MBTiles to level 18, which doesn’t provide enough detail for dense areas. POSM created to level 20
• Level 20 MBTiles does slow down the app though
• Ability to edit polylines in OMK app, so users can split a road and add the correct name to the two seperate features on the ground
• Previously had to add points in OMK app as reference, and then split the road in the office and attach correct information which can be time consuming and lead to errors

OpenMapKit Server

• Ability to filter forms by date and osm user
• More admin options through the GUI instead of the command line, such as the ability to delete forms/submissions and back up data
• Login required and different user levels would help to manage who has admin capabilities

[smit1678]

Thanks for everyone's input thus far. To make sure everyone has the link, we've sketched out some initial tickets and moved the initial work on the server app into a Project view in the hotosm/OpenMapKitServer repo.

Over the next few weeks we're going to knock out some of the low hanging fruit for the OMK Server, but based on the discussion above there is clearly a need to do more development on the Android App.