Two problems here. One is that there’s this unresolved city which is Shanghai as you can see from the images, and I don’t know if it’s because it’s due to a flight from Shanghai to Los Angeles and the airport being the only place for this city.
Naother problem is that after switchiung to arc editor recently, I noticed that my location isn’t updated promptly whenever from stationary to motion, it takes about 1-3 minutes before I see my location updated on the map, and in that 1-3 minutes there doesn’t seem to be any location recorded as seen from the map that a straight line is drawn which isn’t the actual path that I take. This was not a problem in Arc Timeline.
Also I always kept the app running on background without you know removing it from the background process by swiping its tab, but I want to ask is that the standard way for it to run? Because if I do remove it from the background it doesn’t seem to be active anymore.
Hi @dyang886! Thanks for the feedback. I’ll try to work through the points in order.
There’s been another report of issues with the reverse geocode (matching location coordinates to cities and countries) in mainland China. Though my impression is that it’s a broader problem, not limited to mainland China. For example I’ve seen almost the exact same issue with a location around Bali airport in Indonesia.
The problem appears to be that the Apple reverse geocode service the app is using is … not always great. Apple’s maps database isn’t as good as Google’s. So what I’m going to do is add a fallback system, so that if the Apple lookup (which is free) fails to get usable data, the app will try Google Places instead (which is expensive). That should then get us all results filled in. Well, ideally it should. We’ll find out!
I think there’s several things going on here that can result in this happening, or contribute to it being worse and more noticeable.
One is a maths thing, inside the new, more advanced Kalman filter that Arc Editor uses. The new Kalman filter is significantly better than the old one used in Arc Timeline, which means much higher quality location data in our timelines - cleaner and more correct path lines, more detail in the paths lines, less noise and jump bad data. But also the new Kalman filter has a tuning weakness in the specific case of waking from sleep mode.
I won’t go into the full details of that - it’s boring maths stuff! But yeah, I can tune that and make that much better.
Another thing that can be contributing is if it’s a new place you haven’t been to before, or have only been to a few times. Sleep mode (in both Arc Editor and Arc Timeline) dynamically adjust their sleep cycle durations, based on predicted leaving time. If the maths (based on past data) says you’re unlikely to be leaving yet, it’ll go with longer sleep cycles, making it slower to notice when you do leave. If it’s a new place that the system doesn’t know much about yet, it might make the wrong call on sleep cycle durations.
There’s a couple more things that can go into this… but yeah I won’t bore you with all the technical details. Suffice to say: I’m on it! It should get better in future updates.
Yes, this is an absolute requirement for all real time location recording apps. If you swipe an app closed from the app switcher then it’s gone, it can’t record anything. Location data isn’t stored on the phone for apps to ask for later. They can only access location data at the moment it happens. So if the app is swiped closed it can’t record anything about any location data until the app is reopened.
Also as a general rule of thumb: don’t swipe apps closed! It will on average worsen your phone’s performance and also its battery life. It will do the complete opposite of what most people intuitively expect.
Why is it the opposite? Because when 99% of apps are in the background they are “suspended”, which means they’re frozen, can’t do anything, can’t do any processing, can’t use any battery. That makes 99% of background apps zero cost in terms of battery.
When a suspended app is brought back to the foreground again the process of unfreezing it / unsuspending is zero cost. It’s simply switched back on, and it returns to the state it was in pre-suspend immediately, with no harm to battery life.
If an app is instead swiped closed, then when you return to it later it has to go through the app’s full launch process. That launch process is not zero cost, it’s energy/battery expensive. It takes time (sometimes a bunch of seconds) and it eats battery.
So for 99% of apps it’s much better for them to be suspended than fully terminated (which is what happens if you swipe them closed). You want them to be suspended, not terminated.
So yeah, rule of thumb: Leave apps alone in the app switcher. Don’t swipe them closed unless you’re certain that that specific app is causing problems and needs to be terminated.