GeoJSONをOpenLayersで読み込む5つの基本手順

GeoJSONは、点、線、面などの位置情報と属性情報をまとめて扱える実務向けのデータ形式です。現場の位置確認、調査結果の可視化、区域管理、点検記録の整理など、地図上で情報を共有したい場面でよく使われます。一方で、GeoJSONをOpenLayersで読み込むときは、ファイルを指定するだけで常に正しく表示できるとは限りません。座標の向き、地図側の座標設定、属性情報の持たせ方、表示スタイル、更新時の管理方法を理解していないと、点が別の場所に出る、線や面が表示されない、属性が確認できないといった問題が起こります。

この記事では、「geojson 使い方」で検索する実務担当者に向けて、GeoJSONをOpenLayersで読み込む基本手順を、データ準備から運用確認まで5つに分けて解説します。開発担当者だけでなく、測量、点検、設備管理、施工管理などで地図データを扱う担当者が、表示ミスや引き継ぎミスを減らすための考え方として整理しています。

目次

• 手順1 GeoJSONの中身と用途を確認する

• 手順2 座標の前提をそろえて読み込みミスを防ぐ

• 手順3 地図上に表示するレイヤー構成を決める

• 手順4 属性情報と表示スタイルを整理する

• 手順5 更新・共有・現場確認まで含めて運用する

• まとめ GeoJSONの読み込みは表示前の確認で安定する

手順1 GeoJSONの中身と用途を確認する

GeoJSONをOpenLayersで読み込む前に、最初に確認したいのは、読み込むデータが何を表しているのかという基本です。GeoJSONは単なる地図表示用のファイルではなく、位置を示す形状情報と、その形状に紐づく属性情報を一緒に持てる形式です。点であればマンホール、電柱、標識、調査地点などを表せます。線であれば道路中心線、配管、電線、境界の参考線などを表せます。面であれば敷地、区域、調査範囲、管理区画などを表せます。

実務では、GeoJSONを受け取った時点で「点のデータなのか」「線のデータなのか」「面のデータなのか」を確認しないまま地図に読み込んでしまうことがあります。しかし、表示したい内容によって設定の考え方は変わります。点はアイコンや円で見せることが多く、線は太さや色で意味を持たせることが多く、面は塗りつぶしや境界線で範囲を示すことが多いです。用途を整理しないまま読み込むと、地図には出ているのに現場担当者が意味を読み取れない状態になりやすくなります。

GeoJSONの基本構造としては、複数の地物をまとめる入れ物があり、その中に個別の地物が入り、それぞれが形状と属性を持つという考え方です。形状には点、線、面などの種類があり、属性には名称、番号、状態、管理区分、点検日、担当者、備考などを入れられます。OpenLayersで読み込む際も、この構造を理解しておくと、後から表示の切り替えやクリック時の情報表示を作りやすくなります。

特に注意したいのは、GeoJSONのファイル名だけでは内容を判断しないことです。たとえば「調査結果」という名前のファイルでも、中身は点だけの場合もあれば、線や面が混在している場合もあります。点検記録のように、同じファイル内に複数の種類の地物が含まれることもあります。OpenLayers側で表示できないわけではありませんが、点、線、面が混在している場合は、同じ表示スタイルを適用すると見づらくなることがあります。

また、属性情報の項目名も確認が必要です。現場で「管理番号」と呼んでいる項目が、データ内では「番号」「ID」「識別子」など別の名前になっていることがあります。地図上でクリックして情報を出す場合や、条件によって色分けする場合、どの属性を使うのかを事前に決めておかないと、実装後に修正が増えます。GeoJSONの使い方として、まず中身を見ることは地味ですが重要です。

読み込み前の段階では、表示目的も明確にしておきます。単に位置を確認したいのか、属性を検索したいのか、範囲を比較したいのか、現場写真や点検結果と結び付けたいのかによって、必要な項目が変わります。位置だけを見たい場合は形状が正しければ十分なこともありますが、管理台帳として使う場合は属性の整備が欠かせません。施工や点検の引き継ぎに使う場合は、誰が見ても意味が分かる名称や分類にしておく必要があります。

