GeoJSONとKMLを使い分けるための5つの判断軸

目次

• GeoJSONとKMLは何が違うのかを先に整理する

• 判断軸1：Webシステム連携を重視するならGeoJSONを選ぶ

• 判断軸2：地図上での見た目や共有を重視するならKMLを選ぶ

• 判断軸3：属性情報を加工して使うならGeoJSONを優先する

• 判断軸4：現場確認や説明資料に使うなら閲覧環境で選ぶ

• 判断軸5：将来の変換・管理・再利用まで考えて形式を決める

• GeoJSONとKMLを混在させるときの注意点

• まとめ：用途を決めてから形式を選ぶことが実務では重要

GeoJSONとKMLは何が違うのかを先に整理する

GeoJSONとKMLは、どちらも地図上の点、線、面などの位置情報を扱うために使われる代表的なデータ形式です。ただし、同じ位置情報を扱える形式であっても、得意な用途は同じではありません。GeoJSONはJSONを基礎にした地理空間データ形式で、形状と属性をシンプルに扱いやすいことが特徴です。KMLは地理情報を地図上で視覚的に表現する用途で使われることが多く、名称、説明、表示スタイル、階層構造などを含めやすい形式です。

実務で重要なのは、GeoJSONとKMLを「どちらが優れているか」で比べないことです。Webシステムに取り込んで検索、編集、集計、API連携を行うならGeoJSONが扱いやすい場面が多くなります。一方で、関係者に地図上で見てもらう、説明用に色分けする、簡易に位置情報を共有するという目的ならKMLが使いやすい場合があります。

GeoJSONでは、点、線、面などのジオメトリと、地物ごとの属性情報をFeatureとして扱えます。たとえば、点検箇所、施工範囲、管理区域、撮影地点、境界線などに、管理番号、分類、状態、日付、備考といった情報を付けて管理できます。データとしての再利用を前提にしやすいため、業務アプリやWeb地図と組み合わせる用途に向いています。

KMLは、地図上で人が見ることを意識した表現に向いています。点の名称、線の色、面の塗り、説明文、フォルダ分け、表示順などを含めやすく、閲覧用データとして関係者に渡しやすいことがあります。現場の説明、範囲確認、進入経路の共有、注意箇所の提示など、見た人がすぐ理解できることを重視する場面で役立ちます。

注意したいのは、座標の扱いです。現在のGeoJSON仕様では、座標は原則としてWGS 84に基づく経度、緯度の順で表現されます。KMLも座標を経度、緯度、高さの順で記述します。測量データや表計算データでは緯度、経度の順で扱われることもあるため、形式変換や手入力では座標順序の確認が欠かせません。

判断軸1：Webシステム連携を重視するならGeoJSONを選ぶ

最初の判断軸は、Webシステムや業務アプリとの連携を重視するかどうかです。位置情報をWeb画面に表示するだけでなく、クリック時に属性を表示したり、条件で絞り込んだり、サーバー側に保存したり、ほかの業務データと結び付けたりする場合は、GeoJSONを優先して考えると扱いやすくなります。

GeoJSONはJSONを基礎にしているため、WebアプリケーションやAPIとの相性がよい形式です。施工箇所のポリゴンをクリックすると工区名、担当者、進捗状況、点検日、写真の有無などを表示する仕組みでは、GeoJSONのpropertiesに業務属性を整理して入れることで、画面表示や検索処理に利用しやすくなります。

「geojson 使い方」を調べる実務担当者は、単に地図ファイルを開くだけでなく、手元の位置情報をWeb地図や社内システムで活用したいケースが多いはずです。その場合、GeoJSONは位置情報をシステム側で扱うための中間形式として有効です。現場名、管理番号、分類、ステータス、更新日時などを、地物と結び付けて管理できます。

KMLでも名称や説明文を持たせることはできますが、属性を細かく検索、更新、集計する前提では、GeoJSONのほうが扱いやすい場面が多くなります。KMLは表示や説明のための要素を含みやすいため、機械処理だけを目的にすると構造が複雑になることがあります。逆にGeoJSONは、見た目の指定をファイルに強く持たせるより、表示スタイルをアプリ側で管理する設計に向いています。

ただし、GeoJSONを使えば自動的に管理しやすくなるわけではありません。属性名の付け方、日付形式、分類値、空欄の扱いを決めずに運用すると、同じ意味の項目が複数の名前で混在し、後から統合や検索が難しくなります。GeoJSONは柔軟だからこそ、最初の属性設計が重要です。

