Case Studies
There are situations when GPS altitude measurements give very inaccurate results. This page shows three different scenarios recorded by my Samsung i9300 phone and motivates the purpose for the altitude filtering and smoothing algorithms supported by pressure data. All altitudes on the plots below are give relative to the WGS84 ellipsoid.
The script for generating this example is included in the scripts/case-forest.py file.
The first scenario is a recording of my 6km run through a pine forest. The phone was placed in an armband on my left arm. The recorded path has a turnaround point at about 3.11km and I was traversing exactly the same path when going forth and back. The path was almost perfectly flat with a small hill near the turnaround point.
The plot below shows the measured altitude above mean sea level (MSL) as given by the GPS sensor. The dark line is an altitude as measured going forth to the turnaround point and the bright line as measured going back on the exactly same path:
The bright line is plotted in reverse so that ideally those two lines should overlap exactly with a discrepancy of an order of 10cm (resulting from the upward and downward motion of a runner). Clearly this is far from this goal and difference is about 30m in a worst case. Furthermore, the path does not reflect the human experienced altitude changes at all. Trying to improve this results by GPS measurements alone one can compare this with a SRTM elevation data which is shown on the plot below as dark (forth) and bright (back) orange lines.
The SRTM data is obtained from the space-based mission by radar measurements in a microwave range. Altitude values were obtained by interpolation of GPS latitude and longitude measurements on a 30m SRTM data grid. There is some improvement, the altitude variation is now quite small. However as in the previous case this plot does not reflect an experienced altitude changes well. Large altitude changes visible at the beginning of the plot were not experienced and there is a shift on the distance axis between them. This shift is caused by the horizontal GPS measurement error not shown here which was about 2m near the turnaround point but almost 25m between the beginning and the end of this recording. This 25m horizontal difference gives the observed vertical error as SRTM data points are interpolated at different places so they sample different altitudes.
Finally, the plot below presents the results of AltitudeRateSmoother algorithm as red (forth) and green (back) lines. The discrepancy between them is largest at the beginning and the end and is about 2m which is much better results than GPS and SRTM values. It is important that this path reflects an overall human experience, i.e. almost flat terrain with a small hill at the end. Generally, the quality of this filter which combines GPS and pressure measurement is much better than the GPS data or SRTM data alone.
It is insightful to compare the variance of the filtered altitude for different filtering algorithms:
The AltitudeRateSmoother does not require time to converge to the low variance values since it is a forward-backward algorithm which works in two directions, i.e. at each point in time it uses both past and future points to estimate the best altitude value. The main disadvantage is that it cannot be used for real-time filtering. The AltitudeRateFilter and AltitudeFilter are variants of Kalman filters which can be used as a real-time filters. From the above plots it is evident that they require substantial convergence time, i.e. AltitudeRateFilter reaches a steady variance after 2km and AltitudeFilter after about 3km. All three filters estimate mean sea level pressure value. The plot below shows a difference of that estimate between these filters. Again, AltitudeRateSmoother gives the most stable results but in this case there is a very small difference between the remaining filters:
The script for generating this example is included in the scripts/case-milos.py file.
The second scenario is a recording taken on a bike trip through the Milos Island in Greece. The day of the recording was very sunny and the Island has very little trees and almost no tall vegetation. The trip was mostly through the back country terrain or through the small cities with medium-size buildings. The terrain was not flat and the recording contains a altitude difference of about 250m. Phone was placed in a backpack and had very good sky visibility. The plot below shows a comparison of raw GPS measurements, SRTM data interpolation and the altitude filtered by AltitudeRateSmoother:
In this case GPS measurements matches the filtered altitude well. There is only one large discrepancy of about 15m at about 12.5km. Generally this case is quite good for GPS altitude measurements, i.e., the hills were not very steep and in most cases the GPS antenna was directed straight up. On the other hand this case is very bad for SRTM data. It is especially visible near the peak at about 10.5km where the height difference is of the order of 50m. For this scenario there is an observable effect of GPS measurements delay. The pressure-corrected altitude follows the terrain changes almost instantly which is visible on the plot by a slight shift of the red line (filtered) relative to the dark one (GPS). GPS altitude measurements have quite large lag.
The results for all three filters on the plot below shows a substantial difference between the altitude filters and the altitude smoother. This is most likely an effect of the filter convergence and arbitrarily adjusted noise magnitudes.
The internal mean sea level pressure estimates shows some variation between the altitude filers and the altitude smoother.
The script for generating this example is included in the scripts/case-repeat.py file.
It is worthwhile to compare many recordings taken along the same path but at different times and weather conditions. The plot below presents such a comparison of nine recordings taken along exactly the same path. The green-shaded area is a forest area, the white region before the forest is a relatively open-spaced area and the white region behind the forest is a residential area with a small houses. The phone was placed in a backpack during a bike ride. This plot shows GPS altitude measurements for this path. There is a definitive trace of altitude change but generally this data is quite noisy with altitude variations reaching 20m.
Results of the application of AltitudeRateFilter are presented below for sixteen recordings (which include the previous nine). Qualitatively this plot is much cleaner and many minor altitude variations can be observed with a certain confidence. However there is a striking shift between different recordings, i.e. there is a constant offset between different recordings and this offset reaches magnitude of 10m. Unfortunately this effect is hard to overcome as is most likely a direct result of GPS signal propagation errors.
After shifting every recording up or down so that the altitude mean values are fixed on the common value then those sixteen paths converge very accurately to a single altitude trace as shown below. The orange line is an interpolated altitude from the SRTM data. It is interesting to note how accurately this altitude plot converges to the filtered values outside the forest area. However, inside the forest area the SRTM altitude is larger which is most likely an effect of tall trees.
Results presented here clearly shows that altitude estimation using a fusion of GPS and pressure measurements greatly improves the quality of altitude calculation. There are many drawbacks not covered in this document (see Filtering Algorithms) but generally the use of presented algorithms is justified, especially for recreational activities characterized by relatively low speed, low dynamics and altitude range limited to Earth's troposphere.
Three is one more issue, i.e., the quality of a GPS and GPS antenna. The results above have been recorded by relatively high quality and new phone (Samsung Galaxy S3) which has quite good GPS set. Recently my phone GPS antenna started to fail. When I have made a recording over the path from the previous section then it had more than 100m altitude error for a period of over 2 minutes as measured by GPS. Instead of that, the final result matches the results from the previous sections almost exactly and this error has almost no visible influence on the filtered altitude.