この段階で、不要な地物や古いデータが混ざっていないかも確認します。古い点、仮の線、試験的に作った面が同じGeoJSONに残っていると、OpenLayersで正しく読み込めたとしても、業務上は誤解の原因になります。表示されることと、使えることは同じではありません。読み込み前に用途、形状、属性、更新日、管理者を確認しておくことで、後工程の手戻りを減らせます。

手順2 座標の前提をそろえて読み込みミスを防ぐ

GeoJSONをOpenLayersで読み込むときに起こりやすい問題の一つが、座標の前提違いです。GeoJSONの座標は、一般的に経度、緯度の順で扱われます。地図や表計算の感覚で緯度、経度の順に並べてしまうと、まったく別の場所に表示される原因になります。日本国内の位置を表示したつもりが海外や海上に出てしまう場合、座標の順序を疑う必要があります。

実務担当者が特に注意したいのは、座標値の見た目だけで判断しないことです。経度と緯度はどちらも小数で表されることが多いため、数字だけを見ると正しいように見える場合があります。しかし、経度と緯度が入れ替わっていると、地図上の位置は大きくずれます。GeoJSONを受け取ったら、代表的な1点を取り出し、想定している地域の座標範囲に入っているかを確認すると安全です。

次に確認したいのが、地図側の表示座標系との関係です。地図表示では、内部的に表示しやすい座標系が使われることがあります。一方、GeoJSON側は経度・緯度の値で作られていることが多いため、読み込み時に座標の変換を意識する必要があります。OpenLayersでは、読み込むデータの座標系と、地図上で表示する座標系の前提を合わせることが重要です。ここを曖昧にすると、データは読み込めているのに画面上では正しい位置に出ないという状態になります。

座標の問題は、点よりも線や面で気づきにくいことがあります。点であれば明らかに場所が違うと分かりますが、線や面の場合は、画面の外側に出ていて存在に気づかないこともあります。読み込み直後に何も表示されない場合、データが空なのか、スタイルが見えないのか、座標変換が合っていないのかを切り分ける必要があります。まずは地図の表示範囲をデータ全体の範囲に合わせる処理を入れると、地物がどこに読み込まれているか確認しやすくなります。

現場データでは、測量や設計の座標をそのままGeoJSONに変換する場合もあります。このとき、元データが経度・緯度ではなく、平面上の座標値で管理されていることがあります。平面座標の数値をそのままGeoJSONとして読み込むと、地図の位置とは合わない場合があります。データ作成時にどの座標基準で作られたものかを確認し、必要に応じて地図表示に適した座標へ変換してから読み込むことが大切です。

座標の前提をそろえるには、データを作る人、読み込む人、確認する人の間で共通ルールを持つことが有効です。ファイル名や管理表に、座標の種類、作成日、作成元、対象地域、変換の有無を記録しておくと、後から原因調査をしやすくなります。地図上で少しだけずれている場合でも、原因が座標系なのか、元データの精度なのか、表示上の丸めなのかを判断しやすくなります。

また、GeoJSONの精度をむやみに削らないことも重要です。ファイルサイズを軽くするために小数点以下を丸めることがありますが、位置確認に使うデータでは、丸め方によって現場で見える位置が変わる可能性があります。広域の概要図であれば多少の丸めが許容される場合もありますが、設備や境界、施工位置の確認に使う場合は慎重に扱う必要があります。読み込み前に、必要な位置精度と表示目的を合わせて考えることが、GeoJSONの安全な使い方につながります。

手順3 地図上に表示するレイヤー構成を決める

GeoJSONを読み込む際は、データを地図上のどの層として扱うかを決める必要があります。地図表示では、背景となる地図、点検結果、管理区域、補助線、ラベルなどを重ねて見せることが一般的です。GeoJSONを1つ読み込むだけなら単純ですが、実務では複数のデータを重ねることが多いため、レイヤー構成を最初に考えておくと管理しやすくなります。

