Capture location task fully in the background

[jo-spek]

We had this discussion a while ago @gino-m, whether the task "Capture location" should be moved away from users entirely and be always triggered automatically in the background.

The reasons are quite simple:

• This is intended as a data quality control mechanism, such as whether data collectors were actually close to the collected geometry or doing it from afar. When data collectors have control over the "Capture location" task, it kind of defies the purpose.
• During field testing, the Capture location task often led to confusion, especially if preceded or followed by the "Drop a pin" task. It wasn't really clear to data collectors which of the two was actually meant for geolocating a plot. This can be solved by sufficient explanation and training, but it makes surveys less intuitive and adds a layer of obscurity.

Furthermore, moving Capture location into the background as automatic metadata collection would make the discussion on #2719 (comment) redundant.

[anandwana001]

more of a feature than a bug.

Question on this approach:
Capture Location will still based on the survey, like if it is there in the survey then send else not?
Or from now on, do we need to send the location always, no matter which survey?

[gino-m]

@jo-spek I suggested this in the past, but iirc @lecrabe thought it was better to be explicit about it as a task (please cmiiw). I still think it's a good idea, but there are questions about this - what if we want to user to stand in a particular location or to wait for a specific accuracy when the app captures their location? If it only happens in the background then this interaction won't be possible.

My previous suggestion was to always capture the current location when a pin is dropped or when a vertex is added. The min accuracy UX would still be tricky in this case.

[gino-m]

Assigning to @kenstershiro for discussion our the first Product WG meeting.

[gino-m]

After discussion with @n-clinton on #2739, I propose the following:

