The original thread on the forum
The initial specification written in Google Docs
What is the general goal of the feature?
As a supervisor, I would like to collect location coordinates in the background to provide evidence that data was collected in a particular place.
The reason of this feature is to avoid bad data. For example, you might notice an enumerator who as been poorly trained collect location in the morning, then go home and fill in the survey data whenever.
Proposed implementation
The idea is to extend the form audit log to add location to the log if location-mode is set as parameters in the audit row of the XLSForm, we will choose the most accurate point recorded in the age window.
- location-mode: no-power, low-power, balanced, high-accuracy as defined in LocationRequest
- location-interval (optional): the desired minimum interval in seconds that the location will be fetched
- location-age (optional): the time in seconds that will location will be valid
In the ideal case for location-interval=10 and location-age=60, 6 points will be collected and we choose the most accurate one to write the log. But location-interval is not guaranteed and so there may be more points or less points.
If location-interval and location-age are not set, defaults will be set by the application based on the mode. If either is set, the value will override the defaults.
Currently an audit.csv file has the following structure:
| event |
node |
start |
end |
| question |
/data/name |
1523403169208 |
1523403170733 |
Location will be recorded in three columns: latitude, longitude, accuracy in the audit log that is attached to Collect's submissions.
New structure of an audit.csv file:
| event |
node |
start |
end |
latitude |
longitude |
accuracy |
| question |
/data/name |
1523403169208 |
1523403169208 |
27.1080 |
11.19574 |
20 |
New columns will be added only if the audit row of the XLSForm contains background parameters otherwise they are not needed.
When you have an existing form with audit that did not have location enabled and you change that form to add location, three new columns will be added.
XForms specification
In the XForms spec audit is placed in the meta block under the orx namespace. It uses a binary data type. See getodk/xforms-spec#94
<orx:meta>
<orx:audit/>
</orx:meta>
<bind nodeset="/orx:meta/orx:audit" type="binary"/>
We will add the following bind attributes in the odk namespace to the specification. Both attributes are required to enable location audits and location-age must be greater than or equal to location-interval.
<bind nodeset="/orx:meta/orx:audit" type="binary"
odk:location-mode="balanced" odk:location-interval="10" odk:location-age="60" />We prepend "location-" to the tags to ensure that there are no future conflicts with mode, interval and age.
The tentative pyxform specification is as follows.
| type |
name |
parameters |
| audit |
audit |
location-mode=balanced location-age=60 |
Device behavior
When Collect opens the form, we will request location updates from the location provider every desired interval seconds. Location updates will be started in onCreate() method and paused when the app is in the background (onStop() method) to avoid battery draining.
At the time of the audit event (e.g., view question, form save etc.) occurs, Collect will check the cache for the location.
If a user disables/enables location or revokes/grants the permission after starting a form an appropriate event will be logged:
| event |
node |
start |
end |
latitude |
longitude |
accuracy |
| location disabled |
|
1523403169208 |
|
|
|
|
| location enabled |
|
1523403269301 |
|
|
|
|
| location permission revoked |
|
1523403469758 |
|
|
|
|
| location permission granted |
|
1523403669354 |
|
|
|
|
We will not exit a form if a user disables location or revokes the permission.
Data privacy issues
To ensure enumerators are aware that this sensitive data is being gathered...
On first launch of the form, we use a dialog to get consent.
- Paragraph 1: This form continuously collects your location in the background and includes it with the form data.
- Android >6
- Paragraph 2: Revoke Collect's location permissions to fill the form without any location data.
- Buttons: OK | Revoke location permissions
- Android <6
- Paragraph 2: Disable your location provider to fill the form without any location data.
- Buttons: OK | Disable location provider
- On OK, fire up the GPS
- On revoke/disable, go to the location permissions/provider screen
We use the above strategy because if we just ask a yes/no consent question and the user says no, we have no easy way of re-enabling. That is, a yes/no question takes what we expect to be an occasional disabling and turns it into a permanent disable. Using permissions or location providers solves that problem.
The caveat is that this not the easiest thing for users to do. Further, disabling location for the device means no other location apps will work. And revoking permissions means that any required location questions (e.g., geopoint) will not work.
On subsequent launches of the form, we use a snackbar (see image below) to show background location collection status.
- Paragraph 1: This form collects your location continuously and includes it with the form data.
- Paragraph 2: This form needs to continuously collect your location, but <reason why it can't be accessed>
- your location provider has been disabled
- your location permissions have been revoked
This will serve as a reminder to the enumerator that their location is tracked for that specific form. In the case where the enumerator is not the one to open a form for the first time, they will still see the snackbar and have an opportunity to exit the form or turn off location is required for safety or other reasons. Even though Android does show that location is being accessed, it's not clear by which app. The snackbar is clearly associated with Collect.
If location is enabled/disabled during data collection, then we show the snackbar on return to Collect. If this is hard to do, we will show the snackbar on return to Collect (so no need to check enabled/disabled).
Questions
- Is this sensible that we use the odk namespace for these new attribute given that that audit is under orx?
- Are the tradeoffs we make when a user doesn't want location collected acceptable?
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent