GeoJSONとKMLの違いを用途別に比較する4つの視点

GeoJSONとKMLは、どちらも地図上の位置情報や図形情報を扱うためのデータ形式です。点、線、面といった地物を表現できる点では共通していますが、実務で使う場面、編集しやすさ、連携しやすい環境、属性情報の扱い方、現場での確認方法には違いがあります。特に「geojson」で検索している実務担当者にとっては、単に形式の定義を知るだけでなく、どの業務ではGeoJSONを選び、どの業務ではKMLを使うと扱いやすいのかを判断できることが重要です。

目次

• GeoJSONとKMLの基本的な考え方を整理する

• 視点1としてデータ構造と編集しやすさを比較する

• 視点2としてWeb地図やシステム連携での使いやすさを比較する

• 視点3として現場確認や共有用途での使いやすさを比較する

• 視点4として測量・施工・管理業務での選び方を比較する

• GeoJSONとKMLを変換して使うときの注意点

• まとめとして用途に合った形式選定で手戻りを減らす

GeoJSONとKMLの基本的な考え方を整理する

GeoJSONとKMLは、どちらも位置情報を扱うためのファイル形式として使われます。地図上に点を置いたり、道路や配管のような線を表したり、敷地や区域のような面を表したりすることができます。そのため、災害マップ、施設管理、現地調査、施工計画、境界確認、設備台帳、点検記録など、さまざまな業務で利用候補になります。

ただし、両者は同じ目的で作られた形式ではありません。GeoJSONは、位置情報をJSONベースの構造化データとして扱う形式です。標準的なGeoJSONでは、地物をFeatureとして表し、形状情報と属性情報を分けて整理します。点、線、面などの形状を地図上に表示するだけでなく、地物ごとの管理番号、種別、状態、更新日、点検結果などをシステム側で読み取りやすい形にできます。

一方、KMLは、XMLベースの地図表示用データとして使われることが多い形式です。地点、線、面に名称や説明を付けたり、表示スタイル、フォルダ階層、視点情報などを含めたりしやすいことが特徴です。現場関係者に「この場所を見てほしい」「この範囲を確認してほしい」と伝えるような場面では、KMLの考え方が分かりやすい場合があります。

実務上の大きな違いは、GeoJSONがデータ処理寄り、KMLが表示・共有寄りという点です。もちろん、GeoJSONでも地図表示はできますし、KMLでもExtendedDataなどを使って追加情報を持たせることはできます。しかし、ファイルを作成した後にシステムへ組み込むのか、関係者へ配布して地図上で確認してもらうのか、継続的に更新するのか、一時的な説明資料として使うのかによって、向き不向きが変わります。

また、GeoJSONでは座標の順序と座標参照系の前提に注意が必要です。標準仕様に沿うGeoJSONでは、座標は経度、緯度の順で記述します。必要に応じて高さを3番目の値として持てますが、基本的にはWGS 84に基づく経度緯度の地理座標として扱う前提です。現場でよく使われる「緯度、経度」という言い方と順序が逆に見えるため、手入力や独自変換では取り違えが起きやすくなります。

KMLでもcoordinates要素では、経度、緯度、高さの順で座標を記述します。高さは省略でき、表示環境や高度モードの設定によって解釈が変わる場合があります。つまり、GeoJSONとKMLはいずれも地図上の位置を扱えますが、座標順序、高さ、表示環境での解釈を確認しないまま変換すると、表示ずれや情報欠落につながります。

GeoJSONとKMLの比較では、単に「どちらが優れているか」を考えるのではなく、「何をしたいのか」を基準にすることが大切です。たとえば、Webシステム上で複数の地物を扱い、属性検索や更新を前提にするならGeoJSONが扱いやすい場面が多くなります。反対に、限られた地物を地図閲覧用にまとめ、関係者に位置や範囲を共有することを優先するならKMLが便利な場面もあります。形式の違いを理解することは、データ作成後の作業負担を減らすための実務判断でもあります。

視点1としてデータ構造と編集しやすさを比較する

