GeoJSONは、位置情報を扱う実務で使いやすいJSON形式のデータです。点、線、面などの地物をテキストとして表現できるため、地図表示、現地調査、台帳整備、区域確認、施工管理、測量成果の確認など、さまざまな場面で利用されます。一方で、GeoJSONをGitで管理しようとすると、通常の文章ファイルや設定ファイルとは違う注意点が出てきます。座標の桁数、地物の並び順、属性名の揺れ、大容量化、座標参照系の扱い、レビュー方法などを整理しておかないと、差分が読みにくくなり、変更理由も追いにくくなります。この記事では、「geojson 使い方」で調べている実務担当者に向けて、GeoJSONをGit管理するときに特に注意したい6項目を、現場で使いやすい形で解説します。
GeoJSONをGit管理する目的を最初にそろえる
GeoJSONをGit管理するときに最初に整理したいのは、何のために履歴を残すのかという目的です。GeoJSONはテキスト形式なので、バージョン管理との相性がよいように見えます。しかし、実際には座標列が長くなりやすく、面データでは同じ地物でも非常に多くの数値が並びます。そのため、目的を決めずに管理を始めると、変更履歴は残っているのに、どこを確認すればよいのか分からない状態になりがちです。
たとえば、現地調査で取得した点を日ごとに追加していく場合、知りたいのは「いつ、どの地点が追加されたか」です。一方で、道路区域や敷地境界のような面データを管理する場合、重要なのは「どの頂点が動いたのか」「面積や境界の意味が変わったのか」「関係者の確認を経た変更なのか」です。同じGeoJSONでも、目的によって管理方法は変わります。
まずは、GeoJSONを成果物として管理するのか、作業途中の編集データとして管理するのかを分けて考えることが大切です。成果物として管理する場合は、いつの時点の正式版なのか、誰が確認した版なのか、納品や共有に使える版なのかが重要になります。作業途中の編集データとして管理する場合は、変更の試行錯誤や修正理由を追えることが重要です。
また、GeoJSONを単独で見るのか、図面、写真、帳票、現地メモなどと組み合わせて使うのかも整理しておく必要があります。位置情報の実務では、GeoJSONだけを見ても判断できないことがあります。ある点が移動していても、それが現地再測による修正なのか、座標変換の見直しなのか、入力ミスの修正なのかは、関連資料を見なければ判断できません。Git管理では、GeoJSON本体だけでなく、変更理由を説明する記録もセットで扱うことが重要です。
実務では、目的を「復元」「比較」「説明」「共有」の4つに分けると考えやすくなります。復元とは、誤って変更した場合に以前の状態へ戻せることです。比較とは、変更前後でどの地物や座標が変わったか確認できることです。説明とは、なぜその変更を行ったのかを後から追えることです。共有とは、複数人が同じデータを扱うときに、最新版や確認済みの版を取り違えないことです。
この目的があいまいなまま運用を始めると、ファイル名だけが増えたり、作業者ごとのローカル編集が乱立したり、最終的にどれが正しいGeoJSONなのか分からなくなります。特に、現地調査と事務所編集が並行する業務では、同じ地物を別々の担当者が修正することもあります。履歴を残すだけでなく、どの変更を正式に採用するのかを判断できる運用が必要です。
GeoJSONをGit管理する第一歩は、技術的な設定ではなく、管理対象と管理目的を決めることです。ファイルを細かく分けるのか、区域ごとに分けるのか、日付ごとに記録するのか、正式版だけを管理するのか、作業版も含めるのかを最初に決めておくことで、その後の整形ルールやレビュー方法も決めやすくなります。
座標の桁数と整形ルールを固定する
GeoJSONをGit管理するときに特に差分を読みにくくする原因が、座標値の桁数と整形ルールの揺れです。GeoJSONでは座標が数値として並びますが、出力するソフトや処理方法によって、小数点以下の桁数、改行位置、空白の入れ方、地物の並び順が変わることがあります。内容としてはほとんど変わっていなくても、ファイル全体が大きく変更されたように見えることがあるため注意が必要です。
標準的なGeoJSONでは、座標はWGS 84を前提とした経度、緯度の順で表します。高さを含める場合は3番目の値として扱えますが、4番目以降の値は多くの処理系で意味が共有されない可能性があります。社内や関係者間だけで平面直角座標系、ローカル座標、独自の高さ基準を使う場合は、通常のGeoJSONとして外部に渡すと誤解されるおそれがあります。Git管理では、座標参照系や変換条件をGeoJSON本体とは別の説明ファイルやメタデータで明示し、標準的なGeoJSONとして扱うデータと内部用データを混同しないことが大切です。
たとえば、ある作業者が小数点以下6桁で出力し、別の作業者が小数点以下10桁で出力すると、座標の実質的な意味が大きく変わっていなくても、多数の行に差分が発生します。さらに、整形時に1行で出力するか、座標ごとに改行するかが変わると、差分確認はさらに難しくなります。Gitの差分はテキストの変更を追う仕組みなので、位置情報としての変化よりも文字列としての変化が前面に出ます。
そのため、座標の桁数は業務で必要な精度に応じて決めておく必要があります。ただし、座標値の桁数が多いことは、そのまま測位精度や不確かさの小ささを証明するものではありません。過剰に細かい桁数を残すと、わずかな丸め差や再出力差が履歴に残り続けます。逆に、桁数を不用意に減らすと、位置精度が不足したり、境界や点の位置が実務上無視できないほど変わったりする可能性があります。測量、施工、施設管理、台帳整備など、用途によって必要な精度は異なるため、単純に桁数を少なくすればよいわけではありません。
整形ルールでは、改行、インデント、属性の並び順、地物の並び順を固定することが重要です。JSONとしてはオブジェクト内のメンバー順や空白に意味はありませんが、Gitの差分では文字列として表示されます。人がレビューするファイルであれば、読みやすい改行とインデントを採用した方が差分を確認しやすくなります。一方で、ファイル容量や処理速度を重視する場合は、圧縮された形式に近い出力を使いたくなることもあります。どちらが正しいというより、チーム内で統一されていることが大切です。
GeoJSONの整形ルールが固定されていないと、実際の位置修正と単なる再保存の差分が混ざります。たとえば、地物の属性名を1つ直しただけなのに、整形処理によって全地物の並び順が変わると、レビュー担当者は本当に必要な変更を見つけにくくなります。これは、承認作業の負担を増やすだけでなく、誤った変更を見落とす原因にもなります。
また、座標配列の順序にも注意が必要です。面データでは、外周や内周の座標列が意味を持ちます。GeoJSONのPolygonでは、外周リングと穴を表す内周リングの区別があり、標準仕様では外周と内周の向きにも推奨されるルールがあります。出力処理によって座標の開始点が変わったり、リングの向きが変わったりすると、見た目が大きく変わらない場合でもテキスト上の差分は大きくなります。互換性のために処理系が受け入れる場合があっても、チーム内ではリングの扱いを統一しておく方が安全です。
実務で安定したGit管理を行うには、編集前後で同じ整形ルールを通すことが効果的です。担当者ごとに異なる出力設定を使うのではなく、保存時や取り込み前に共通の整形処理を行う運用にしておくと、不要な差分を減らせます。特に、複数人でGeoJSONを更新する場合は、整形ルールを文書化し、作業開始前に共有しておくことが重要です。
座標の桁数と整形ルールは、一度決めたらむやみに変えないことも大切です。途中でルールを変更する場合は、位置情報の変更と整形ルールの変更を同じ履歴に混ぜない方が安全です。整形だけを行う変更と、地物の内容を変える変更を分けて記録すれば、後から履歴を確認したときに判断しやすくなります。
地物IDと属性名の設計を先に決める
GeoJSONをGit管理するうえで、座標と同じくらい重要なのが地物IDと属性名の設計です。GeoJSONは、地物ごとに形状と属性を持たせることができます。Featureには位置や形状を表すgeometryと、任意の属性を入れるpropertiesを持たせることができます。属性には、管理番号、種別、名称、調査日、状態、担当者、備考などを入れることができますが、ここに揺れがあると、履歴管理も検索も難しくなります。
まず、地物を識別するためのIDを用意することが重要です。点、線、面のどれであっても、同じ地物を継続的に追跡したい場合は、安定したIDが必要です。GeoJSONでは、Featureに共通して使う識別子がある場合、Feature直下のidとして持たせる考え方があります。実務上は、properties内の管理番号と併用する場合もありますが、どの項目を主キーとして扱うのかを最初に決めておくことが大切です。IDがないGeoJSONでは、地物の順番が変わっただけで、どの地物が修正されたのか分かりにくくなります。
IDは、作業のたびに変わらないものにする必要があります。ファイルを出力するたびに自動採番が変わるような設計では、履歴管理の意味が薄れます。ある地物が前回のどの地物に対応するのか分からなくなるためです。実務では、既存の台帳番号、管理番号、区画番号、測点番号など、業務上の意味を持つ識別子を活用すると管理しやすくなります。ただし、個人情報や不要な機密情報を含めないように注意が必要です。
属性名も、最初に統一しておくべき項目です。たとえば、同じ意味の属性を「調査日」「調査年月日」「date」「survey_date」のように複数の名前で管理すると、後工程で集計や検索がしにくくなります。人間が見れば同じ意味だと分かっても、データ処理では別の項目として扱われます。Git上の差分でも、単なる名称変更なのか、項目追加なのか、値の修正なのかが分かりにくくなります。
属性値の表記揺れにも注意が必要です。たとえば、状態を表す値として「確認済」「確認済み」「済」「OK」のような表記が混在すると、検索やフィルタリングの精度が落ちます。GeoJSONの属性は自由に入れられる分、ルールを決めないとすぐに揺れます。現地入力を行う場合は、自由記述を増やしすぎず、選択式にできる項目は選択式のルールを用意することが望ましいです。
Git管理では、属性の変更理由を追えることが大切です。地物の位置は変わっていないが、属性だけが変わる場合もあります。たとえば、点検結果が「未確認」から「確認済み」に変わる、施設状態が「要確認」から「補修済み」に変わる、備考に現地状況が追記されるといった変更です。このような属性変更は、形状変更とは別の意味を持ちます。レビュー時には、位置が変わったのか、属性だけが変わったのかを分けて確認できるようにしておく必要があります。
また、属性に日付を入れる場合は、日付形式を統一することが重要です。人によって年月日の表記が変わると、並び替えや検索がしにくくなります。時刻まで必要なのか、日付だけでよいのかも業務に応じて決めておくべきです。現地調査データでは、取得日時が後から重要になることがありますが、すべての属性に細かい時刻を入れると管理が煩雑になる場合もあります。
地物IDと属性名の設計は、後から直そうとすると大きな負担になります。すでに多くのGeoJSONファイルが存在する状態で項目名を統一しようとすると、過去ファイルとの互換性や履歴の読み替えが必要になります。できるだけ運用開始前に、地物ID、必須属性、任意属性、入力ルール、値の候補、空欄の扱いを決めておくことが安全です。
大容量GeoJSONをそのまま管理しない
GeoJSONはテキスト形式で扱いやすい一方、地物数や頂点数が増えるとファイルサイズが大きくなりやすい形式です。特に、詳細なポリゴン、長い線形データ、多数の現地点、メッシュ状の区域、点群から派生した大量の点データなどをGeoJSONとして保存すると、Git上での管理が重くなることがあります。
大容量GeoJSONをそのままGit管理すると、いくつかの問題が起きます。まず、差分表示が見づらくなります。ファイルが大きいほど、変更箇所を探すのに時間がかかります。次に、複数人で作業すると競合が起きやすくなります。1つの巨大なGeoJSONファイルを複数人が同時に編集すると、別々の地物を触っていても同じファイルの変更として扱われ、統合作業が複雑になります。さらに、履歴が増えるほど保管容量も増え、取得や更新の操作が重くなることがあります。
この問題を避けるには、GeoJSONを適切な単位で分割することが重要です。分割の考え方には、区域別、地物種別、作業段階別、用途別などがあります。たとえば、点検地点、路線、区域、施設範囲を1つのファイルに混在させるのではなく、用途ごとに分けると差分を追いやすくなります。市区町村、工区、現場、管理区域など、実務で扱う単位に合わせて分ける方法もあります。
ただし、細かく分けすぎると別の問題が起きます。ファイル数が増えすぎると、どのファイルを編集すべきか分かりにくくなり、結合や一覧化の手間も増えます。分割は、作業しやすさ、レビューしやすさ、後工程で使いやすいかどうかのバランスで決める必要があります。地物数が少ない段階では1つのファイルでも問題ない場合がありますが、将来的に増える見込みがあるなら、早めに分割単位を決めておく方が安全です。
大容量化を防ぐうえでは、GeoJSONに入れる情報を絞ることも重要です。GeoJSONは形状と属性を持てますが、すべての情報を詰め込む必要はありません。画像、詳細な帳票、長文のメモ、大量の履歴情報などを属性に直接入れると、ファイルが肥大化し、差分も読みにくくなります。GeoJSONには位置情報と必要最小限の属性を入れ、詳細資料は別ファイルとして管理し、IDで関連付ける方が運用しやすい場合があります。
また、表示用データと編集用データを分ける考え方も有効です。地図表示を軽くするために簡略化したGeoJSONと、編集や確認に使う詳細なGeoJSONでは、必要な情報量が異なります。表示用に頂点を減らしたデータを正式な編集元として扱うと、位置精度が落ちる可能性があります。逆に、詳細な編集データをそのまま公開や共有に使うと、表示が重くなることがあります。Git管理では、元データ、編集データ、共有用データの役割を分けておくことが大切です。
大きなデータで、Gitの通常履歴にすべてを載せると運用が重くなる場合は、大容量ファイル向けの管理方法や、元データを別管理して生成済みGeoJSONだけを出力する方法も検討できます。ただし、その場合でも、生成元、生成条件、変換日時、変換担当、採用した座標系の情報を残しておかなければ、後から同じデータを再現しにくくなります。
大容量GeoJSONを扱う場合、変更単位を小さくすることも意識したい点です。複数の修正をまとめて1回で反映すると、後から原因を追いにくくなります。たとえば、座標の修正、属性名の変更、地物の追加、不要地物の削除を同時に行うと、レビュー担当者は変更の意図を判断しにくくなります。できるだけ、意味のある単位ごとに変更を分けることで、履歴の価値が高まります。
GeoJSONをGitで管理する目的は、単に保存することではありません。変更内容を後から確認でき、必要に応じて戻せることに価値があります。大容量ファイルを無理にそのまま管理すると、その価値が下がります。分割、情報の絞り込み、表示用と編集用の分離、変更単位の整理を行い、履歴が読みやすい状態を保つことが重要です。
差分レビューで見るべきポイントを明確にする
GeoJSONをGit管理する場合、差分レビューの考え方を決めておくことが欠かせません。一般的な文章や設定ファイルであれば、変更された行を読めば内容を理解しやすいですが、GeoJSONでは座標値が大量に並ぶため、テキスト差分だけで判断するのは難しいことがあります。そのため、レビュー時に何を見るべきかを事前に明確にしておく必要があります。
最初に確認すべきなのは、地物の追加、削除、変更の区別です。新しい地点が追加されたのか、既存の地点が移動したのか、不要な地物が削除されたのかによって、確認方法は変わります。追加であれば、必要な属性が入っているか、位置が想定範囲内かを確認します。削除であれば、本当に削除してよい地物か、別ファイルへ移しただけなのかを確認します。変更であれば、座標の変更なのか、属性の変更なのか、両方なのかを分けて見る必要があります。
座標変更では、変更量の大きさが重要です。わずかな丸め差なのか、現地再測による修正なのか、座標参照系の取り違えなのか、入力ミスなのかを判断する必要があります。数値だけを見ると小さな変更に見えても、実際の位置では意味を持つ場合があります。逆に、テキスト上は多くの行が変わっていても、整形ルールの違いだけで地物の形状は変わっていない場合もあります。
属性変更では、業務上の意味が変わっていないかを確認します。名称、種別、状態、管理番号、調査日などの変更は、地図上の見た目に表れにくい一方で、台帳や検索結果に大きく影響することがあります。特に、地物IDや管理番号の変更は慎重に扱う必要があります。IDが変わると、関連資料や過去履歴との対応が切れる可能性があります。
レビュー時には、地図上での確認も必要です。テキスト差分だけでは、線が交差してしまった、面がねじれた、隣接区域との境界がずれた、点が道路外に出たといった問題を見落とすことがあります。GeoJSONは地理データなので、最終的には地図上で見て確認することが重要です。特に、面データでは、閉じた形状になっているか、不要な自己交差がないか、隣接する面との重なりや隙間がないかを確認する必要があります。
また、レビューでは変更理由を確認できる状態にしておくことも大切です。GeoJSONの差分だけを見ても、なぜその変更が必要だったのか分からない場合があります。現地で境界を再確認した、古い図面から新しい図面に更新した、調査結果を反映した、入力ミスを修正したなど、変更理由を短く残しておくことで、後から判断しやすくなります。
複数人でレビューする場合は、役割分担を決めておくと効果的です。位置精度を見る担当者、属性の整合性を見る担当者、現地資料との対応を見る担当者など、確認観点を分けることで見落としを減らせます。すべてを1人で確認しようとすると、座標、属性、業務判断のどこかが手薄になる可能性があります。
差分レビューでは、問題が見つかったときの戻し方も考えておく必要があります。修正をすべて取り消すのか、一部の地物だけ戻すのか、別の修正版を作るのかを判断できるようにしておくと、運用が安定します。大きなGeoJSONファイルでは、一部だけ戻す作業が難しくなることがあります。これも、ファイル分割や変更単位の整理が重要になる理由です。
GeoJSONのGit管理において、レビューは単なる承認作業ではありません。位置情報の品質を守るための確認工程です。座標、属性、形状、整合性、変更理由をそれぞれ確認し、テキスト差分と地図表示の両方を使って判断することで、実務で使えるデータ品質を保ちやすくなります。
現地データと図面データの更新手順を分ける
GeoJSONを実務で使う場合、現地で取得したデータと、図面や台帳から作成したデータが混在することがあります。どちらもGeoJSONとして保存できますが、性質は大きく異なります。現地データは取得条件や測位精度、作業時刻、担当者、現場状況の影響を受けます。一方、図面データは設計情報、管理図、既存資料、座標変換の条件などに依存します。この2つを同じ手順で更新すると、変更理由が分かりにくくなることがあります。
現地データでは、取得時の条件を残すことが重要です。どの日時に、どの地点で、どのような目的で取得したのかが分からないと、後から座標の信頼性を判断しにくくなります。現地で点を追加した場合、それが新規確認点なのか、既存点の再測なのか、仮置きのメモなのかを属性や変更記録で分かるようにしておく必要があります。
図面データでは、元にした資料と変換条件が重要です。図面からGeoJSONを作成する場合、座標系、縮尺、原点、回転、単位、レイヤ分けなどの条件が関係します。図面上では正しく見えていても、GeoJSONとして出力したときに位置がずれることがあります。特に、標準的なGeoJSONとして扱うなら、経度、緯度の順序やWGS 84への変換を確認する必要があります。平面直角座標系や現場独自のローカル座標をそのまま使う運用では、関係者が同じ前提を共有しているか、外部共有時に誤解されないかを確認することが重要です。
現地データと図面データを同じファイルに入れる場合は、属性で由来を分けることが重要です。現地取得なのか、図面由来なのか、台帳由来なのか、手入力なのかを判別できるようにしておけば、レビュー時に確認観点を変えられます。由来が分からないデータは、後から修正の優先順位や信頼性を判断しにくくなります。
更新手順も分けておくべきです。現地データの更新では、取得データをそのまま正式版に反映するのではなく、確認、整形、属性補完、重複確認を経てから反映する流れが安全です。図面データの更新では、変換条件の確認、既存データとの重ね合わせ、境界や地物の対応確認を行ってから反映する必要があります。
特に注意したいのは、現地データで図面データを上書きする場合です。現地で取得した位置が常に正しいとは限りません。測位条件が悪い場所、周辺環境の影響を受けやすい場所、入力時に点を取り違えた場所では、現地データにも誤差やミスが含まれる可能性があります。逆に、図面データが古く、現況と合っていない場合もあります。どちらを優先するかは、業務目的と確認資料に基づいて判断する必要があります。
Git管理では、この判断過程を履歴として残せることに価値があります。ただし、ただ上書きするだけでは判断過程が見えません。現地確認による修正、図面更新による修正、座標変換の見直し、属性補完などを分けて記録することで、後から変更の意味を説明しやすくなります。
また、現地と事務所の作業タイミングにも注意が必要です。現地担当者が取得したGeoJSONを事務所担当者が編集し、その間に別の現地担当者が追加取得するような運用では、更新の衝突が起きやすくなります。作業前に最新版を確認する、更新中の範囲を共有する、反映前に差分を確認するなど、基本的な手順を決めておくことが重要です。
現地データと図面データは、どちらも重要ですが、同じ意味を持つものではありません。GeoJSONをGit管理する場合は、データの由来、更新手順、確認方法を分けておくことで、位置情報の信頼性を保ちやすくなります。
GeoJSON管理を現場活用につなげる考え方
GeoJSONをGit管理する最終的な目的は、履歴をきれいに残すことだけではありません。実務で使える位置情報として、現場、事務所、関係者間で安全に活用できる状態を作ることです。履歴管理が整っていても、現場で使いにくいデータになってしまっては意味がありません。
現場活用を考えるときは、まず「誰が、どの場面で、どの粒度のGeoJSONを使うのか」を整理することが重要です。現地確認で使うデータは、必要な地物がすぐ見えること、属性が分かりやすいこと、端末上で重くなりすぎないことが求められます。一方、事務所での確認や編集では、詳細な属性や履歴との対応が重要になります。すべての用途を1つのGeoJSONで満たそうとすると、データが重くなり、管理も複雑になります。
そのため、管理用のGeoJSONと現場利用用のGeoJSONを分ける運用が有効です。管理用には、必要な属性や履歴と対応するIDを保持し、現場利用用には、表示や確認に必要な項目だけを整理して出力します。このとき、現場利用用データを手作業で別管理すると、元データとのずれが発生しやすくなります。元データから一定のルールで作成する流れにしておくと、更新時のミスを減らせます。
また、GeoJSONを現場で使う場合は、座標の意味を現場担当者が理解できる形にしておくことも大切です。地図上に点や線が表示されていても、それが設計位置なのか、現況測定位置なのか、確認済み位置なのか、仮登録位置なのかが分からなければ、誤った判断につながる可能性があります。属性名や表示用の名称を分かりやすくし、地物の状態が判断できるようにしておくことが重要です。
Git管理で整えた履歴は、現場での説明にも役立ちます。たとえば、ある区域の形状がいつ変更されたのか、どの確認結果を反映したのか、以前の位置とどれくらい変わったのかを説明できれば、関係者間の認識合わせがしやすくなります。これは、施工管理、施設管理、用地確認、点検業務などで特に有効です。
一方で、現場活用を急ぐあまり、未確認データを正式版として扱わないように注意が必要です。GeoJSONは簡単に編集できるため、仮の点や確認途中の線もすぐに共有できます。しかし、共有しやすいことと、正式に使えることは別です。Git上では、作業中、確認中、承認済みといった状態が分かるようにしておくと、誤利用を防ぎやすくなります。
GeoJSON管理を現場活用につなげるには、データ品質だけでなく、運用の分かりやすさも重要です。担当者が更新手順を理解でき、レビュー担当者が差分を確認でき、現場担当者が必要な情報を迷わず使える状態を目指す必要があります。難しい仕組みにしすぎると、運用が形だけになり、結局は個人管理のファイルが増えてしまいます。
実務では、最初から完璧な運用を作るよりも、重要なルールから段階的に整える方が定着しやすいです。まずは、ファイル分割、地物ID、属性名、座標桁数、座標参照系の前提、更新手順、レビュー観点を決めます。そのうえで、現場で使ってみて、重い、見づらい、属性が足りない、差分が追いにくいといった課題を改善していきます。
GeoJSONは、位置情報を扱う実務担当者にとって便利な形式ですが、Git管理では「テキストとして管理できる」だけでは不十分です。座標の意味、地物の由来、属性の設計、変更理由、現場での使いやすさまで含めて考えることで、履歴管理の価値が高まります。
GeoJSONを活用する現場では、図面上の位置、現地で取得した位置、確認済みの施工位置をつなげて扱う場面が増えています。こうした運用では、データをきれいに保管するだけでなく、現場で正しく位置を確認し、必要に応じてすばやく共有できることが重要です。スマートフォンや現地測位機器、地図アプリ、台帳システムなどと組み合わせ、管理用データと現場利用データの関係を明確にしておけば、GeoJSONで整理した位置情報を机上のデータにとどめず、現場で使える情報として活かしやすくなります。