TCX を GPX に変換

TCX は Garmin の形式で、その周辺のエコシステムはこれを難なく読みます。そのエコシステムの外に出ると、これは障害になります。ルートプランナー、地図ツール、オープンソースのナビゲーションアプリ、クラブのアップロードフォーム、多くの GIS ソフトは GPX しか受け付けません。GPX はこれらすべてより古く、地理情報だけを記述する形式だからです。

ですからこの変換はたいてい、データについての選択ではありません。特定の行き先がファイルを拒んだために取る互換性の手段です。有用な問いは「変換するかどうか」ではなく「変換したあとに何が手元に残らないか」です。答えはトレーニングファイルらしさの大半で、グラフが空になったときに気づくより、先にその一覧を読んでおく価値があります。

ポイントごとには <HeartRateBpm>、<Cadence>、<DistanceMeters>、そして <Extensions> ブロックに入っているすべて——ランニングケイデンス、ワット数、機器自身の瞬間速度が住んでいる場所です。ラップごとには TotalTimeSeconds、DistanceMeters、MaximumSpeed、Calories、AverageHeartRateBpm、MaximumHeartRateBpm、Intensity、TriggerMethod。アクティビティごとにはラップの区切りそのものと、記録した機器を示す <Creator> ブロックです。

これは「その他いろいろ」で終わる部分的な一覧ではなく、TCX が定義する要素そのものであり、そのどれも読まれません。残るのは <Time>、<Position> の緯度経度、<AltitudeMeters> だけで、これはまさに GPX の trackpoint がネイティブに持つ情報です。この変換はルートには忠実で、トレーニングの内容については沈黙しています。どちらを持ち運んでいるのかを知っておくほうがよいのです。

よくある説明は「GPX は心拍を運べない」というものですが、これは誤りです。基本の GPX 1.1 にセンサー用の項目はありませんが、この形式は明示的に拡張可能で、Garmin 自身の TrackPointExtension 名前空間は trackpoint の <extensions> 要素の中に心拍やケイデンス、気温などを加えます。Strava も Garmin Connect も、多くのトレーニングプラットフォームもそれを読みますし、時計から書き出した GPX には日常的にそれが含まれています。

ここで出力されるファイルには、そうした拡張ブロックが一切含まれません。すべての trackpoint は緯度・経度・任意の <ele>・任意の <time> だけで書かれ、それ以外は何もありません。変換器は四つの GPS 形式すべてを一つの共有された内部形状として読み込み、その形状にセンサーストリームの入る余地がないからです。この損失は行き先の形式の性質ではなく、この変換の性質です。そう述べることが、正確な期待と間違った期待の分かれ目になります。

位置情報は小数点以下 6 桁、約 11 センチメートルの精度で書かれます。一般的な受信機が持つ数メートルの誤差の中に十分収まる精度です。標高は <AltitudeMeters> から <ele> へ、丸めも単位変換もなくそのまま転記されます。両方ともメートルだからです。タイムスタンプは書式を変えず原文のまま複製されるので、Garmin のファイルが 2026-03-14T06:41:07.000Z のように書いていれば、ミリ秒と UTC の印もそのまま残ります。

この最後の点が、出力を本物の記録たらしめています。タイムスタンプ付きの GPX は所要時間とペースを持ち、GPX を受け付けるものであれば何にでも、完了したアクティビティとしてアップロードできます。これがこの変換の一般的な理由であり、うまくいく理由でもあります。受け取ったプラットフォームがその時刻からどう計算するかは、そちら側の計算です。Garmin が見せていた数字とはわずかに異なります。Garmin はもうファイルにないセンサーストリームを使っていたからです。

TCX は trackpoint をラップにまとめて記録し、ラップこそがトレーニングを読み解く構造です。分割タイム、回復区間、区間ごとの平均。これらの境界は平坦化されます。すべてのラップの点は順番どおりに一つの <trkseg> に、一つの <trk> の中で連結され、GPX にはどこで終わったかを示すものが何もありません。

