Nike+ on the left and our sample app on the right
In the last three sessions, we added a background tracking engine + map drawing to our sample code.
Having a short run with the sample app makes you feel it already works like a normal running app as Runtastic.
But you might encounter some situation where your app doesn’t work correctly.
Especially when you are running ..
- under cloudy weather
- in an alley surrounded by tall buildings
- in a forrest or park with many trees
To make your app work more accurate as Nike+ under such situation, you need to make your app log “good locations only”.
In this blog post, I’m going to explain how to make various filters to log good locations only.
Logging accurate locations only helps the app not only draw beautiful path on the map, but also calculate accurate distance or speed from those locations.
In the current sample, we simply log new location to locationDataArray within didUpdateLocation callback.
First we replace this with a call to filterAndAddLocation() as below.
filterAndAddLocation() filters obtained locations, and log accurate locations only to locationDataArray**.**
There are three filters in this method.
Filtered by timestamp
There is a property called “timestamp” in CoreLocation object. This property holds the time when the phone’s GPS hardware obtains the location information.
As explained in Vol.4 of this blog series, obtaining GPS information is an asynchronous task. And how quickly a location information is obtained is affected by below factors.
- Location of GPS satellites — GPS satellites are not geostationary satellites, thus number of satellites and their location above the user change from time to time.
- Obstacles between GPS satellites and the user’s iPhone — Buildings, trees, cloud and etc.
- Locations of 3G/4G base stations — Type of GPS chip embedded in iPhone is Assisted GPS or A-GPS which uses assistance of 3G/4G base stations to calculate the user’s location. Accessibility to base stations affects the speed and accuracy of location information acquisition.
- Obstacles between 3G/4G base stations and the iPhone such as buildings.
When above condition is bad, the GPS hardware won’t get any location. You may have a experience of the Google Map not showing your location when you were in a building. It was because of such situation.
In this case, CoreLocation gives a cached location to the didUpdateLocation callback.
Cached location is a location which was obtained earlier when the above condition was good.
Cached location is not the user’s current location, thus showing it on the map makes your app look inaccurate.
To avoid logging and showing cached locations, we filter the location by timestamp.
We calculate elapsed time since this timestamp property by using timeIntervalSinceNow, and if the elapsed time is more than 10 seconds, filter the location out.
A user could run around 40 meters in 10 seconds. Without this filter, the user’s location will be shown 40 meters behind the actual location.
Filtered by horizontal accuracy
Next we check a property named horizontalAccuracy.
horizontalAccuracy is the value indicating which accuracy range (in meters) the location would be in. Say if the value is 20, the actual user’s position can be within a circle with the radius of 20 meters from the location value.
We first validate the horizontalAccuracy to be equal to or more than 0 meter.
Apple’s document says,
“A negative value indicates that the location’s latitude and longitude are invalid”
If horizontalAccuracy is negative value, the location information is invalid. We filter this location out.
If horizontalAccuracy is non negative value, we will further examine the value.
In this sample if horizontalAccuracy is more than 100 meters, we filter the location out (which means we log locations with their accuracy value less than 100 meters).
You may want to change this threshold from 100 based on your app’s purpose.
If your app is like Uber, less than 100 meters may be suitable. If you are making a running app and calculating the distance and pace based on location information, you may set it more strict like 50 meters or 30 meters.
Power of the filter
Below is a pair of tracking paths logged during two rounds of run in a park (with some trees) under a bit cloudy weather.
Left hand side is the one logged without the filter, and the right side is the one logged with the filter.
左がフィルターなし、右がフィルターあり
The left track (with no filter) has logged several inaccurate locations around the areas marked with blue circles. The right track doesn’t have inaccurate locations and the path looks smoother.
Better than Nike+
I tested the sample app with the filter and compared performance with Nike+.
I opened both the sample app and Nike+ in my iPhone and went out for a 2–3 km run.
In the areas marked with blues circles, our tracking algorithm showed better performance.
左がNike+、右が我々のアプリ
Later I ran on the street of Shibuya on the other day. The tracking paths from Nike+ and our sample app are below.
These two trials are not enough to be called as an experiment, but the filter I explained above seems to have made our app to perform the same or even better than Nike+.
Even better tracking engine
There is still some room to make this tracking engine even better.
If you run in a forest on a day of heavy rain with your iPhone in your backpack, you might see your app tracks nothing.
If you see such case, your filter might be too strict.
Last few steps to make the tracking engine greater is to make your filter adaptive to the environment.
I won’t go deeper in this but here is a couple of hints
- Knowing the condition from average horizontal accuracy
- Knowing the condition from temporal interval between location callbacks
- Knowing the weather
Take up the challenge, and make your engine even greater!
I’m running an app development studio in Tokyo called Goldrush Computing.
If you need any development force to empower your app with location tech magic, feel free to contact me any time.
[email protected]