また、GeoJSONはテキスト形式で座標を保持するため、頂点数の多い線や面を大量に扱うとファイルサイズが大きくなることがあります。Web画面で配信する場合は、用途に応じて形状を簡略化したり、表示範囲に応じてデータを分けたりする検討が必要です。

判断軸2：地図上での見た目や共有を重視するならKMLを選ぶ

二つ目の判断軸は、地図上での見た目や関係者への共有を重視するかどうかです。社内外の関係者に位置情報を渡して、すぐに地図上で確認してもらいたい場合や、点、線、面を色分けして説明したい場合は、KMLが向いていることがあります。

KMLは、地図上での表示を意識した情報を持たせやすい形式です。線の色や太さ、面の塗り、点の表示名、説明文、階層構成などを含めることで、閲覧者が内容を理解しやすい地図データを作れます。調査済み範囲、未調査範囲、注意箇所、進入経路、仮設道路、立入制限区域などを色分けして共有する場合、説明用データとして扱いやすくなります。

実務では、位置情報を作る人と見る人が同じとは限りません。作成担当者は座標や属性を理解していても、確認者は地図上に表示された色、名称、範囲を見て判断することが多くあります。このような閲覧中心の場面では、データ構造の扱いやすさよりも、開いたときに意図した内容が伝わることが重要です。

GeoJSONでも地図表示はできますが、色やアイコンなどの見た目は表示する側のシステムに依存しやすくなります。GeoJSONファイルだけを渡した場合、相手の閲覧環境によっては期待した色分けや表示名にならないことがあります。共有先の環境が決まっていない場合は、KMLのほうが説明用ファイルとして扱いやすいことがあります。

ただし、KMLを使うときは、見た目を作り込みすぎることで再利用が難しくなる場合があります。説明文の中に多くの情報を文章として入れると、後から項目別に抽出したり、別システムへ取り込んだりしにくくなります。KMLは共有に便利ですが、長期的な管理データにする場合は、属性の整理方法に注意が必要です。

判断軸3：属性情報を加工して使うならGeoJSONを優先する

三つ目の判断軸は、位置情報に付随する属性情報をどの程度加工して使うかです。地図上に表示するだけでなく、属性を抽出したり、条件検索したり、集計したり、外部データと結合したりする場合は、GeoJSONを優先するほうが管理しやすくなります。

GeoJSONでは、一つひとつの地物に対してpropertiesとして属性情報を持たせることができます。点検対象の地点であれば、管理番号、種別、点検日、判定、写真番号、担当者、備考などを属性として持たせられます。施工範囲の面であれば、工区名、施工予定日、完了状況、面積区分、確認者などを持たせることができます。

GeoJSONでつまずきやすいのは、座標だけを入れれば十分だと考えてしまい、属性設計を後回しにすることです。GeoJSONは属性を自由に追加できるため便利ですが、自由に入力し続けると表記ゆれが増えます。たとえば、「完了」「済」「施工済み」「完了済み」が混在すると、完了した地物を一括抽出するだけでも余計な処理が必要になります。

そのため、GeoJSONを業務データとして使う場合は、属性名、入力形式、分類値、日付形式、空欄の扱いを最初に決めておくことが重要です。複数人で編集する場合や、複数現場のデータを後で統合する場合は、属性設計の統一が欠かせません。

KMLにも名称や説明を入れることはできますが、属性を機械的に加工する用途では、GeoJSONのほうが向いています。KMLの説明文に人が読むための文章として情報を入れてしまうと、後から項目ごとに分けて取り出すのが難しくなります。閲覧用のKMLと、管理用のGeoJSONを分けて考えることで、見やすさと加工しやすさを両立できます。

たとえば、現場で確認した点検位置を管理する場合、元データはGeoJSONで持ち、共有用に必要な項目だけをKMLに変換する運用が考えられます。GeoJSON側には管理番号や点検結果などの属性を整えて保存し、KML側では関係者が見るための名称や色分けを整えるという使い分けです。

判断軸4：現場確認や説明資料に使うなら閲覧環境で選ぶ

四つ目の判断軸は、現場や打ち合わせで実際に誰が、どの環境で見るのかです。形式として正しくても、閲覧する人が開けなかったり、現場で確認しにくかったりすれば、実務では使いにくいデータになります。作成者側の都合だけでなく、閲覧者側の環境を考慮する必要があります。

