Show accuracy for GPS mock location for external sensors

[seewhy]

Hi @seadowg
I found an alternative app called Bluetooth GNSS from ClearEvo.com (on the Play Store). It can handle NTRIP / RTK corrections (irrelevant for the old iBT-GPS), works as a mock-location provider and is open-source (no ads!). Works well with ODK Collect.

I noticed that using the placement-map option, the mapbox mapping is able to detect the accuracy of the external gps by putting the blue circle around the point (when I have 1m+ accuracy). So just need to get the accuracy data recorded in Collect... But being mindful of people having to cope with naughty enumerators making up their locations!

Thanks for your help.

[JulFrey]

@seadowg

I'd like to understand if there's a way that Collect could just grab the location data from the external device.

I am sorry, for the late reply, I was on vacation. Handling external GPS devices is device specific and might require a proper configuration of the device. Basically, it should be possible to parse NMEA, RINEX or UBX (raw GPS device) messages directly in ODK collect, but I guess the overhead is relatively large. Especially since the way the mobile device is getting the position data could vary between Bluetooth, USB or WiFi. It would also require additional configuration fields in the ODK collect settings to select the GPS device if there are multiple devices available (internal and external). Therefore, I think using third party apps with the additional options for RTK/NTRIP and mock providers is the fruitful route. Maybe it is helpful to take a look to RTKlib (http://www.rtklib.com/) to get an idea how complicated all those things are.
There are two things that need to be solved in my opinion: (1) the accuracy of the external gps needs to be considered when placing points within the precision limit in the collect app and (2) that it is detectable that a mock location provider was used in the data (aggregate / central). I think it would be enough to simply take the precision from the mock provider for the point placement in collect and multiply it with -1 prior saving as @seewhy suggested.

[seadowg]

@JulFrey

Basically, it should be possible to parse NMEA, RINEX or UBX (raw GPS device) messages directly in ODK collect, but I guess the overhead is relatively large.

I haven't had a proper chance to look into this, but I imagine you're right that Collect would have to interface with the devices directly. I had hoped there might be a generalized way to work with external GPS in the Android OS (like with microphones) but that hope is pretty weak.

@JulFrey

There are two things that need to be solved in my opinion: (1) the accuracy of the external gps needs to be considered when placing points within the precision limit in the collect app and (2) that it is detectable that a mock location provider was used in the data (aggregate / central).

Agreed. I'm going to have a play with the device that @seewhy and then come back with a potential direction.

[seadowg]

@JulFrey @seewhy I just wanted to double-check anything to make sure I'm not making any dodgy assumptions here. To set up Collect to use an external GPS device (in the current or older versions of the app), you need to:

1. Download an app that can provide a mock location (Bluetooth GPS is an example, Emlid recommend Lefebure NTRIP Client for their devices)
2. Enable developer options on the phone
3. Enable the downloaded app as the "Mock location app" Android's developer options
4. Pair the phone with the external GPS device and set it up in the app

Does it sound like I've gone through the same steps you/your enumerators do?

[JulFrey]

Yes, this is exactly how I did this, besides the fact that I used an different app (https://play.google.com/store/apps/details?id=de.pilablu.gpsconnector&hl=en_US&gl=US) for the mock lacation.

[seewhy]

Apologies for the lack of response - I've been out doing remote fieldwork near Assynt (no signal for a week - blissful!) - mock vacation!.

The work-flow you describe is how I did it - and from this you can see that it is very much a deliberate choice, rather than accidental to end up with mock location as a source, so should be easily verified if anyone is concerned whether their enumerators use external GPS... I suspect in a few cases it would need some support to set up?

Thanks.

[seadowg]

I've spent a bit of time playing around with the Bluetooth GPS device (that @seewhy very kindly sent to me) as a location provider when using Collect. As discussed here, that involves using the "Mock Location App" developer option in Android - I've also verified that this feature still works on later versions of Android (including Android 12). Of course, enabling this feature will cause Collect to ignore the accuracy reported by the external device and default the accuracy for points recorded to 0. This was intended to prevent any shenanigans around faking locations when filling out forms.

Here are a few options that come to mind (some of which have already been mentioned) of how we can re-enable collecting accuracy for enumerators using external GPS devices with Collect:

1. Stop setting mock location accuracies to 0 - simplest thing to do but would reintroduce the problems some projects were experiencing with enumerators faking locations.
2. Annotating the location data in the filled form to flag the mock location - would allow us to preserve the accuracy for mock locations, but I believe anything we do here could cause problems for parsing submissions for analysis and would disrupt anyone already using "0" to detect fake locations.
3. Make mock location accuracy negative (5.64 becomes -5.64) - seems less risky for parsing than the above option but still causes disruption for fake location detection.
4. Add Collect setting to enable negative accuracy - allows us to fix this for external devices without disrupting existing projects but does mean maintaining a Collect setting (potentially long term).
5. Introduce a parameter for "geo" questions that describes how to deal with mock locations - allows mock locations to be enabled by projects but would require changes to more of the ODK ecosystem (and to forms being used in the field).
6. Allow external GPS devices to interact directly with Collect - would be ideal but requires building and maintaining integrations with several communication protocols as well as UI to configure devices.

After discussion with the team, it seems like option 5 is the favourite. Option 3 was also considered but there were worries around the risks presented to existing data analysis pipelines by introducing negative accuracy (and to projects already using 0 to catch mock locations).

I propose we introduce an XLSForm parameter for geo questions (geopoint, geotrace and geoshape):

type	name	label	parameters
geopoint	location	Location	allow-mock=true

When the allow-mock parameter is true, the client should allow “mock” locations. In Collect, this will mean that locations from Android’s mock providers will use the reported accuracy. The default for allow-mock will be false so this behaviour will be “opt-in” and by default, “mock” locations will still have an accuracy of 0.

A nice advantage of this is that this “filtering” of mock locations will be a more explicit feature of ODK as it will be the documented behaviour when allow-mock is false.

How does all this sound @seewhy @JulFrey?

[JulFrey]

This sounds like my prefered sollution. I would only be carefull with the name. allow-mock sounds like false would disable the possibility to use mock location providers compleatly. Therefore it should be something like allow-mock-precission. Thanks a lot for taking care about this.

[seewhy]

Hi @seadowg
Thanks for your work on this.
From my perspective option 5 would work, although I think that would mean re-deploying all existing forms so that I can allow external GPS providers to be used. Not a problem as I have a relatively small number (<20) of 'live' or 'dormant' forms.

My concern would be (if I had shenanigans going on) how to differentiate between 'real' external GPS and mock-location (I think @JulFrey was making that point in his response) with option 5 - it sounds like this 'opens' mock-location feature, but doesn't flag that a mock-location is being used?

An advantage of a negative value for accuracy (option 3) is that it allows the 'administrator' to spot questionable data (currently I am guessing that any zero-value dataset is flagged manually or by script, which should be pretty simple to adapt), and differentiates that from manual data (genuinely zero-value) or internal GPS data. Still not sure it's the 'best' solution, but it gives the nuance and means that administrators could use an 'if -ve multiply by -1' script once they have assessed the veracity of the data (could that even be introduced as a new feature of Central in the data validation process?)

Another option (um, number 7?) would be to use the audit log (is that always automatically recorded?) so that if Android detects a mock-location provider, it triggers a field/ variable within the audit log for that form, but records all mock or internal GPS locations with their accuracy and leaves manual locations as 0. That would be an 'easy' flag, and not affect the data collected. Administrators concerned about false data could look for that flag in the audit - which should be as simple as the current 'look for zero', but still gives the nuance of differentiating manual locations (assuming maps-placement appearance is in play). The audit log would not work for manual transfer of data (i.e. via Briefcase on a PC with a cable!) but then you'd be likely to have an idea whether that device had external GPS capabilities set up...

Both of these options have zero / low impact on already deployed forms, I think, making either backwards compatible. They do require notification to anyone relying on 0 to catch the naughty enumerators, so are not without 'cost', but it looks like option 5 isn't 'free' either...

However, we need to check it works for those who are concerned about abuse of mock-location providers, so should probably involve them in the decision-making process (to avoid the pendulum swinging away from their comfort zone). Quick shout out to @Lama , @caneeraj, @arcunha and the redoubtable @Xiphware in case they have any further thoughts. Seems like the issues were raised in one way or another, now I look back at the 'cause' of the zero-accuracy setting. Not wishing to be critical of that discussion, it appears to have looked at solving their immediate problem without picking up on the current consequences - so I am mindful of finding something that works for everyone (including you lovely people at ODK!).

Well that's thruppence of my tuppence (or 3 of my 2 cents) worth on this topic! Hope it helps...

[seadowg]

@JulFrey

allow-mock sounds like false would disable the possibility to use mock location providers completely.

Good point. How about allow-mock-accuracy to make it clearer?

@seewhy

My concern would be (if I had shenanigans going on) how to differentiate between 'real' external GPS and mock-location (I think @JulFrey was making that point in his response) with option 5 - it sounds like this 'opens' mock-location feature, but doesn't flag that a mock-location is being used?

As far as I understand, we haven't really heard a need for both detecting mock locations and using external devices/mock locations legitimately. The assumption I have in my head is that programmes/projects that need to use external devices are not concerned about locations being faked/mocked - this could, of course, be incorrect.

Another option (um, number 7?) would be to use the audit log (is that always automatically recorded?) so that if Android detects a mock-location provider

I personally like the idea of this being added down the line! It feels like a simpler way to deal with detecting mocks for projects that might also want to enable their accuracy (the case that would destroy my assumption above) than needing to flag the mock value using the value itself.

[JulFrey]

If you put the effort into this question to solve this problem using an option in the form, I would try to solve it compleatly for the future. I agree that the default should stay the same. I would add "mock-accurancy" as a field and the add the options "false" (default), "true" and "force". The last option would set the precission to a defined unrealistic value to avoid the accidential use of internal gps sensors in cases when a higher precission is needed. I would prefer something like 9999 as a precission value to make sure the user recognizes that something is wrong. True would just handle internal and mock-gps providers the same way.

[BORNLOVE_NTIKHA]

Hello @seewhy @JulFrey et al.

I had the same issue still looking for solution for it. Here are some thoughts that came in my mind though am looking on how I can implement it

1.External GPS configured to collect information on it is own, to do some calculation on it is own and what it can share to ODK is only a print out of the final results based on desired accuracy being reached. Like you have configured your Dual frequency GPS to retrieve a location and send the report after accuracy being reached let say 5cm and once attained that accuracy, the print out of the coordinate to be sent to ODK for records to your GPS format of interest (This might need some programming skills to enable logging of the data from the Mobile App that can log those information then parse those logged data to send only required information as programmed) Python can be used to enable Logging if mobile App does not allows, also can be used to parse the data to extract the desired those required one also to link with ODK for print our to where you are looking for ODK to display those data. Any thoughts!

[seewhy]

Hi @BORNLOVE_NTIKHA
My thoughts on this suggestion are that it sounds more like an 'intermediary' app that you are needing, to log GNSS data streams and calculate data on demand when requested by ODK Collect. Way beyond my competence! However, something highlighted by @seadowg raises a caution here - you'd need to be able to read data from an unknown range of GNSS devices (so possibly varying standards / language formats), which could limit the practicality of creating a solution that can be used widely.

I suggested in an earlier post a simple way of doing something that starts you on the road to averaged positions - use a geotrace to record a number of points, then process the results to calculate the desired answer. It's probably way more complicated, but if you record the geotrace for a set period (e.g. 2 minutes, recording a point every 10 seconds), you could then adapt the process suggested by @Xiphware in this post: ODK geoshape/geotrace/geopoint to KML to extract the coordinates and calculate an average (and presumably a standard deviation to contribute to your accuracy) which you could then use within your form - take note of the cautions he includes at the bottom of the post! Or process the geotrace field once you've downloaded the instance.

I'm still learning the ropes with my high accuracy GNSS receiver, but one salutary lesson is that the log files are huge. I'm not sure how practical it is store them or even access them from ODK. And as with all data, I am mindful of not getting hung up on accuracy at the expense of meaning - it does matter that I have accuracy of 1m or less for some work (rather than 3-6m which is sufficient in many of my projects) but 5cm accuracy would give a false sense of quality (and probably isn't repeatable anyway, without a tripod, for example, which I never carry in the mountains!). It's a similar argument to people worrying about how many 'significant figures' to present when the underlying data is coarse.

Apologies if that sounds disrespectful of your idea or needs, I'm just a boring pragmatist!

[seadowg]

@JulFrey

If you put the effort into this question to solve this problem using an option in the form, I would try to solve it compleatly for the future. I agree that the default should stay the same. I would add "mock-accurancy" as a field and the add the options "false" (default), "true" and "force".

Implementing and maintaining extra cases brings extra cost, so right now we'll just focus on the problem we understand and allow configuring a form so that it behaves as before in Collect (as in my proposed changes). We'll go with a more specific parameter name, as you suggested.

I'll post an update when we have a beta release of Collect ready to test!

[JulFrey]

OK, thanks for putting the effort in it. I am locking foreward for the beta release.

[LN]

This is now ready to try out in the v2021.3 beta.

You will need to upgrade to Central v1.3.2 to convert forms with the allow-mock-accuracy parameter. Alternately, you can use https://getodk.org/xlsform/

[mathieubossaert]

Hi @LN and the team.
Just in time to test with success -) the 2021.3 beta and the "mock-location accuracy usage" new parameter.
@Remy_CLEMENT and I followed a course this week by Julien Ancelin about the open GNSS RTK Centipede network he initiate and this morning we can test the v2021.3 beta with success, using a DIY RTK Rover behind a Lefebure NTRIP Client
Here are the screenshots of the taken geopoint and pictures of the the rover.

One (out of topic) learn is that with such a DIY material, without using the RTK correction, we got better than 50cm accuracy And 1 cm with the RTK activated
More information about this (great) open and reproducible project on the https://docs.centipede.fr

[yanokwa]

allow-mock-accuracy is now available in ODK Collect v2021.3.

[seewhy]

Well done everyone! I have tested it (I know, you've already done that) and can now use forms where external GNSS measurement accuracy can be included. Perfectly timed as I have some fieldwork to do next week where sub-metre accuracy is important (GCPs for a drone survey!)

Thanks especially to Callum @seadowg for implementing the solution.