Graham, Mark’s comments make sense. Your quality test where you set the phone down in a fixed location and look at the results seems good also. If it can’t pass that test, nothing else will work. Best, Bill
William Prothero https://earthlearningsolutions.org > On May 6, 2020, at 7:52 AM, 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
