Convert TCX to KMZ

A TCX is unopenable for most people. It has an extension nobody recognises, it is XML rather than anything a double-click will render, and the software that reads it properly is the training platform the recipient may not use. Sending one to a club secretary or a race director produces a reply asking what it is.

A KMZ produces a globe with a line on it. That difference — between a file that has to be explained and a file that opens — is the whole reason for this conversion, and it is worth being clear that it is a presentation decision rather than a data one. Nothing about the route is improved. What changes is whether the person on the other end can see it without being talked through anything.

Measured on a 7,200-point session — two hours at one sample a second, carrying time and altitude — the TCX was about 2.2 MB, the intermediate KML about 258 KB, and the finished KMZ about 47 KB. That is roughly 315 bytes a trackpoint reduced to under seven.

Two unrelated effects are stacked and it is worth keeping them apart. The first drop, nearly nine to one, is the training file becoming a drawing: the verbose `<Position>` markup, the timestamps and the sensor elements all leave, and none of that is recoverable. The second, five and a half to one, is the deflate, and it is fully reversible. Only the second is compression, and describing the whole thing as compression would suggest the original is still in there somewhere.

Renaming the output to `.zip` and opening it reveals a single member called `doc.kml` at the root of the archive. That name and that position are what every KML reader looks for first, so the file opens without any fallback logic.

There is nothing else inside — no images folder, no icons, no second document, no manifest. Most KMZ files in circulation carry assets alongside the KML, which is what the format was designed for; this one is doing the narrower job of compressing a single document into a single filename. It also makes the archive trivially auditable: if you want to know exactly what your coach will see, extract that one file and read it.

Everything a training platform reads is absent. Heart rate, cadence, power, the running distance on each point, calories, the lap divisions and every per-lap average are dropped, because a Google Earth document has no element that could hold any of them. So there is no analysis to be done on the file, only a route to be looked at.

The timestamps go with them, which is the loss that catches people out. Google Earth's time slider — the control that replays a track — needs a gx:Track with parallel `<when>` values, and this conversion writes a plain LineString. If the person you are sending it to actually wants to study the session, send the TCX itself, or convert it to GPX, which keeps the clock and which most training software will import.

One placemark per activity, named after the sport — `Running`, `Biking` or `Other`, since a TCX activity has no name field and the platform title you know it by lives in a database rather than in the export. The line follows the terrain rather than cutting through it, because a tessellation flag is set on each LineString, and it is drawn with Google Earth's default appearance since no style is written.

There are no pins. A TCX has no waypoint concept, so nothing in the file becomes a marker, and the recipient sees a bare line in the sidebar. If a start, a summit or a meeting point needs highlighting, the practical route is to add the placemarks in Google Earth after opening the file and save it back — which takes a minute and produces a better briefing document than any converter could.

Trackpoints with no `<Position>` are dropped, and watches record them whenever the receiver has no sky: tunnels, underpasses, multi-storey car parks, deep street canyons. In the KMZ those stretches are absent, so the line runs straight from the last fix to the first one after the gap, sometimes across a river or through a hillside.

It looks like an error and it is not — the file never contained those positions, and no conversion can restore them. Worth a sentence in the covering email if the route has an obvious one, because the alternative is the recipient concluding the file is broken. An entirely indoor session has no fixes anywhere and produces no geometry at all, at which point the conversion says that no track or waypoints were found, which is the correct description.

Send the KMZ when the question is "which way did you go" and the recipient is not a training platform. Send the TCX when the question is about the session — pacing, effort, splits — and the recipient has software that reads it. Send both when you are not sure, since together they are still under three megabytes and the ambiguity costs more time than the bytes do.

The one combination worth avoiding is sending only the KMZ and treating it as an archive of the session. It is not one, and it cannot be converted back: the training data does not exist in the file and no tool can reconstruct it. Keep the TCX wherever you keep your records, and think of the KMZ the way you would think of a PDF exported from a document.

A KMZ cannot be edited in place. To rename the placemark, colour the line or trim a stray point, rename the file to `.zip`, extract the document, edit the XML, and rezip it with that document at the root of the archive rather than inside a folder. The root detail is the one people get wrong, and the symptom is a file that opens to an empty map in some readers and works fine in others.

If you expect more than one round of changes, keep a KML as the working copy and produce a KMZ each time you send one. That is the same discipline as keeping a source document and exporting from it, and it avoids the position where the only copy of a corrected route is inside an archive somebody else already has.

A TCX downloaded as a bulk export from a training platform can hold many activities in one document, and every one becomes its own placemark in the archive. They all take their name from the sport, so a month of riding lands in the recipient's sidebar as a column of entries all reading `Biking`, drawn on top of each other on the globe with nothing to say which is Tuesday and which is Sunday. Toggling them one at a time to find the right one is the only way through, and it is a poor thing to hand somebody.

Splitting before converting is the fix. Activity boundaries are unmissable in the XML — each `<Activity>` element opens with its own `<Id>` timestamp — so cutting the file into one session per document is mechanical, and converting them separately gives one archive per ride with a filename that says which. Where they genuinely belong together, the alternative is to edit the `<name>` of each placemark in the KML before it is zipped, which takes about as long and produces a sidebar somebody can actually read.

The TCX is parsed, the KML written and the archive zipped inside this browser tab. No request carries the file anywhere, which the network panel will show during a conversion, and the page works with the connection switched off once it has loaded.

The alternative most people reach for is a web converter or a file-compression site, which means a document holding your heart rate and your home address goes through a stranger's machine so that an email attachment would be smaller. You are going to send the result to somebody by design; that is one recipient you chose. Doing the conversion locally keeps it at one.