現場確認では、事務所の大きな画面で見る場合と、屋外で携帯端末を使って見る場合で、必要なデータの作り方が変わります。屋外では画面が小さく、通信環境も安定しないことがあります。そのため、現場用データでは、必要な地物だけを入れ、名称や色分けを分かりやすくし、ファイルサイズを抑えることが重要です。

KMLは、現場で関係者に位置を見せる用途で使いやすい場合があります。閲覧用の地図環境に読み込むことで、点や線や面を直感的に確認しやすくなります。現場範囲、進入ルート、注意箇所などを共有する場合には、KMLの見た目に関する情報が役立ちます。

一方で、現場で取得した情報をそのまま業務システムに戻したい場合や、位置情報と写真、メモ、判定結果などを連携したい場合は、GeoJSONのほうが向いています。現場で入力した属性を後から集計したり、点検履歴として保存したりする場合には、データ構造が整理されたGeoJSONのほうが扱いやすいからです。

説明資料に使う場合も、目的によって形式は変わります。関係者に場所を伝えるだけであれば、KMLのように見た目を整えた形式が便利です。しかし、説明資料の根拠データとして、面積、距離、分類、件数などを後で再利用する場合は、GeoJSONで元データを管理しておくほうが安全です。

閲覧環境で形式を選ぶときは、相手がどの形式を受け取れるかも確認しておく必要があります。自分の環境では問題なく開けても、受け取り側ではファイルを読み込めない、文字化けする、色分けが反映されない、座標がずれて見えるといったことが起こり得ます。特に、公共座標、緯度経度、ローカル座標の違いが関係するデータでは、形式以前に座標系の確認が欠かせません。

判断軸5：将来の変換・管理・再利用まで考えて形式を決める

五つ目の判断軸は、将来の変換、管理、再利用まで考えることです。GeoJSONとKMLは相互に変換できる場面もありますが、変換すればすべての情報が完全に保たれるとは限りません。特に、スタイル、階層構造、属性の持ち方、座標の扱い、面の向き、複数形状の表現などは、変換時に注意が必要です。

実務では、最初に作った地図データが、その後も何度も使い回されることがあります。調査範囲のデータが施工計画に使われ、施工後には確認資料に使われ、さらに維持管理の基礎データになる場合もあります。このような長期利用を想定するなら、見た目だけでなく、データとしての再利用性を重視すべきです。

GeoJSONは、将来的にWebシステムやデータベースに取り込む可能性がある場合に向いています。属性情報を整理しやすく、ほかの形式に変換する前の元データとして管理しやすいことが多いためです。同じデータを複数の画面やアプリで使う場合、GeoJSONを基準にしておくと、表示側の都合に応じて加工しやすくなります。

KMLは、配布用や閲覧用の成果物として使いやすい一方で、長期管理の元データにする場合は注意が必要です。スタイルや説明文を含めて人が見やすい状態にできる反面、後から属性を整備したり、機械的に分類したりするには、データ構造を再整理する作業が発生することがあります。

また、変換時には座標の扱いにも注意が必要です。GeoJSONでは経度、緯度の順で座標を扱います。KMLでも座標は経度、緯度、高さの順で記述されます。ほかの測量データや表計算データでは緯度、経度の順で扱われることもあるため、形式変換そのものよりも、座標の順序や座標系を誤ることで、地物が大きくずれて表示されるトラブルが起きやすくなります。

将来の管理を考えるなら、ファイル名や更新履歴の付け方も重要です。GeoJSONでもKMLでも、同じような名前のファイルが増えると、どれが最新版か分からなくなります。現場名、日付、用途、座標系、作成段階などを分かるようにしておくと、後から確認しやすくなります。

GeoJSONとKMLを混在させるときの注意点

GeoJSONとKMLは、どちらか一方だけを使うよりも、用途に応じて併用する場面が多くあります。社内システムではGeoJSONで管理し、関係者への共有にはKMLを書き出す。外部から受け取ったKMLをGeoJSONに変換して、属性を整えたうえで管理台帳に取り込む。このような運用は実務的ですが、混在させる場合には注意点があります。

