GeoJSONは、点・線・面などの地理情報を扱いやすい形式で表現できるため、Web地図や現場管理用の地図画面、位置情報を使った業務システムで広く使われています。テキスト形式で中身を確認しやすく、属性情報も一緒に持たせられるため、データの受け渡しや簡易な可視化にも向いています。
一方で、GeoJSONは見た目が分かりやすい反面、座標の順番、座標参照の前提、ポリゴンの閉じ方、属性名の揺れ、ファイル容量などの小さな不整合が、そのままWeb地図上の表示崩れや誤表示につながることがあります。特に実務では、図面、測量データ、台帳、現地確認結果など、別々の工程で作られた情報をGeoJSONに変換して使う場面が多くあります。そのため、Web地図に読み込む直前だけでなく、作成・変換・共有の段階から確認すべき点を整理しておくことが大切です。
この記事では、geojsonで検索して情報を探している実務担当者に向けて、Web地図で使う前に確認したい7項目を、現場運用に近い視点で整理します。
座標系と経度・緯度の順番を確認する
GeoJSONをWeb地図で使う前に、最初に確認したいのが座標系と座標値の並び順です。GeoJSONの位置情報は、原則として経度、緯度の順番で記述します。日常的な会話では「緯度・経度」と言うことが多いため、データ作成時に緯度を先、経度を後にしてしまうミスが起こりやすくなります。この順番を誤ると、地物が本来の場所から大きく離れた位置に表示されたり、地図上に何も出てこないように見えたりします。
日本国内のデータを扱う場合、経度はおおむね120度台から150度台、緯度は20度台から40度台に収まることが多いため、数値の範囲を見るだけでも明らかな入れ替わりを発見できる場合があります。ただし、作業対象地域が限定されている場合は、もっと狭い範囲で確認する必要があります。たとえば、ある現場や自治体の範囲で使うデータであれば、その地域の中心座標や外接範囲をあらかじめ把握しておき、GeoJSON内の座標がそこから大きく外れていないかを見ると、読み込み前の段階で不自然なデータを見つけやすくなります。
もう一つ注意したいのが、元データが緯度経度ではなく、平面直角座標や独自のローカル座標で管理されている場合です。測量や設計の工程では、メートル単位の座標値が使われることがあります。その値を変換せずにGeoJSONへ入れると、Web地図側では経度・緯度として扱われ、意図しない場所に表示されたり、読み込みエラーの原因になったりします。数値の桁が経度・緯度として不自然である、対象地域の範囲から大きく外れている、座標値に想定外の符号や大きな整数が混在しているといった場合は、元の座標系を確認した方が安全です。
GeoJSONの標準的な扱いでは、座標はWGS 84の経度・緯度を前提にするのが基本です。元データが日本測地系、世界測地系、平面直角座標系、ローカル座標など別の前提で作られている場合は、Web地図に載せる前に変換条件を確認する必要があります。座標系の名称だけでなく、何系の平面直角座標なのか、単位はメートルなのか、原点や回転を含むローカル座標なのかまで確認しておくと、表示後の位置ずれを避けやすくなります。
高さ情報を含むデータにも注意が必要です。GeoJSONでは、座標配列の3番目に高さなどの値を含められる場合がありますが、すべてのWeb地図画面がその値を表示や判定に使うとは限りません。標高や高さを業務上重要な属性として扱う場合は、座標値の3番目に入れるだけでなく、属性情報にも分かりやすく持たせるなど、後工程で確認しやすい形にしておくと安心です。Web地図上で平面的に表示するだけなのか、現場確認や点検記録として高さも見たいのかによって、データの持たせ方は変わります。
座標系の確認は、表示前の地味な作業に見えますが、GeoJSON運用の土台です。位置がずれたまま属性や見た目を調整しても、最終的には信頼しにくい地図になります。最初に座標の順番、座標参照の前提、元データの単位、対象地域の範囲をそろえておくことで、その後の確認作業を大きく減らせます。
ジオメトリの種類と閉じ方を確認する
GeoJSONでは、点を表すPoint、線を表すLineString、面を表すPolygon、複数の地物をまとめるMultiPoint、MultiLineString、MultiPolygon、複数種類のジオメトリを含められるGeometryCollectionなど、用途に応じてジオメトリの種類を使い分けます。Web地図で正しく表示するには、まずデータの目的とジオメトリの種類が合っているかを確認する必要があります。点検箇所や写真撮影位置を表したいなら点、道路中心線や配管ルートを表したいなら線、敷地や管理区域を表したいなら面、というように、現場で何を見せたいのかに合わせて選ぶことが基本です。
よく起こるのは、本来は面として扱うべき区域を線として出力してしまうケースです。見た目だけを見ると外周線が表示されているため気づきにくいのですが、面積計算、内外判定、塗りつぶし表示、重なり判定を行う場面では期待どおりに動かなくなります。逆に、線で十分な対象を面にしてしまうと、表示が重くなったり、管理したい中心線と実際の表示位置がずれて見えたりします。GeoJSONを作るときは、単に地図に見えるかどうかではなく、その後にどのような操作や判定を行うのかまで考えてジオメトリを確認することが大切です。
PolygonやMultiPolygonを扱う場合は、外周の閉じ方も重要です。面を表す座標列では、外周の始点と終点が一致している必要があります。閉じていない面は、読み込み側の処理によっては自動的に補正されることもありますが、常に期待どおりに補正されるとは限りません。Web地図上では一見表示されていても、穴あきポリゴン、複数ポリゴン、細長い区域、境界線が複雑な区域では、塗りつぶしや境界の表現が不自然になることがあります。
ポリゴンでは、外周と内周の向きにも注意します。GeoJSONでは、外周と穴を表す内周を区別して扱うため、座標列の閉じ方だけでなく、外周と内周の関係が正しく表現されているかを確認することが大切です。多くの表示環境では多少の違いを補正して表示できる場合もありますが、面の塗りつぶしや穴の表現、他形式への変換で意図しない結果になることがあります。変換ツールを使う場合も、出力後に代表的な面を開いて確認しておくと安全です。
内側に穴を持つ面では、外周と内周の関係も確認しておきたいところです。たとえば、管理区域の中に対象外の敷地や水域がある場合、外側の面だけで表すと、本来は除外すべき場所まで含んで見えてしまいます。穴を使って表現するのか、別の面として属性で区別するのかは、Web地図での見せ方や検索条件によって変わります。後から見た人が判断できるように、データ構造と属性の両方で意図が分かる状態にしておくと、運用時の誤解を減らせます。
また、線や面の自己交差にも注意が必要です。境界線が途中で交差していたり、細かい折れ点が不自然に入り込んでいたりすると、地図上の表示が崩れるだけでなく、面積や重なりの判定に影響することがあります。特に図面由来のデータや手作業で編集したデータでは、見た目では分かりにくい微小な重複や隙間が残ることがあります。Web地図で使う前には、代表地点だけでなく、拡大表示で境界のつながりや端点の位置を確認しておくと安全です。
属性情報の名前と値の揺れを確認する
GeoJSONの便利な点は、位置情報だけでなく、propertiesに属性情報を持たせられることです。現場名、管理番号、種別、施工日、点検結果、写真番号、担当者、状態区分などを一緒に扱えるため、Web地図上でクリック表示や検索、絞り込みに使いやすくなります。しかし、属性情報は自由に書ける分だけ、名前や値の揺れが起きやすい部分でもあります。
まず確認したいのは、属性名が統一されているかです。同じ意味の項目が、あるFeatureでは「id」、別のFeatureでは「番号」、さらに別のFeatureでは「管理ID」のように分かれていると、Web地図側で一覧表示や検索条件を組むときに扱いづらくなります。人間が見れば同じ意味だと分かる項目でも、システム上は別の項目として扱われます。読み込み後に表示されない属性がある、検索に引っかからない地物がある、色分け条件から漏れる地物があるといった問題は、属性名の揺れが原因になっていることがあります。
値の表記ゆれも見落とせません。たとえば、状態区分として「完了」「済」「施工済み」が混在していると、同じ状態の地物を一括で色分けしたいときに条件が分かれてしまいます。日付も同様で、「2026-05-25」「2026/5/25」「令和表記」などが混在すると、並び替えや期間検索に使いにくくなります。数値についても、文字列として入っているのか、数値として入っているのかによって、集計や比較の動きが変わることがあります。面積、延長、高さ、数量などをWeb地図上で扱う場合は、単位とデータ型の前提をそろえておくことが大切です。
空欄や未入力の扱いも決めておく必要があります。属性がないFeature、属性名はあるが値が空のFeature、値として「未定」や「不明」と書かれたFeatureが混在していると、後工程で判断が難しくなります。未入力なのか、確認した結果として該当なしなのか、現時点では未確定なのかを区別できるようにしておくと、現場確認や台帳更新のときに混乱しにくくなります。とくに複数人で編集する場合は、入力ルールがあいまいだと短期間で属性の品質がばらつきます。
Web地図でクリックしたときに表示する項目も、属性設計と関係します。すべての属性をそのまま表示すると、現場担当者が必要な情報を探しにくくなることがあります。一方で、表示項目を絞りすぎると、確認に必要な番号や日付が見えず、別資料を開く手間が増えます。GeoJSONをWeb地図で使う前には、地図上で見る人が何を判断するのかを想定し、属性名、値、空欄、単位、表示順を整えておくことが重要です。
属性情報には、個人情報や公開範囲に注意すべき情報が含まれることもあります。担当者名、電話番号、所有者名、詳細な住所、内部管理用の備考などをそのままWeb地図に載せると、共有先や公開範囲によっては不要な情報まで見えてしまいます。GeoJSONはテキストとして中身を確認しやすい反面、ファイルを渡すと属性情報も一緒に渡る点に注意が必要です。Web公開や外部共有を行う場合は、表示しない項目だけでなく、GeoJSONファイル自体に含めない項目も整理しておくと安全です。
ファイル容量と表示速度の負荷を確認する
GeoJSONはテキスト形式のため扱いやすい一方で、地物数や頂点数が増えるとファイル容量が大きくなりやすい特徴があります。境界線が非常に細かい区域、長い道路線形、多数の点検位置、広域の管理区画などをそのままWeb地図に読み込むと、表示に時間がかかったり、拡大縮小の操作が重くなったりすることがあります。業務で使うWeb地図では、正確さだけでなく、現場でストレスなく開けるかどうかも重要です。
まず見るべきなのは、データの目的に対して頂点数が過剰になっていないかです。図面や測量成果から変換したGeoJSONでは、境界を非常に細かい折れ点で保持していることがあります。高精度な確認が必要な場合は細かさが意味を持ちますが、広域の位置把握や概略表示が目的であれば、過剰な頂点が表示負荷を増やすだけになることがあります。Web地図では、縮尺によって必要な細かさが変わるため、詳細確認用と概要表示用でデータを分ける考え方も有効です。
次に、属性情報の量も確認します。各Featureに長い説明文や重複した情報を大量に持たせると、座標だけでなく属性によっても容量が増えます。写真や帳票そのものをGeoJSONの中に直接入れるような設計は、表示や共有の負担が大きくなることがあります。現場写真や関連資料は、GeoJSON内にファイル名、識別番号、参照用の情報を持たせ、実体は別の管理方法に分ける方が運用しやすい場合があります。GeoJSONは地図表示と関連情報の入口として使い、重いデータをすべて抱え込ませないことが大切です。
表示範囲に対して不要な地物が含まれていないかも確認しましょう。特定の現場で使うWeb地図なのに、広域の過去データや別工区の地物まで含まれていると、読み込みに時間がかかるうえ、誤って別の地物を参照する原因になります。ファイルを分割する、対象範囲で切り出す、完了済みと作業中を分けるなど、利用場面に合わせて軽くする工夫が必要です。1つのGeoJSONにすべて入れておけば管理しやすいように見えますが、閲覧する人や端末の条件を考えると、分割した方が安全なこともあります。
モバイル端末で使う場合は、通信環境も考慮する必要があります。事務所の安定した回線では問題なく開けるGeoJSONでも、現場の屋外や地下、山間部では読み込みに時間がかかることがあります。Web地図を現場で開く前提なら、実際に近い端末と通信環境で試し、初回表示、拡大縮小、クリック表示、検索の動きを確認しておくと安心です。データの正確さと表示速度はどちらか一方だけを満たせばよいものではありません。目的に合わせて必要な精度を残しながら、現場で使える軽さに整えることが実務上のポイントです。
必要に応じて、GeoJSONをそのまま配布するのではなく、用途に合った形式や配信方法を検討することもあります。たとえば広域データや大量の地物を扱う場合、縮尺ごとにデータを分ける、サーバー側で必要範囲だけを返す、地図表示用に別形式へ変換するなどの方法があります。ただし、どの方法が適しているかは利用する地図環境や更新頻度によって変わるため、まずは実際の利用条件に近い状態で表示確認を行うことが大切です。
地物の表示範囲と重なりを確認する
GeoJSONをWeb地図に読み込むときは、データが表示されるかどうかだけでなく、表示範囲や重なり方も確認する必要があります。地物が地図上に出ていると、それだけで正しく使えるように見えてしまいますが、実際には一部の地物が範囲外に飛んでいたり、別の地物に隠れていたり、重なり順の影響で判断しにくくなっていたりすることがあります。特に点、線、面を同じ地図上で扱う場合は、見え方の確認が重要です。
まず、全体表示でデータの外接範囲を確認します。対象地域に対して極端に離れた場所に1点だけ地物がある場合、座標入力ミス、経度緯度の入れ替わり、不要データの混入、変換時の不具合などが考えられます。地図を読み込んだときに表示範囲が不自然に広がる場合は、どこかに外れ値が含まれている可能性があります。Web地図で最初に全体表示したとき、対象地が小さく見えすぎる、地図が想定外の地域まで広がる、中心位置がずれるといった現象があれば、外れた座標を探すことが必要です。
面データでは、隣接するポリゴンの隙間や重複も確認したい点です。管理区域、筆界、施工範囲、点検対象エリアなどを扱う場合、隣り合う面にわずかな隙間があると、内外判定や面積集計に影響することがあります。逆に、重複している部分があると、同じ場所が二重に集計されたり、色分け表示で上にある面だけが見えたりします。見た目では分かりにくい小さなズレでも、業務判断に使う場合は問題になることがあります。境界が重要なデータでは、縮尺を変えながらつなぎ目を確認することが大切です。
線データでは、端点の接続や分断が問題になることがあります。道路、管路、ケーブル、巡回ルートなどを線で表す場合、見た目ではつながっているように見えても、実際の座標上では端点が少し離れていることがあります。経路検索や区間管理、延長集計を行う場合、この小さなズレが不整合につながります。Web地図で線を表示するだけなら気づかないこともあるため、端点が多い場所、分岐点、工区境、変換元が異なるデータの接続部を重点的に確認するとよいです。
点データでは、同じ位置に複数の点が重なっていないかも見ます。写真撮影位置、点検箇所、設備位置などでは、同一点に複数の記録が重なることがあります。これは正しい場合もありますが、表示上は1つの点に見えて、下にある情報をクリックできないことがあります。点が密集する現場では、表示方法や属性のまとめ方を考えておかないと、地図上で必要な記録にたどり着きにくくなります。GeoJSON側で重複を整理するのか、Web地図側で近接点をまとめて表示するのか、業務に合わせて方針を決めることが必要です。
表示範囲と重なりの確認は、単なる見た目の調整ではありません。現場担当者が地図を見て判断する場合、見えない地物、隠れた地物、誤って目立つ地物があると、確認漏れや作業ミスにつながります。Web地図で使う前には、全体、拡大、重なり、接続、密集のそれぞれを見て、地図として読みやすい状態に整えておくことが重要です。
更新・変換・配布時の壊れやすい点を確認する
GeoJSONは、作った時点で正しくても、変換、編集、結合、分割、配布の過程で壊れることがあります。実務では、元データを別形式から変換したり、複数の担当者が編集したり、Web地図用に軽量化したりすることが多いため、最終的に使うGeoJSONがどの工程を通ってきたのかを把握することが大切です。データの見た目だけを確認していると、更新時に同じ不具合が繰り返されることがあります。
まず確認したいのは、変換前後で地物数が変わっていないかです。元データに100件の地物があるのに、GeoJSON化した後に98件になっている場合、変換できなかった地物、空のジオメトリ、対応していない形状、属性エラーなどが含まれている可能性があります。逆に件数が増えている場合は、複数パートの地物が分割された、重複データが混入した、変換時に余計なレコードが作られたといった原因が考えられます。Web地図で目視確認する前に、件数の照合を行うだけでも多くのミスを防げます。
文字コードや文字化けも実務では重要です。現場名、住所、担当者名、備考欄などに日本語が含まれる場合、変換や保存の条件によっては文字が崩れることがあります。GeoJSONは文字コードとしてUTF-8を前提に扱うのが基本ですが、元データや変換途中のファイルで文字化けが発生していると、そのまま属性に残ることがあります。Web地図上で文字化けしていると、現場で識別できないだけでなく、検索にも影響します。特に外部から受け取ったデータや、複数の環境を経由したデータでは、属性表示を実際に開いて確認することが必要です。地図上の形だけでなく、クリックしたときの属性表示まで見ることが大切です。
更新作業では、古いGeoJSONと新しいGeoJSONの差分管理も課題になります。地物が追加されたのか、削除されたのか、位置が修正されたのか、属性だけが変わったのかを把握できないと、現場でどれが最新か判断しにくくなります。ファイル名に日付を入れるだけでは、同じ日に複数回更新した場合や、後から修正した場合に混乱することがあります。更新日、版数、作成者、対象範囲、元データの名称などを属性または管理情報として残しておくと、後から確認しやすくなります。
配布時には、GeoJSON単体で意味が伝わるかも確認しましょう。作成者だけが分かる略称や社内用語、説明のないコード値が多いと、受け取った側は正しく扱えません。Web地図に読み込む担当者、現場で見る担当者、台帳に反映する担当者が別々の場合は、属性名や区分値の意味が分かるように整えておく必要があります。GeoJSONは開きやすい形式ですが、開けることと正しく理解できることは別です。配布する前に、受け手が迷わず使える状態かどうかを見直すことが大切です。
変換や更新のたびに毎回すべてを目視で確認するのは大変です。そのため、最低限の確認項目を決めておくと運用が安定します。件数、座標範囲、属性名、必須項目の空欄、文字化け、ファイル容量、代表地点の表示確認など、定型的に見る項目を決めておけば、担当者が変わっても品質を保ちやすくなります。GeoJSONは柔軟だからこそ、運用ルールを持たないと品質がばらつきやすい形式でもあります。
現場で使う前提と運用手順を確認する
最後に確認したいのは、GeoJSONを実際の現場業務でどう使うかという前提です。Web地図上に正しく表示されることは重要ですが、それだけでは現場で使えるデータとは言い切れません。誰が、どの端末で、どのタイミングで、何を判断するために見るのかを決めておかないと、せっかく整えたGeoJSONも十分に活用されません。
現場で使う場合、まず閲覧する人の目的を整理します。施工範囲を確認するための地図なのか、点検位置に迷わず向かうための地図なのか、写真記録と位置を照合するための地図なのか、管理区域の境界を共有するための地図なのかによって、必要な情報は変わります。事務所で確認する担当者には詳細な属性が必要でも、現場で移動しながら見る担当者には、名称、状態、注意点、現在地との関係がすぐ分かる方が使いやすい場合があります。GeoJSONを作る段階で、利用者ごとの見方を意識しておくことが大切です。
次に、現地での位置精度に対する期待値をそろえる必要があります。Web地図上のGeoJSONと端末の現在位置を重ねて見る場合、端末側の測位条件によって現在地表示にズレが出ることがあります。周囲の建物、樹木、地形、空の開け具合、通信環境などによって、表示される現在地の安定性は変わります。GeoJSONの境界が正しくても、現地で見ている現在地が揺れていれば、境界付近の判断には注意が必要です。現場で使うときは、地図データの精度と現在地取得の精度を分けて考えることが重要です。
オフラインや通信不安定時の扱いも確認しておきましょう。事務所でWeb地図を開けても、現場で同じように開けるとは限りません。GeoJSONを事前に読み込めるのか、通信が切れた場合に表示が残るのか、更新後のデータがいつ反映されるのかを確認しておかないと、古い地図を見ながら作業してしまう可能性があります。特に当日の施工範囲、立入禁止区域、点検済み箇所のように更新頻度が高い情報では、最新版の確認手順を決めておくことが大切です。
現場写真や記録とGeoJSONを結びつける場合は、識別番号の持たせ方が重要になります。地図上の点や区域と、写真、帳票、作業記録が別々に管理されていると、後から照合するときに手間がかかります。GeoJSONの属性に共通の管理番号を入れておけば、地図上の地物と記録を結びつけやすくなります。逆に、ファイル名や備考欄だけに頼ると、表記ゆれや記録漏れによって追跡しにくくなることがあります。現場で撮る、地図で見る、事務所で整理するという一連の流れを想定して、識別情報を整えておくと運用が楽になります。
GeoJSONをWeb地図で安全に使うには、データ作成者だけでなく、現場で見る人、更新する人、確認する人が同じ前提を共有することが欠かせません。座標系、形状、属性、容量、表示範囲、更新管理を確認したうえで、現場の使い方に合わせて運用手順を決めることで、GeoJSONは単なる地図データではなく、業務判断を支える情報基盤になります。
Web地図でGeoJSONを活用する場面では、正しい位置情報を現場で取得し、写真や記録と結びつけて残す流れも重要になります。特定の製品やサービスに依存して考えるのではなく、位置取得方法、端末の測位精度、写真や帳票との管理番号、更新手順、共有範囲を整理し、現場で再現しやすい運用に落とし込むことが大切です。