たとえば、点検対象の設備を点データで表示し、その点検範囲を面データで表示し、巡回経路を線データで表示する場合、それぞれを別のレイヤーとして分けた方が表示切り替えやスタイル設定がしやすくなります。すべてを一つのレイヤーにまとめると、最初は簡単に見えますが、後から「設備だけ非表示にしたい」「未点検だけ色を変えたい」「範囲だけ薄く見せたい」といった要望に対応しにくくなります。

OpenLayersでGeoJSONを扱う場合、読み込んだ地物は地図上に表示するためのデータ源として扱い、その上に表示用の層を重ねる考え方になります。このとき、データ源と表示層を分けて考えると整理しやすくなります。データ源はGeoJSONの中身を保持する役割、表示層はそのデータを地図上にどう見せるかを決める役割です。実務でトラブルを減らすには、この役割分担を意識しておくことが大切です。

レイヤー名も分かりやすくしておきます。開発中だけで使う名前ではなく、運用担当者が見ても意味が分かる名前にすると、後から引き継ぎや保守が楽になります。「点データ」「線データ」だけではなく、「設備位置」「巡回経路」「管理区域」「注意箇所」など、業務上の意味が分かる名前にする方が実用的です。地図上の表示切り替え機能を作る場合にも、そのまま利用者向けの名称として使いやすくなります。

表示順も重要です。面データを濃く塗りつぶしてしまうと、その上にある点や線が見えにくくなることがあります。背景地図、面、線、点、ラベルのように、利用者が見たい情報が隠れない順番を考える必要があります。特に面データは範囲を示すために便利ですが、塗りつぶしが強すぎると他の情報を邪魔します。最初から透明度や境界線の見せ方を意識しておくと、読み込み後の調整が少なくなります。

データ量が多い場合は、表示速度も考える必要があります。GeoJSONは扱いやすい形式ですが、大量の地物や細かすぎる形状を一度に読み込むと、表示が重くなることがあります。広域の面データや細かな線データを扱う場合は、必要な範囲だけに絞る、表示縮尺に応じて見せ方を変える、不要な属性を整理するなどの工夫が必要です。単に読み込めるかどうかではなく、利用者がストレスなく操作できるかを確認することが大切です。

また、複数のGeoJSONを読み込む場合は、データの更新単位も考えておきます。設備位置は月に一度更新、点検結果は毎日更新、管理区域は年度単位で更新といったように、更新頻度が違うデータを同じファイルにまとめると運用が複雑になります。更新頻度や管理者が違う情報は、別ファイル、別レイヤーとして分ける方が安全です。OpenLayersでの読み込み設計は、画面上の見た目だけでなく、データ管理のしやすさにも影響します。

手順4 属性情報と表示スタイルを整理する

GeoJSONの便利な点は、位置情報だけでなく属性情報も一緒に扱えることです。地図上に点や線や面を表示するだけでなく、その地物が何を意味するのか、どの状態なのか、いつ確認したのか、誰が担当しているのかといった情報を持たせることができます。OpenLayersでGeoJSONを読み込む場合も、属性情報を活用することで、単なる地図表示から実務向けの確認画面に近づけられます。

まず整理したいのは、どの属性を表示に使うかです。たとえば点検対象を表示する場合、状態が「未確認」「確認済み」「要対応」などに分かれていれば、状態ごとに色や形を変えると視認性が上がります。管理区域を表示する場合、区域種別や優先度によって塗りつぶしの色を変えることができます。線データであれば、種別や重要度によって線の太さや線種を変えることも考えられます。

ただし、色や形に意味を持たせる場合は、現場担当者が誤解しないようにルールを明確にする必要があります。赤は危険、青は通常、灰色は未確認といった決め方をするなら、画面内や操作説明でその意味を共有します。担当者ごとに色の意味が違うと、地図を見たときの判断にばらつきが出ます。GeoJSONの使い方として、属性を持たせるだけでなく、その属性をどう見せるかまで設計することが重要です。

