Ability to load locations into the geowidget to guide data collection

1. What is the general goal of the feature?

The goal of the feature is to make it possible to load in a series of locations (eg. health facilities) into ODK and make them viewable on a map similar to the way you can currently view submissions now (see ticket below). Clicking on the point would allow you to pass metadata (eg. the feature id) to the submission. This would provide similar "check-in" functionality that OMK provides.

More feature specifics

  • The source for the locations would be a CSV or geojson file downloaded as a form media file
  • In the form ability to launch the geowidget view, view nearby locations, click on them and have that populate the form with specified properties from the locations file
  • In the form definition, define the properties to pull from the location file when you click on it.

2. What are some example use cases for this feature?

Anyone wanting to visit specific locations to collect data. This is particularly the case where you are collecting data on things (eg. waterpoints) or locations (hamlets) that don't have clear names.

3. What can you contribute to making this feature a reality?

We would be up for helping to develop it. We have already developed a different Mapbox based Geowidget capable of providing a lot of this functionality. Part of our analysis is to figure out if we should develop a solution based on that would pair our map app with ODK (similar to OMK) to achieve this. If ODK's map widget has the needed based functionality we would be open to building out the functionality here.

Wanted to start this conversation to understand if #1 people thought this would be useful and #2 how viable using ODK's map widget as a starting point would be for this.

At first glance, this looks like some functionality that is on the general roadmap. I think the biggest challenge is coming up with specifications that are coherent with what already exists and reasonable for tools across the ecosystem to support.

What's higher priority, this or Collect will need to stop using /sdcard/odk for files? Could y'all maybe free up some cycles to think through this by doing pyxform/XLSForm review?

Hi @LN they both are important and we can potentially invest time in both so I would rather keep them separate when we try and figure out the approach for this.

If you have a bit more clarity on the roadmap that would be helpful. We can spend more time on how this would be represented in XLSForm spec if that is what you are requesting.

At a high level, I think we would probably want to be able to define in the geowidget question type the file being referenced and the metadata that would be passed back. We can probably assume for now that the locations file only have one set of GPS points per feature to start.

We've got a few big things on our plate at the moment so it would help to know the relative priority since both will need cycles from the core ODK team. I'll try to get some links to prior conversations soon.

Yes, the first step is defining the scope, then it's coming up with an XForms proposal, then an XLSForm proposal.

1 Like

Cool thank you that is very helpful to understand. Will speak internally re: XLSForms and get back.

1 Like

CC @danbjoseph @Ivangayton @zestyping @russbiggs_hotosm who have been involved in related prior conversations.

Here is the library I referred to. It's pretty robust and is being used in OpenSRP, DHIS2 tracker and I believe CommCare soon.

I've been chatting with @Ivangayton / HOT OSM about how to resume some of the past work around improving the geo widgets that @zestyping was such a key part of, and also develop the ideas for the work into a more cohesive vision. There were community discussions around this at the most recent ODK Convening in late 2019, and a variety of forum discussions. We're just wrapping up on an initial document to describe the aspirations and so it has not been discussed with the TSC yet. The hope was to get additional eyes on the ideas and work with the TSC to figure out the technical feasibility and fit with the ODK project. Then if we can agree on a clear scope and plans, move on to identification of resources to make happen.

EDIT: I think there is a lot of overlap between the above and our proposed roadmap ideas.

2 Likes

As @danbjoseph alludes to, the general space of selecting a geo feature as part of the data collection process is now being taken up more actively by the TSC. The geo future directions doc gives a good overview of the various themes that users have brought up related to all things geo and that the dev team would like to take up. The map-centered form workflow section in that doc is closely related to what is being described here and what @danbjoseph has started fleshing out in the doc linked above.

@Matt_Berg1, could you please share a writeup of the specific project/workflow that is triggering this request? A good example of such a writeup is @J_D1’s View GPS point on Map for Blank Forms. I think the biggest decision to make is whether to treat this as a subset of entity-based data collection or not and getting a clear understanding of what workflows need to be supported would really help. Specifically, the first post in this thread suggests attaching the geo features data to a single form. @danbjoseph describes a model where the feature selection happens before form selection (e.g. select a waterpoint and then select what form to fill about it) which means features data has to come from outside the context of a single form.

There are excellent notes from the last TSC call here. @Ukang_a_Dickson brought up various related projects and I imagine you’ve probably synced up (I mention this because @Matt_Berg1 and @Ukang_a_Dickson are both from Ona).

Since there are a lot of moving pieces in this general space, there would definitely need to be detailed user stories leading to a specification and iteration with the TSC. @Matt_Berg1, what is your timeline and would you be up for working towards a specification for the TSC to consider?

Regarding Kujaku, the systems that incorporate it are all entity-centric and I assume that those systems use it as a way to visualize and collect data about those entities. Without an entity context, that pushes more data/workflow management onto users. @Matt_Berg1 do systems that incorporate the library build their Kujaku configs on the client or server? Regardless, leveraging the library might be possible. An immediate question that would need to be explored is how the existing Collect point/trace/shape question types that use the Mapbox API coexist with the Kujaku lib. Kujaku pulls various functionality from Collect like offline mbtiles management, location provider management and both rely on the same underlying Mapbox lib but Kujaku has an older version. I think that almost certainly means conflicts.

1 Like