How to calculate mile or kilometre splits from a GPX file

The short answer

Work through the track points in order, adding up the distance between each consecutive pair until the running total crosses a full mile or kilometre. The timestamp at that crossing, minus the timestamp where the previous mile or kilometre was crossed, is that segment's split. Repeat for every full unit in the hike, and the shorter stretch left over at the end becomes its own final segment. Everything this needs — a coordinate and a timestamp on every point — is already in a standard GPX track. Nothing has to be recorded specially for splits to be possible afterwards.

What a split actually is

A split is the same calculation as overall pace — time divided by distance — run separately for each mile or kilometre instead of once for the whole hike. A walk with an overall pace of 15 minutes per kilometre might have gone through splits of 13, 14, 19 and 14 minutes per kilometre, with the slow one landing exactly where a climb, or a long stop to take a photo, happened to fall. The overall figure is the average of those four numbers, weighted by distance — accurate as a summary, but it cannot show which part of the hike was actually the slow one, because averaging is precisely the operation that throws that information away.

Why a GPX file can do this and a single pace figure cannot

A pace figure, or a CSV row with one pace column, is a result — the calculation has already happened and only the answer survived. A GPX track never stores a pace, or a split, at all. It stores the raw ingredients, in order: a latitude, a longitude and a timestamp for every point the whole way round. Splits are one of several things that list of points can be turned into afterwards, in much the same way elevation gain is a running total built by walking the same list and comparing each point's altitude to the one before it. Neither figure lives in the file as a number of its own — both are calculated fresh from the points, which is exactly why a summary export built for one row per hike cannot produce either one on its own.

Working through it, with real numbers

Say a recorded track starts at 10:00:00, crosses the 1 kilometre mark at 10:14:00, the 2 kilometre mark at 10:29:20, and the 3 kilometre mark at 10:47:35. Subtracting each crossing time from the one before it gives three splits: 14 minutes flat for the first kilometre, 15 minutes 20 seconds for the second, and 18 minutes 15 seconds for the third — a hike that got steadily slower, most likely because of a climb building through the second half rather than anything wrong with the recording. An overall pace for the same three kilometres works out to 47:35 ÷ 3 ≈ 15 minutes 51 seconds per kilometre: a single number that is honestly the average of those three, but says nothing about which kilometre was actually the hard one.

The one wrinkle: points rarely land exactly on the mark

A GPS receiver logs a point on a timer — roughly once every second or few seconds — not on a distance interval, so a running distance total almost never lands on exactly 1.000 km at the moment a point happens to be recorded. Getting a crossing time in practice means finding the two consecutive points that straddle the mark, one just under and one just over, and interpolating between their timestamps in proportion to where the mark sits between their two distances. A point at 0.996 km logged at 10:13:57, followed by one at 1.009 km logged at 10:14:10, puts the 1 km mark about four tenths of the way between them by distance, which lands the estimated crossing time around 10:14:02 — a short interpolation, not a guess, and close enough over the length of a whole kilometre that it barely moves the resulting split.

Doing this by hand versus letting something else do it

For a short walk of a few kilometres, working through this by hand, or in a spreadsheet, walking down a column of cumulative distance and time, is a few minutes of tedious but entirely mechanical work. For a long hike with dozens of kilometres and thousands of points, the same arithmetic is exactly the kind of repetitive task a script or a piece of GPX-analysis software is built to run through in a fraction of a second, using the same interpolation described above at every crossing rather than a person doing it by eye. Either way, the one thing the process actually needs is a file with a timestamp on every point — a plain summary total never had that information to begin with, so no amount of software or patience can extract splits from one.

What can make one split look slower without the pace actually changing

• A track left running through a break instead of paused folds that stationary time straight into whichever kilometre it happened to fall inside, making that one split look dramatically slower than the walking around it actually was.
• A short stretch of lost or noisy GPS signal can pad a segment's recorded distance slightly, or widen the time between two real crossings, without any change in how fast you were actually moving.
• A genuinely steep or technical stretch is the ordinary, uninteresting explanation most of the time — splits are built to reveal exactly this kind of real variation, not just recording artefacts.

Reading a slow split correctly usually means glancing at the route or the elevation profile for that stretch before assuming anything about the recording went wrong.

Where TrailCam fits in

TrailCam logs a timestamped point the whole time it is recording, and exports a route as a GPX 1.1 file — a single hike or the whole history at once — which is exactly the kind of file this entire process starts from. The app itself reports one pace figure per hike rather than a table of per-kilometre splits, so getting to splits means working through the exported points the way this guide describes, in a spreadsheet or a tool built for it. Export is part of the optional TrailCam Pro upgrade; the app itself is free to download.