A couple of days ago I talked about my experiences with a geolocation driver bug that was not presenting a heading to the Geolocation sensor, and how to account for this problem in your app by calculating the value yourself. Today, I want to talk about a very similar problem I have encountered with geolocation drivers: zero and NULL speeds. Speed, like heading, is a value you can calculate based on the device's position shifts and it's pretty easy to check to see if the driver is providing it correctly. If your position known and it's changing then your speed should be non-NULL and non-zero. Once again, math and trigonometry are our friends.
A couple of caveats
Before we get started, however, we should understand two technical details of global positioning systems, and how those should affect your decision process.
The first is that a stationary device will have some amount of positional jitter because of errors that creep in to the positioning system. A nice discussion of error sources is given in the Wikipedia article on GPS errors and I encourage you to read it if you are interested in the technical details, but in general they can be summarized as:
- atmospheric affects, which affect the speed of signals as they travel through the atmosphere
- clock errors, which impacts the accuracy of time measurements
- ephemeris errors, which lead to inaccurate satellite positiong information
- geometric dilution of precision, a multiplicative scalar for the overall position error that is based on satellite geometry
- multipath effects, such as when a reflected signal is received but the direct signal is not due to local obstructions
At the core of positioning systems is the ability to measure the length of time it takes for a signal sent from a satellite to reach the receiver, and where the signal originated from. The above error sources all impact the receiver's ability to accurately "know" these two pieces of information. As these effects fluctuate with time, a receiver-- particularly a consumer grade one-- will see fluctuations in its position with time even when standing still. What this means is, just because your position is changing that doesn't mean you are actually moving. Some GPS receivers actually rely on doppler shifts in the incoming signal to validate that the device is moving, and some will even use that to adjust or outright determine the estimated speed.
The second is that GPS receivers are presenting speeds to the geolocation driver as part of its NMEA output stream. When these values are calculated, when they are sent to the driver, and when the Location API sends them to your application can, in fact, be slightly different times. Fractions of a second matter when you are getting sample points roughly once a second, and the speeds you calculate may be off by as much as 10 to 15%.
To calculate a speed you need to know two pieces of information: the distance traveled between points, and the time delta. The location API will feed you Geoposition objects that contain a Geocoordinate object, and in each Geocoordinate object is your latitude, longitude, and a timestamp at which it was generated. Now all we need is the math.
As with determining heading, using the great circle formula in my blog "Calculating geographic distances in location-aware apps" to find the distance is overkill, and we can go to the Pythagorean Theorem for an equirectangular approximation:
d = r * √ (x² + y²)
x = Δλ cos( (Φ1 + Φ2) / 2)
y = ΔΦ
where r is the radius of the earth. We want our result in meters per second since that's what the Windows Runtime Location API uses, so:
Also, remember that our latitudes and longitudes, Φ and λ, need to be in radians.
Once we have a distance, we simply devide by Δt to get our speed. Again, to stay consistent with the Location API, your time difference should be in seconds.
Putting it all together
As with heading, we must first determine whether or not our driver is giving us a valid and sensible speed. Checking for NULL is, of course, pretty easy, but what if speed is non-zero? Remember that our calculated speed might vary as much as 15%, perhaps more, so we should not casually assume it's broken. Only when speed is off by a significant amount should we discard the Location API's values and substitute our own.
It's also important to note that we will be introducing a delay into the system when we calculate speeds ourselves. This is not wrong or necessarily bad, but it will give the user the impression that their reported speed lags behind actual changes in motion.
Using the same track points from the previous blog entry, I have calculated speeds and compared them to the values reported by the Location API. The track points are one second apart so we don't even need to do any division:
As you can see, our calculated speed is generally pretty close with the greatest variations, one as high as 15%, occuring during rapid acceleration and deceleration. This technique is quite practical.
And that's it. Heading and speed are two values that your app can calculate if it determines that they are not being provided by the driver/Location API, and these are useful techniques for ensuring your location-aware app still functions properly under those conditions.