まず重要なのは、元データを一つに決めることです。GeoJSONとKMLの両方を編集対象にしてしまうと、どちらが正しい最新版なのか分からなくなります。GeoJSONを管理用の元データにするなら、KMLはそこから書き出した閲覧用データとして扱う。外部から受け取ったKMLを基準にする場合でも、管理開始時点でGeoJSONに変換し、以後の更新基準を決めることが必要です。

次に、変換で失われる情報を把握しておくことが大切です。KMLのスタイル情報をGeoJSONに変換しても、色やアイコンの指定がそのまま標準的に使えるとは限りません。反対に、GeoJSONの属性情報をKMLに変換しても、閲覧環境ではすべての属性が見やすく表示されるとは限りません。変換は便利ですが、目的に応じた整形が必要です。

面データの扱いにも注意が必要です。ポリゴンの外周、穴あきポリゴン、複数ポリゴンなどは、形式や変換環境によって扱いに差が出ることがあります。単純な点や線であれば問題が起きにくい一方、複雑な区域データでは、変換後に面が欠ける、穴が反映されない、境界が意図と異なるといった確認が必要になる場合があります。重要な施工範囲や管理区域では、変換後に必ず地図上で目視確認することが欠かせません。

文字コードや属性名の扱いも見落としやすい点です。日本語の名称や備考を含むデータでは、変換後に文字が崩れたり、属性名が変わったりすることがあります。複数の環境をまたいでデータを扱う場合は、変換直後に名称、分類、備考、日付などが正しく残っているかを確認する必要があります。

混在運用では、ファイルの用途を明確にすることも重要です。管理用、閲覧用、提出用、現場確認用、変換前、変換後といった用途が曖昧なままファイルが増えると、誤ったデータを使って作業してしまうリスクがあります。編集は管理用データに対して行い、共有用データは必要に応じて書き出すという方針を決めておくと安全です。

まとめ：用途を決めてから形式を選ぶことが実務では重要

GeoJSONとKMLの使い分けで最も重要なのは、形式から考え始めないことです。先に考えるべきなのは、その地図データを何のために使うのか、誰が見るのか、誰が編集するのか、後からどのように再利用するのかです。目的が整理できれば、GeoJSONとKMLのどちらを選ぶべきかは自然に見えてきます。

Webシステムとの連携、属性情報の管理、検索や集計、データベースとの接続、将来的な再利用を重視するなら、GeoJSONが有力な選択肢になります。GeoJSONは、位置情報を業務データとして扱うときに向いています。点、線、面の形状に対して、管理番号や分類、状態、日付、備考などを持たせることで、単なる地図表示を超えた活用がしやすくなります。

一方、地図上での見た目、関係者への共有、説明用のファイル、閲覧中心の用途を重視するなら、KMLが使いやすい場面があります。色分けや名称、説明文、階層構成を含めて、開いた人が内容を理解しやすいデータを作れるため、現場説明や確認用の資料として役立ちます。ただし、KMLを長期管理の元データとして使う場合は、属性の再利用性や変換時の情報欠落に注意が必要です。

実務では、GeoJSONとKMLを対立する形式として考えるより、役割を分けて使うほうが現実的です。GeoJSONを管理用の元データとして整備し、必要に応じてKMLを共有用に書き出す。外部から受け取ったKMLは、内容を確認したうえでGeoJSONに変換し、属性や座標を整理してから管理する。このような流れにすると、現場で見やすく、後から使いやすいデータ運用ができます。

また、形式選定だけでなく、座標系、座標順序、属性名、ファイル名、更新履歴、変換後の確認も重要です。GeoJSONを使っても、属性が揺れていれば管理しにくくなります。KMLを使っても、閲覧環境で意図通りに表示されなければ共有資料として不十分です。形式の特徴を理解したうえで、実際の運用手順まで設計することが大切です。

「geojson 使い方」を調べている段階では、まずGeoJSONを単なる地図ファイルではなく、位置情報を業務で再利用するためのデータ形式として捉えると理解しやすくなります。そのうえで、関係者に見せるための形式としてKMLを活用すれば、データ管理と現場共有を両立できます。

現場で取得した位置、図面上の区域、点検箇所、施工範囲、出来形確認のポイントなどを正しく扱うには、形式選びだけでなく、実際の位置をどの精度で測り、どの属性と結び付け、どの形式で保管・共有するかを決めることが重要です。高精度な位置計測、現場記録、地図データ化の流れを整理しておけば、GeoJSONやKMLを単なるファイル交換ではなく、継続的に使える現場データとして活用しやすくなります。