...
This article explains this function & how to use it, and also highlights a few pitfalls to watch out for.
The function may also be useful for getting smaller amounts of data onto a phone quickly - e.g. 30 mins of data for a quick test on an emulated device, or a device in Perfecto cloud.
Import Location Data onto the Mobile App
...
If you have not enabled feature Flags yet, enable Feature Flags
To do this, go to the About screen, and tap on the “PathCheck GPS” heading 10 times (if it’s not working, click a few more times, we have seen it take 12 or more clicks on some devices - e.g. in Perfecto Cloud).
Under More / Feature Flags enable “Import from Google”
(the import doesn’t really come from google, the naming is historical - I’d lie like to fix, but this is what it is for now)
Now on the More screen, press the “Import past locations” button
Scroll down and press “Import from URL”
Enter the URL of some JSON data (see below), for example
https://diarmidmackenzie.pythonanywhere.com/location-data?latitude=51.5&longitude=-0.144
Press the confirmation button on the keyboard (green check on Android, not sure on iOS), then press Add.
The locations will be added to your local location database.
Note that hashes (needed for Exposure Notification Detection) will only be included if the JSON data provided included hashes. The App does not generate these hashes itself.
...
Just add a “points” parameter (e.g. “&points=4032”) to specify the number of data points that you want.
Data points are generated exactly 5 minutes apart.
In terms of hashes generated for these data points, we have made a compromize because generating large numbers of hashes is (intentionally) expensive. WIth this in mind:
If you generate 287 data points or fewer (up to 1 day), the hashes generated are real. With current hash cost of 12, this takes ~60 seconds on our server.
If you generate 288 data points or more (>= 1 day), the hashes generated are fake random numbers. It’s srill worth including them as the mobile app will store them compare them with hashes etc. so we’ll get a realistic view of intersection calculation performance. But we won’t generate any real intersections.
[actually there is a further issue: the current App code (15/7) does not load the hashes into the DB but discards them, we are working on a fix]
Some enhancements I’m considering:
Make timestamps a bit more variable: 5 mins +/- a random amount. This will make the data more realistic.
Allow data to be created up to time X, where X may be in the past. This will avoid overlapping data points in the case where someone installed the app some hours before they added the fake location dataAdding hashes to the import so that the data can
be usedMore control over when hashes are real vs. fake (real hashes are needed for Exposure Notifications to actually trigger) - e.g. ability to make the most recent 100 hashes real, and the rest of the hashes fake.
More control over the shape of the data that is generated - right now it’s a slow random walk. We could make it more predictable, follow specific paths/shapes etc.
Requests on the above to Diarmid Mackenzie - I will also put the code into GitHub if others want to contribute (it’s a very simply fairly simple Python Flask server).
Pitfalls
...
There is no way to delete that data, other than explicitly deleting the app’s data (which will reset everything and require you to repeat onboarding), or a complet uninstall/reinstall of the app.
AFAIK there is no mechanism in the app to stop you overloading the database with far too many points, either from one upload with too many points, or from multiple uploads in sequence. If you put far more than 4000 data points in the app, it might start to behave oddly.
At the moment, Safe Places does not perform well with hundreds of location data points, and it is really really slow with 4,000 data points. This is reported as PLACES-492 - we understand the problem and are working on a fix, but until that fix is rolled out, you might want to keep data sets down to 1-2 days.
As per limitation above, the tool does not compute the correct hashes for the data points. So while it should offer realistic testing of exposure notification performance, none of these points will actually trigger an exposure notification (and so you’ll need a few real points for that purpose).
Getting 14d Data into Safe Places
For teh the same reasons that we want to test the GPS Mobile App with 14d data, we also want to test Safe Places with 14d data.Currently, the best technique we have for doing this is to load
There are two main ways of doing this:
Load 14d data into the Mobile App, using the techniques described above, and then share location data with Safe Places.
...
Upload 14d data set directly to Safe Places without using the Mobile App,
...
Further information
There are a number of improvements we could make to better support isolated testing of Safe Places - see Testability of Safe Places - PathCheck GPS Mobile App interactions for details.