Defer locations to max of one per second about locokit HOT 3 CLOSED

My thoughts on this:
Back in the day with Moves, I used this trick to make the Moves track more accurate. On long bus rides through the countryside for example, I'd have a long line without any detail with just Moves. If I was running a GPX-Recorder or Navigation app at the same time, the Moves track would be very detailed.
This came (and I'm assuming this) at now extra battery cost for Moves App.

I would appreciate if Arc wouldn't ditch any information that'd make the tracking more accurate.

from locokit.

@thoughtgap Yeah I've noticed a similar effect. Whichever app is requesting the highest location accuracy also benefits all the other apps. [Aside: Although it's not as symmetrical as you'd think - iOS seems to be doing more than just providing every app the best quality location data it has available].

I suspect the energy consumption problem will be a case of Arc/LocoKit getting much more location data than it needs.

If the locations are arriving at 1 Hz, that's ideal, and already more than enough for LocoKit. But if the locations start arriving at 2 Hz, then that's just a waste of energy as far as LocoKit is concerned. But LocoKit is still taking all those locations in, even if it doesn't need them. It's Kalman filtering them, updating the ActivityBrainSample (an internal mutable representation of a LocomotionSample), and all the rest.

So I think the thing to do will be to draw the line at 1 Hz, and either tell the CLLocationManager to defer locations beyond that, or just ignore them when they arrive (if the location deferral API doesn't play nice - I haven't tried it in a couple of years, so I can't remember the details).

I'll also probably experiment with restricting it back to 0.5 Hz (ie location updates only every 2 seconds), just for the fun of it, to see what happens. My hunch is it'll have no negative impact on the resulting data quality, and will result in lower energy consumption and longer battery life. But ... that's not the kind of change I'd want to ship without thorough testing 😉 So it'd just be a personal experiment, unless it proves to be super safe.

from locokit.

So the CLLocationManager "deferred locations" feature can't be used. It requires the desiredAccuracy setting to be set unnecessarily high (ie requesting kCLLocationAccuracyBest or kCLLocationAccuracyBestForNavigation).

Instead I've just made the LocomotionManager ignore incoming locations if they arrive too soon and aren't of higher accuracy than the previous.

from locokit.