GeoJSONは、地物の形状と属性をひとつのテキスト形式で扱えるため、地図データの受け渡し、外部システムとの連携、簡易な現場確認でよく使われます。一方で、ArcGISでGeoJSONを読み込んだり書き出したりする場面では、位置がずれる、属性が意図した型にならない、ポリゴンが崩れる、複数の形状が一部しか取り込まれない、面積や距離の値が想定と合わないといった問題が起きることがあります。
特に注意したいのは、GeoJSONという拡張子だけを見て、座標参照系や属性、形状の前提まで正しいと考えてしまうことです。現在広く参照されるGeoJSONの仕様では、座標はWGS 84に基づく経度、緯度の順序で扱うことが前提です。ただし、実務では旧仕様や独自出力、変換途中のデータ、ArcGIS側の出力設定によって、受け渡し先で期待どおりに解釈されないファイルに出会うことがあります。そのため、ArcGISでGeoJSONを扱う時は、読み込み前、編集時、書き出し後のそれぞれで確認すべき設定を整理しておくことが重要です。
GeoJSONで最初につまずきやすい座標参照系の確認
GeoJSONをArcGISで扱う時に最も多いトラブルは、読み込んだ地物の位置が想定と違う場所に表示されることです。日本国内のデータなのに海外に飛んでしまう、海上に表示される、同じ市町村の背景地図と微妙にずれる、現地で取得した点と重ならないといった現象は、座標参照系の認識違いから起きることがあります。
GeoJSONでは、標準的には座標の並びを経度、緯度の順で扱います。高さを持つ場合は三番目の値として標高を持つことがありますが、平面位置として最初に見るべきなのは経度と緯度です。普段の測量図面や設計図面でX座標、Y座標を扱っている担当者ほど、緯度と経度の順序を逆に読んでしまうことがあります。日本国内の緯度経度であれば、経度はおおむね百数十度、緯度は二十数度から四十数度の範囲に入ります。座標値を見た時に、最初の値が三十数度、二番目の値が百数十度になっている場合は、緯度経度の順に並んだデータをGeoJSONとして扱おうとしている可能性があります。
ここで大切なのは、GeoJSONの標準仕様と、実務で見かけるGeoJSON風のデータを分けて考えることです。現在のGeoJSON仕様に準拠して共有するなら、座標はWGS 84の経度緯度で扱うのが基本です。一方で、過去の仕様や特定システムの独自運用では、座標参照系を示す情報を付けたり、平面直角座標系やローカル座標に近い値をGeoJSON形式のファイルとして出力したりする例があります。そうしたファイルは、受け手の環境で同じように解釈されるとは限らないため、標準的なGeoJSONとしてそのまま扱うのではなく、作成元の前提を確認する必要があります。
位置ずれを防ぐには、読み込み前に座標値の桁と範囲を確認します。経度緯度であれば、座標値は度単位の小数になります。一方、平面直角座標系やローカル座標系のようなメートル単位の座標では、値の桁が大きくなり、数千、数万、場合によっては数十万の値になります。拡張子が.geojsonであっても、中の値が標準的な経度緯度ではない場合は、ArcGISに読み込む前に変換方法を整理した方が安全です。
ArcGIS上で確認する時は、座標参照系の定義と座標変換を混同しないことも重要です。定義は、このデータの座標値をどの座標系として解釈するかを明確にする作業です。座標変換は、ある座標系の座標値を別の座標系の座標値に変える作業です。すでに正しい経度緯度を持つGeoJSONに対して誤った変換をかけると、かえって位置がずれます。反対に、平面直角座標系の値を単にWGS 84として定義しただけでは、正しい経度緯度にはなりません。
実務では、背景地図と重なるかどうかだけで判断しない方が安全です。背景地図は便利ですが、表示縮尺やデータ更新時期、図化の都合によって見え方が変わることがあります。既知点、境界点、構造物位置、現地で取得した座標など、基準となる点との重なりを確認すると、座標参照系の取り違えを早期に見つけやすくなります。GeoJSONを施工管理、設備管理、境界確認、現況整理に使う場合は、最初に座標の前提を確認することが、後工程の手戻りを減らす出発点になります。
緯度経度と平面直角座標系を混同しないための見方
GeoJSONを扱う時に、次につまずきやすいのが緯度経度と平面直角座標系の混同です。どちらも位置を表す座標ですが、単位、値の意味、距離や面積の扱い方が異なります。緯度経度は地球上の位置を角度で表す考え方であり、単位は度です。平面直角座標系は、一定の区域を平面として扱い、メートル単位で位置を表す考え方です。この違いを理解しないままデータを読み込むと、地図上では一見表示できていても、距離計測や面積集計で誤った判断につながることがあります。
たとえば、GeoJSON内の座標が経度緯度で記録されている場合、その数値差をそのままメートルの差として読むことはできません。経度一度に相当する距離は緯度によって変わり、緯度方向と経度方向でも距離の意味が異なります。地図上で近くに見える線や面であっても、緯度経度の座標値に対して単純な平面計算を行うと、実務で使う距離や面積と合わない結果になることがあります。
一方、平面直角座標系で作られたデータは、施工図、測量成果、公共座標に基づく管理図面などでよく使われます。現場の距離や面積を扱うには便利ですが、そのままGeoJSONとして外部に受け渡すと、読み込み側が経度緯度だと解釈して大きな位置ずれを起こす可能性があります。標準的なGeoJSONとして共有するなら、ArcGIS上で適切に投影変換し、WGS 84の経度緯度として出力する流れを確認する必要があります。
実務担当者がまず見るべきなのは、座標値の大きさです。経度緯度であれば、小数を含む度単位の値になっているはずです。平面直角座標系やローカル座標系であれば、メートル単位の数値になり、現場基準や区域によって桁が異なります。さらに、測量成果や設計データから変換したGeoJSONであれば、元データの座標系、測地系、原点、単位を確認します。座標の桁だけで完全に判断するのではなく、作成元の説明や変換履歴と合わせて確認することが大切です。
ローカル座標で作られたデータにも注意が必要です。工事現場や施設管理では、現場内だけで通用する任意座標が使われることがあります。任意座標は、現場内の相対的な位置関係を扱うには便利ですが、そのままでは広域地図や他の地理空間データと重ねることができません。GeoJSON形式に変換されていても、元が任意座標であれば、公共座標や緯度経度へ変換するための基準点情報が必要になります。
また、ArcGISで地図上に表示できたからといって、座標系の問題が解決しているとは限りません。表示時にオンザフライで投影されている場合、画面上では重なって見えても、出力時や別システムでの利用時に前提が失われることがあります。特に、GeoJSONを書き出して他の担当者に渡す場合は、出力後のファイルを再度読み込み、座標値の並び、位置、測定値、属性を確認します。
納品や共有を前提にする場合は、ファイルそのものだけでなく、使用した座標参照系、変換条件、作成日時、元データの種類を管理メモとして残しておくと後から原因を追いやすくなります。GeoJSONは軽量で扱いやすい形式ですが、座標の意味を自動的に説明してくれるわけではありません。データを見る人が、値の単位と座標系の前提を理解してはじめて、正しい地図データとして活用できます。
ポイント・ライン・ポリゴンの形状エラーを読み込み前に確認する
GeoJSONでは、点、線、面などの地物形状を表現できます。設備の位置を点で表す場合、道路や管路を線で表す場合、敷地や区域を面で表す場合など、用途に応じて形状の種類が変わります。しかし、ArcGISで読み込む際には、形状の種類や構造が期待どおりになっていないことで、表示されない、途中で切れる、ポリゴンが塗られない、属性はあるのに地図上に出てこないといった問題が起こることがあります。
ArcGISでは、GeoJSONからフィーチャクラスへ変換する際に、出力するジオメトリタイプを意識する必要があります。GeoJSONのファイル内には複数の地物タイプを含められますが、フィーチャクラスは基本的に同じジオメトリタイプの地物で構成されます。そのため、ポイント、ライン、ポリゴンをひとつのGeoJSONにまとめている場合、読み込みや変換の設定によって、必要な地物が一部だけ取り込まれたように見えることがあります。設備点、道路中心線、区域ポリゴンを安定して扱いたい場合は、用途ごと、形状ごとにファイルやレイヤを分ける方が安全です。
ポリゴンでは、外周の閉じ方や頂点の並びにも注意が必要です。面として扱うには、外周線が閉じている必要があります。始点と終点が一致していない場合、見た目には線で囲まれているように見えても、面として認識されないことがあります。また、外周と穴の関係が正しく整理されていないと、くり抜き部分が塗りつぶされたり、反対に面が消えたように見えたりします。
自己交差にも注意が必要です。ポリゴンの辺が途中で交差していると、面の内外判定が不安定になり、面積計算や塗り分けに影響します。境界線を手作業で編集したデータ、複数の図面を結合したデータ、簡易変換で作られたデータでは、こうした形状エラーが残っていることがあります。読み込めるかどうかだけでなく、編集、集計、重ね合わせに耐える形状になっているかを確認することが重要です。
ラインデータでは、線が分断されているか、連続した一本の線として扱われているかが問題になります。道路、河川、配管、電線などの管理では、一本の連続した対象として扱いたい場合と、区間ごとに属性を持たせたい場合があります。GeoJSONの構造上はどちらも表現できますが、実務上の管理単位とデータ構造が合っていないと、延長集計や点検区間の抽出で手間が増えます。
ポイントデータでは、座標が空になっている地物や、同じ場所に重複した点がないかを確認します。帳票や表計算データから変換したGeoJSONでは、緯度または経度が欠落している行、ゼロ値のまま残っている行、入力ミスで遠方に飛んでいる点が混じることがあります。これらは地図上で見落としやすく、後から集計や現地確認の対象に入ってしまうことがあります。
読み込み前の確認では、ファイルが正しいJSON構文になっているかも重要です。GeoJSONはJSONを基にしたテキスト形式であるため、括弧の不足、カンマの位置、引用符の不整合などがあると読み込めないことがあります。データ量が多い場合、目視で全部を確認するのは現実的ではありませんが、読み込みエラーが出た時には、座標系だけでなく構文と形状構造も疑う必要があります。
形状エラーを防ぐためには、元データの段階で管理単位を決めておくことが大切です。点は設備単位なのか、確認箇所単位なのか。線は路線単位なのか、点検区間単位なのか。面は筆界、施工範囲、管理区域、危険範囲のどれを表しているのか。この整理が曖昧なままGeoJSONに変換すると、ArcGIS上では表示できても、実務で使いにくいデータになります。
属性フィールドの型と文字化けを防ぐ設定確認
GeoJSONは、形状だけでなく属性情報も一緒に持てる点が便利です。設備番号、点検日、管理者、路線名、区域名、状態、写真番号、備考などを地物ごとに持たせることで、単なる地図表示ではなく、検索、分類、色分け、帳票化に活用できます。しかし、読み込み時に属性フィールドの型が想定と異なったり、文字が化けたりすると、現場で使う情報としての信頼性が下がります。
GeoJSONのpropertiesは柔軟に属性を持てますが、一般的な表形式データのように、フィールド長、日付型、コード体系まで厳密に定義する仕組みではありません。そのため、ArcGISへ取り込んだ時に、値の内容から型が推定されたり、変換先のフィールド仕様に合わせて扱われたりします。読み込み後は、地図表示だけでなく属性テーブルを開き、項目名、型、値の表示、空欄の扱いを確認することが重要です。
よくある問題は、数値として扱いたい項目が文字列として読み込まれることです。たとえば、延長、面積、標高、勾配、管理番号の一部などは、一見すると数値に見えます。しかし、空欄、単位記号、全角数字、不要なスペースが混じっていると、文字列として認識されることがあります。文字列として取り込まれると、数値順の並べ替え、範囲抽出、集計、段階的な色分けが思うようにできません。
反対に、文字列として保持したい管理番号が数値として扱われてしまうこともあります。先頭にゼロを含む番号、枝番を含む番号、ハイフンを含む番号などは、実務上は識別子であり、計算対象ではありません。これを数値として処理すると、先頭のゼロが消えたり、表記が変わったりする可能性があります。設備番号や図面番号は、見た目の表記そのものが意味を持つため、文字列として扱う方が安全です。
日付項目にも注意が必要です。点検日、撮影日、更新日などは、作業履歴を追う上で重要ですが、GeoJSONでは日付値の表現が読み込み先によって同じように解釈されるとは限りません。年月日の表記、年月のみ、時刻付き、和暦表記、自由記述が混在していると、読み込み後に検索や抽出が難しくなります。GeoJSONにする前の段階で、日付表記を統一し、ArcGISに取り込んだ後に日付として扱えるかを確認します。
文字化けは、文字コードや特殊文字の扱いで発生します。日本語の属性名や備考欄を含むデータでは、読み込み環境によって文字が正しく表示されないことがあります。特に、複数のシステムを経由したデータ、古い形式から変換したデータ、表計算ソフトで編集したデータでは、文字コードの不一致や特殊文字の混入が起こりやすくなります。読み込み後に属性テーブルを確認し、項目名と値が意図した通りに表示されているかを必ず確認します。
属性名の付け方にも実務上の注意があります。長すぎる項目名、同じ意味の項目が複数あるデータ、全角と半角が混在した項目名、空白や記号を多く含む項目名は、後工程で扱いにくくなります。GeoJSON自体は柔軟に属性を持てますが、別形式への変換や帳票出力、他システムへの受け渡しを考えると、項目名は短く、意味が分かりやすく、表記揺れが少ない形にしておく方が安全です。
また、属性の中に座標値を文字列として持たせている場合もあります。形状の座標と属性欄の座標が両方存在するデータでは、どちらが正なのかを確認する必要があります。たとえば、属性欄に緯度経度が残っているが、地物形状は別の変換後座標を持っている場合、更新時に不整合が起きることがあります。現場で取得した写真位置や点検位置を扱う場合は、属性と形状の関係を明確にしておくことが重要です。
読み込み後に色分けやラベル表示を行う場合は、属性値の揺れも問題になります。同じ状態を表すのに、良好、正常、異常なしのように複数の表記が混在していると、分類結果が分かれてしまいます。空白の有無、全角半角、表記の略称も同様です。GeoJSONを地図表示だけでなく管理データとして使うなら、属性値の標準化まで含めて整備する必要があります。
面積・距離・縮尺の確認で誤った判断を避ける
GeoJSONをArcGISに読み込んだ後、面積、距離、延長、周長などを確認する場面は多くあります。施工範囲の面積、管理区域の広さ、点検路線の延長、対象物までの距離など、数値を使って判断する業務では、表示できたことだけで安心してはいけません。座標系や計測方法が適切でないまま測ると、現場感覚と合わない値が出ることがあります。
緯度経度のまま表示しているデータでは、画面上の地図表示は問題なく見えても、平面上の距離や面積として直接扱うには注意が必要です。地球上の位置を角度で表しているため、単純な座標差を距離として扱うことはできません。ArcGISには計測やジオメトリ計算の機能がありますが、どの座標系、どの単位、どの計算方法で値を出しているかを理解しておく必要があります。
現場で使う距離や面積に近い値を得たい場合は、対象地域と用途に適した座標系や計算方法を選ぶことが基本です。狭い施工現場や施設管理区域であれば、現地の測量成果や平面直角座標系に基づくデータと整合する形で扱うことが重要です。広域のデータを扱う場合は、地域差や地球の曲面を考慮した測定方法が必要になることがあります。広域表示と実測管理を同じ設定で済ませようとすると、用途によって精度感が合わなくなることがあります。
縮尺の見え方にも注意が必要です。画面上で拡大表示していると、わずかな位置ずれが大きな問題に見えることがあります。反対に、小縮尺では大きなずれが目立たないこともあります。GeoJSONを確認する時は、全体表示だけでなく、実務で使う縮尺に近い状態で確認することが大切です。境界、道路中心線、構造物、設備点など、照合対象が明確な場合は、拡大して重なり方を確認します。
また、簡略化されたGeoJSONでは、頂点数が削減されている場合があります。Web表示や軽量化を目的として作られたデータでは、線や面の形状が元データより粗くなっていることがあります。見た目の確認や概要把握には十分でも、面積算定、境界確認、施工位置の判断には向かない場合があります。データがどの用途で作られたものかを確認し、精度が必要な業務では元データや高精度な座標情報に戻って確認することが必要です。
面積や距離の値を報告書や協議資料に使う場合は、計測条件を記録しておくと安心です。どのデータを使ったのか、どの座標系で計測したのか、どの単位で出したのか、いつの時点のデータなのか、簡略化の有無はどうかを残しておけば、後から数値差が出た時に説明しやすくなります。GeoJSONは共有しやすい形式ですが、軽量化や変換を経ていることも多いため、計測値の根拠として使う場合は慎重な確認が必要です。
施工や点検の現場では、数十センチの差が問題になる場面もあれば、数メートルの概略で十分な場面もあります。重要なのは、業務に必要な精度とデータの性質が合っているかを判断することです。GeoJSONを読み込んで表示できたからといって、そのまま精密な測量成果として扱えるとは限りません。表示用、共有用、解析用、施工確認用といった用途の違いを意識することで、誤った判断を避けやすくなります。
書き出し時に欠落しやすい情報と再利用を前提にした整理
GeoJSONをArcGISで読み込む時だけでなく、編集後に書き出す時にも注意が必要です。読み込み時には正しく見えていたデータでも、書き出し設定によって属性が欠落する、座標系の前提が伝わらない、形状が変わる、文字列の表記が変わるといった問題が起こることがあります。特に、別の担当者や別のシステムで再利用することを前提にする場合は、書き出し後の確認が欠かせません。
ArcGISからGeoJSONを書き出す場合、標準的なGeoJSONとして外部に渡すなら、WGS 84の経度緯度へ投影して出力する設定を確認します。入力データの座標系を保持したままGeoJSONに出力できる場合でも、その座標参照系を示す情報が受け取り側で常に正しく使われるとは限りません。非標準または互換性に注意が必要なGeoJSONとして扱われる可能性があるため、外部共有ではWGS 84へ変換した出力と、変換前の元データを区別して管理することが重要です。
まず確認したいのは、出力されたGeoJSONに必要な地物がすべて含まれているかです。表示中のレイヤだけを書き出したつもりが選択中の一部だけになっている、逆に不要な地物まで含まれている、フィルタがかかった状態で出力してしまうといったことがあります。作業画面上の状態と、書き出し対象の条件は必ずしも同じではありません。出力後に件数を確認し、元データとの対応を見ます。
次に、属性フィールドが保持されているかを確認します。ArcGISの書き出しでは、表示されている属性フィールドだけが出力対象になる設定や、結合、リレート、添付ファイルがそのままGeoJSONに含まれない制約に注意が必要です。納品や共有を考えるなら、必要な属性をあらかじめ通常のフィールドとして整理し、項目名と値のルールを整えてから書き出す方が安全です。
曲線を含むデータにも注意します。GeoJSONは円弧などの曲線ジオメトリをそのまま保持する形式ではないため、ArcGISからGeoJSONへ出力する際に曲線が線分化されることがあります。見た目の表示では問題がなくても、元データの曲線情報とは異なる頂点構成になるため、施工位置や境界確認で使う場合は、出力後の形状を再確認する必要があります。
座標の桁数も重要です。小数点以下の桁が丸められると、位置精度に影響します。概要図や広域表示であれば大きな問題にならなくても、設備点、境界点、施工位置の確認では、丸めによる差が無視できない場合があります。書き出したGeoJSONを再度読み込み、元データと重ねてずれがないかを確認します。
一方で、過度に細かい座標や不要な頂点をそのまま保持すると、ファイルサイズが大きくなり、表示や共有が重くなることがあります。現場で使う端末や通信環境を考えると、軽量化が必要な場合もあります。ここで大切なのは、軽量化してよいデータと、精度を保持すべきデータを分けることです。現地誘導や概略説明用であれば軽量化したGeoJSONが便利ですが、施工位置や境界確認に使うデータでは、元の精度を保つ必要があります。
再利用を前提にするなら、ファイル名と管理情報も整えるべきです。作業日、対象区域、座標系、用途、版数が分かるようにしておくと、複数のGeoJSONが混在しても判断しやすくなります。ファイル名が単に新規、修正、最終といった曖昧な名前だと、後からどれが正しいのか分からなくなります。地図データは一度作って終わりではなく、更新、共有、確認、再編集を繰り返すことが多いため、管理しやすい命名が重要です。
また、GeoJSON単体では伝わりにくい前提もあります。どの測地系に基づいているのか、どの範囲を対象にしているのか、どの時点の現況を反映しているのか、どの属性が必須なのか、どの項目は参考情報なのかといった情報は、ファイルだけを見ても分からない場合があります。共有時には、簡単な説明文や管理メモを添えることで、受け取った側の誤用を防げます。
書き出し後の最終確認では、別環境で開くことも有効です。作成した環境では問題なく表示できても、受け取り側の環境では文字化けや位置ずれが起こることがあります。すべての環境を完全に再現することは難しくても、少なくとも出力ファイルを再読み込みし、座標、属性、件数、見た目、計測値を確認するだけで、多くのトラブルを事前に防げます。
GeoJSONを現場で使いやすいデータに整える考え方
GeoJSONを業務で活用する目的は、単にArcGISに読み込むことではありません。現場で位置を確認する、関係者に分かりやすく説明する、設備や区域を検索する、写真や点検記録と結び付ける、更新情報を共有するなど、実際の作業に役立つ形にすることが重要です。そのためには、座標や属性の設定だけでなく、現場で使う人の視点に合わせてデータを整える必要があります。
まず、地物の粒度をそろえることが大切です。設備管理であれば、ひとつの点が何を表すのかを明確にします。設備そのものなのか、点検箇所なのか、写真撮影位置なのか、異常箇所なのかによって、必要な属性や表示方法が変わります。施工範囲のポリゴンであれば、契約範囲、実施工範囲、立入禁止範囲、仮設範囲などを混同しないように分ける必要があります。
次に、表示時に迷わない属性設計を行います。現場では、長い説明文よりも、対象名、状態、優先度、更新日、担当区分などがすぐ分かる方が使いやすいことが多いです。すべての情報をGeoJSONに詰め込むのではなく、地図上で判断するために必要な項目と、別資料で管理する項目を分けると、扱いやすくなります。
写真や点検記録と連携する場合は、識別子の統一が重要です。地図上の点、写真ファイル、点検帳票、補修履歴がそれぞれ別の番号体系になっていると、後から照合するのに時間がかかります。GeoJSONの属性に共通の管理番号を持たせ、ほかの資料でも同じ番号を使うことで、現場確認から報告作成までの流れがスムーズになります。
更新運用も最初から考えておくべきです。GeoJSONは編集しやすい形式ですが、複数人が別々に編集すると、どれが最新か分からなくなることがあります。更新担当、更新日、変更内容、元データの版数を管理しないと、古い情報に基づいて現場判断をしてしまう恐れがあります。特に、施工中の現場や点検業務では、日々情報が変わるため、最新版の扱いを決めておくことが重要です。
現場利用では、通信環境や端末性能も考慮します。大きすぎるGeoJSONは、読み込みに時間がかかったり、地図操作が重くなったりします。必要な範囲だけに分割する、表示用と編集用を分ける、詳細データは必要な時だけ読み込むなどの工夫が有効です。ただし、軽量化によって必要な頂点や属性を失わないよう、用途ごとにデータを作り分けることが大切です。
また、現場で見た時に意味が分かる名称にすることも重要です。机上で作った分類名や内部コードだけでは、現地担当者が判断しにくい場合があります。属性には正式名称だけでなく、現場で呼ばれている名称や管理上必要な補足を入れると、確認作業がしやすくなります。ただし、自由記述が増えすぎると表記揺れが起こるため、選択肢で管理する項目と自由記述で補足する項目を分けるとよいです。
GeoJSONは、軽量で共有しやすい一方、測量成果、設計図面、点検記録、写真、現場メモのすべてを自動的に整合させるものではありません。現場で使いやすいデータにするには、何のために使うのか、誰が見るのか、どの精度が必要なのか、どこまで更新するのかを決めてから整備する必要があります。形式の理解と運用設計を組み合わせることで、GeoJSONは単なる変換データではなく、現場と図面をつなぐ実務データとして活用しやすくなります。
まとめ
GeoJSONをArcGISで扱う時のつまずきは、読み込み操作そのものよりも、データの前提を確認しないまま作業を進めることから生まれます。座標参照系が曖昧、緯度経度と平面直角座標系を混同している、形状エラーが残っている、属性フィールドの型がそろっていない、面積や距離の計測条件が曖昧、書き出し時の設定が確認されていないといった状態では、地図上に表示できても実務判断に使うには不安が残ります。
特に、geojsonで検索する実務担当者が知りたいのは、形式の説明だけではなく、ArcGISで読み込んだ時に何を確認すればよいかです。まず座標値の桁と並びを見て、標準的な経度緯度なのか、メートル単位の座標が混在した非標準的なデータなのかを判断します。次に、形状の種類、ポリゴンの閉じ方、ラインの分断、ポイントの欠落を確認します。さらに、属性の文字化け、数値と文字列の扱い、日付の表記、管理番号の保持を確認します。そのうえで、面積や距離を使う場合は、計測に適した座標系と計算方法であるかを確認することが重要です。
GeoJSONは、現場で取得した位置情報や管理対象の地物を共有するうえで便利な形式です。しかし、便利だからこそ、表示用のデータと精度管理用のデータを混同しないことが大切です。図面、測量成果、写真、点検記録、施工範囲をつなげるには、データ形式だけでなく、座標、属性、更新ルール、現場での確認方法まで含めて整える必要があります。
現場でGeoJSONを活用する場面では、机上のArcGIS作業だけでなく、実際の位置確認や写真記録との連携が重要になります。地図上で正しく表示できること、必要な属性が残っていること、現場で確認できる精度と粒度になっていることを確認すれば、GeoJSONは関係者間の情報共有や現地確認を効率化する実務データとして使いやすくなります。