Collect: Switch all location capture to FusedLocationProvider

[lognaturel]

• [x] Implement changes
• [ ] Explore and document how users can force GPS-only results
• [ ] Understand and document implications for external high-precision GPS sensors
• [ ] Document implications for accuracy and location data availability for user-facing docs

FusedLocationProvider is the location provider recommended by Google. It's supposed to balance accuracy, resource usage, etc.

Collect used to use it but in Feb 2018, it started capping accuracy at 10m (https://github.com/opendatakit/collect/issues/2008). This turned out to be an Android bug which is now fixed. However, accuracy is still capped at 3m.

It would probably make sense for the 3m issue to be addressed before switching back to using it.

Regardless, there are some higher-level questions about whether it's the right way to go. It's supposed to provide better battery management but that's only if less accuracy is acceptable. It may make sense to continue only using the GPS since accuracy is almost always important. That said, there are certain environments (urban) where other location sources may be more accurate. Users could force using the GPS by turning other providers off at the Android level, I think, but that may be harder to use.

This may be a conversation more appropriate for the forum. I wanted to at least file the issue so the content and history is not forgotten but feel free to close and start a thread elsewhere or comment here.

[boscacci]

@opendatakit-bot claim

As an urban user I don't see why collect doesn't use the fused location whenever it can. 3m is pretty good. I'm not getting any location at all when I'm indoors and can't see GPS satellites. Don't want to step on any toes but also want to try my hand at android development for the first time. Is this a good first issue?

[getodk-bot]

Hello @boscacci!

You have attempted to claim an issue without the labels "help wanted", "good first issue". It seems like you are new to Open Data Kit, so we suggest working on a good first issue issue first. After doing one quick win, then try a help wanted issue. We also recommend reading README.md and CONTRIBUTING.md before getting started.

To claim this issue anyway, comment on this issue again with the command @opendatakit-bot claim --force.

[boscacci]

@opendatakit-bot claim --force

[getodk-bot]

Welcome to Open Data Kit, @boscacci! We just sent you an invite to collaborate on this repository at https://github.com/opendatakit/collect/invitations. Please accept this invite in order to claim this issue and begin a fun and rewarding experience contributing to Open Data Kit!

Here are some tips to get you off to a good start:

• Please read the README.md and CONTRIBUTING.md in this repo. Those two documents have much of what you need to get started.
• Join the ODK developer Slack to get help, chat about this issue, and meet the other developers.
• Sign up and introduce yourself on the ODK community forum to meet the broader ODK community.

See you on the other side (that is, the pull request side)!

[getodk-bot]

Hello @lognaturel, you have been unassigned from this issue because you have not updated this issue or any referenced pull requests for over 15 days.

You can reclaim this issue or claim any other issue by commenting @opendatakit-bot claim on that issue.

Thanks for your contributions, and hope to see you again soon!

[boscacci]

@opendatakit-bot unclaim

On Mon, Jan 14, 2019 at 6:41 AM Open Data Kit [e-mail]
wrote:

Hello @boscacci https://github.com/boscacci, you claimed this issue to
work on it, but this issue and any referenced pull requests haven't been
updated for 10 days. Are you still working on this issue?

If so, please update this issue by leaving a comment on this issue to let
me know that you're still working on it. Otherwise, I'll automatically
remove you from this issue in 5 days.

If you've decided to work on something else, simply comment @opendatakit-bot
unclaim so that someone else can claim it and continue from where you
left off.

Thank you for your valuable contributions to Open Data Kit!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/opendatakit/collect/issues/2717#issuecomment-453977529,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALyPDiibEQJlWc4XN7e4UshN2G6clsYeks5vDGz-gaJpZM4YI69J
.

--
Robert Boscacci
​@cinemarob1​
650.759.1367

[lognaturel]

(Copying some notes from https://github.com/opendatakit/collect/pull/2793#issuecomment-526445492 to make the status clearer)

Fundamentally, I don't yet understand the tradeoffs well enough to make a decision on whether this is beneficial for the majority of users. I do think things are currently in a really confusing state, though (#2997), and that we should try to make a thoughtful decision on how Collect accesses location consistently across location question types and basemap options.

Some things I think we should have an understanding of before flipping the switch:

• what happens in environments where only GPS is available (no wifi or cell)? Is only GPS used? Is the same accuracy reported as if the GPS provider were used directly? I don't think this is actually documented and the Fused provider is a total black box so this might require experimentation. I think an exercise such as https://forum.opendatakit.org/t/why-can-t-i-get-as-accurate-gps-position-with-odk-collect-as-i-can-get-with-other-apps/21741 might be helpful.
• how Android settings affect the Fused provider. Specifically, is it actually possible to configure GPS-only behavior if desired and how can we best document this for users.

[lognaturel]

The table below shows my current understanding of the likely impact of switching to the fused provider across the board.

Current: GPS only with fallback to network if GPS is explicitly off

Scenario | Current | Fused only | Improvement?
-- | -- | -- | --
Collecting location in rural areas with no wifi | Reportedly takes a while to get lock | Likely similar behavior with perhaps some improvement if cell towers are available | ?
Collecting location in dense urban areas | GPS rarely works; GPS provider needs to be explicitly turned off in Android settings to use network | Works if any location source is available | Better
Collecting location in suburban areas with wifi (forum example) | Seemingly works well | Would probably get a reading more quickly | Possibly better
Collecting location or testing/demoing indoors (GitHub example) | GPS needs to be explicitly turned off in Android settings | Works if any location source is available | Better
Analyzing location data | Reading came from GPS if GPS provider enabled or network if not | Reading is always a composite from provider sources | Slightly worse? Folks in places that only have access to GPS or network have high certainty of where the reading came from.
Collecting location with high-accuracy chipset | Can get very high accuracies guaranteed to be straight from chipset | Reported accuracy is capped at 3m (why?!) | Worse

My concern comes from the fact that I've heard several users over the years say that they want to know that their location readings come from an actual GPS chip (@ivangayton, maybe?). It occurs to me that this is only likely to be more accurate if the GPS chip is high quality (= expensive). I'm guessing that those users have their Android location settings set to device-only. Perhaps using Fused always but falling back to raw GPS in that case covers all user needs. That's what I'm inclined to do at the moment.

(Note, according to this post, Fused won't work when Android location settings are set to device-only, anyway, so the fallback is required.)

CC @zestyping

[zestyping]

Tagging @ivangayton — could you weigh in on @lognaturel's table above?

[mmarciniak90]

Tests executed with a scenario:

• open view of the sky,
• lots of wifi in the area
• no SIM

As a test result, time and accuracy are presented.
Tests executed on two devices: Samsung S7 with Android 7.0 and Huawei with Android 5.1.
ODK Collect v1.25.1 was used during tests.

Tests were executed of three forms:

• All widgets,
• setlocation-action-with-repeats.xml.txt,
• setlocation-action-value-changed2.xml.txt

The location was reset between each submission.
During filling the form with a repeat section, the location was not reset for each repeat
For the form with a repeat section, I waited 20 sec between repeats

---

Results for Samsung S7 (Android 7.0)

|Geopoint with no appearance|One background geopoint |Repeats with background geopoints|
|---|---|---|
|- 20s, no location data| - 20s, no location data| - 20s, no location data|
|- 20s, no location data|- 20s, no location data |- |
|- 20s, no location data|- 20s, no location data| - |
|- 39s, accuracy 6m|- 40s, no location data | - |
|- 22s, accuracy 48m| - 40s, no location data|- |
|- 25s, accuracy 32m| - 40s, no location data| -|
|second try| | |
| | - ~20s, accuracy 28.3m| - ~20s, accuracy 15.7m, accuracy 13.4m, accuracy 12.8m|
| | - ~20s, accuracy 12.3m| - ~20s, accuracy 8m, accuracy 11.1m, accuracy13.7m|
| | - ~20s, accuracy 24.6m|- ~20s, accuracy 14.2m, accuracy 12.6m, accuracy 12.9m|

---

Results for Huawei (Android 5.1)

|Geopoint with no appearance|One background geopoint |Repeats with background geopoints|
|---|---|---|
|- 20s, no location data| - 20s, no location data| - 20s, no location data|
|- 20s, no location data|- 20s, no location data |- 40s, no location data|
|- 20s, no location data|- 20s, no location data| - |
|- 43s, accuracy 22m|
|- 1m10s, accuracy 24m|
|- 1m12s, accuracy 28m|
|second try| | |
| - | 1min, accuracy 18m| 20s, accuracy 500m, accuracy 500m, accuracy 500m|
|-| 1min, accuracy 17.5m|20s, accuracy 899m, accuracy 899m, accuracy 899m|
|-| 30s, accuracy 1000m|20s, accuracy 899m, accuracy 500m, accuracy 300m|
|-| 20s, accuracy 500m| |

[lognaturel]

Thanks for doing some experimentation @mmarciniak90. Could you please describe what the rows represent? Are they each submissions that the location was reset between? What was done between first try and second try? Do the dashes mean you didn't try a certain case?

The background geopoint should stop trying after 20s so waiting for longer should have no impact. When you say e.g. 1min in the "One background geopoint" column, what does that mean? What happened between the rows that say "1min, accuracy 17.5m" and "30s, accuracy 1000m" in the One background geopoint column for the Huawei device? It seems very surprising to me that the accuracy radius would increase by so much.

What is your qualitative summary after this experiment? That is, do you feel like you can say anything about how the geopoint with no appearance behaves as opposed to the background geopoint? Or not really?

[mmarciniak90]

Could you please describe what the rows represent? Are they each submissions that the location was reset between?

One cell is one test. Between tests, the location was reset.

What was done between first try and second try?

I came back to the office and after a while, I went again to the same place outside the building (because of cold weather)

Do the dashes mean you didn't try a certain case?

Yes, I did not fill each form the same number of times. I added dashes to empty cells.

The background geopoint should stop trying after 20s so waiting for longer should have no impact.

Oh, sorry. I didn't know that. I waited longer hoping to get better result but it was just luck.

When you say e.g. 1min in the "One background geopoint" column, what does that mean?

I filled the setlocation-action-value-changed2.xml form and I waited one minute on question with background geopoint.

What happened between the rows that say "1min, accuracy 17.5m" and "30s, accuracy 1000m"

The location was reset in the device between them but I did not change my real location.

What is your qualitative summary after this experiment?

It's hard to find conclusions from the received results. If you agree with me, I prefer to execute eg. two more tries. The results are not clear. They are quite extreme - the location wasn't found at all or achieved a quite good accuracy for Samsung S7.

[lognaturel]

I think doing another round would be helpful. Can you please let a standard amount of time pass after the reset? I’m thinking something like 4 mins. And for geopoint please only wait 20s to match the background behavior.

[mmarciniak90]

Tests executed with a scenario:

• open view of the sky,
• lots of wifi in the area
• no SIM
• ODK Collect v1.25.1
• filled 5 submissions for each form

Steps:

1. Reset the location
2. Wait 4 minutes
3. Fill submission - wait 20 seconds on a question with background location

Results for Samsung S7 (Android 7.0)

| |One background geopoint |Repeats with background geopoints |
|--- |--- |---|
|1.|accuracy 17.8m|accuracy 6.0m, accuracy 6.1m, accuracy 9.2m|
|2.|accuracy 22.5m|accuracy 7.2m, accuracy 9.3m, accuracy 13.3m|
|3.|accuracy 22.9m|accuracy 6.0m, accuracy 7.1m, accuracy 8.5m|
|4.|accuracy 18.5m|accuracy 8.2m, accuracy 6.3m, accuracy 6.3m|
|5.|accuracy 22.1m|accuracy 22.5m, accuracy 16.5m, accuracy 18.2m|

Results for Huawei (Android 5.1)

| |One background geopoint | Repeats with background geopoints |
|--- |--- |---|
|1.|no location data|no location data|
|2.|no location data|no location data|
|3.|no location data|no location data|
|4.|no location data|no location data|
|5.|no location data|no location data|

[lognaturel]

Thanks, @mmarciniak90. Looking at this, I conclude that the Samsung device is a higher-end device than the Huawei device. I guess 4 mins after a reset is just not good enough for that Huawei to get lock.

For the Samsung data, is the first column really one background geopoint? It's not geopoint with no appearance? Geopoint with no appearance is the one with the raw gps provider.

[mmarciniak90]

I conclude that the Samsung device is a higher-end device than the Huawei device. I guess 4 mins after a reset is just not good enough for that Huawei to get lock.

Definitely, Huawei is not a high-quality device. We notice problems with it during regression testing, with the smoothness of device work, speed of action, etc.

For the Samsung data, is the first column really one background geopoint? It's not geopoint with no appearance? Geopoint with no appearance is the one with the raw gps provider.

This time I did not check All widgets form, so I did not test Geopoint with no appearance widget. I focused only on background geopoints. Is it cause a big miss of data? If yes, it's not a problem to update these results.

[mmarciniak90]

New results of test execution following this scenario:

• open view of the sky,
• lots of wifi in the area
• no SIM
• ODK Collect v1.25.1
• filled 5 submissions for each form

Steps:

1. Reset the location
2. Wait 4 minutes
3. Fill Geopoint widget with no appearance from All widgets form - 20 seconds
4. Save form and exit
5. Reset the location
6. Wait 4 minutes
7. Fill question with background location from setlocation-action-value-changed2.xml form - 20 seconds

Results for Samsung S7 (Android 7.0)

| |Geopoint with no appearance|One background geopoint|
|---|---|---|
|1.|accuracy 32.0m|accuracy 20.0m|
|2.|no location data|accuracy 16.5m|
|3.|no location data|accuracy 12.7m|
|4.|accuracy 16m|accuracy 14.6m|
|5.|no location data|accuracy 27.6m|

Results for Sony Z3 (Android 6.0)

| |Geopoint with no appearance|One background geopoint|
|---|---|---|
|1.|no location data|accuracy 34.7m|
|2.|no location data|accuracy 29.4m|
|3.|no location data|accuracy 40.8m|
|4.|no location data|accuracy 30.8m|
|5.|no location data|accuracy 32.7m|

@lognaturel these results of comparing geopoint with no appearance and background geopoint allow to make a thesis that background geopoint works better.
I can retest this case to check that similar results will be achieved.
Let me know if you see that something need improving

[lognaturel]

Thank you, @mmarciniak90. I do think that's conclusive for areas with wifi access so there's no need for more experimentation.