The Case of the Zero-Kilometre Course Points

TL;DR: Garmin Connect silently drops every course point to 0 km when a route is longer than 200 miles (321.9 km). Export as FIT, or split the route into sub-200-mile legs, to avoid it.

A handful of riders told us the same odd thing: they would export a route with points of interest from PitStopper, import it into Garmin Connect, and every course point would show up at 0 km from the start. Not missing - they were on the map, in exactly the right place - but every single one claimed to be at the very beginning of the ride.

Stranger still:

• Some files worked and some did not. The same export process, different routes, different results.
• Even Garmin's own files failed. Add course points to a course inside Garmin Connect, export it to GPX, re-import it, and they too came back at 0 km.

That last point is what made this interesting. If Garmin could not even read its own exports back correctly, the problem was not obviously "PitStopper writes bad files". Something deeper was going on. So we did what we always do when a system is misbehaving in a way we do not understand: we stopped guessing and started measuring.

This was not our first run-in with Garmin Connect quietly mangling waypoints. Only a few weeks ago we chased down a different complaint - POIs that did not show up at all after import - and traced it to Garmin dropping any waypoint more than about 40 metres from the route line. We wrote that one up in Why Garmin Connect deletes your distant waypoints, and it turned out to be ours to fix (PitStopper now snaps waypoints onto the track before export). This time the symptom was different - the points were all present, just all sitting at zero.

So we tried something different. We handed the whole puzzle to Claude Code - Anthropic's agentic coding tool - and set it a challenge: work out why these course points import at zero. We told it to build test files, import each one into Garmin Connect, read back exactly what Garmin computed, and narrow in on the cause. This is what it did.

How we tested it

Garmin Connect builds a "course" from an uploaded file and computes a distance-from-start for each course point. We wrote a stack of small GPX files, each one identical except for one deliberate change, fed them through Garmin Connect's course importer, and read back the distance it calculated for each point. Change one thing, measure, repeat. Roughly twenty files in all.

To make the results unambiguous, most test files were the same shape: a straight track with waypoints placed at known positions - say 2.5, 5.0 and 7.5 km along a 10 km route. A correct import shows 2.5 / 5.0 / 7.5. The bug shows 0.0 / 0.0 / 0.0.

The first wrong guess: timestamps

Our first theory was timing. Garmin's native course format (TCX) gives every course point a timestamp and matches it to the track that way. GPX waypoints have no timestamp, so maybe Garmin could not place them and gave up.

It was a tidy theory. It was also wrong. A plain GPX file with no timestamps at all, waypoints sitting exactly on the route, imported perfectly: 2.51 / 5.01 / 7.52 km. Garmin computes distance from the geometry of the track, not from time. Timestamps are irrelevant.

So we kept eliminating suspects. None of these made any difference to the distance Garmin computed:

• The <type> of the point (even odd values like WATER or AID STATION were accepted).
• The descriptive fields - name, comment, description, links, symbols.
• Whether the path was stored as a GPX <trk> (track) or <rte> (route).
• The number of waypoints - we threw 80 at it and all 80 came back correct.
• Track detail - even points sitting 500 m from the nearest track vertex, on a sparsely-sampled line, snapped on correctly.

One genuine rule did surface along the way, and it is worth repeating even though it has its own post already: Garmin silently drops any waypoint more than about 40 metres from the route line. We pinned the threshold between 40 m (kept) and 42 m (dropped). But that produces missing points, not points stuck at 0 km - a different symptom. The points our users were seeing were definitely there, just all at zero.

We even found a bonus quirk: if a GPX contains more than one track segment, Garmin only uses the first one and ignores the rest - so a route split into segments gets quietly truncated. Useful to know, but still not our zero.

After all that, every well-formed file we could think of imported correctly. We could not reproduce the bug. Which usually means the real trigger is hiding in a real file.

The real file

So we asked for one of the actual routes that failed, and imported it. There it was at last:

Look closely. The course total distance is correct - 322.66 km, top left. But every course point in the list reads 0.00 km. This is exactly what our users described: right place, zero distance.

Digging into what Garmin returned, the giveaway was not in the waypoints at all. It was the track. Garmin had parsed all 6,071 track points and all their coordinates, but the distance value for every one of them was empty. The entire distance profile of the route had failed to compute. And if the track has no distances, then every course point that snaps onto it inherits a distance of zero. All of them. At once.

So the question stopped being "what is wrong with the waypoints" and became "why did Garmin refuse to measure this track?"

Bisecting to the number

This route was 322 km long. Our synthetic tests had topped out around 116 km, and those worked. So we tested length directly: clean straight tracks, nothing fancy, just longer and longer, watching for the moment the distance profile collapsed.

• 150 km - fine.
• 200 km - fine.
• 250 km - fine.
• 300 km - fine.
• 322 km - every distance null. Every course point zero.

It broke between 300 and 322 km, so we closed in. The number it converged on is suspiciously round:

The cliff edge is exactly 200 miles (321.87 km). A course of 200.00 miles imports perfectly. Add 0.01 of a mile - about 16 metres - and Garmin silently abandons the entire distance calculation, pinning every course point to the start.

The Salisbury route that started all this? 322 km. 200.1 miles. It missed the limit by about 150 metres.

The smallest possible reproduction