最初の比較視点は、データ構造と編集しやすさです。GeoJSONは、位置情報を地物、形状、属性に分けて整理しやすい形式です。点、線、面などの形状を持つ地物に対して、名称、種別、管理番号、状態、更新日、点検結果などの属性を付けられます。これにより、地図として見るだけでなく、データベースや表形式の台帳と連携させる考え方に向いています。

GeoJSONの特徴は、構造が機械処理に向いていることです。人間が読んでもある程度理解できますが、特にシステムが読み取りやすい形式として強みがあります。たとえば、複数の現場点検結果をGeoJSONとして管理すれば、属性値によって未点検、要確認、対応済みといった分類を行いやすくなります。地物の種類ごとに表示色を変えたり、条件に合う地物だけを抽出したりする処理も組み込みやすくなります。

一方、KMLは、地図上でどのように表示するかを含めて記述しやすい形式です。名称、説明、線の色、面の塗り、アイコンの見え方、階層的なフォルダ構成などを持たせる考え方と相性があります。地図上で確認する人にとっては、KMLのほうが「見せるデータ」として扱いやすいことがあります。特に、少数の地点やエリアを分かりやすくまとめ、説明付きで共有するような用途では、KMLの構造が役立ちます。

ただし、属性情報の扱いやすさで見ると、GeoJSONのほうが実務システムに組み込みやすい場面が多くなります。KMLにも説明文や拡張的な情報を入れることはできますが、各地物の属性を統一的に管理し、条件検索や集計に使う場合は、GeoJSONのほうが設計しやすい傾向があります。たとえば、すべての地物に管理番号、点検日、状態、担当者、備考を持たせ、後から一覧化するような使い方では、GeoJSONのほうが処理の見通しを立てやすくなります。

編集しやすさについても、作業内容によって評価が変わります。テキストとして開いて細かな属性を確認したり、プログラムで一括修正したりする場合は、GeoJSONが扱いやすいです。地物の属性名を統一し、不要な項目を削除し、座標の桁数を調整し、複数ファイルを結合するといった作業も、データ処理の流れに乗せやすくなります。

一方、現場説明用の見た目を調整したい場合は、KMLが分かりやすいことがあります。地図閲覧環境で目印を追加し、名称や説明を付け、線や面の見え方を整えてから共有するような作業では、KMLが自然に使われる場面があります。関係者がファイルを開いたときに、階層や表示状態をそのまま確認できる構成にしやすい点も利点です。

実務でよく起きる問題は、データ構造の目的を決めないまま形式だけを選んでしまうことです。たとえば、後で台帳連携や検索に使う予定があるのに、見た目中心でKMLを作り込むと、属性を取り出す段階で手間が増える可能性があります。反対に、現場説明だけでよいのにGeoJSONを単体ファイルとして渡しても、受け取る側の環境によっては開き方や見方が分からず、確認が進まないことがあります。

そのため、データ構造の観点では、まず地物を業務データとして管理したいのか、地図上の説明資料として共有したいのかを整理する必要があります。前者ならGeoJSONが有力であり、後者ならKMLが候補になります。どちらを使う場合でも、地物名、属性名、座標の桁数、更新ルール、ファイル分割の単位をあらかじめ決めておくことで、後工程の混乱を減らせます。

視点2としてWeb地図やシステム連携での使いやすさを比較する

次の比較視点は、Web地図や業務システムとの連携です。GeoJSONは、Web上で地図データを表示したり、システム間で位置情報を受け渡ししたりする用途に向いています。多くのWeb開発環境では、GeoJSONのような構造化されたデータを読み込み、地物を画面に描画し、属性に応じてスタイルを変え、クリック時に情報を表示する処理を作りやすくなっています。

GeoJSONがWeb連携で使いやすい理由は、データの中身をプログラムで扱いやすいからです。地物ごとの形状と属性が分かれており、属性値を条件にして表示を変えられます。たとえば、施設点検のデータであれば、異常ありの地点だけを強調し、対応済みの地点は薄く表示し、未点検の地点を一覧で抽出するといった処理が考えられます。こうした動的な処理は、GeoJSONの構造と相性が良いです。

