GeoJSONは、位置情報を含む地図データをJSON形式で扱えるため、部門間の共有、外部委託先との受け渡し、Web地図への表示、現地調査データの整理などで使いやすい形式です。一方で、GeoJSON形式で保存しただけで、誰にとっても正しく使える共有データになるわけではありません。座標の前提、属性情報の意味、ファイル容量、更新ルール、現地確認とのつなぎ方を決めておかないと、同じデータを見ているはずなのに位置がずれる、どの地物が最新かわからない、属性の意味が担当者ごとに違うといった問題が起こります。
この記事では、「geojson 使い方」で調べている実務担当者に向けて、GeoJSONを地図データ共有に使うときに押さえておきたい5つの実務ポイントを解説します。
GeoJSONで共有する目的と地物の単位を先に決める
GeoJSONを地図データ共有に使うとき、最初に決めるべきことは、どの情報を何のために共有するのかという目的です。GeoJSONは点、線、面といった地物を扱える形式ですが、目的が曖昧なまま作成すると、後から属性が足りない、地物の分け方が合わない、現地確認に使いにくいといった問題が起こりやすくなります。
たとえば、設備位置を共有したい場合は、設備一つひとつを点として管理するのか、設備群や管理範囲を面として管理するのかでデータの作り方が変わります。道路や配管のような連続した対象であれば線として扱うことが多くなりますが、施工区間ごとに分けるのか、管理番号ごとに分けるのか、点検単位ごとに分けるのかによって、共有後の使いやすさは大きく変わります。地図上に見える形だけでなく、誰がどの単位で判断し、更新し、報告するのかを考える必要があります。
GeoJSONの中心になる考え方は、Featureという地物単位で情報を持つことです。Featureには形状を表すgeometryと、名称や管理番号などを入れるpropertiesがあります。この構造を理解しておくと、地図上の図形と業務上の情報を一体で扱いやすくなります。ただし、何でも一つのFeatureにまとめればよいわけではありません。複数の対象を一つのFeatureにしてしまうと、個別の更新や検索がしにくくなります。逆に細かく分けすぎると、地物数や管理項目が増え、運用が複雑になります。
共有目的が閲覧中心なのか、現地での確認に使うのか、後から集計するのかによっても適切な地物単位は変わります。閲覧中心であれば、地図上で見やすいまとまりを優先できます。現地確認に使う場合は、担当者が現場で一つずつ確認しやすい単位に分けることが重要です。集計に使う場合は、面積、延長、件数、状態区分などを後から集計しやすいように、属性と地物単位をそろえる必要があります。
実務では、GeoJSONを作る前に、このデータを受け取った人が最初に何を確認するのかを具体的に想定すると失敗が少なくなります。地図上で位置を見るだけなのか、対象物を選択して詳細を読むのか、状態ごとに色分けするのか、修正箇所を返送してもらうのかを先に整理します。これにより、必要な属性、地物の分け方、ファイル名、更新ルールが決まりやすくなります。
また、地物の種類を混在させる場合にも注意が必要です。一つのGeoJSONファイルの中に点、線、面を混ぜることはできますが、共有先の利用環境によっては表示や編集がしにくくなることがあります。点データは設備、線データは路線、面データは範囲というように、種類ごとに分けておくと扱いやすくなります。特に実務では、点の一覧を検索したい人、線の延長を確認したい人、面の範囲を確認したい人が異なる場合があります。利用者が異なるなら、データも分けておいた方が混乱を防ぎやすくなります。
地図データ共有では、見た目のきれいさよりも、判断に使えることが重要です。GeoJSONはJSON形式なので、内容を確認しやすく、別の仕組みに取り込みやすいという利点があります。しかし、業務上の意味が整理されていなければ、形式だけ整っていても使いにくいデータになります。共有前には、地物の単位、対象範囲、属性の意味、更新担当者を簡単なルールとしてまとめておくと、受け渡し後の認識違いを減らせます。
座標参照系と位置精度の前提を共有ルールに含める
GeoJSONを使ううえで特に重要なのが、座標の扱いです。標準的なGeoJSONでは、座標は経度、緯度の順で記述し、単位は度で扱います。多くの表計算データや現場メモでは緯度、経度の順で書かれることもあるため、変換時に順番を取り違えると、地物がまったく別の場所に表示される原因になります。地図データ共有では、座標値そのものだけでなく、座標の順序、単位、取得方法、想定精度を確認することが欠かせません。
GeoJSONの標準仕様では、座標参照系はWGS 84を使う経度緯度の地理座標系で、OGCのCRS84に相当するものとして扱われます。そのため、日本の平面直角座標系、ローカル座標、図面座標、測量成果の座標をそのままGeoJSONとして渡すと、利用環境によっては意図しない位置に表示されるおそれがあります。元データが別の座標参照系で管理されている場合は、共有前に経度緯度へ変換するか、関係者間で前提を明確にしたうえで扱う必要があります。
GeoJSONの座標は、点であれば一組の座標、線であれば複数の座標列、面であれば閉じた座標列として表現されます。面データの場合、外周や穴を表す線は始点と終点を一致させて輪を閉じる必要があります。こうした基本構造を理解せずに手作業で修正すると、表示できないGeoJSONになったり、面が意図しない形で描画されたりします。特に境界線や施工範囲などを共有する場合は、形状が正しく閉じているか、線が不自然に交差していないか、不要な頂点が混ざっていないかを確認することが大切です。
位置精度についても、共有先に誤解されやすい部分です。GeoJSONに細かい桁数の座標が入っているからといって、必ずしも高精度な測位で取得されたデータとは限りません。スマートフォンやタブレットで取得した座標、図面から読み取った座標、現地測量で得た座標、既存台帳から変換した座標では、信頼できる精度が異なります。共有時には、座標の取得方法と想定精度を属性や説明資料に入れておくと、利用者が過剰に信頼してしまうリスクを下げられます。
地図データを共有する実務では、この座標が何の位置を表しているのかも重要です。設備の中心なのか、端部なのか、確認者が立った位置なのか、写真を撮影した位置なのか、施工範囲の代表点なのかによって意味が変わります。GeoJSON上では同じ点として表示されても、業務判断ではまったく異なる情報になります。たとえば点検結果を示す点であれば、対象物の位置なのか、点検者が確認した位置なのかを明確にしておかないと、現地で迷う原因になります。
また、標高や高さを扱う場合にも注意が必要です。GeoJSONでは座標の三つ目の値として高さを含めることができますが、標準仕様上はWGS 84楕円体を基準にしたメートル単位の高さとして扱われます。共有先の表示環境によっては三つ目の値が表示や検索に使われないこともあります。高さを業務上重要な情報として扱う場合は、座標の三つ目の値に入れるだけでなく、propertiesにも高さ、基準、測定方法などを入れておくと安全です。特に施工管理、設備管理、災害調査などでは、高さの基準が異なると判断が変わることがあります。
実務でよくある失敗は、表示できたことをもって正しいデータだと判断してしまうことです。GeoJSONは形式が正しければ地図上に表示されることが多いですが、表示された位置が業務上正しいとは限りません。共有前には、既知の地点と重ねて位置を確認する、代表点を現地写真や図面と照合する、範囲の外れや極端な座標値がないか確認するなど、最低限の品質確認を行うとよいです。
GeoJSONを地図データ共有に使う場合、座標の前提はデータの信頼性そのものです。座標の順序、座標参照系、取得方法、精度、基準、高さ情報の扱いを共有ルールに含めておくことで、データを受け取った人が安心して判断に使えるようになります。
属性情報は検索・集計・更新を意識して設計する
GeoJSONの使いやすさは、地図上の形だけでなく、propertiesに入れる属性情報によって大きく変わります。属性情報とは、地物に付随する名称、管理番号、分類、状態、確認日、備考などの情報です。地図上で位置がわかっても、属性が整理されていなければ、検索や集計、更新がしにくくなります。
属性設計でまず考えたいのは、共有後にどの項目で探すのかという視点です。現場担当者が対象物を探すなら、管理番号、名称、区間名、住所に相当する情報が必要になることがあります。管理部門が状況を集計するなら、状態区分、点検結果、優先度、更新日などが重要になります。外部委託先に修正を依頼するなら、修正対象かどうか、修正内容、確認者、確認状況を入れておくとやり取りがしやすくなります。
属性名は、短くても意味が伝わる名前にすることが大切です。担当者だけがわかる略語や、部署内だけで通じる表記を使うと、共有先で誤解される可能性があります。たとえばstatusという項目名だけでは、点検状態なのか、施工状態なのか、承認状態なのかが曖昧になることがあります。必要に応じてinspection_statusやwork_statusのように意味がわかる名前にすると、後から扱いやすくなります。
値の入れ方も重要です。同じ状態を表すのに、完了、済、対応済みのような表記が混在すると、検索や集計で漏れが出ます。GeoJSONは自由に属性を入れられるため便利ですが、自由度が高い分、入力ルールを決めないとデータ品質が下がります。状態区分、種別、優先度などは、あらかじめ使う値を決めておくとよいです。自由記述が必要な場合でも、検索や集計に使う項目と、補足説明に使う項目を分けておくと運用しやすくなります。
日付の形式もそろえる必要があります。点検日、更新日、撮影日、共有日などを入れる場合、表記がばらばらだと並べ替えや期間検索が難しくなります。年、月、日を一定の形式で記録し、必要に応じて時刻も含めます。複数地域の関係者と共有する場合は、日付の読み違いが起こらないように、月日年の順序が曖昧にならない形式を使うことが大切です。
属性情報には、地図表示のための項目と業務管理のための項目があります。表示のための項目には、ラベル名、色分け区分、表示順などがあります。業務管理のための項目には、管理番号、担当部署、確認状況、更新履歴に関する情報があります。この二つを混ぜて考えると、見た目を変えるたびに業務データまで変わってしまうことがあります。表示用の項目と管理用の項目を分けておくと、後から使い回しやすいGeoJSONになります。
また、属性に個人情報や機密情報を入れすぎないことも大切です。GeoJSONは中身を確認しやすく、メールや共有フォルダで渡されることも多い形式です。そのため、必要以上に担当者名、連絡先、詳細な契約情報、内部メモなどを入れると、共有範囲が広がったときに管理が難しくなります。外部共有用のGeoJSONと内部管理用のGeoJSONを分ける、共有前に不要な属性を削除する、公開範囲に応じて項目を制限するなどの運用が必要です。
更新を前提にする場合は、IDの設計が特に重要です。地物ごとに一意のIDを持たせておくと、共有後に修正されたデータを戻すとき、どの地物が変更されたのかを追いやすくなります。GeoJSONではFeatureにidを持たせることもできますし、propertiesの中に管理用IDを持たせる運用もあります。どちらの場合でも、IDは途中で変えないことが基本です。地物を削除した場合や分割した場合の扱いも、簡単なルールを決めておくと運用が安定します。
GeoJSONの属性情報は、単なる補足情報ではなく、地図データを業務に使うための入口です。検索したい項目、集計したい項目、更新時に必要な項目、共有時に隠したい項目を整理しておくことで、地図データは単なる図形から、実務で使える情報資産になります。
ファイル容量と表示速度を考えてデータを分ける
GeoJSONはJSON形式で扱いやすい一方、地物数や頂点数が増えるとファイル容量が大きくなりやすい形式です。小規模な点データであれば問題になりにくいですが、広い範囲の境界線、細かい道路形状、多数の設備、詳細な面データを一つのファイルにまとめると、読み込みに時間がかかったり、表示が重くなったりします。共有先で快適に使えるようにするには、ファイル容量と表示速度を意識した設計が必要です。
まず考えたいのは、一つのGeoJSONファイルにすべてを詰め込まないことです。共有の目的ごとに、点、線、面、対象エリア、業務区分、更新頻度などで分けると、必要なデータだけを読み込めるようになります。たとえば、設備位置と点検範囲と施工予定範囲をすべて一つのファイルに入れるより、それぞれを分けた方が、表示切り替えや更新がしやすくなります。ファイルを分けることで、共有先も自分に必要な情報だけを扱えます。
ただし、細かく分けすぎると、どのファイルを使えばよいかわからなくなります。ファイル分割は、利用者が理解できる単位にすることが重要です。地域別、案件別、年度別、地物種別、用途別など、業務で自然に使われている分類に合わせると運用しやすくなります。ファイル名にも、対象範囲、内容、日付、版数がわかる情報を入れておくと、受け渡し時の取り違えを防げます。
表示速度に影響しやすいのは、地物の数だけではありません。線や面を構成する頂点の数も大きな要因です。図面や測量データから変換したGeoJSONには、非常に細かい頂点が含まれることがあります。詳細な形状が必要な場面もありますが、閲覧や概要共有が目的であれば、細かすぎる形状がかえって扱いにくくなることがあります。用途に応じて、詳細版と共有版を分ける考え方が有効です。
地図データ共有では、正確さと軽さのバランスを考える必要があります。施工境界や管理境界のように精度が重要なデータでは、安易に形状を簡略化すると問題になることがあります。一方で、全体位置の説明や関係者への概要共有では、細部よりも読み込みやすさが優先されることがあります。GeoJSONを共有する前に、このデータは現地作業の基準にするものなのか、説明用の参考図なのかを明確にしておくことが大切です。
容量を抑えるためには、不要な属性を削除することも効果的です。変換元のデータから多くの属性がそのまま入っていると、使わない項目まで共有され、ファイルが大きくなります。共有先が必要としない内部管理項目、空欄ばかりの項目、同じ値が繰り返される項目は見直しの対象になります。特に外部共有では、容量だけでなく情報管理の観点からも、必要最小限の属性に整理することが望ましいです。
文字コードや改行、整形の扱いにも注意が必要です。GeoJSONは人が読めるように整形することもできますが、整形によってファイルサイズが増える場合があります。編集や確認を重視する段階では読みやすい形にし、配布用には余分な空白を減らすという運用も考えられます。ただし、手作業で圧縮や変換を繰り返すと内容確認が難しくなることがあるため、元データと配布データを分けて管理すると安心です。
共有先の利用環境も確認しておきたいポイントです。高性能な業務用端末で扱うのか、現場のタブレットで扱うのか、通信環境が安定している場所で使うのか、山間部や地下、災害現場のように通信が不安定な場所で使うのかによって、許容できるファイル容量は変わります。現地で使うGeoJSONは、できるだけ軽く、必要な情報に絞る方が実用的です。
ファイル容量と表示速度の問題は、作成者の環境では気づきにくいことがあります。作成した端末では問題なく表示できても、共有先では読み込みに時間がかかる場合があります。公開前や配布前には、実際に使う環境に近い条件で読み込み確認を行うとよいです。特に、複数のGeoJSONを同時に表示する運用では、単体のファイル容量だけでなく、合計の負荷を考える必要があります。
GeoJSONは地図データ共有に使いやすい形式ですが、どんな規模のデータでもそのまま快適に扱えるわけではありません。目的別に分ける、不要な属性を削る、詳細度を使い分ける、共有先の環境で確認するという基本を押さえることで、実務で扱いやすい地図データになります。
更新履歴と現地確認の流れを決めて運用する
GeoJSONを一度作成して共有するだけなら、形式の確認と表示確認で済むこともあります。しかし実務では、地図データは何度も更新されます。新しい設備が追加される、点検結果が変わる、施工範囲が修正される、現地確認で位置の誤りが見つかるなど、共有後の変更が発生します。そのため、GeoJSONを地図データ共有に使う場合は、更新履歴と現地確認の流れを最初から決めておくことが重要です。
まず必要なのは、どのファイルが最新なのかを誰でも判断できる状態にすることです。ファイル名に日付や版数を入れる、属性に更新日を持たせる、共有フォルダ内で最新版の置き場所を固定するなど、単純なルールでも効果があります。逆に、担当者ごとにファイル名の付け方が違うと、同じデータの複数版が混在し、どれを使って判断したのかわからなくなります。地図データは現場判断に影響することがあるため、版管理の曖昧さは避けるべきです。
更新履歴では、何が変わったのかを残すことも大切です。単に最新版だけを共有すると、前回との差分を確認できません。地物が追加されたのか、削除されたのか、位置が修正されたのか、属性だけが変わったのかを追えるようにしておくと、確認作業が効率化します。GeoJSON自体にすべての履歴を持たせる必要はありませんが、変更日、変更者または変更元、変更理由、確認状況などを管理できる仕組みを用意しておくと安心です。
現地確認を行う場合は、GeoJSON上の地物と現地で確認する対象を対応させる必要があります。ここで重要になるのが、一意のIDです。現地で、この点は移動が必要、この線は実際の位置と違う、この範囲は未施工といった確認結果が出たとき、どのFeatureに対する指摘なのかが明確でなければ、修正作業に時間がかかります。IDがあると、現地メモ、写真、修正依頼、更新後のデータを結び付けやすくなります。
現地確認の流れとしては、共有用GeoJSONを作成し、現地で対象を確認し、修正点を記録し、担当者がGeoJSONを更新し、再確認するという循環を想定します。この循環を曖昧にすると、現地で見つかった問題が反映されなかったり、誰かが手元で修正したファイルだけが残ったりします。特に複数人で確認する場合は、修正権限を持つ人と確認結果を報告する人を分けると、データの整合性を保ちやすくなります。
写真やメモとの連携も、GeoJSON運用では重要です。地図上の点や線だけでは、現地の状況を十分に説明できないことがあります。属性に写真番号、撮影日、確認メモ、関連資料の識別情報を入れておくと、後から判断しやすくなります。ただし、GeoJSONの中に長い文章や大量の情報を入れすぎると扱いにくくなるため、地図上で必要な要約情報と、詳細資料を分ける考え方が有効です。
外部委託先や協力会社とGeoJSONをやり取りする場合は、修正方法のルールも決めておく必要があります。元の地物を直接編集して返してもらうのか、修正指摘用の別ファイルを作ってもらうのか、属性に確認結果を追記してもらうのかによって、受け取り後の処理が変わります。直接編集を許可する場合は、IDを変更しない、属性名を変えない、不要な地物を削除しないといった基本ルールを伝えることが重要です。
現場で使うデータとして整えるには、見え方にも配慮が必要です。点、線、面が重なっている場合、表示順によって重要な対象が見えにくくなることがあります。表示の制御は利用環境側で行うことが多いですが、データを分けておく、属性に表示区分を持たせる、重要度を示す項目を入れるなど、共有データ側でも工夫できます。現地で確認したい対象がすぐに見つからないデータは、正確であっても使われにくくなります。
名称やラベルの付け方も実務上は重要です。地図上に表示する名称が長すぎると見づらくなり、短すぎると意味が伝わりません。管理番号だけでは現場担当者に伝わりにくい場合もありますし、名称だけでは同じ名前の対象を区別できない場合もあります。ラベル用の短い表示名と、詳細確認用の正式名称を分けて属性に入れておくと、閲覧性と正確性を両立しやすくなります。
承認や確定の扱いも整理しておきたい点です。現地確認済み、修正中、確認待ち、確定済みといった状態を属性で管理すると、地図上で進捗を把握しやすくなります。ただし、状態区分が多すぎると入力ミスや判断のばらつきが増えます。実務では、誰が見ても判断できる程度の区分に絞り、状態を変える条件を明確にしておくと運用しやすくなります。
更新履歴を残す際には、古いデータをいつまで保管するかも考える必要があります。過去版をすべて残すと安心ですが、ファイルが増えすぎると探しにくくなります。重要な節目の版だけを保管する、更新前後の差分がわかる記録を残す、確定版と作業版を分けるなど、業務の重要度に応じた保管ルールを作るとよいです。
GeoJSONを共有する実務では、作成時の正確さだけでなく、更新され続ける前提での運用設計が重要です。最新ファイルの判断、変更内容の把握、現地確認との対応、修正権限、承認状態の管理を決めておくことで、地図データを継続的に使える状態に保てます。
まとめ
GeoJSONを地図データ共有に使うときは、形式の理解だけでなく、実務で使い続けるための設計が重要です。点、線、面を扱えることや、JSON形式で共有しやすいことはGeoJSONの大きな利点ですが、地物の単位、座標の前提、属性の設計、ファイル容量、更新ルールが曖昧なままでは、現場や関係者間で混乱が生じます。
まず、共有する目的と地物の単位を決めることが基本です。閲覧用なのか、現地確認用なのか、集計用なのかによって、Featureの分け方や必要な属性が変わります。次に、座標参照系、座標の順序、取得方法、想定精度を明確にし、位置の意味を共有します。表示できることと、業務上正しい位置であることは別であるため、既知点や現地情報との照合も欠かせません。
属性情報は、検索、集計、更新を意識して設計します。管理番号、状態、確認日、更新日、担当区分など、業務で使う項目をそろえ、値の表記ゆれを防ぐことが大切です。外部共有では、不要な情報や機密性の高い情報を入れすぎないように注意します。さらに、ファイル容量と表示速度を考え、目的や範囲に応じてGeoJSONを分けることで、共有先でも扱いやすいデータになります。
運用面では、最新版の判断、更新履歴、現地確認、修正権限、承認状態を整理しておく必要があります。GeoJSONは一度作って終わりではなく、現地確認や業務の進行に合わせて更新されるものです。地物ごとのIDを維持し、変更内容を追えるようにしておくことで、継続的な管理がしやすくなります。
GeoJSONは、地図データ共有を始めるための実用的な形式です。しかし、実務で価値を出すには、現場で確認しやすいこと、関係者が同じ意味で読めること、更新しても整合性を保てることが欠かせません。位置情報を単なる地図表示で終わらせず、現地作業や施工管理、点検、設備管理に結び付けたい場合は、取得から共有、確認、更新までを一連の流れとして設計することが重要です。