Convert KML to TCX

Open the KML in a text editor and search for the string `when`. If it is there, the file holds a gx:Track with real timestamps and this conversion will produce a sensible activity. If it is not — and for anything drawn by hand it will not be — the file is a shape with no clock, and the TCX built from it will be a workout that claims to have happened at midnight on 1 January 1970 and to have taken no time at all.

That is not a bug to be worked around; it is what the source contains. TCX is a record of a training session, and a session is defined by when it started and how long it lasted before it is defined by where it went. A line drawn on a map has neither property, and no converter can supply them without making them up. If your KML fails the test, the honest destination is a route format, and the last section of this page says which.

The TCX schema requires a `StartTime` attribute on every `<Lap>` and an `<Id>` on every `<Activity>`, and both are timestamps. With no times in the source there is nothing to read, so the Unix epoch — `1970-01-01T00:00:00.000Z` — is written into both, and `TotalTimeSeconds` is written as zero because the difference between the first and last point times cannot be computed.

The file that results is schema-valid, which is why it uploads rather than being rejected. What it does downstream is less tidy. A platform sorting activities by date puts it fifty-odd years before everything else, a training-load calculation over a zero-second session either divides by zero or discards it, and any pace derived from distance over duration is undefined. None of that is a malfunction — it is the arithmetic of a file that says it took no time.

A gx:Track is Google's extension for recorded data: parallel lists of `<when>` timestamps and `<coord>` positions, written by tools that export GPS traces as KML rather than as GPX. It is read as its own case, and the timestamps are carried through into the `<Time>` element of every TCX trackpoint.

When that is what you have, everything downstream works properly. The lap start comes from the first point, the duration is the real elapsed time, and the activity lands in the right place in a training log. This is a genuinely useful path for anyone whose recording software exports KML and whose coach wants Garmin files, and it is the reason this conversion exists at all rather than being refused.

A TCX lap must declare a `DistanceMeters`, and a KML stores none, so the figure is computed by summing the great-circle distance between consecutive vertices on a sphere of radius 6,371,000 metres. Against an ellipsoidal calculation that is accurate to a few parts in a thousand, which is not the source of error worth worrying about here.

The error worth worrying about is the shape of the input. A hand-drawn line has a vertex where you clicked, so every curve has been replaced by the straight chord across it. A road with fifteen switchbacks traced in six clicks is measurably shorter than the road, and the activity will claim that shorter number as fact. A route snapped to the path network by a proper planner does not have this problem, which is another reason planners are the better source for anything you intend to measure.

Three declarations are written with fixed values because nothing in a KML corresponds to them. The activity `Sport` is `Other`, since the schema allows only a short enumeration and a drawn line says nothing about the discipline. `<Intensity>` is `Active` and `<TriggerMethod>` is `Manual`, which are the honest readings for a lap that no device ever started or stopped.

All three are worth correcting after import if the activity is going to stay. Most platforms let you change the type after the fact, and the change matters more than it looks — training-load models, pace zones and personal-best detection are all keyed to the discipline, so a session filed as `Other` is quietly left out of most of them. The intensity and trigger values are cosmetic by comparison and can be left alone.

A workout has no waypoint concept, so where the KML contains lines the point placemarks are simply left out. There is no TCX element that would hold them, and inventing one would produce a file that fails validation for every reader.

A KML made entirely of pins is handled rather than refused: the points are read as one track in document order, which produces an activity claiming a route between them. Whether that means anything depends on what the pins were. A sequence of checkpoints along a course converts into something recognisable; a scatter of unrelated sites converts into an activity describing a journey nobody made, at a distance nobody travelled, dated 1970.

The third value of a KML coordinate becomes `<AltitudeMeters>` on the trackpoint. Google Earth, drawing a line clamped to the terrain, writes that value as `0` on every vertex because the renderer ignores it, so a converted TCX commonly carries an altitude of zero from start to finish.

A training platform reading that file reports no ascent and a flat profile, which is the correct interpretation of the numbers it was handed. Where the KML omits the third value entirely — which My Maps exports often do — no altitude element is written at all, and most platforms will then fill in elevation from their own terrain model, producing a better answer than the zeros would have. The absence is more useful than the false value, which is an unusual thing to be able to say.

Beyond the distance figure, the vertex count affects how the activity looks once it is in a training log. A recorded ride has a point every second; a drawn route might have one every kilometre. Charts built from the second kind are made of a handful of samples, and any per-point speed a platform computes from timestamps that do not exist is not computed at all.

The result is an activity that renders as a line on a map and as an empty space everywhere else — no pace graph, no elevation graph, no splits. That is a fair reflection of a file containing forty coordinates and no clock, and it is the clearest practical argument for treating the thing as a route rather than dressing it as a session.

If the KML is a plan, convert it to GPX and load it as a route or a course. Every platform and device has that feature — Garmin calls it a course, Strava and Komoot call it a route — and none of them requires a start time or a duration, because a plan is not supposed to have either. The line will navigate, the waypoints will come with it, and nothing in the file claims to be a measurement.

The activity you want will exist afterwards, recorded by the device that follows the course, with real times and real sensor data attached. That is the ordering the tools were built around, and it is a great deal less work than importing a fabricated session and correcting its date, its type and its duration by hand.

The KML is parsed and the TCX is written in this browser. No request carries the file anywhere, which the network panel confirms during a conversion, and the page works offline once loaded.

For a planned route the sensitivity is not the same as for a recorded one, but it is not nothing. A drawn line says where somebody intends to be, and a My Maps layer of client visits, property viewings or survey stops is commercially confidential before it is personal. Converting locally means the plan does not acquire a copy on somebody else's disk as a side effect of changing its file extension.