また、GeoJSONは、他のデータ形式やデータベースとつなぐ際にも扱いやすいです。業務システムでは、地物の位置だけでなく、管理番号、所有区分、施工日、点検履歴、写真番号、担当部署など、多くの属性を同時に扱います。GeoJSONは、これらの属性を地物ごとに持たせやすいため、地図表示と台帳管理をつなぐ中間形式として利用しやすいです。

一方、KMLは、Webシステム内部で細かく処理するというよりも、地図閲覧用のファイルとして読み込む、または関係者へ共有する用途に向くことがあります。KMLには表示スタイルや階層構造を含めやすいため、作成者が意図した見せ方をある程度保ちながら配布できます。現場説明、簡易的な位置共有、区域確認、候補地の確認などでは、KMLを受け取った人が地図上で視覚的に確認しやすい場面があります。

ただし、Webシステムに組み込む前提では、KMLの表示情報が必ずしもそのまま業務データとして使いやすいとは限りません。説明文の中に複数の情報がまとめて書かれている場合、後から管理番号や状態だけを取り出すのが難しくなります。表示上は分かりやすくても、データ処理上は扱いにくい構成になることがあります。

ファイルサイズや読み込み速度の観点でも注意が必要です。GeoJSONは、属性を多く持たせたり座標点数が多かったりするとファイルが大きくなります。KMLも、表示スタイルや説明文、複雑な形状が増えると重くなることがあります。どちらの形式でも、大量の地物や細かすぎる線形をそのままWeb画面に表示しようとすると、読み込みが遅くなったり、操作が重くなったりします。

GeoJSONをWeb地図で使う場合は、用途に応じて座標精度を調整し、表示に不要な属性を削除し、地物数が多い場合は範囲や種類ごとに分割することが重要です。たとえば、広域の区域境界を概略表示するだけであれば、測量成果そのものの細かさをすべて持ち込む必要はありません。表示縮尺に対して過剰な座標点を減らすことで、画面表示を軽くできます。

KMLをWebシステムに取り込む場合は、表示用の情報と業務用の属性を分けて考える必要があります。KMLをそのまま使うのではなく、必要な地物と属性を抽出し、システム側で扱いやすい構造に整える工程が必要になることがあります。この変換時に、地物名、説明文、階層、スタイルのどれを保持するのかを決めておかないと、見た目は変換できても、業務上必要な情報が失われる可能性があります。

システム連携を重視するなら、GeoJSONを基本形式として検討し、KMLは外部共有や閲覧用に書き出すという考え方が現実的です。反対に、社内外の関係者が地図閲覧ファイルとしてやり取りするだけであれば、KMLを中心にしても問題ない場面があります。重要なのは、最終的にどの画面で、誰が、どの頻度で、どの属性を使うのかを先に決めることです。

視点3として現場確認や共有用途での使いやすさを比較する

三つ目の比較視点は、現場確認や関係者への共有です。実務では、データを作る人と現場で確認する人が同じとは限りません。設計担当者、測量担当者、施工担当者、維持管理担当者、発注者、協力会社など、立場の異なる人が同じ位置情報を見ながら判断することがあります。このとき、ファイル形式の選定は、受け取る側が迷わず開けるか、地図上で意図を理解できるかに大きく関わります。

KMLは、現場確認や共有に向いている場面があります。地図閲覧用のデータとして、地点名、説明、線や面のスタイル、階層構造を含めやすいため、受け取った人が地図上で内容を把握しやすいからです。たとえば、候補地、進入路、仮設ヤード、立入制限範囲、点検対象箇所などを示す場合、KMLでまとめると、地図を開いたときに確認したい場所へたどり着きやすくなります。

特に、現場説明では、データの厳密な属性構造よりも「どこを見ればよいか」が優先されることがあります。KMLは、そうした視覚的な共有に向いています。地物を階層に分け、名称を付け、説明を加えることで、地図上のメモとして機能します。短期間の確認や打ち合わせ資料としては、KMLのほうが扱いやすいと感じる担当者もいます。

一方、GeoJSONは、共有相手がWebシステムや専用の業務画面で確認する場合に強みがあります。現場担当者がブラウザや業務アプリ上で点検対象を確認し、属性を更新し、写真やメモとひも付けるような運用では、GeoJSONの構造が役立ちます。地物ごとに状態や担当を持たせられるため、現場確認の結果をデータとして回収しやすくなります。