You do not need a 6,000-point route to see this. Here is the whole thing in nine lines - a straight line of three track points with a single waypoint at the middle:

<?xml version="1.0" encoding="UTF-8"?>
<gpx version="1.1" creator="garmin-200mi-demo" xmlns="http://www.topografix.com/GPX/1/1">
  <wpt lat="51.5" lon="2.333953"><name>Middle</name></wpt>
  <trk><trkseg>
    <trkpt lat="51.5" lon="0"></trkpt>
    <trkpt lat="51.5" lon="2.333953"></trkpt>
    <trkpt lat="51.5" lon="4.667907"></trkpt>
  </trkseg></trk>
</gpx>

That file is 201 miles long, and the "Middle" waypoint imports at 0.00 km. Now shorten the line to 199 miles by trimming the longitudes - nothing else changes - and the very same waypoint reads correctly:

<?xml version="1.0" encoding="UTF-8"?>
<gpx version="1.1" creator="garmin-200mi-demo" xmlns="http://www.topografix.com/GPX/1/1">
  <wpt lat="51.5" lon="2.31073"><name>Middle</name></wpt>
  <trk><trkseg>
    <trkpt lat="51.5" lon="0"></trkpt>
    <trkpt lat="51.5" lon="2.31073"></trkpt>
    <trkpt lat="51.5" lon="4.62146"></trkpt>
  </trkseg></trk>
</gpx>

The only difference between the two files is those longitude values. Here are both, right at the 200-mile boundary.

At 200.01 miles, Garmin labels the start and finish but leaves the imported "Middle" waypoint stranded at 0.00 km:

At 199.99 miles - the same file, 0.02 of a mile shorter - the identical waypoint is correctly placed at 160.93 km:

Notice that Garmin computes the Course Start and Course Finish distances correctly even on the broken course. It is specifically the imported waypoint that loses its distance - because the underlying track distance profile was never built.

What is striking is that this limit does not appear to be written down anywhere. There are forum threads and Reddit posts about course points importing at "0 km" going back years, full of guesses about file formats and timestamps - but we could not find a single one that names a 200-mile limit. As far as we can tell, this is the first time the actual cause has been pinned down.

Why "some files work and some don't"

Because the only thing that matters is whether the route is over 200 miles. A 322 km route with a hundred genuinely useful POIs comes in at zero across the board; trim it to 318 km and every one of them snaps back to its correct distance. Same waypoints, same file, same everything - only the length differs.

And the limit is silent. Garmin shows no warning and no error - it just quietly zeroes everything, leaving you to discover on the ride that none of your stops have distances.

The fix: export as FIT, not GPX

Here is the useful part. This limit is specifically about Garmin computing the distance profile from raw GPS positions. A FIT file is different: it carries the distance baked into every track point and every course point, so Garmin reads those numbers straight out of the file instead of recalculating them. The 200-mile wall never comes into play.

We tested it the same way as everything else - we took the exact same 201-mile course that zeroes out as GPX and built it as FIT instead. The course point imported with its correct distance:

This is exactly why PitStopper offers a FIT export and recommends it for Garmin devices: it sidesteps not only this 200-mile limit but several of Garmin's other GPX quirks at the same time. So if your route is over 200 miles, export it as FIT and your course points keep their distances. (If you specifically need GPX, the only other option is to split the route into legs under 200 miles.)

Every Garmin GPX waypoint gotcha, in one table

Chasing this bug meant ruling out a lot of others, and along the way we mapped out the various ways Garmin Connect mishandles GPX waypoints. Here is the full set in one place:

The good news is that PitStopper already handles two of these for you automatically: it snaps exported waypoints onto the track so they clear the ~40 m rule, and it writes a single continuous track segment. The 200-mile limit is the one to keep in mind - export as FIT to sidestep it, or split into sub-200-mile legs if you need GPX.

Is there a limit on how many POIs you can import?

One limit we went looking for and did not find is a cap on how many course points Garmin Connect will import. We gave a 199-mile course a thousand waypoints and it took every one, each with the correct distance. (Push past roughly 1,200 and the import simply times out rather than refusing.) The real ceiling is your device, not Connect: Garmin notes that "Edge cycling computers typically support 200 course points, while most watches support 50", and the exact figure depends on the model. So Connect can happily import 300 POIs that your watch then quietly trims to 50 when you sync.

What PitStopper does about it

Four things, in order of importance:

1. Offer a FIT export, and recommend it for Garmin. FIT embeds the distances directly, so it dodges the 200-mile limit entirely - and most of Garmin's other GPX quirks too. It is the safest way to get a PitStopper route onto a Garmin device.
2. Keep waypoints close to the route. We snap exported waypoints to within a safe margin of the track so Garmin does not discard them at that ~40 m threshold.
3. Single, continuous track. We keep the exported track as one segment so Garmin does not truncate it.
4. Warn on long GPX routes. If you are exporting GPX for a route approaching or over 200 miles (321.9 km), that needs a heads-up: use FIT instead, or split it into legs under 200 miles (321.9 km), because beyond that line Garmin drops every course-point distance to zero.

There is a certain satisfaction in chasing a bug that looks like it must be your fault, only to find a clean, hard limit sitting quietly inside someone else's software with no error message attached. Twenty test files to find one number. But now we know exactly where the edge is - and we can keep your rides on the right side of it.