Has anyone experience of GPS on iPhone?
livfoss at mac.com
Fri May 8 05:27:26 EDT 2020
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.
> On 6 May 2020, at 18:24, Graham Samuel via use-livecode <use-livecode at 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.
>> On 6 May 2020, at 16:52, Mark Waddingham via use-livecode <use-livecode at 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:
>> 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 Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
>> LiveCode: Everyone can create apps
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the use-livecode