GPX を KML に変換

どちらの行き先も Google Earth で開け、同じルートを表示するので、どちらを選ぶかは見た目ではなく、そのあと何をするかで決まります。KML は 1 つの XML 文書で、どんなテキストエディターでも開け、昨日のバージョンと差分を取れ、QGIS や ArcGIS にベクターレイヤーとして読み込め、スクリプトで編集できます。これが、このページが KMZ のページとは別に存在する理由です。

本当に必要なのがトラックをメールに添付したり、同僚に渡したり、Google Earth ファイルを求めるどこかへアップロードすることなら、圧縮された形のほうが優れた答えで、編集のしやすさ以外の何も失いません。ここで測定した同じ内容は、ZIP にすることでおよそ 5 分の 1 に縮みます。ファイルが作業中の文書なら KML を、納品物なら KMZ を選んでください。

GPX のトラックポイントは <time> 要素を持ち、これが GPX を単なる図面ではなく記録たらしめています。ファイルは線がどこを通るかだけでなく、その各部分にいつ到達したかも知っています。KML の LineString にはそれに相当するものがありません。座標のリストであり、それ以上ではないので、変換の過程でタイムスタンプは失われ、出力からは復元できません。

この帰結は具体的です。Google Earth のタイムスライダー——トラックをこすって、それが自分自身を描いていくのを見られる機能——は、変換されたファイルには現れません。この機能は並行した <when> の値を持つ gx:Track 要素を手がかりにしており、この変換は素の LineString を書くからです。ペースや移動時間、休憩について何か計算したいなら、GPX から行う必要があります。元データを KML と一緒に残しておいてください。両者は交換可能ではなく、KML のほうが非可逆です。

GPX のトラックポイントが <ele> の値を持っていた場所では、書かれる座標は 3 つ組になり、3 つ目の枠にメートルの値が入ります。持っていなかった場所では座標は 2 つ組になり、読み取る 3 つ目の枠がありません。これはウォッチで記録されたのではなくブラウザーで計画されたルートによくある状態です。つまり、記録された散歩の高度プロファイルはバイト単位で保たれ、KML をデータとして読むツールはそれを見つけられます。計画されたルートにはそもそも見つけるものがなく、どちらの場合もエラーにはなりません。

Google Earth はそれを描きません。理由は 1 つの要素が欠けているからです。KML の高度は、それをどう解釈するかを示す <altitudeMode> なしには意味を持たず、何も宣言されていない場合の既定値は clampToGround です。高度は無視され、線は地形の上に置かれます。これはトラックにとって正しい既定値です。GPS の高度は数十メートル単位でぶれ、尾根の上に不揃いに浮かぶ線は壊れて見えるからです。線を空中に描きたいなら、LineString に <altitudeMode>absolute</altitudeMode> を手作業で加えてください。

各 LineString は <tessellate>1</tessellate> 付きで書かれ、これは特定の見た目の不具合を直すためにあります。細分化なしに地面に固定すると、Google Earth は各頂点を地形の上に置き、その後、連続する頂点の間を直線で結びます。谷や尾根を越えるとき、その直線は地表の下を通ってしまい、トラックは丘の中に消えて反対側で再び現れます。

細分化を有効にすると、レンダラーは各セグメントを分割し、頂点の間で地形をたどるので、線は全長にわたって見え続けます。代償はレンダラーが扱う幾何情報が増えることで、数千点なら気づきませんが、長いトラックを何本も一度に読み込むと目に見えて重くなります。Earth の中でファイルが重いと感じたら、まずこのフラグを外してみる価値があります。

GPX は緯度と経度をトラックポイントの別々の属性として書き、名前が付いているのであいまいさはありません。KML はそれらを「経度, 緯度, 高度」の順で 1 つのカンマ区切りの文字列として書きます。この一族のほかのほとんどの形式とは逆で、地図がギニア湾に現れてしまう典型的な原因です。