クリックしたときに属性を表示する場合は、見せる項目を絞ることも大切です。GeoJSONには多くの属性を入れられますが、すべてを画面に出すと読みにくくなります。現場で必要な情報は、管理番号、名称、状態、更新日、備考などに限られることが多いです。内部管理用の項目や、利用者が判断に使わない項目は、画面上では出さない方が分かりやすくなります。必要な情報に絞ることで、地図を確認する時間を短縮できます。

属性名の表記ゆれにも注意が必要です。同じ意味の項目が、ある地物では「status」、別の地物では「状態」、別のファイルでは「確認区分」のように分かれていると、条件分岐や表示制御が複雑になります。実務で継続的に使うGeoJSONでは、属性名のルールを決めておくことが重要です。日本語名にするのか、英数字の管理名にするのか、画面表示用の名称を別に持つのかを決めておくと、後からデータが増えても整理しやすくなります。

表示スタイルでは、点、線、面の違いを意識します。点データは小さすぎると見落とされ、大きすぎると密集した場所で重なります。線データは細すぎると背景に埋もれ、太すぎると周辺情報を隠します。面データは塗りつぶしが強いと背景や点を隠し、薄すぎると範囲が分かりにくくなります。表示スタイルは一度で決めきるのではなく、実際のデータを読み込んで、広域表示と拡大表示の両方で確認することが大切です。

ラベル表示も便利ですが、使い方には注意が必要です。すべての地物に名称を表示すると、地図上が文字だらけになり、かえって読みにくくなります。ラベルは拡大時だけ表示する、重要な地物だけ表示する、クリック時に詳細を出すなど、利用場面に合わせた設計が必要です。GeoJSONをOpenLayersで読み込む目的が現場確認であれば、画面を見た瞬間に必要な判断ができる程度の情報量に抑えることが重要です。

属性情報は、検索や絞り込みにも使えます。たとえば未確認の地物だけ表示する、特定の区域だけ表示する、更新日が古いデータを目立たせるといった使い方ができます。これにより、GeoJSONは単なる表示データではなく、作業対象を管理するための情報になります。読み込みの段階から属性設計を意識しておくと、後から検索機能や確認機能を追加しやすくなります。

手順5 更新・共有・現場確認まで含めて運用する

GeoJSONをOpenLayersで読み込む仕組みを作るときは、最初の表示だけでなく、その後の更新や共有まで考えておく必要があります。実務では、一度作ったGeoJSONをずっと使い続けるよりも、調査結果の追加、点検状態の変更、区域の修正、設計変更への対応などによって、データが繰り返し更新されることが多いです。読み込み方法だけを整えても、更新ルールが曖昧だと、古い情報を見て判断してしまう危険があります。

まず決めたいのは、誰がGeoJSONを作成し、誰が確認し、誰が公開するのかという流れです。作成者がそのまま公開する場合でも、最低限の確認項目を設けることでミスを減らせます。座標が想定範囲に入っているか、地物数が極端に変わっていないか、必要な属性が入っているか、空の値が混ざっていないか、更新日が記録されているかを確認します。OpenLayersで読み込めるかどうかだけではなく、実務で使える状態かどうかを確認することが重要です。

ファイルの版管理も欠かせません。同じ名前のGeoJSONを上書きし続けると、問題が起きたときにいつのデータからずれたのか分かりにくくなります。日付や版番号を付ける、更新履歴を残す、古い版を一定期間保管するなどのルールを作ると安心です。特に施工管理や点検管理では、過去の状態を確認したい場面があります。地図上では最新情報だけを表示するとしても、元データの履歴を追えるようにしておくと、説明や確認がしやすくなります。

