# Garmin Distance Calculation

by Edward Sargisson.## Introduction

A common question from runners is whether Garmin devices calculate distance using elevation or not. Using elevation would use Pythagoras' Theorem to calculate the distance and would be longer than the sea level distance which ignores elevation. The distance along the hypotenuse is also called the slope distance. However, it is clear that Garmin devices do **not** calculate slope distance and here is how we know and the reason why.

## Slope distance

The first question is to calculate what kind of difference we might expect when we compare the slope distance with the sea level distance.

### Example data

For my sample data I'm going to use two points from the Knee Knacker course. This run is a 50km trail run which is known for its elevation and technical difficulty. The first part of the course is a climb up Black Mountain. Much of this climb is not runnable so it makes for a useful example of very steep segment. To be fair, part of the start of this segment is very runnable but most of it goes straight up.

My first point is the start point of the race. The second is the highest point in the race (a few metres below the summit of Black Mountain). These points are expressed as EWKT (Enhanced Well Known Text). The SRID means they are in WGS84 projection which is what GPS uses. The 3 figures are longitude, latitude and altitude.

Start Point: SRID=4326;POINT(-123.2582757 49.3607281 123.666748)

Black Mountain: SRID=4326;POINT(-123.21865 49.3913605 1169.5812988)

### Sea level distance

Using PostGIS (a spatial extension to the PostgreSQL database) I calculated the distance between the two points ignoring height. This calculation uses the spheroid so it respects the curved surface of the earth using the parameters of WGS84.

Spheroid distance - no height: 4459.49830020891 m

### Calculating slope distance with Pythagoras' Theorem

If we now assume that this distance is small enough that we can use a right-angled triangle then we have:

The question is: How much does the length of A differ from the length of C?

Point AC is at 123.666748m

Point BC is at 1169.5812988m

The length of B is 1169.5812988 - 123.666748 = 1 045.91455m (because we are assuming that line A is straight even though it is along the spheroid)

So, with a climb of 1000m over 4.5km we get a difference of 121.011m (2.7%)

## Investigating the Garmin device distance calculation

### Method

I used some sample data from Garmin Connect. I chose the 2010 Dirty Duo 25km route as recorded by my friend Ross Fleming. Garmin Connect reports this distance as 26.47km. This route has a lot of elevation gain and loss and is across rough terrain so will clearly show what is happening. I exported this data in the TCX format and imported it into the TrailHunger.com database. TrailHunger.com uses the PostGIS spatial extension so I have a set of well-tested distance functions to use.### Slope Distance for the route

PostGIS has a function called ST_Length_Spheroid. The documentation says that this method, "Calculates the 2D or 3D length of a linestring/multilinestring on an ellipsoid." An ellipsoid is a term for a geometric shape which approximates the shape of the Earth i.e. a sphere which is squashed at the top and bottom. In order to use this function we need to provide the parameters of the ellipsoid. There are many sets of values which are used by various countries and systems. GPS data uses an ellipsoid called WGS 84 so we'll use that.

The result is: 28472.5159057563 m. This is almost exactly 2km longer than the 26.47km that Garmin Connect reports.

### Sea Level Distance (2D Spheroid Distance)

PostGIS provides a function, ST_Force_2D, which removes the elevation from the data. We can then use the same ST_Length_Spheroid function above to calculate the distance.

The result is: 26683.4596549352 m. This is much closer to the result that Garmin Connect is reporting.

### Great Circle Distance

The ST_Length_Spheroid function uses Vincenty's algorithm to calculate distance. Vincenty's algorithm is the best known algorithm for this purpose because is uses the ellipsoid (instead of just using a sphere) and is more accurate than the Haversine method. We can see that PostGIS uses Vincenty's algorithm by examining the source code and comparing that with Vincenty's original paper. The next question is perhaps the Garmin devices are using the faster great circle method. After all, we're expecting a lot from a computer that runs in a watch. We can use the ST_Length function from PostGIS and specify that we want to use the sphere method.

The result is: 26648.9895884097 m. This is closer still to what Garmin Connect is reporting but is not close enough to match.

## Discussion and Conclusion

Garmin devices measure distance at sea level and ignore elevation. However, Garmin devices do not calculate distance using only the GPS fix points. Some other data must also be used.

Calculating slope distance from GPS data is an interesting but unreliable method. GPS devices have the greatest error when calculating elevation because it requires a signal from more satellites. This means that the recorded elevation varies more than the recorded position.

### Appendix: Queries Used

Slope Distance query: select st_length_spheroid(geometry, 'SPHEROID["WGS 84",6378137,298.257223563]') from per_route where id = 76;

Sea Level Distance query: select st_length_spheroid(st_force_2d(geometry), 'SPHEROID["WGS 84",6378137,298.257223563]') from per_route where id = 76;

Great Circle Distance query: select st_length(geometry, false) from per_route where id = 76;

Contact us at info - at - trailhunger.com