GeoJSONを地図表示に使う5ステップと失敗例

GeoJSONは、点、線、面などの地物情報をテキスト形式で扱えるため、現場調査、設備管理、台帳整備、区域確認、施工管理、維持管理など、さまざまな実務で使いやすいデータ形式です。一方で、見た目は比較的わかりやすくても、座標の順序、座標系、属性情報、ファイル容量、表示条件を誤ると、地図上に何も表示されない、位置が大きくずれる、必要な情報が確認できないといった失敗につながります。この記事では、「geojson 使い方」で調べている実務担当者に向けて、GeoJSONを地図表示に使う基本の流れと、現場で起こりやすい失敗例を整理します。

目次

• GeoJSONを地図表示に使う前に押さえる基本

• ステップ1として表示したい地物を整理する

• ステップ2として座標と位置の前提を確認する

• ステップ3としてGeoJSONの構造を整える

• ステップ4として地図表示に読み込ませる

• ステップ5として見え方と属性情報を確認する

• 地図表示で起こりやすい失敗例を知る

• 実務でGeoJSONを安定運用するための考え方

• まとめ

GeoJSONを地図表示に使う前に押さえる基本

GeoJSONは、地図上に表示したい位置情報と、その位置に関連する属性情報を一つのデータとして扱うための形式です。点であれば設備の位置、線であれば道路や管路の中心線、面であれば敷地、区域、管理範囲などを表現できます。地図表示に使う場合は、単にファイルを作ればよいのではなく、何を表示したいのか、どの縮尺で確認したいのか、誰がどの場面で使うのかを決めておくことが重要です。

実務でGeoJSONを使う場面では、測量成果、現地確認の記録、図面から抽出した範囲、設備台帳、点検箇所、施工範囲など、元になる情報が複数に分かれていることがあります。これらをそのまま一つの地図に載せようとすると、表示内容が多すぎて見づらくなったり、属性項目がばらばらになったりします。そのため、GeoJSONを作る前に、地図上で見せる目的を明確にすることが欠かせません。

GeoJSONの特徴は、テキスト形式で中身を確認しやすい点にあります。専用の高度な環境がなくても、構造そのものは開いて確認できます。ただし、構造を目で追えることと、正しく地図に表示できることは同じではありません。括弧やカンマの不足、座標の並び間違い、属性名の表記揺れ、面データの閉じ忘れなど、わずかな不備でも表示エラーになることがあります。

また、GeoJSONを地図に表示する場合、位置の正しさだけでなく、表示後の使いやすさも大切です。例えば、点が地図上に表示されても、何の点なのか分からなければ実務では使いにくくなります。面が表示されても、範囲名、管理者、確認日、状態などが確認できなければ、現場判断や共有資料としては不十分です。つまり、GeoJSONの使い方では、形状データと属性データをセットで考える必要があります。

GeoJSONは柔軟な形式ですが、自由に作れるからこそルールを決めずに運用すると混乱しやすくなります。ファイル名、属性名、座標の扱い、更新日、作成者、用途、表示色の考え方などをあらかじめ整理しておくことで、後から見直したときにも意味が分かるデータになります。地図表示は最終的な見た目だけでなく、作成から確認、共有、更新までを含めた一連の流れとして設計することが大切です。

ステップ1として表示したい地物を整理する

GeoJSONを地図表示に使う最初のステップは、表示したい地物を整理することです。点を表示するのか、線を表示するのか、面を表示するのかによって、作るべきデータの形は変わります。現場写真の撮影位置、点検箇所、基準点、設備位置のように一点で示せるものは点データが向いています。道路中心線、排水路、配管、電線ルート、移動経路のように連続した形を持つものは線データが向いています。敷地、工区、立入禁止範囲、管理区域、浸水想定範囲のように広がりを持つものは面データが向いています。

