Just to conclude the tale: I have consulted the developers of one of my favourite apps that tells you how far you’ve walked or cycled (maybe long journeys as on sees on car satnavs are a different proposition, and I am not so interested in these for my own purposes). I am not revealing any secrets when I say that the lead guy reports that they have dedicated "tens of thousands of lines of code” to the issue. True, they cope with elevation, which I was planning to ignore, but nevertheless their ways of handling changes in accuracy include several things like reasonableness checks, so not even just simple curve-fitting.
In my particular circumstances and with my own limited skills I have simply decided to give up on that part of my app. A user can run another app simultaneously to mine to find out how far they’ve travelled - that’s easy. So, a wiser and a sadder man, I will try to finish what I started but with limited functionality. Thanks to everyone who chipped in with advice, facts etc. Graham > On 6 May 2020, at 18:24, Graham Samuel via use-livecode > <use-livecode@lists.runrev.com> wrote: > > Mark, thanks for that contribution. Looks like more maths is needed. I will > follow up on your approach, as mine really only works if all GPS readings are > nearly accurate. As I have seen accuracies (really inaccuracies!) as large as > 65 metres even after a settling-down period, a few of those will certainly > put the integral-style calculation way out. > > Really for this part of my app I need to emulate the work done in dozens of > trekking apps available in lots of countries. I have one sneaky idea, which > is to approach the developers of one of my favourite apps, since I have had > some contact with them on other matters, and just see if they might tell me > their approach - I can easily show that I am not a competitor! But that’s not > an approach I can rely on, of course! > > I will keep plugging away even though the initial motivation for my app > (local lockdown) is probably going away. Hard to give up now. > > Thanks everyone for their input. > > Graham > >> On 6 May 2020, at 16:52, Mark Waddingham via use-livecode >> <use-livecode@lists.runrev.com> wrote: >> >> On 2020-05-06 14:09, Graham Samuel via use-livecode wrote: >>> Bill, I think you are confirming that there is some mystery here. >>> There are a lot of apps that seem to get location, and measures >>> derived from location, almost completely right, whereas I am having >>> trouble doing so with what must be the same essential data. >>> How then to avoid either under- or over-estimating the trip distance? >>> Plenty of apps have done it but I just can’t see how, although I keep >>> tinkering with the parameters. Of course I can never forget that my >>> scripting might just be plain wrong, but so far my incremental method >>> hasn’t worked sufficiently well, in the sense that if run the app and >>> choose to walk in an exact straight line, I can compare a single >>> measure of distance from the starting point with my integral approach. >>> So far the result is not even close. As you say, intensive Internet >>> searches are called for. >> >> I'm pretty sure that the data you are getting is precisely what all other >> apps will get - we are just returning the location data as provided by >> CoreLocation. The difference will be the analysis which these apps are doing >> on the data to derive an accurate assessment of the route taken I'd imagine. >> Indeed, it could be they also take into account other senses (compass and >> accelerometer) to help - but I don't know that for sure. >> >> There are two functions which might help you with your endeavour: >> >> mobileSetLocationHistoryLimit >> mobileGetLocationHistory() >> >> The details are in the docs, but basically the engine can collect and keep a >> list of locations which you can collect periodically. >> >> I suspect the way to think about this is not to think about it as an >> incremental thing at all as any outliers will completely destroy the >> accuracy. Instead imagine it as a 'curve-fitting' exercise (piece-wise >> linear approximation is probably sufficient!) - i.e. taking sets of >> (slightly) overlapping samples and derive a 'best-guess' path which fits the >> data. >> >> It is likely that some cleaning of the data would be needed first to >> eliminate outliers also. e.g. You can compute speed needed to get between >> individual points, if any given point is outside of a reasonable range of >> 'current' speed with approximated acceleration/deceleration taken into >> account then it should be discarded. >> >> Doing a google search for "deriving a approximate path from gps data" turns >> up quite a lot of literature on the subject, so this is definitely something >> which has/is studied in depth... >> >> Warmest Regards, >> >> Mark. >> >> -- >> Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ >> LiveCode: Everyone can create apps >> >> _______________________________________________ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your subscription >> preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
