TrailCam

Guides

Why a GPX file doesn't show your pace

Open a GPX file in a text editor and you can search it end to end without finding the word "pace" anywhere. That is not a bug in whichever app produced the file — a GPX track point was never designed to hold a pace figure. It holds a position, a height and a time. Pace comes from doing arithmetic on those three things, and every app that reads the file does that arithmetic on its own.

The short answer

Pace isn't a field in a GPX track point, so it is never "in" the file to begin with. What is in the file, for each point along a route, is a latitude, a longitude, usually an elevation and a timestamp. Any app that opens the file — including the one that recorded it — calculates pace afterward, by measuring the distance and time between points. Two apps doing that calculation slightly differently is the whole reason the same GPX file can show two different pace numbers.

What a track point actually carries

The core of a GPX file is a series of <trkpt> elements, one per recorded point, each with a lat and lon attribute for position. Nested inside, most recording apps add an <ele> tag for elevation and a <time> tag for the timestamp. That is the standard set. There is no <pace> tag and no <speed> tag in the core GPX schema — the format was built to describe where and when you were, not how fast you were moving between any two of those points.

Some apps write extra data into a track point using GPX's extensions mechanism — a way of tucking vendor-specific fields, like speed, into a file without breaking the core format. An app that doesn't recognise a given extension just ignores it, which means a speed value written this way is not something you can rely on surviving a trip through a different app, or even being read at all.

So where does the pace on your screen come from

It is calculated, not stored

Whatever app shows you a pace figure — during a walk or afterward, looking at an old route — worked it out from the coordinates and timestamps of nearby points: distance covered, divided by time elapsed. That is true even for the app that originally recorded the route. The pace shown live while you walk and the pace calculated later from the saved GPX file are two separate calculations that happen to use the same underlying points.

Why the same file gives two different numbers elsewhere

Import the same GPX file into two different services and each one is free to calculate pace its own way: how much smoothing it applies to noisy points, how it decides a stretch counts as "moving" rather than stopped, how it handles two points that landed unusually close together. None of that is written into the file — it lives in the app doing the reading, so a mismatch between two pace numbers for the same route is not a sign that either file or app is wrong.

Where pace actually does live

If you want a pace number that travels with your data rather than getting recalculated every time, that is what a summary export is for. A CSV export normally includes a pace column alongside distance, duration and elevation gain, because a CSV row is a summary of a whole route rather than a point-by-point trace — there is room in it for a single settled number in a way there isn't in a GPX track point. GPX and CSV are complementary for exactly this reason: GPX preserves the route so anyone can recompute pace from it later, and CSV keeps the number itself so you don't have to.

Things that trip people up

  • A route imported into a new app shows a different average pace than the one recorded originally — expected, since the new app recalculated it from the raw points rather than importing a number that was never in the file.
  • A GPX file "loses" pace when converted to another format — nothing was lost, because pace was never carried by the GPX in the first place; it has to be recalculated after conversion too.
  • An app claims to preserve speed data from GPX extensions, but another app that reads the same file shows nothing — extensions are optional to support, so a speed value one app writes is not guaranteed to be read by the next one.
  • Average pace for a whole hike looks slower than the pace felt during any single stretch — that usually comes down to whether the calculation counts time spent stopped, not from anything about the GPX data itself.

Where TrailCam fits in

TrailCam records distance, moving time, pace and elevation gain for every route as it happens, so the pace you see is not something recalculated later from a bare track. A route exports as GPX 1.1 — the format that preserves the points themselves — or as a CSV summary that carries the pace figure alongside the rest of the numbers. Export is part of the optional TrailCam Pro upgrade; the app itself is free to download.

Questions

Does GPX support a pace or speed field at all?
Not in its core schema. A GPX track point has position, elevation and time. Speed can be added through GPX's extensions mechanism, but support for reading it back is not guaranteed across apps, so it isn't something to rely on.
Why does the same GPX file show a different average pace in two apps?
Because neither app is reading a stored pace value — both are calculating it from the coordinates and timestamps, and small differences in how each one handles stops and noisy points produce slightly different answers.
Is CSV a better format than GPX for keeping pace?
For the number itself, yes — a CSV summary keeps a settled pace figure per route. GPX is still worth keeping alongside it, because it preserves the underlying points that any pace figure, past or future, is calculated from.

Recording your own routes

TrailCam is an iPhone app that records your route with GPS, keeps video clips, photos and voice notes pinned to the spot where you took them, and exports the result as GPX 1.1 or CSV. It is free to download.

Download on the App Store