実務では、最初からすべてを一つのGeoJSONにまとめようとしがちですが、用途が異なる情報を無理に混在させると後で扱いにくくなります。例えば、点検箇所の点データと工事範囲の面データを同じファイルに入れることはできますが、表示設定や属性項目が異なるため、確認画面で混乱することがあります。まずは用途ごとに分けるのか、同じファイル内で地物の種類を属性として管理するのかを決める必要があります。

表示したい地物を整理するときは、地図を見る人が何を判断したいのかを考えるとよいです。点の有無を確認したいだけなのか、点の種類まで見分けたいのか、線の接続関係を確認したいのか、面の重なりや境界を見たいのかによって、必要なデータの粒度が変わります。点が多すぎる場合は、全点を表示するよりも、種類や状態で絞り込めるようにした方が実務では使いやすくなります。

属性情報もこの段階で整理しておくと、後の作業が安定します。属性とは、地物に付ける説明情報のことです。点検箇所であれば、名称、管理番号、確認日、状態、担当者、備考などが候補になります。施工範囲であれば、工区名、作業内容、予定日、進捗、確認状況などが考えられます。ただし、必要以上に項目を増やすと入力や更新の負担が大きくなるため、地図上で確認する目的に合う項目に絞ることが大切です。

このステップでよくある失敗は、元データにある情報をすべてGeoJSONに入れてしまうことです。台帳や表計算データには多くの列が含まれていることがありますが、そのすべてが地図表示に必要とは限りません。不要な項目が多いとファイルが重くなり、表示や検索の処理にも影響する場合があります。さらに、個人情報や公開に適さない内部情報が混入するおそれもあります。地図表示に使うGeoJSONでは、表示目的と共有範囲に合わせて項目を選ぶことが重要です。

もう一つの失敗は、地物の単位がそろっていないことです。例えば、ある点は設備一基ごと、別の点は施設一式ごと、別の点は写真一枚ごとに作られていると、同じ点データでも意味が混在します。線データでも、道路一本を一つの線にするのか、交差点ごとに分割するのか、工事範囲ごとに分けるのかで後の使い方が変わります。最初の整理があいまいなまま進めると、地図に表示できても集計や検索で不整合が出やすくなります。

ステップ2として座標と位置の前提を確認する

GeoJSONを地図表示に使ううえで、座標の確認は特に重要な作業です。GeoJSONでは、原則として座標を経度、緯度の順で記述します。標高などを含める場合は、その後ろに値を追加する形になります。日常的な表記では緯度、経度の順で扱うことが多いため、この違いを見落とすと、地図上でまったく違う場所に表示される原因になります。日本国内の位置を扱う場合でも、座標の順序が逆になると海外や海上に点が飛んでしまうことがあります。

座標の前提では、どの座標系で作られたデータなのかも確認する必要があります。GeoJSONで地図表示に使う座標は、一般的に経度緯度を前提として扱われます。一方、現場測量や設計図面では、平面直角座標系などの平面上の座標値が使われることがあります。元データが平面座標のままなのに、そのままGeoJSONに入れて地図へ読み込むと、正しい位置に表示されません。必要に応じて、地図表示で使う座標系に変換してからGeoJSON化する必要があります。

座標確認では、数値の桁や範囲を見るだけでも多くのミスを発見できます。経度や緯度として扱う値であれば、日本周辺ではおおむね一定の範囲に収まります。ところが、桁数が大きすぎる値や、緯度として考えにくい値が入っている場合は、座標系の違いや列の取り違えを疑うべきです。表データから変換する場合は、経度列と緯度列の見出しが正しく対応しているか、単位が混ざっていないかを確認します。

位置の前提では、測定した点が何を代表しているのかも重要です。建物の位置を示す点でも、入口の位置なのか、中心付近なのか、敷地代表点なのかによって意味が変わります。施工範囲の面データでも、設計上の範囲なのか、実際に施工した範囲なのか、確認対象範囲なのかを区別する必要があります。GeoJSONは位置を表示できますが、その位置が何を意味するのかは属性や運用ルールで補う必要があります。

