These calls bring together the Technical Steering Committee for the ODK suite (@TSC) to discuss roadmaps, working groups, and other issues of technical governance. Everyone is welcome to come to these calls, but only TSC members may talk.
In the last meeting it was floated to invite @LN this meeting to discuss geo in ODK (and @yanokwa would have to tag out of the meeting). Hélène would you be open to leading that discussion? Your forum posts show you have thoroughly thought about the issues involved. Are there some good points for the TSC to talk about or do we need some more discussion on the forum first?
I'm seeing a v1 emerge that directly addresses @danbjoseph's second use case. This one matches a lot of the others that came up in the thread. From a user perspective, it would enable attaching a list of features to a form definition and having those features be displayed and tappable on the existing Collect form instance map. Tapping on a feature would launch a new form instance with pre-populated values from the feature data. With Enketo, the selection would likely happen in whatever the host application is (e.g. Central) and then the rest would be the same. The major question is whether this covers enough ground. Relatedly, is it worth doing separately from the broader entity-based project. It would be good to also get some opinions on what to do about the Ona thread and related library at Ability to load locations into the geowidget to guide data collection.
I think it's premature to go deep on the technical side but I know it can be helpful to look at something concrete so here are some quick notes. I'm thinking it'd be possible to write XPath queries on the feature data simplified in XLSForm to something like ${feature#properties/type}. There'd be some standard for defining features and their IDs (e.g. https://tools.ietf.org/html/rfc7946#section-3.2). The form instance map would have knowledge of that data and would render every feature it contains. Initial ideas for how that could work would be to render the features in all secondary instances with extension .geojson or to have a reserved secondary instance name. All of those features would be tappable. Tapping a feature would launch a form instance with the tapped feature ID (e.g. in a context virtual instance as suggested by @martijnr).
A possible alternative might be to add a new select-one appearance which instead renders the choice values - in this case, geopoint strings - on a map?
Other than presentation (and pre-filling feature data...) this usecase seems very much like existing selection-based usecases, except we are now picking (geo-referenced) things on a presented map vs a presented list. Also, this could be applied to select-multi, allowing selection of multiple map features. These select choices could be pulled in from external data sources, and I suspect susceptible to the usual count-selected(), repeat loop iteration, etc... ie using our existing XForm mechanics. BTW this isnt that far off the current Image map select widget
The main difference is now you would still load the form (per usual), then presumably the first question would be a map-based selection to pick the target/subject. And this doesn't inherently solve the pre-populating feature data (although I suspect this could be equally accommodated by pulling values in from the associated external dataset...)
