Just a little more info for those that are interested. 

In general, it is extremely frustrating having to recreate a solution to a 
problem which has clearly been solved already many times. I can list several 
iOS apps which I use personally that appear to give reasonably accurate 
measures of how far someone has walked, run or cycled. Yet I still have not 
cracked the problem of inaccuracy which essentially causes all the trouble. 
Still trying, obviously.

I did come across an interesting document, an MSc thesis by Benjamin Bennett, a 
graduate student at the University of Oregon, written in 2018, entitled 
"Accurate Distance Calculation Using GPS While Performing Low Speed Activity “. 


Bennett used Android devices, using of course GPS coords, including speed. His 
preoccupations with walking and cycling were very relevant. He himself found 
that the raw GPS point-to-point calculation was pretty good, but I am having a 
really good look at his other methods. His use of speed is interesting: in 
general the speed data gave terrible results, except that it was a very 
accurate way of assessing that the user had stopped moving! This is needed 
because if you simple keep the phone stationary and measure successive GPS 
readings, the GPS inaccuracies cause variations which falsely add to the 
distance calculation. So it would be good to include “idling” detection, which 
he did.

[BTW, you can get the speed from the GPS in iOS in LC via mobileSensorReading, 
although it’s only mentioned in a footnote in the LC Dictionary. It’s an array 
element with the expected key “speed”. Minor update to the Dictionary needed.]

Sorry if all this seems tedious. Despite the frustrations, I still find it 


PS Kevin Willett did answer me, but he wasn’t very forthcoming about exactly 
how he filters out inaccuracies. Of course he was under no obligation to do so!