このステップでよくある失敗は、地図上に表示できたことだけで正しいと判断してしまうことです。座標の順序や変換がたまたま近い場所に見える場合でも、数メートルから数十メートルのずれが発生していることがあります。現場管理や点検、境界付近の確認では、このずれが大きな問題になることがあります。表示後には、既知の地点、現地写真、図面、管理台帳などと照合して、位置が実務上許容できる範囲にあるか確認することが大切です。

また、座標の精度を過信することも避けるべきです。GeoJSONに細かい小数桁の座標が入っているからといって、必ず高精度な測位結果を意味するわけではありません。元データが目視で置いた点であれば、数値の桁が細かくても実際の位置精度は限定的です。逆に、高精度に取得した座標でも、変換や丸め、編集の過程で精度が損なわれることがあります。地図表示に使うときは、座標値だけでなく、取得方法や更新履歴も把握しておくと安心です。

ステップ3としてGeoJSONの構造を整える

座標と表示対象が整理できたら、GeoJSONの構造を整えます。GeoJSONでは、複数の地物をまとめて扱う場合、FeatureCollectionの中に複数のFeatureを入れ、それぞれのFeatureに形状情報と属性情報を持たせる構成がよく使われます。形状情報には、Point、LineString、Polygonなどの種類と座標が入ります。属性情報には、名称、分類、状態、確認日、備考など、地図上で確認したい情報を入れます。この構造が整っていないと、地図表示側で読み込みに失敗したり、一部の地物だけ表示されなかったりします。

構造を整えるときにまず見るべきなのは、括弧、引用符、カンマなどの基本的な記述です。GeoJSONはJSON形式に基づいているため、人が読める一方で、機械が読むための厳密な構造を持っています。余分なカンマがある、必要なカンマがない、文字列を囲む記号が欠けている、括弧の対応が崩れていると、全体を読み込めなくなることがあります。手作業で編集する場合は、少しの修正でも全体の構造確認を行うことが大切です。

点データでは、座標が一組で表現されます。線データでは、複数の座標を順番に並べます。面データでは、外周を構成する座標列が必要で、最初の座標と最後の座標を一致させて閉じた形にします。面が閉じていない場合、表示環境によっては面として扱えなかったり、意図しない形に塗られたりすることがあります。複数の面や穴を持つ形状を扱う場合は、さらに構造が複雑になるため、まずは単純な面から確認する方が安全です。

属性情報では、項目名の統一が重要です。同じ意味の項目でも、「名称」「名前」「地物名」のように表記が揺れると、表示側でラベルや検索条件を設定しにくくなります。状態を表す値も、「未確認」「未調査」「確認前」のようにばらつくと、後で絞り込みや色分けを行うときに不便です。GeoJSONを実務で使う場合は、属性名と入力値のルールをあらかじめ決め、できるだけ表記をそろえることが必要です。

このステップで起こりやすい失敗は、見た目だけを整えて、データとしての一貫性を確認しないことです。例えば、地図上では点が表示されていても、ある点だけ管理番号が空欄だったり、日付の形式が異なっていたりすると、後で検索や集計に支障が出ます。属性情報は地図の付属情報ではなく、実務で判断するための重要な情報です。地図表示の前に、空欄、重複、表記揺れ、不要な文字、公開できない情報の混入を確認しておくべきです。

もう一つ注意したいのは、ファイルの分け方です。一つのGeoJSONに多くの地物を詰め込みすぎると、読み込みや表示が重くなることがあります。特に細かい面データや長い線データは、座標数が増えやすくなります。範囲ごと、用途ごと、更新頻度ごとにファイルを分けることで、表示負荷を抑えやすくなります。ただし、細かく分けすぎると管理が難しくなるため、地図を見る人が迷わない単位で整理することが大切です。

ステップ4として地図表示に読み込ませる

構造を整えたGeoJSONは、地図表示の仕組みに読み込ませて確認します。ここで重要なのは、いきなり本番用の地図に載せるのではなく、まずは確認用の環境で表示テストを行うことです。小さなサンプルから読み込み、点、線、面が想定した場所に表示されるか、属性情報が確認できるか、表示の重さに問題がないかを確認します。最初から大量のデータを読み込むと、どこに原因があるのか切り分けにくくなります。