つまり、単純な閲覧共有ならKML、更新や集計を伴う現場運用ならGeoJSONという分け方ができます。ただし、これは絶対的な区分ではありません。KMLでも現場確認はできますし、GeoJSONでも見やすい地図画面は作れます。判断のポイントは、共有後にデータをどう使うかです。見るだけで終わるのか、見た結果を記録し、次の工程に渡すのかによって、適した形式は変わります。

現場共有で注意したいのは、座標の精度と見た目の分かりやすさを混同しないことです。地図上で線や面が表示されていると、それが正確な位置を示しているように見えます。しかし、元データの測位精度、座標参照系、変換方法、地図背景のずれ、端末側の測位状態によって、表示位置には差が出る可能性があります。KMLでもGeoJSONでも、表示されたから正しいとは限りません。

現場で位置確認に使う場合は、ファイル形式だけでなく、測位方法や基準点、座標系、現地での照合手順まで含めて考える必要があります。たとえば、施工位置の確認、境界付近の確認、出来形の確認、設備設置位置の確認では、単なる地図閲覧では不足する場合があります。このような場面では、GeoJSONやKMLを現場用の背景データとして使いながら、高精度測位や現地照合の仕組みと組み合わせることが重要になります。

共有用途では、ファイルを受け取る人のIT環境にも配慮が必要です。KMLは閲覧用として渡しやすい反面、受け手の環境によって表示のされ方が異なることがあります。GeoJSONはシステム連携しやすい反面、単体ファイルとして渡された場合に、受け手がそのまま開けないことがあります。したがって、社外共有や現場配布では、ファイル形式だけを渡すのではなく、開き方、確認範囲、更新してよい項目、注意点を合わせて伝えることが大切です。

実務では、GeoJSONをマスターデータとして管理し、現場説明用にKMLへ書き出すという運用も考えられます。この方法なら、業務データとしての整合性を保ちながら、現場では見やすい形で共有できます。逆に、現場からKMLで受け取った情報をGeoJSONへ変換し、属性を整理して台帳に取り込む運用もあります。どちらの場合でも、変換時に何を失ってはいけないかを明確にしておく必要があります。

視点4として測量・施工・管理業務での選び方を比較する

四つ目の比較視点は、測量、施工、維持管理といった業務別の選び方です。GeoJSONとKMLは、地図データ形式として共通点がありますが、現場業務では「どの工程で使うか」によって適性が変わります。測量成果の確認、施工範囲の共有、点検対象の管理、災害対応時の情報整理など、目的が異なれば必要な情報の粒度も変わります。

測量や現況確認に近い業務では、GeoJSONは属性付きの地物管理に向いています。たとえば、測点、境界候補、施設位置、現況線、区域ポリゴンなどを地物として整理し、それぞれに種別や確認状況を持たせることができます。後から測点だけを抽出したり、未確認の区域だけを表示したりする場合、GeoJSONの属性構造は便利です。

ただし、GeoJSONを測量成果そのものとして扱う場合には注意が必要です。GeoJSONは地図データの交換や表示に便利ですが、すべての測量成果や設計データの厳密な表現に向いているわけではありません。精度、座標系、高さ、曲線、注記、レイヤ構成、観測記録など、業務上必要な情報が別形式で管理されている場合もあります。GeoJSONに変換するときは、何を簡略化しているのかを理解する必要があります。

施工業務では、KMLが説明用として役立つ場面があります。施工範囲、搬入ルート、仮置き場所、危険箇所、立入禁止区域、作業予定範囲などを地図上で共有する場合、KMLは見た目を整えやすく、関係者に伝えやすい形式です。日々の打ち合わせや現地確認の資料として、地図上に線や面を重ねて確認する用途には向いています。

一方、施工管理の記録や進捗管理まで視野に入れるなら、GeoJSONが有力になります。施工済み、未施工、確認待ち、是正済みといった状態を属性として管理できるため、地図上で進捗を可視化しやすくなります。さらに、日付、担当、写真番号、検査結果などとひも付ければ、単なる地図表示ではなく、管理データとして活用できます。