GPX にもセグメントの概念はあるので、原理的にはラップをセグメントの区切りに対応させることもできますが、GPX のセグメントの区切りは慣習的に記録の途切れを意味し、ボタン操作を意味しません。ラップをその形で表せば、読む人は信号が 12 回途切れたと誤解してしまいます。平坦化するほうが誤解が少ない選択です。ラップ構造が必要なら TCX を残してください。多くのプラットフォームはアップロードしたアクティビティを手動で再分割できますが、ラップごとの平均心拍はいずれにせよ失われます。

<Position> のない Trackpoint は <trkpt> になれず、捨てられます。これが GPX のポイント数が TCX より少なくなる通常の理由です。時計は衛星の捕捉があってもなくても毎秒サンプリングするため、駐車場で始まったセッションや、地下道や高いビルの間を通過したセッションには、時刻と心拍を持ちながら座標を持たない区間がまるごと存在します。

極端な例では、トレッドミルやターボトレーナー、ローイングマシンでの屋内セッションはファイルのどこにも位置情報がなく、変換はトラックもウェイポイントも見つからなかったと報告します。それは失敗ではなく正確な結果です。ファイルの中にルートは存在せず、それを表す GPX も存在し得ません。そうしたセッションにとってトレーニングデータこそがすべての内容であり、それを保持しない形式へ変換することは、どの方向であっても意味がありません。

TCX のアクティビティには名前の要素がありません。あるのはスキーマで短い一覧に限定された Sport 属性で、その値が GPX トラックの <name> になります。ですから変換された多くのファイルは Running、Biking、Other といったトラック名で出てきます。

Garmin Connect や Strava で見えているタイトルは、そのプラットフォームのデータベースに住んでいて、書き出しの一部ではないため運べません。複数のセッションを変換すると、実務上の結果として、トラックは名前では区別が付かず、ファイル名と最初のタイムスタンプに頼ることになります。あとから <name> 要素を書き換えるのはテキストエディターでの 1 行の編集で、ルートのライブラリに入れる前にやっておく価値があります。

TCX はこの系統の中で最も冗長な形式です。各 trackpoint は座標を <Position> 要素の中に <LatitudeDegrees> と <LongitudeDegrees> の子要素として包み、数字 1 桁の前にすでに 34 文字のタグ名があります。時刻と標高だけを持ちセンサーデータを持たない 7,200 ポイントのトラックで測ると、TCX は約 2.2 MB、同等の GPX は約 950 KB でした。ポイントあたりおよそ 315 バイト対 132 バイトです。

実際の Garmin の書き出しは、この比較では省いた心拍・ケイデンス・距離の要素がすべての点に含まれるため、さらに大きくなります。ですから実際に見る縮小幅は倍以上のことが多く、その大部分はトレーニングデータが去っていくことそのものです。このサイズの縮小を効率と読むのは誤りで、ファイルにもう何が入っていないかを示す、かなり直接的な指標です。

TCX は 1 つの文書に複数のアクティビティを持てて、それはトレーニングプラットフォームからの一括書き出しがよく取る形です。各 <Activity> は独自の <trk> になり、そのスポーツから取った独自の名前を持ち、トラックは文書の順番で並びます。

行き先がそれをきちんと扱えるかどうかはさまざまです。ルートプランナーはたいてい一覧を見せて選ばせてくれますが、1 ファイルにつき 1 アクティビティを前提とするアップロードフォームは、しばしば最初の 1 本だけを取り、残りを何も言わずに捨てます。一括書き出しを個々のセッションに分けたいなら、変換する前に TCX を分割してください。アクティビティの境界は XML の中でははっきりしていますが、GPX になった瞬間、トラックの境界の中に消えてしまいます。

TCX の解析も GPX の書き出しも、どちらもローカルで行われます。ファイルを運ぶリクエストはなく、それは変換中のネットワークパネルで確かめられます。ページは、読み込んだあとは接続を切っても動き続けます。

トレーニングファイルは、同じ文書の中に健康データと位置データを持っています。時刻に対する心拍、時刻に対する位置——たいてい自宅から始まったセッション全体についてです。アップロードするタイプの変換ツールは、たいていファイルを変換に必要な時間だけ、時にはもっと長く保持し、それを定める規約は、GPX が必要になったその瞬間に誰も読みません。ブラウザーの中で行えば、その問い自体が要らなくなります。