読み込み時には、ファイルの保存形式や文字コードも確認します。属性情報に日本語が含まれる場合、文字化けが発生すると地図上で名称や備考が読めなくなります。表示側で扱える文字形式になっているか、余分な制御文字が入っていないかを確認すると、読み込み後のトラブルを減らせます。特に複数の表データや外部出力を組み合わせた場合は、文字の扱いが混在しやすいため注意が必要です。

地図表示に読み込ませる際は、表示範囲の設定も確認します。データが正しく読み込まれていても、初期表示位置が離れていると、何も表示されていないように見えることがあります。この場合、地図を大きく縮小したり、地物の範囲に合わせて表示範囲を調整したりすることで確認できます。読み込みエラーではなく、表示している場所が違うだけというケースは実務でもよくあります。

表示スタイルは、実務での見やすさに大きく影響します。点の大きさ、線の太さ、面の塗りつぶし、透過の有無、ラベル表示の条件などを調整しないと、地図に載っていても判読しにくくなります。特に面データは、塗りつぶしが濃すぎると背景地図や他の地物が見えなくなります。線データは細すぎると縮尺によって見落としやすくなります。点データは数が多いと重なって見えるため、分類や表示縮尺を考える必要があります。

このステップでよくある失敗は、読み込みエラーの原因をGeoJSONだけに限定してしまうことです。実際には、ファイルの置き場所、アクセス権限、表示側の設定、読み込みタイミング、地図の初期位置、データ量など、複数の要因が関係します。GeoJSONの構造が正しくても、表示側が想定する条件と合っていなければ見えない場合があります。確認するときは、ファイル単体の妥当性、読み込み経路、表示設定を分けて確認することが大切です。

読み込み後には、代表的な地物をいくつか選び、地図上で属性情報を開いて確認します。名称が正しく表示されるか、分類が想定通りか、日付や備考が崩れていないか、不要な項目が表示されていないかを見ます。実務では、地図上の見た目だけでなく、クリックや選択をしたときに必要な情報がすぐ分かることが重要です。表示確認は、作成者だけでなく、実際に使う担当者の視点でも行うと効果的です。

ステップ5として見え方と属性情報を確認する

GeoJSONを地図に表示できたら、最後に見え方と属性情報を確認します。この段階では、単に表示されたかどうかではなく、業務で使える状態になっているかを確認します。点、線、面が正しい位置にあり、必要な縮尺で見やすく、属性情報が判断に使える内容になっているかを確認します。地図表示は完成物に見えやすいですが、実務ではここからの確認が品質を左右します。

見え方の確認では、縮尺を変えながら表示を確認することが大切です。広域で見ると分かりやすい表示でも、拡大すると点がずれて見えたり、線が対象物と重ならなかったりすることがあります。逆に、拡大時には見やすくても、広域では点やラベルが密集して読みづらいことがあります。どの縮尺で主に使うのかを想定し、必要に応じて表示条件を調整します。

属性情報の確認では、地図上で選択したときに、利用者が必要とする情報が過不足なく表示されるかを見ます。名称だけでは現場で判断できない場合があります。管理番号、種別、状態、確認日、備考など、業務に必要な情報を表示できるようにしておくと、地図から次の行動につなげやすくなります。一方で、内部メモや公開対象外の情報を表示してしまうと、共有時のリスクになります。表示項目は、利用場面ごとに見直す必要があります。

見え方の確認では、色や記号の意味を明確にすることも重要です。状態によって色を変える場合、どの色がどの状態を示すのかを利用者が理解できなければ、誤解の原因になります。点の形や線の種類を変える場合も同じです。地図上の表現は直感的に見えますが、ルールが共有されていないと、見る人によって解釈が変わります。GeoJSON側の属性値と表示側のルールを対応させ、誰が見ても同じ意味で読めるようにします。

