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_Berg, 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 - #10 by J_D1. 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_Berg 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_Berg, 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_Berg 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.