KML を CSV に変換

KML は地球儀の上に描くために作られました。プレイスマークのファイルは位置よりずっと多くのものを運びます。アイコンごとのスタイル、HTML を含む説明の吹き出し、それらをまとめるフォルダーツリー、ときには背後のグラウンドオーバーレイまで。ですが、出回っている KML ファイルの多くは、地図の姿をした一覧として使われています。40 か所の支店、調査地点の集合、Google Earth で 1 年かけて印を付けた場所などです。

そうしたファイルにとって、CSV のほうが正直な入れ物です。各プレイスマークは名前と座標の 1 行になり、それこそがジオコーダーやルート最適化ツール、CRM のインポート、GROUP BY が実際に消費するものです。図面らしさを構成していたものはすべて置き去りにされますが、それは制約ではなく意図的な損失です。アイコンの URL 用の列を作っても誰の役にも立たず、HTML の説明の吹き出しをそのまま保てる列の形はどこにもありません。

KML は座標を「経度, 緯度, 高度」という 1 つの空白区切りの文字列として書きます。この一族の他のほとんどの形式——GPX や TCX も含めて——は緯度を先に名付けており、この逆転こそ KML の変換がもっともよく間違える原因です。数値がずれるのではなく入れ替わってしまうので、経度 13.4、緯度 52.5 のベルリンが 52.5、13.4 として出てくると、アラビア海に着地してしまいます。

この変換はそれを入れ替えるので、CSV の列は緯度、続いて経度の順になります。信じるより確認する価値があり、1 秒で済む確認方法があります。西ヨーロッパのどこであれ、緯度はおよそ 36 から 71、経度はおよそ −10 から 30 の範囲に収まります。最初の座標の列が小さく、2 番目が大きいなら、どこかで入れ替えが元に戻されてしまっています。

KML は入れ子になります。<Document> は <Folder> 要素を含み、それがさらにフォルダーを含み、最終的にジオメトリを運ぶ <Placemark> 要素にたどり着きます。読み込み処理は 1 段だけ見るのではなくその木構造全体を歩きます。地図作成ツールから書き出された KML は、プレイスマークを 3 段下に置くのが普通で、文書の先頭しか確認しないパーサーは、実際には満杯のファイルを空だと報告してしまうからです。

この探索が保たないのがフォルダー構造です。「Sites / Phase 2 / Confirmed」にあるピンも、トップレベルにあるピンと見分けが付かない行として出てきます。CSV には name の列が 1 つしかなく、それはプレイスマークに属するものだからです。グループ分けが重要な情報なら、変換前にプレイスマークの名前にそれを組み込むか、変換後に KML から復元する必要があります。

<Point> を持つプレイスマークは waypoint と分類された 1 行になります。<LineString> を持つプレイスマークは track と分類された行の連続になり、各頂点につき 1 行、すべて同じプレイスマーク名を共有します。この 2 つが出回っている KML の圧倒的多数をカバーし、どちらも名前を保ったまま渡ってきます。

2 つのものはまったく何も生まず、変換前に知っておく価値があります。<Polygon>——影付きの領域、敷地境界、サービスエリアなど——は、その輪郭を、このパーサーが降りていかない入れ子の境界要素の中に保持しているので、面は行を 1 つも生みません。1 つのプレイスマークの中に複数の線をまとめる <MultiGeometry> も同じ理由でスキップされます。面だけでできた KML は「トラックもウェイポイントも見つかりませんでした」というメッセージで失敗しますが、これは正確な報告であって、ファイルの問題ではありません。

LineString はいつという概念を持たない形です。KML が描画ではなく GPS の書き出しから来たものなら、代わりに Google の拡張である gx:Track を持っていることがあります。これは <when> のタイムスタンプと <coord> の位置を並行したリストとして保持します。読み込み処理はこれを線として扱うのではなく別のケースとして処理し、タイムスタンプは time の列に入ります。