このステップでよくある失敗は、作成者の画面だけで確認して終わることです。作成者は元データや意図を知っているため、多少分かりにくい表示でも意味を補って読めてしまいます。しかし、現場担当者や確認者、発注者、協力会社など、別の立場の人が見ると、何を示しているのか分からないことがあります。地図表示を共有する前には、初めて見る人でも判断できるかという視点で確認することが大切です。

また、更新後の確認も忘れてはいけません。GeoJSONは一度作って終わりではなく、点検結果、施工進捗、区域変更、設備追加などに応じて更新されることがあります。更新のたびに一部の属性が消えたり、座標がずれたり、過去データと新データが混在したりすることがあります。更新後には、変更箇所だけでなく、全体の表示と属性の整合性も確認することで、運用中のトラブルを減らせます。

地図表示で起こりやすい失敗例を知る

GeoJSONの地図表示で特に起こりやすい失敗の一つは、座標の順序を間違えることです。緯度と経度を逆にしてしまうと、地図上の位置が大きくずれます。特に表データでは、緯度、経度の順で列が並んでいることが多く、そのまま変換するとGeoJSONで求められる順序と合わない場合があります。地図に表示されない、極端に離れた場所に表示される、範囲外に飛ぶといった場合は、まず座標順序を確認するべきです。

次に多いのは、元データの座標系を確認しないままGeoJSON化する失敗です。図面や測量成果で使われる座標が、そのまま地図表示用の経度緯度として使えるとは限りません。平面上の座標を経度緯度として読み込ませると、表示位置がまったく合わなくなります。座標変換が必要なデータかどうかを確認せずに作業すると、見た目の問題ではなく、データの前提そのものがずれた状態になります。

構造上の失敗もよくあります。括弧の閉じ忘れ、カンマの不足、余分なカンマ、文字列の囲み忘れなどは、GeoJSON全体の読み込み失敗につながります。手作業で属性を追加したり、複数のファイルを結合したりすると、このようなミスが発生しやすくなります。表示側では単に読み込めないとだけ示される場合もあり、原因を特定しにくいことがあります。小さな単位で確認しながら編集することが重要です。

面データでは、外周が閉じていない、座標の順番が乱れている、自己交差しているといった失敗があります。面として塗りたい範囲が正しく閉じていないと、表示されなかったり、意図しない形に表示されたりします。境界線を図面から変換した場合や、手入力で座標を補った場合に起こりやすい問題です。面データは点や線よりも構造が複雑なため、作成後に地図上で形状を拡大確認することが欠かせません。

属性情報の失敗としては、表記揺れ、空欄、重複、不要な情報の混入があります。例えば、状態を示す属性に「完了」「済」「確認済み」が混在していると、同じ意味でも別の値として扱われます。地図上で色分けや絞り込みを行う場合、表記揺れは大きな支障になります。また、内部用の備考や公開すべきでない情報が属性に残ったまま共有されることもあります。GeoJSONはテキストとして中身を見られるため、共有前の確認が特に重要です。

ファイル容量による失敗もあります。細かすぎる線や面をそのままGeoJSONにすると、座標数が非常に多くなり、地図表示が重くなることがあります。表示に時間がかかる、操作が遅くなる、端末によっては開けないといった問題につながります。高精細なデータが常に良いとは限りません。表示目的に合わせて、必要な精度と軽さのバランスを取る必要があります。

さらに、地図の初期表示範囲や表示条件が原因で、データが見えないこともあります。読み込み自体は成功しているのに、表示位置が遠く離れていたり、縮尺条件で非表示になっていたり、背景と同系色で見えにくかったりするケースです。この場合、GeoJSONの構造を何度直しても解決しません。表示されないときは、データ、読み込み、表示範囲、スタイルの順に切り分けて確認することが大切です。

実務でGeoJSONを安定運用するための考え方

GeoJSONを一度だけ地図に表示する場合と、業務で継続的に使う場合では、必要な管理の考え方が変わります。継続運用では、誰が作成し、いつ更新し、どの元データから作られ、どの用途で使うのかを記録しておく必要があります。ファイルだけが残っていても、作成経緯が分からなければ、後から正しいデータか判断しにくくなります。

