Thanks @danbjoseph and @TAB for driving towards a spec for selecting a map feature to collect information about. We know ODK is already broadly used to collect data that is spatial in nature and I think being able to use previously-defined map features in addition to creating new points, traces and shapes would be very powerful. I really look forward to reading specific scenarios that drive out the "business needs." I want to share a few things that are on my mind.
First, in the TSC meeting notes I asked @MartijnR about what Enketo users and developers might be interested in related to this general space. I ask because there’s a lot of user value to Enketo and Collect not deviating too significantly. So I think we should be aware of and at least consider Enketo priorities around these geo workflows.
Second, I see three broad approaches with various tradeoffs:
- Stay within ODK clients’ form-centric model and communicate map feature data as a form attachment. I see two sub-options here: a
GeoFeaturesquestion type that lets users pick a feature within the context of a particular form instance or exposing a way to pass a feature ID into a form instance. In the latter case, Collect would add selectable features on the existing form map. The advantage of the latter is that data collectors would see map features in the context of previously-collected form instances. - Provide specialized functionality for communicating geo features to be selected outside of any form context. That means focusing on this case and accepting that there might be redundancy with future more general entity-based functionality.
- Treat this as a subcase of entity-based data collection. That doesn’t necessarily mean having to answer everything about the more general case but it means trying to come up with APIs and workflows that can be used for it.
As @yanokwa mentioned in the last TSC call, anything that stays within the form-centric model is relatively straightforward. That’s why @zestyping and I had previously framed it as a stepping stone. My sense is that even if/when we do have an entity-based model, form-centric map feature selection would still be in use because it will be simpler and adequate for folks with less dynamic data collection workflows.
My understanding from the last TSC meeting call and notes is that y’all were starting to rally around something like the second option. This would require a little more designing than the form-centric option but probably not a whole lot. The implementation would likely not be much more complex. However, the concern I have is that it potentially adds another “data collection mode” to continue supporting in the future.
Let’s say we agree on some API for clients to get features data that’s outside of a form context and let users select features to launch a form list. As @danbjoseph and others have mentioned, there could be a different mode in “Fill Blank Form” that displays a map. Once we add a general entity concept, we’d be supporting a text list and map for “loose forms” (what we have now) and a text list and map for “entities.” Similarly, on the server side, there’d be an endpoint for pulling map features for “loose forms” and some way to pull entity data that also includes map features. No single component of this duplication is hugely complex but I think that the explosion of combinations of features that ODK already has makes software maintenance, documentation writing, support, and coherent evolution of the tools really difficult.
The third option would entail thinking of the map features as entities and having servers communicate entity lists and the forms that apply to them. Naturally, there are a lot of unknowns here. I don’t know how realistic it is to design APIs for entity-based data collection without considering the full workflow.
My current thinking is that trying to get a form-centric model out to users relatively quickly and then leveraging that implementation in a future entity-based model strikes a good balance between improving things in the short term and providing ideal functionality in the long term. I’m nervous about the second option but perhaps more concrete details around the path to an entity-based model and the API for communicating feature data would change my mind.
Related threads:
