# Selecting a map feature to collect data about **URL:** \ **Category:** Development\ **Created:** [July 20, 2020, 10:38pm UTC](https://forum.getodk.org/t/selecting-a-map-feature-to-collect-data-about/28466 "2020-07-20T22:38:53Z")\ **Posts on this page:** 1\ **Showing post:** 13
**Author:** ![LN](https://getodk.b-cdn.net/user_avatar/forum.getodk.org/ln/32/1605_2.png) [@LN](https://forum.getodk.org/u/LN)\ **Post date:** [August 3, 2020, 10:27pm UTC](https://forum.getodk.org/t/selecting-a-map-feature-to-collect-data-about/28466/13 "2020-08-03T22:27:49Z")
> [@Paul\_Storry](#): > > the select feature is inside a repeat loop, so selecting a feature inside the form is essential, although launching a form from a map might work well too That makes sense. Virtually all usages of repeats that I've seen could be represented as multiple instances of the same form definition linked by something like a map or a hierarchical menu (e.g. household \> people \> pets are each a different form definition). Is your fork one that you could share? > [@Xiphware](#): > > the _current_ entity is essentially the latest 'submission' (for lack of a better word...) of the entity form having a specific pre-defined entityid Yes, great, that is consistent with what I remembered from our in-person discussions at the convening. @Xiphware and I chatted a bit off-forum. And indeed, I think this comes back to one of the major questions we had coming out of the convening discussions: whether "the entity" is defined across a single form definition ("entity form") or across many. This may have significant repercussions on performance, complexity, and expressiveness (I say "may" because I haven't put in enough design time to really feel confident about the tradeoffs). To put this in very concrete terms in the context of this discussion, the question is whether "location" would be editable only through the "entity form" or not. Let's say I have patients with addresses. This is the difference between updating the patient's address in a scheduled visit form vs. going to the entity form to make that change. Swimming pools have the advantage of being relatively static so this isn't a very big deal. Some entity types will be much more likely to have their core properties change over time than others. > [@mathieubossaert](#): > > the ability to click/select an object to start a entire form for it This seems like a really clear win to me and seems like something we can do by attaching geo data to a single form definition ("pond frog survey" in @mathieubossaert's example). Features defined in that geo data file would appear on the existing form instance map. Tapping one would start a form instance with fields populated from the geo data file. > [@mathieubossaert](#): > > A great evolution would be to select the cell where I am as a select-one list entry Wouldn't it be even better to have each cell be a geo feature with a feature ID and be able to tap on a cell to start a form? That would be essentially the same thing as the frog case. > [@mathieubossaert](#): > > wine growers Let's help the wine growers. 🍷 > [@danbjoseph](#): > > the use cases i've written down so far I asked for some clarifications in the doc. While I agree with @Xiphware that these cases are longitudinal, as you say, it's possible to improve these significantly without supporting the full workflow. In all of the cases described, I think this can be achieved in the context of a single form definition. Thanks for chiming in, @RubenFoquet. I think your first point is likely to be addressed in the relatively near-term. We'll make sure to loop you in to ongoing conversations. Points 2 and 3 are squarely in the realm of [entity-based data collection](https://forum.getodk.org/t/odk-ecosystem-longitudinal-data-collection-table-of-contents/22234). I don't think we'd tackle those workflow aspects as part of this work but hopefully we get there sooner than later. It's a big piece of work and we have to figure out how to resource it. --- _[View the full topic](https://forum.getodk.org/t/selecting-a-map-feature-to-collect-data-about/28466)._