安定運用のためには、ファイル名のルールを決めることが有効です。対象範囲、データ種別、作成日、版数などが分かる名前にしておくと、古いファイルと新しいファイルの取り違えを防ぎやすくなります。単に「最新」や「修正版」といった名前だけでは、時間が経つと意味が分からなくなります。更新のたびに履歴を残し、どの版を共有しているのかを明確にすることが重要です。

属性項目の標準化も欠かせません。業務ごとに自由な項目名で作ると、後からデータを統合するときに手間がかかります。名称、分類、状態、確認日、備考など、よく使う項目は共通の命名にしておくと、地図表示や集計がしやすくなります。入力値についても、選択肢を決めておくことで表記揺れを減らせます。特に状態管理や進捗管理に使う場合は、属性値の統一が運用品質に直結します。

共有範囲に応じたデータの分け方も大切です。社内確認用、現場共有用、外部提出用では、必要な情報と出してよい情報が異なります。同じGeoJSONをそのまま使い回すのではなく、共有先に合わせて属性情報や表示内容を調整する方が安全です。公開や外部共有を行う場合は、個人名、連絡先、内部メモ、未確定情報などが含まれていないかを確認する必要があります。

運用時には、元データとの関係も整理しておきます。GeoJSONを直接編集していくのか、表データや台帳を元に毎回生成するのかで、管理方法が変わります。直接編集は小規模な修正には便利ですが、複数人で更新すると整合性が崩れやすくなります。元データから生成する方法は手順を整える必要がありますが、台帳との一致を保ちやすくなります。どちらを採用する場合でも、正本となるデータを明確にしておくことが重要です。

現場で使うGeoJSONでは、取得時点の情報も大切です。点の位置が現地で測ったものなのか、図面から作成したものなのか、空中写真や既存地図を見ながら置いたものなのかによって、信頼できる範囲が異なります。地図上では同じ点に見えても、取得方法が違えば使える判断も変わります。属性や別管理の記録として、取得方法や確認状況を残しておくと、後から誤解を防ぎやすくなります。

まとめ

GeoJSONを地図表示に使う流れは、表示したい地物を整理し、座標と位置の前提を確認し、構造を整え、地図に読み込み、見え方と属性情報を確認するという順番で考えると分かりやすくなります。GeoJSONは扱いやすい形式ですが、座標順序、座標系、構造、属性、表示条件のどれか一つでも崩れると、地図上で正しく使えないデータになります。表示できたかどうかだけでなく、実務判断に使える状態かどうかを確認することが重要です。

特に「geojson 使い方」を調べている実務担当者にとって大切なのは、技術的な記述方法だけではありません。どの情報を地図に載せるのか、どの精度で扱うのか、誰に共有するのか、更新時にどう管理するのかまで含めて設計することです。点、線、面の違いを理解し、属性情報を整理し、表示後に現地感覚と照合することで、GeoJSONは単なるデータ形式ではなく、現場と事務所をつなぐ実務資料として使いやすくなります。

失敗を防ぐには、最初から大きなデータを作るのではなく、小さな範囲で確認しながら進めることが有効です。代表的な点を数件表示し、座標順序と位置を確認し、属性情報を開き、見え方を調整してから範囲を広げると、原因の切り分けがしやすくなります。面データや大量の線データを扱う場合も、いきなり完成形を目指すのではなく、構造確認と表示確認を段階的に行うことで、手戻りを減らせます。

今後、現場で取得した位置情報や写真記録を地図表示に活かしたい場合は、取得段階からGeoJSON化や地図共有を意識しておくと、後工程がスムーズになります。現地で位置を記録し、写真やメモと合わせて管理できれば、点検、施工管理、出来形確認、維持管理などの場面で活用しやすくなります。GeoJSONを安定して使うには、作成方法だけでなく、確認、共有、更新までを含めて運用ルールを整えることが大切です。