維持管理業務では、GeoJSONのほうが長期運用に向いている場面が多いです。道路付属物、排水設備、電気設備、標識、境界杭、点検箇所などを継続的に管理する場合、地物ごとに属性を持たせ、更新履歴や点検結果と結び付ける必要があります。こうした台帳型の運用では、GeoJSONの構造を基礎にすると、他の管理システムと連携しやすくなります。

ただし、維持管理でも現場説明用にはKMLが便利です。たとえば、点検対象の範囲を一時的に共有したり、修繕候補箇所を関係者に見せたりする場合には、KMLとして出力することで、地図上で直感的に確認しやすくなります。つまり、維持管理ではGeoJSONを内部管理用、KMLを外部説明用または閲覧用として使い分ける考え方が実務的です。

災害対応や緊急確認のような場面では、スピードと共有性が重要になります。被害箇所、通行止め、避難関連施設、危険区域などを急いで地図化する場合、関係者がすぐ確認できる形式が求められます。この場合、短期的な共有ではKMLが便利なことがあります。一方で、複数の情報を集約し、状態を更新し、関係者ごとに表示を切り替える場合はGeoJSONのほうが扱いやすくなります。

業務別に見ると、GeoJSONは更新するデータ、検索するデータ、集計するデータ、システムに取り込むデータに向いています。KMLは見せるデータ、共有するデータ、説明するデータ、一時的に確認するデータに向いています。この違いを理解しておくと、形式選定で迷いにくくなります。

重要なのは、最初から一つの形式に固定しないことです。業務の中心となるデータはGeoJSONで整備し、現場や関係者に渡すときはKMLへ変換する。あるいは、関係者からKMLで受け取った位置情報をGeoJSONに整理し直して管理する。このような使い分けを前提にすれば、各形式の強みを活かしながら、実務上の手戻りを抑えられます。

GeoJSONとKMLを変換して使うときの注意点

GeoJSONとKMLは相互に変換して使われることがあります。たとえば、地図閲覧用に作られたKMLを業務システムで使うためにGeoJSONへ変換したり、GeoJSONで管理している地物を関係者共有のためにKMLへ書き出したりする場面です。変換自体は一般的な作業ですが、実務では変換後のデータを必ず確認する必要があります。

まず注意したいのは、座標の順序です。GeoJSONでは標準的に経度、緯度の順で座標を扱います。一方、現場で口頭説明するときは緯度、経度の順で言われることも多く、混乱が起きやすい部分です。KMLのcoordinates要素でも、経度、緯度、高さの順で記述します。手入力や独自変換を行う場合、順序を取り違えると、地物がまったく違う場所に表示されます。

次に、座標参照系の扱いです。標準的なGeoJSONやKMLを地図上で表示する場合、多くの環境では地球上の経度緯度を前提に扱います。しかし、実務データには平面直角座標、ローカル座標、工事基準の座標、図面上の座標などが含まれることがあります。これらをそのままGeoJSONやKMLに入れても、正しい位置に表示されません。変換前に、元データがどの座標系なのかを確認する必要があります。

高さ情報にも注意が必要です。KMLでは高さを含めた表現が使われることがありますが、すべての表示環境で同じように扱われるとは限りません。GeoJSONでも座標に高さを含められますが、地図表示やシステム処理で高さが無視されることがあります。施工や測量で高さが重要な場合は、ファイル形式に含めるだけでなく、受け側のシステムが高さをどう扱うかを確認する必要があります。

属性情報の欠落もよくある問題です。KMLの説明文にまとめて書かれている情報をGeoJSONへ変換すると、属性としてきれいに分かれないことがあります。逆に、GeoJSONの属性をKMLへ変換すると、どの属性を名称として使うのか、どの属性を説明に入れるのかを決める必要があります。変換後に見た目だけを確認して安心すると、必要な管理番号や点検結果が抜けていることがあります。

スタイル情報の扱いも異なります。KMLでは線色、面色、アイコンなどの表示スタイルを含めやすいですが、GeoJSONではスタイルを別の設定として扱うことが多くなります。そのため、KMLからGeoJSONへ変換したときに、見た目の設定が失われることがあります。GeoJSONからKMLへ変換する場合も、属性に応じた色分けをどのように反映するかを決める必要があります。

