Add accuracyThreshold and unacceptableAccuracyThreshold as parameters for geopoint

[lognaturel]

There's no explicit pyxform support for accuracyThreshold now though the XLSForm site documents it using the generic body attribute column structure: https://xlsform.org/en/#gps-with-accuracythreshold Adding it to the parameter column as capture-accuracy will make it more accessible.

unacceptableAccuracyThreshold is new to ODK Collect. It configures a threshold for the worst accuracy that will be labeled as "unacceptable" to help encourage data collectors to wait or improve conditions for a higher-accuracy point.

XForms attribute	XLSForm parameter
accuracyThreshold	capture-accuracy
unacceptableAccuracyThreshold	warning-accuracy

[lindsay-stevens]

Would this imply removal of support for the body::accuracyThreshold column in favour of the parameter capture-accuracy?

[lognaturel]

Good question! No, the body:: and bind:: things are generic tools. Whatever is after the :: gets passed in to the body or bind, respectively. I imagine they were introduced as both a stopgap for XForms features that get introduced and for flexibility for custom clients. This change would be purely additive for convenience.

[seadowg]

I'm thinking capture-accuracy (and unacceptable-accuracy for the other threshold we've talked about) make sense as names here

[lindsay-stevens]

Some options for unacceptable in unacceptable-accuracy: invalid, lowest, minimum.

[lognaturel]

Thanks, @lindsay-stevens, talking it through was helpful. How about warning-accuracy: the unacceptable threshold represents a threshold above which clients are encouraged to warn the user to change conditions or keep waiting.

~I'm proposing warn-accuracy rather than warning-accuracy by analogy to capture-accuracy but don't feel strongly about it. warning-accuracy might be easier to remember.~ I am convinced that warning is easier to remember.