Color-coded GPS accuracy and minimum threshold for mapping

[jo-spek]

Problem
When collecting field data with Ground, the GPS's accuracy is displayed in the "Current location" pane. However, for the non-professional user this might be easily overlooked or its importance not understood.
(At the Kenya workshop we had participants ask for it after they had already successfully mapped something, because they simply overlooked it.)

Potential solution
Is it possible to implement a minimum threshold of accuracy before users are able to register a point? E.g. that "Add point" would only work if GPS accuracy is 10m or better and display a "Please wait a few seconds" when clicking "Add point" but accuracy is too low? And can the accuracy display in the "Current location"-pane be color-coded? (Green: High GPS accuracy --> 0 to 5m, Yellow: Medium GPS accuracy --> 5 to 15m, Red: Low GPS accuracy --> 15m and less).

Implementation in the app of our partners at GIZ:

[jo-spek]

After the regular meeting yesterday I put some further thoughts into the possible implementation.

Problem: Unlike in the INATrace app from GIZ, free-form data collection is enabled in Ground where data collectors can pan and zoom to any location to drop points or polygon corners. That doesn't go well with the idea of a GPS accuracy threshold (i.e., why should the GPS be accurate at your current location, when you are moving the cursor freely on the map).

2 Possible solutions:

1. It seems after pressing the target button that there is a soft lock on the current location. The "Current location" pane is displayed with GPS accuracy. When moving the cursor manually, the pane disappears for a moment and reappears without GPS accuracy indication. It seems that there are two different modes. Can the GPS accuracy threshold apply only to the first mode right after clicking the target button, but not to the other when the user manually moves the cursor?

2. If the above solution doesn't work, maybe there could be an actual target-lock instead: When you press the target button, the cursor could be locked to your location and the threshold applied when you add the point. (Target button could appear in dark green as lock indication). When you press it again, it unlocks and you can freely move the cursor with no GPS accuracy threshold applied.

[gino-m]

Hi @jo-spek thanks again for documenting our discussion and possible solutions.

I had another ideas about how to handle this:

1. Remove the "Capture location" task type from the survey editor, instead always capturing both the current location and the map location when dropping a pin. Both "Current location" and "Map location" would be shown in the card/pane.
2. Allow organizers to specify an optional min. accuracy on "Drop a pin" tasks at survey creation time. If specified, this constraint would apply, regardless of whether data collectors have the location lock enabled.

This would result in fewer decision points for survey organizers. Automatically adding a "Capture location" task could also be disabled.

You may also want to do the same for polygon (perimeter) tasks, perhaps at the start of data collection.

Lastly, you may still want to consider an override of the min. accuracy, since without it the survey will unusable if the organizer specifies too low of a threshold.

[jo-spek]

Hi Gino, thanks for answering.

Regarding point 1:

• I really like the idea of always capturing the current location in the background by default. That makes for a good quality control mechanism.
• Not sure about removing "Capture location" altogether. That's what feature request #2675 is about. I think it could be advantageous to have three types of geolocating: 1. Free form polygon collection, 2. free form point collection, 3. non-free point collection (i.e. capture location). 1.&2. require a lot more skill and understanding of what's going on on the data collector's end. Capture location with an in-built threshold is a lot more fail-safe in the hands of laymen and at least in Kenya virtually all plots of smallholders were smaller than 4 hectares, i.e. only necessitating a point for EUDR compliance and not a polygon.
• Displaying both current location and map location in the card/pane is something that probably only professionals would read and understand. I saw a lot of confusion on users' ends in the field and I'd rather argue for reducing or dropping it. Since it might be useful for a small subset of users I would argue for the possibility to optionally enable it in the settings.

Regarding point 2:

• Specifying min. accuracy adds a decision point for survey organizers again. I'd argue for it defaulting to 10m, but that could be further discussed. From experience in the field, 10m is not too inaccurate but quickly established by most GPS sensors.
• Here everything comes together again which is why I created #2675. Throwing out Capture location as a task and instead making it one of three geographic data collection options: 1) Free form polygon collection, 2) Free form point collection, 3) Non-free form point collection (same function as Capture location but different position in the survey work flow).

How do you suggest implementing for the polygon tasks?

Last point wouldn't be a problem if we set the threshold somewhere between 10 and 15. Any device that can't hold it probably shouldn't be used anyway.

[gino-m]

There are a few caveats here which we should explore and which are probably too long to document here. Let's discuss when we meet in the PM forum?