この変換はその入れ替えを処理し、それを自分で確かめる簡単な方法があります。KML をテキストエディターで開いて最初の座標を見てください。英国やアイルランドのどこであれ、最初の数値は小さな負の数で、2 番目は 50 から 59 の間になるはずです。大きい数値が先に来ているなら、どこかで再び入れ替わってしまっており、ファイル内のすべての点が同じように間違っています。

GPX の <wpt> 要素は、誰かが意図的に印を付けた地点です。山頂、水場、駐車スポット、鍵のかかっていたゲートなど。それぞれが独自の Placemark になり <Point> を含み、持っていた名前を保つので、Google Earth のサイドバーに、線に統合されるのではなく名前付きのピンとして表示されます。

この分離には価値があります。ウェイポイントとトラックポイントは違う意味を持つからです。トラックポイントは機器がスケジュールに従って取ったサンプルであり、ウェイポイントは人が下した決定です。それらを別々の KML の地物として保つことで、記録された線には一切触れずに、ルートを隠したままピンを残したり、ピンをドラッグして修正したりできます。

3 つの名前が運ばれます。GPX の <metadata> ブロックの中の <name> は KML の Document 名になり、Google Earth のサイドバーの上部に表示されます。各トラック自身の <name> はその Placemark の名前になります。各ウェイポイントの名前はそのピンの名前になります。

GPX ヘッダーの残りは引き継がれません。作者、著作権、記録サービスへのリンク、説明、キーワード、境界ボックスはすべて GPX 1.1 で定義されていますが、そのどれも KML には書き込まれません。ウォッチが心拍数やケイデンスを保存するトラックポイントごとの拡張要素も同様です。それらの来歴を保つ必要があるなら、1 つのファイルに両方持たせようとせず、GPX ファイルを KML の隣に残しておいてください。

出力には <Style> も styleUrl も含まれません。そのため Google Earth は既定の線の見た目を適用し、変換されたどのトラックも他のものと同じに見えます。これから自分で色を付け直すつもりなら望ましいことで、8 本のトラックを一度に読み込んで見分けたいときには少し不便です。

あとからスタイルを加えるのはどちら向きでも簡単です。Google Earth では、プレイスマークを右クリックしてプロパティから色と太さを設定すれば、ファイルに保存されます。テキストエディターでは、<LineStyle> の色と太さを持つ 1 つの <Style> ブロックを作り、各プレイスマークの styleUrl から参照させれば同じことができ、変換されたトラックのフォルダー全体にスクリプトで適用するのも簡単です。

KML は元の GPX よりかなり小さくなり、変換にはバイト数のコストがかかると思っている人を驚かせます。7,200 点のトラック——2 時間分、1 秒ごとに記録され、すべての点に高度と時刻を持つ——で測定したところ、GPX はおよそ 950 KB、KML はおよそ 258 KB でした。原因は XML タグのオーバーヘッドです。GPX は各サンプルの周りに <trkpt>、<ele>、<time> のマークアップを繰り返しますが、LineString は座標を一度だけ記し、空白で区切ります。

この節約の一部はタイムスタンプが失われた分でもあるので、ただで得られるものではありません。それでも読めて編集できるファイルが残ります。開いて、GPS が 2 キロメートル離れた畑に投げ出してしまった迷い点を見つけ、その行を削除して保存できます。同じ編集を GPX に対して行うなら 1 行ではなく 4 行を削除することになり、KMZ に対して行うなら先に展開が必要です。

GPX の解析と KML の書き出しは、どちらもこのブラウザーのタブの中で行われます。ファイルをサーバーへ運ぶリクエストは発生せず、変換中はネットワークパネルでそれを確認でき、一度読み込めばオフラインでも動作し続けます。アップロードの待ち行列も、残されるコピーもありません。

ルートファイルにとって、これは見た目以上に強い保証です。ウォッチからの GPX はたいてい記録者の自宅で始まり自宅で終わり、タイムスタンプはどの朝に家が空だったかを語ります。KML に変換する過程で時刻が失われても、通勤やトレーニングの決まったコースの形そのものが、地図の上でそれを見た誰かに人物と住所を特定させます。