線や面の形状も確認が必要です。変換時に座標点が間引かれたり、面の内外の扱いが変わったり、複数の面が一つにまとまったりすることがあります。特に、境界線、施工範囲、規制範囲、災害区域など、形状そのものが重要なデータでは、変換後に地図上で重ね合わせ確認を行うことが欠かせません。面積や延長を使う場合は、表示確認だけでなく、計算条件も確認する必要があります。

文字コードや日本語項目名にも注意が必要です。ファイルを別の環境で開いたときに、日本語の名称や説明が文字化けする場合があります。現場名、地物名、備考、担当者名などが読めなくなると、共有データとして機能しません。変換後は、地図表示だけでなく、属性の文字が正しく読めるかも確認する必要があります。

変換運用で大切なのは、変換前後のチェック項目を決めておくことです。位置が合っているか、地物数が変わっていないか、点、線、面の種類が保たれているか、属性が残っているか、名称が正しく表示されるか、必要なスタイルが反映されているか、座標系の前提が合っているかを確認します。毎回担当者の勘に頼るのではなく、確認手順として固定しておくことで、ミスを減らせます。

また、元データを残しておくことも重要です。GeoJSONからKMLへ変換した後、KML側を編集してしまうと、どちらが正しい最新データなのか分からなくなることがあります。マスターデータをどちらに置くのか、変換後ファイルは閲覧用なのか、編集して戻してよいのかを決めておかないと、データの不整合が起きます。実務では、マスターデータ、共有用データ、現場確認用データを分けて管理する考え方が有効です。

まとめとして用途に合った形式選定で手戻りを減らす

GeoJSONとKMLは、どちらも地図上の点、線、面を扱える便利な形式ですが、実務での役割は同じではありません。GeoJSONは、属性付きの地物をシステムで扱い、検索、更新、集計、Web地図表示に活用する用途に向いています。KMLは、地図上で分かりやすく見せ、関係者に位置や範囲を共有する用途に向いています。

用途別に整理すると、内部管理や台帳連携、Webシステム連携、点検結果の更新、進捗管理にはGeoJSONが適しています。現場説明、簡易共有、候補地確認、打ち合わせ用の地図配布にはKMLが使いやすい場面があります。どちらか一方を常に選ぶのではなく、業務の入口、処理、共有、保管のどこで使うのかを分けて考えることが大切です。

形式選定で失敗しやすいのは、見た目だけで判断してしまうことです。地図上にきれいに表示できても、属性が管理できなければ後工程で困ります。反対に、データ構造が整っていても、現場の人が開けない形式では確認作業が進みません。GeoJSONとKMLの違いは、見た目の差というよりも、業務の流れに対する適性の差として理解する必要があります。

また、GeoJSONとKMLを変換して使う場合は、座標順序、座標参照系、高さ、属性、スタイル、文字化け、地物数の変化を必ず確認することが重要です。変換できたことと、業務で安全に使えることは同じではありません。特に、施工位置、境界、設備位置、点検対象、災害範囲など、位置の誤りが手戻りや判断ミスにつながるデータでは、現地照合まで含めた確認が必要です。

実務担当者がGeoJSONを扱うときは、まずマスターデータとして何を管理したいのかを決めることが出発点になります。属性を整理し、座標系を確認し、更新ルールを決め、必要に応じてKMLなどの共有用形式に書き出す流れを作れば、地図データを単なる表示資料ではなく、業務を支える情報基盤として活用できます。

一方で、現場では地図データだけでは判断しきれない場面もあります。図面やGeoJSON、KMLで示した位置を、実際の現地でどのように確認するかが重要です。机上の地図データと現場の位置をつなぐには、測位精度、座標系、現地基準、確認手順をそろえる必要があります。

GeoJSONやKMLを使った位置情報管理を、現場での確認や施工管理までつなげたい場合は、スマートフォンやタブレットで扱える地図データと、高精度GNSS測位や現地照合の仕組みを組み合わせる方法が有効です。データ形式の違いを理解したうえで、どの形式をマスターにするのか、どの形式を共有用にするのか、現場ではどの精度で確認するのかを決めておくことが、位置情報活用の精度と効率を高める近道です。