> On 4 Nov 2020, at 23:57, Graham Samuel <livf...@mac.com> wrote:
> Thanks Alan and Bob - I was beginning to think I was alone on this one…
> Yes, I do look at horizontal accuracy. I found out the following using my 
> iPhone XS.
> 1. Horizontal accuracy tends to be rather poor for the first 10 to 20 
> readings after activation, typically 65 metres. In context, a test walking 
> round my garden, which is about 110 x 60 meters, can quite often be woefully 
> inaccurate at the beginning.
> 2. Even when has settled down it is still  quite variable, but tends to 
> settle to an average less than 10 metres after a time.
> 3. Occasionally it throws colossal anomalies, like 5000 metres, with a 
> corresponding crazy waypoint taking someone on foot right out of the park.
> Of course I can catch the really big ones and ignore them, especially as they 
> are infrequent (maybe two or three in an hour’s walk); but on my tests, the 
> issue is the points that are a bit out, which can be fairly subtle - I mean 
> if you draw them on a map, they are obvious to the human eye, but detecting 
> them is quite difficult. For those, Bob’s idea is a good one, though of 
> course it works best after the trip has been going for while. Anyway, thanks, 
> I'm planning to use it. I agree seconds is the way to go - especially if the 
> app doesn’t know the intended speed (it might be walking, cycling or driving 
> for example). You can tell the user what you’re doing (some apps do this) but 
> I prefer not to ask the user to make that choice.
> I just bought a little app from the App Store, GPSOdometer by Kevin Willett. 
> This does more or less what I want my app to do (it’s cosmetically quite 
> different), and it offers a “Filter Level” setting, which effectively allows 
> the user to decide how much horizontal (in)accuracy to accept. The level 
> varies between 0.05 and 2.00, where a higher number means a larger tolerance 
> of inaccuracies. I’ve written to Kevin to ask for a little more detail - of 
> course he doesn’t have to reply, but I hope he does.
> I will come back to the list to say how I got on. You never know, this may 
> help others eventually.
> Graham
> PS The only test data I have been able to find for the XCode Simulator is a 
> bike ride in California which runs along giving a succession of GPS . It is 
> quite useful, but naturally it doesn’t involve anomalies.
>> On 3 Nov 2020, at 23:55, Bob Sneidar via use-livecode 
>> <use-livecode@lists.runrev.com <mailto:use-livecode@lists.runrev.com>> wrote:
>> Seems to me if you are tracking linear movement, you need to average the 
>> trending values, say the last 5 or 10 reads, against a time base, and reject 
>> the ones outside an acceptable tolerance. You may reject some good data here 
>> and there, but something grossly outside tolerance should be pretty easy to 
>> grok.
>> Sounds easy, huh? :-) But it really is. For a car moving at 60mph, obviously 
>> the trend is going to be greater than a person walking, and slower than a 
>> small airplane. For an alien spacecraft traveling at insane speeds and 
>> making wild maneuvers, I’m afraid you are on your own. The tolerance can be 
>> a percentage of the average of the last x reads or the last x seconds. 
>> Seconds makes more sense to me since if you drop 2 or 3 reads it will skew 
>> the averages significantly. That is likely how Google Maps does it.
>> Bob S
>> On Nov 3, 2020, at 2:39 PM, Alan Stenhouse via use-livecode 
>> <use-livecode@lists.runrev.com 
>> <mailto:use-livecode@lists.runrev.com><mailto:use-livecode@lists.runrev.com 
>> <mailto:use-livecode@lists.runrev.com>>> wrote:
>> Hi Graham
>> Are you checking the horizontal accuracy of each reading? (It's part of the 
>> array of data with your lat-longs, as well as speed, etc - though not on 
>> every phone).
>> If not, try that and see if the anomalous readings are hugely out. From my 
>> experience, that's normally the case. If so, the easiest thing is to drop 
>> them in the short term, unless you get too many and then you may need to be 
>> a bit fancier. If you do, would love to hear the solution that you come up 
>> with.
>> HTH, cheers
>> Alan
>> On 4 Nov 2020, at 3:30 am, Graham Samuel <livf...@mac.com 
>> <mailto:livf...@mac.com>> wrote:
>> From: Graham Samuel <livf...@mac.com <mailto:livf...@mac.com>>
>> To: How to use LiveCode <use-livecode@lists.runrev.com 
>> <mailto:use-livecode@lists.runrev.com>>
>> Subject: Ideas on iOS GPS tracking needed
>> Message-ID: <6c855814-1850-4975-b185-1731efcd6...@mac.com 
>> <mailto:6c855814-1850-4975-b185-1731efcd6...@mac.com>>
>> Content-Type: text/plain;    charset=utf-8
>> Sorry this is a bit long.
>> For a long time I?ve been tinkering with an app that uses the GPS on iPhones 
>> to show how far ?as the crow flies? the user is from some base point, which 
>> is set before the journey starts. It?s intended for walkers and cyclists, 
>> and I was using a beta version in the first French lockdown, which forbade 
>> one walking more than 1km from one?s house. I put the completion of this 
>> aside, but now we?re in the second French lockdown and it looks worth 
>> finishing - but I have some issues which I believe are not just down to my 
>> bad coding (though of course that?s more than possible), and I wonder if 
>> anyone else has thought about this stuff.
>> The basic idea is extremely simple, as you can imagine, and it wasn?t hard 
>> to code. The app keeps working out the point-to-point distance from the base 
>> and tests it against the permitted limit. If the limit is exceeded, it 
>> sounds an alarm. If the user goes back within the limit, the alarm stops. 
>> Everything else is just cosmetic, really.
>> The issue I have is that in every journey of say 40 minutes to an hour, the 
>> iPhone appears to generate a few ?bad? GPS readings. When I say bad, I mean 
>> way beyond the published accuracy of the GPS (which varies up to about 70m). 
>> Sometimes the GPS wants to tell me that I?ve walked half a kilometer in 
>> three seconds!
>> I have analysed a lot of data (.gpx files) from other apps for walkers, 
>> drivers and cyclists and I don?t see such glaring anomalies; and using such 
>> apps on my main test phone (an iPhone X), I don?t see these strange readings 
>> affecting the data.
>> Assuming this isn?t just a stupid coding error on my part (OK, a risky 
>> assumption), I need to find a solution, either by increasing the accuracy of 
>> the readings, or by finding the anomalies as they occur and eliminating 
>> them. I know no way of doing the first, and although I have ideas for the 
>> second (check apparent speed, for example), none seems foolproof. As the app 
>> works in real time, a retroactive curve-fitting solution is no good for me, 
>> even if my maths was up to coding it (Kalman filter, anyone?).
>> Has anyone tried anything like this, and if so, did you find any anomalies 
>> in the data, and how did you cope with them?
>> I?d be grateful for any ideas.
>> Graham

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to