GPX route planning: turning a track into marshal points
A GPX file is the most underused document in race planning. Most organisers use it to publish a route map and nothing else, when it contains everything needed to place marshals, set shift times and tell each volunteer when runners will actually reach them. This is how to get that out of it.
7 min read
1. Get a clean track first
Export the route from your planning tool as a GPX track, not a route of waypoints, and check three things: it starts and ends where the race does, it follows the direction of travel, and it has no straight-line jumps where the tool snapped across a field. A dirty track produces wrong distances, and wrong distances produce wrong ETAs, which is worse than none.
2. Place points on the track, then read the distance off it
Drop each marshal position onto the track rather than typing a distance you estimated. The distance along the route to that point should be computed from the track itself. That number is what drives signage, split timing, aid station stocking and every ETA that follows.
3. Set two pace bands per race, not one
You need a front-runner pace and a sweeper pace — the fast and slow bounds of your field. Use last year's actual first and last finish times if you have them; otherwise take a realistic winning pace and your cut-off pace. Two numbers turn every distance marker into an arrival window.
4. Turn distance plus pace into a per-point window
For each point: first athlete expected = start time + (distance × fast pace); last athlete expected = start time + (distance × slow pace), plus your wave interval if you start in waves. Add a buffer of 10 minutes before the first and 20 after the last. That window is the shift, and it belongs on the brief.
5. Handle multi-lap and two-way sections explicitly
A lapped course means one position sees runners at several different distances. Record each pass separately with its own distance and its own arrival window, then combine them into one shift that spans the first arrival of pass one to the last of the final pass. For out-and-back sections, flag the point as two-way so the brief tells the marshal which way runners will be coming, and when both directions overlap.
6. Multi-distance events: one course, several clocks
Where a 10k, half and marathon share sections, each race has its own start time and its own pace bands, so a shared point has one window per race. The marshal needs the union of those windows and — critically — the instruction that differs between them, such as which distance turns and which continues.
7. Sanity-check the numbers against reality
Before publishing, check two points against last year's timing data. If your model says the last runner reaches 30km at 14:10 and the timing mats say 14:55, your slow pace is optimistic — and marshals will be sent home early or left waiting. Adjust the sweeper pace, not the individual points.
8. Let the tool do the arithmetic
None of this is difficult; it is just error-prone in a spreadsheet, and it all has to be redone whenever the route changes. mrshl imports the GPX, computes the distance to every point on it, and prints first- and last-runner ETAs on each marshal brief from your pace bands — recalculating when you move a pin.
The short version
- Start from a clean GPX track, in the direction of travel.
- Compute point distances from the track, never by estimate.
- Two pace bands — front-runner and sweeper — give arrival windows.
- Record each lap pass and flag two-way sections separately.
- Validate the model against last year's timing data.