Geo: Filter points by location provider (GPS, wifi, network)

(This item is moved here from the ODK Geo roadmap document.)

Currently, when using Google Maps, locations from any provider are used (GPS, wifi, etc.), but when using OSM as the basemap, only GPS locations are used.

We've been told it would be useful to be able to configure the geo widgets (by the user or in the form) so that only GPS locations are used, because non-GPS locations (wifi, mobile tower, etc.) are much less accurate.

Some discussion is needed here as to whether we want to just filter to GPS only, or also allow filtering to wifi only, and how to provide feedback to the user about the state of the filter and which provider is being used.

We'd like to hear about your use cases in which GPS-only collection is desired, or GPS-only is undesirable, or filtering by any other kind of location provider is desirable. Thanks!

I think we should standardize behavior between the two SDKs and I'm not sure why they aren't. @zestyping can you file an issue so we don't forget?

I think a parameter that requires GPS only would be a nice addition to all the geo widgets. I don't see much value in adding a parameter for Wi-Fi or cell towers.

All that said, all this might be a moot point, because Android seems to be moving to FusedProviders that instead need accuracy and power criteria and the OS sorts it out.

This is one reason why the location audit parameters require a priority (e.g., high-accuracy, low-power) instead of specifying the provider. It seems like we should do something similar here.

1 Like

Good idea! Filed as #2997.

After discussions with various users and research into the recommended way to get location on Android (fused provider), we are planning to no longer use raw sensors for geolocation. This means that the filtering described in this feature idea would no longer be relevant. Instead, every question type will use the fused location provider. We will be sharing a beta within the next week to give users a chance to try it out and give feedback.

This was the behavior in Collect for some time but it was reverted because of a Google bug that capped accuracy at 10m. Now that this bug has been fixed, we have confirmed with extensive manual verification that using the fused provider leads to faster location fixes and less noisy location which is closer to true location. We have reproduced this with a variety of devices with different Android levels and with different combinations of WiFi availability, WiFi sensor on, cell service availability, GPS availability and GPS sensor on. We got accuracy radius readings as good as 2.79m on a low-end device in an environment with GPS, WiFi, and cell service and could confirm that the location identified matched the real-world position.

The one case we haven't been able to try and which I know is of particular interest to @zestyping and @Ivangayton is when using an external high-accuracy GPS device. From everything I've read, it is my belief that if the GPS sensor reports very high accuracy readings, it will overtake all other sensors. I will specifically invite users to try this out in the beta announcement.

Unfortunately this depends a lot on the environment and the device. Particularly on inexpensive devices, the GPS sensors tend to produce very noisy location output. Additionally, as far as I understand it (e.g. from the sensor stack docs), handset manufacturers are responsible for combining sensor and Global Navigation Satellite System to provide Android with a "GPS reading" and this may not be consistent across manufacturers.

The Google fused location provider is closed-source so we can't know exactly what it does. However, Google has published various resources describing it. In particular, this talk from Google I/O '19 provides good insights. One of the issues with the fused provider in the past was dramatic jumps when GPS stopped being available in a rural area and the location of a cell tower was used. This talk describes how step detection and direction of movement are now used to avoid this. This article also describes some of the approaches planned for the fused provider moving forward.

From my recent experience studying this, I believe the fused provider will allow most users to get higher precision location readings with less lag and better accuracy radius readings. I no longer believe that using raw sensor data will be helpful for the typical user.

1 Like

We still have a fleet of 20 Lenovo Tab3 devices with one budget-restricted program who can't yet switch to the more expensive but more GPS accurate Samsung TabA 2019. The Tab3s suffer from the "10m" bug and get horrendous accuracy (10-20m, enough to show turtle nests outside of the turtle nesting beach). Keen to test accuracy improvements on those Tab3!

1 Like

It is strange but a colleague have problems since months with the accuracy (about kilometers) of its Blackview BV6000.
1.28 beta version make it work again...

1 Like

That's great to know, @mathieubossaert! I'm not surprised -- there are a lot of things that can go wrong with the raw GPS sensor.