共有時には、表示する相手の環境も意識します。事務所で大きな画面を使って確認する場合と、現場で小さな画面を使って確認する場合では、見やすい表示が異なります。点の大きさ、線の太さ、ラベルの量、クリックしやすさなどは、実際に使う環境で確認する必要があります。OpenLayersでの表示は柔軟に調整できますが、調整できるからこそ、利用場面に合わせた基準を持つことが大切です。

現場確認では、地図上の位置と実際の対象物が一致しているかを確認します。GeoJSONの座標が正しくても、現場の目印や設備の状態が変わっている場合があります。逆に、現場で取得した位置情報をGeoJSONとして読み込む場合は、取得時の精度や環境によって位置にばらつきが出ることがあります。そのため、地図表示だけを過信せず、必要に応じて写真、備考、点検記録、図面情報などと組み合わせて判断することが重要です。

読み込み後の確認では、代表地点だけでなく、端部や境界付近も見るようにします。面データでは、範囲の角が欠けていないか、線が閉じているか、隣接する区域と重なっていないかを確認します。線データでは、途中で途切れていないか、不要な折れ点がないかを見ます。点データでは、重複点や極端に離れた点がないかを確認します。全件を目視するのが難しい場合でも、件数、範囲、属性の空欄、異常値を確認するだけで多くのミスを発見できます。

運用が進むと、GeoJSONの使い方は単なる読み込みから、業務フロー全体の中での利用に変わります。調査担当者が現場で記録し、管理担当者が属性を確認し、地図画面で関係者が共有し、必要に応じて修正するという流れです。この流れを意識しておくと、どの段階で何を確認すべきかが明確になります。OpenLayersでの読み込みは、その中の表示部分を担うものですが、元データの作成や更新ルールと切り離して考えないことが大切です。

また、利用者からの修正依頼を受ける仕組みも考えておくと便利です。地図を見た担当者が「位置が少し違う」「属性が古い」「名称が現場と違う」と気づいたときに、どこへ連絡し、誰が修正し、いつ反映するのかが決まっていれば、データの品質を保ちやすくなります。反対に、修正窓口が曖昧だと、現場では間違いに気づいていても地図データが古いまま残ることがあります。読み込み機能を作った後も、改善を続けられる体制が必要です。

まとめ GeoJSONの読み込みは表示前の確認で安定する

GeoJSONをOpenLayersで読み込む基本は、ファイルを指定して地図に表示するだけではありません。まずGeoJSONの中身を確認し、点、線、面の種類や属性情報を理解することが出発点です。次に、座標の順序や座標の前提をそろえ、地図側の表示設定と合うように確認します。そのうえで、レイヤー構成、表示順、スタイル、属性表示を整理し、利用者が必要な情報を読み取りやすい地図にしていきます。

実務では、読み込めることよりも、正しく判断に使えることが重要です。位置が少しずれている、属性が古い、表示色の意味が共有されていない、更新履歴が分からないといった状態では、地図として表示できていても業務上のリスクが残ります。GeoJSONの使い方を安定させるには、読み込み前の確認、読み込み時の設定、読み込み後の検証を一つの流れとして扱う必要があります。

特に、現場で使うデータでは、座標、属性、更新日、管理者、確認方法をセットで管理することが大切です。地図上に表示された情報を見て、誰が、いつ、何を判断するのかを想定しておくと、必要な項目や表示方法が自然に決まります。OpenLayersはGeoJSONを地図上で扱うための柔軟な仕組みを備えていますが、実務で成果を出すには、データの整備と運用ルールが欠かせません。

今後、現場の点検記録や測位データをGeoJSONとして整理し、地図上で確認する機会はさらに増えていきます。スマートフォンで取得した位置情報、写真、メモ、点検結果を地図上で見える化できれば、事務所と現場の情報共有がしやすくなります。現場で取得した位置情報を活用し、GeoJSONとして扱いやすい形で整理したい場合は、次のステップとしてLRTK Phoneのような現場向けの位置情報活用手段を検討すると、記録から地図表示までの流れをより実務に合わせて整えやすくなります。