• Always capture location on drop a pin and when adding vertices on draw/walk perimeter tasks. The site will use the user-defined location(s), but the actual location(s) will be stored as metadata.
• Show location accuracy on geometry tasks.
• Auto-enable location lock when drop a pin task is shown.
• If user drags farther than some threshold, show distance between manual location and actual (["Draw area" and "drop pin" tasks] Show distance between current and selected location #2141).
• Allow organizer to set max. distance from current location when creating geometry tasks.
• Allow organizer to set min. accuracy when creating geometry tasks.
• Remove the Capture location task altogether.

@jo-spek @lecrabe @n-clinton @jabramowitz5 Wdyt?

[n-clinton]

I guess I'm saying that "capture location" should be 100% GPS based, thereby avoiding the possibility of dropping a pin anywhere that's NOT your location. Perhaps that could be enabled in some break-glass way, but I don't think that should be enabled by default.

[gino-m]

"Capture location" is 100% location based, "Drop a pin" gives you the option to do either. There are cases when you can't actually stand where you want to add something (a point on the plot perimeter in a ditch or a thorn bush), or when canopy is too dense to get an accurate reading, for example, so there needs to be some manual override. The above solution tries to give the best of both worlds, while simplifying usage for organizers and data collectors by eliminating the need for two separate tasks (drop pin vs capture).

[kenstershiro]

Am I right that you would typically use either "Capture location" (preferred) OR "Drop a pin" (when you can't stand at the specific point)? In which case there could be one task which has a default and an override option? The steps described above by Gino make sense to me, although there is a lot of complexity. In particular is a an organizer always going to know sensible values for the max distance and min accuracy, which may be affected by conditions in the field on the day?

[jabramowitz5]

Perhaps an example from our field campaign is helpful - a sequences of tasks we have in our survey is:

1. "draw or walk perimeter" task for mapping the boundaries of an agricultural area. This is similar to the "drop a pin" task where a user can use their current location OR drag around map interface to select a different location

2. "take a photo" task as a pseudo-ground truth to make sure data collectors are in the fields we are interested in (cocoa) and to give some info that can help verify survey answers on field condition

3. "capture location" task to function like a geotag for the photo that was just captured, allowing us to make sure the photo was taken (task 2) in/near the field that was mapped (task 1) - for this task you can ONLY use your current location. You cannot drop a point elsewhere by panning around map

I think these tasks are all functioning as we expect/want them to, so not sure I see the problem here - but I may be missing something?

[gino-m]

Am I right that you would typically use either "Capture location" (preferred) OR "Drop a pin" (when you can't stand at the specific point)? In which case there could be one task which has a default and an override option? The steps described above by Gino make sense to me, although there is a lot of complexity. In particular is a an organizer always going to know sensible values for the max distance and min accuracy, which may be affected by conditions in the field on the day?

Am I right that you would typically use either "Capture location" (preferred) OR "Drop a pin" (when you can't stand at the specific point)?

I both get used, for ex in the case where we both want them to have full control over where they drop the pin, but also know whether they were in the vicinity when carrying out the data collection.

Allowing the organizer to add an explicit Capture location task has a few benefits over auto-capturing the location during the data collection process:

1. It's more transparent to the data collector that the app is capturing their location (consent, trust)
2. It's allows the survey organizer to communicate special instructions before capturing the location (e.g, stand in the center of the plot)
3. It allows the data collector to decide when the location is capture, rather than it being incidentally captured while carrying out tasks.

Also, I think max distance and mix accuracy are usually known, but we should note that the cost of the organizer getting them wrong is quite high.

Perhaps we shouldn't be thinking about this as an either-or prospect; perhaps we need both Capture location, and the ability to record the device location, either constantly, or on each task?

[jabramowitz5]

I don't really see why we need "the ability to record the device location, either constantly, or on each task." If you want to know where the data collector is you can use the "capture location" task to do so. I do not see a huge gain in knowing the task by task location of the data collector, rather than just the location on a "capture location" task (and multiple of these can be put into a survey if the organizer is very concerned about data collectors' locations throughout the survey).

Going back to @jo-spek original 2 points:

• If you are using "Capture location" as a quality control mechanism I think it achieves this purpose as is. Are you saying it does not because the data collector can fill out tasks from elsewhere and then go to proper location to capture location? This does not seem realistic to me since it would not actually end up saving the data collector time in trying to game the system this way since they would have to still go to the proper location for each data entry upon reaching the "Capture location" task
• I agree it can make it slightly more complicated, but I think this is easily avoidable with proper directions attached to the "Capture location" task and also with training of enumerators.

[kenstershiro]

I'm hearing good reasons from @gino-m and @jabramowitz5 to keep "Capture location" as an explicit task performed by data collectors. And that Drop a pin makes sense as a separate task. @jo-spek do you still feel strongly that we need to capture the location in the background as well as/instead of explicit Capture location? @gino-m 's approach would allow both, if we feel we need this additional level of validation.

[gino-m]

Also - some users have requested the ability to record the users' position as they walk/travel. @jo-spek perhaps adding optionally recording the user's GPS tracks in addition to what's already there would address your original need?

[jo-spek]

Hi everybody, I'm back.

I'm hearing good reasons from @gino-m and @jabramowitz5 to keep "Capture location" as an explicit task performed by data collectors. And that Drop a pin makes sense as a separate task. @jo-spek do you still feel strongly that we need to capture the location in the background as well as/instead of explicit Capture location? @gino-m 's approach would allow both, if we feel we need this additional level of validation.

Seeing @jabramowitz5 campaign running pretty smoothly now, it might be fine as is. The perspective I am coming from has been to make this application as easy to use as possible, even without prior training. When using GROUND for the first time myself, I got quite confused by the two separate yet similar tasks of "Drop a pin" and "Capture location". I saw this happening to participants during the training in Kenya, too. Therefore I find the idea of an automatic capture-location in the background more appealing. Capture location can be easily manipulated by Fake GPS apps, which is why it might defy the control mechanism purpose when it is an actual task.

Also - some users have requested the ability to record the users' position as they walk/travel. @jo-spek perhaps adding optionally recording the user's GPS tracks in addition to what's already there would address your original need?

--> Yes, that would be pretty neat. That would be the polygon version of the idea to have "Capture location" as a geometry task of its own (completely disconnected from the other discussion of it being a control mechanism). If we want to go that path, I'd suggest making it an issue of its own. Seems like a pretty major task.

[gino-m]

Brainstorming a bit, if google/ground-platform#2075 is implemented, the process could be something like this:

For ad hoc / free form / opportunistic data collection jobs:

1. The job must contain exactly one, required "Map a new site" data collection task; adding "capture location" would not be an option. (@vittorino)
2. At data collection time the app captures both device location, and map center storing both separately. We'll end up with two geometry for both polygon and point tasks; once with the actual device coordinates, the other with the map coordinates. We may want to show both in the data collection UI or allow the user to toggle between them if it makes sense (@rawbzz)
3. Secondary geometries are already shown on the map when a site is selected in the web app (@amysorto). We might also want to allow organizers to toggle between the actual and reported locations (@vittorino)
4. Exported data will contain two geometry columns, e.g. user_defined_geometry and device_locations_geometry

For predefined / structured jobs:

In this case, site geometries for these jobs are imported, so the "map a new site" data collection task doesn't apply here. We may want to allow "Capture location" tasks to be added so that organizers can ask data collectors to provide their actual location when collecting data about an existing sample plot. We may or may not also want to implement google/ground-platform#1736, in which case users would be able to annotate an existing plot with points and/or polygons as described in the "ad hoc" section above.

@kenstershiro @jo-spek @n-clinton @jabramowitz5 Thoughts?

[jo-spek]

Abstract but very cool idea. Thinking this through, I do see some problems with the polygon secondary geometries. I would imagine that especially the last closing point of a geometry would often be taken from a distance. Since collectors can't verify those background-collected polygon corners, I think that much of this would not be too useful, but maybe serve as a backup for later reference when professionals edit the polygons in a GIS? I don't know, we might also run into putting too much effort on this while neglecting other more pressing issues. However, when it comes to a 'secondary geometry' alongside the 'drop a pin' task, I am all for it!

[jabramowitz5]

At least in my experience testing the app and from what I have heard from the Ghana team in the field, there has not been confusion around the "capture location" task. This could be due to our training walking the enumerators through all the steps as well as clear directions associated with the task in our survey.

I still feel that the current flow is fine and does not need changing, as I think the benefits @gino-m mentioned (below)

• It's more transparent to the data collector that the app is capturing their location (consent, trust)
• It's allows the survey organizer to communicate special instructions before capturing the location (e.g, stand in the center of the plot)
• It allows the data collector to decide when the location is capture, rather than it being incidentally captured while carrying out tasks

outweigh the challenges brought up by @jo-spek of Fake GPS to game the survey and potential confusion. IMO, these challenges would mainly come up during large open surveys where the survey creation team never directly interacts with the data collectors, potentially in a citizen science type model (certainly something I could see in Ground's future through FDaP or other initiatives). For the potential confusion I think clearly worded survey text in the "capture location" task should be able to avoid this, and perhaps really thinking about task ordering to prevent "drop a pin" and "capture location" from following one another? For the Fake GPS concern, perhaps there can be an option during survey creation to make "capture location" user facing (as it currently is) or automatic behind the scenes. This could allow the current option for most surveys and the automatic option for large, open surveys where there is no interaction with data collectors.