それを持っているかどうかは、time の列が埋まっているかどうかでわかります。すべてのセルが空なら、元データは LineString を保持していたということで、どんな変換ツールも、ファイルがそもそも保存していなかった時刻を復元できません。gx:Track の中の 3 つ目の座標値がカンマではなくスペースで区切られているのも、これが理由です。同じ文書の中で 2 つの異なるジオメトリに 2 つの異なる区切り文字が使われているのは、ファイルの間違いではなく、この形式が本当に持つ奇妙さです。

KML の座標の 3 つ目の値はメートル単位の高度で、この変換は存在する場合それを elevation の列に書き込みます。行わないのは <altitudeMode> の参照です。これは、高度をどう解釈すべきか——地表に固定するか、地表からの相対値か、絶対値か——を示す隣接要素です。

Google Earth の既定値は clampToGround で、この場合高度の値はまったく無視され、しばしば 0 として書かれます。そのため、起伏のある地形の上で手描きされた KML は、「海抜ゼロ」ではなく「地表面上」を意味するゼロで埋まった elevation の列を生みがちです。ゼロの列はデータではなく欠落として扱ってください。標高の数値が本来の目的なら、GPX や TCX から取得してください。

出力はすべての waypoint 行を、文書内での出現順にかかわらず、すべての track 行より前に置きます。これはよくある場合への配慮です。ピンだけの KML は、すべての行がウェイポイントであるファイルに変換され、ピンと描かれたルートが混在する KML では、ピンがスクロールなしで選べる位置——先頭——にまとまります。

代償は、2 つの型をまたいで文書の順序が保たれないことです。KML の中の要素の並びに意味があった場合——たとえば調査が各地点を訪れた順番など——その順序はプレイスマークの名前か time の列から取る必要があり、行番号からは取れません。各型の中では、元の順序は正確に保たれます。

プレイスマークの名前は、素朴な CSV をもっとも壊しやすいフィールドです。人が書いた自由記述のテキストだからです。「Warehouse 3, Rear Entrance」は区切り文字を含んでいますし、住所を名前として使えば複数含むこともあります。書き出し処理は、カンマ、引用符、改行を含む値を引用符で囲み、内部の引用符は二重にします。これは RFC 4180 が求めるもので、どの表計算ソフトや CSV ライブラリも正しく読み戻せます。

座標は引用符を必要としないので、ファイルはテキストエディターの中でも読みやすいままです。目視で結果を確認するなら、引用符付きの名前が確認する価値のある行です。元の KML の中で引用符の対応が崩れている名前は、元のファイルがすでに不正な形式だった唯一のケースで、この変換はそれを忠実にそのまま運びます。

KML はプレイスマークに <address> 要素を定義しており、地球儀をクリックしてではなく場所を検索してピンが作られたとき、Google Earth がそれを埋めます。ここでは読み込まれないので、元の文書に住所があった場合でも、出力は名前と座標だけを持ち、郵便住所らしきものは何も含みません。

ほとんどの行き先にとってこれは損失ではありません。緯度と経度は番地の 1 行よりも強力な鍵で、ルート案内や地図、ジオコーディングのサービスはどれもそれを直接受け付けるからです。住所が本当に必要な場合——郵送や配送マニフェストなど——座標に対する逆ジオコーディングの段階が必要で、結果のいくつかは目視で確認する価値があります。駐車場の真ん中に落とされたピンは、いちばん近い建物へと解決されますが、それはそのピンが示していた建物ではないことがよくあります。

この変換はこのブラウザーのタブの中で完結します。KML はローカルで読み込まれ、走査され、書き直され、どこかへ運ぶリクエストは発生しません。アカウントも待ち行列も、読むべき保持方針もありません。サーバー上に保持するものが何もないからです。

これに気を配る理由は、プレイスマークの一覧が普段どういうものかにあります。ピンの KML はしばしば顧客の一覧、配送先の住所の集まり、患者やクライアントの所在地、あるいは公開したくない資産の位置です。CSV に変換すれば持ち運びやすく読みやすくなりますが、出力はこれから加わる表計算ファイルと同じ扱いを受けるべきものです。