GeoJSONをLeafletで表示する基本手順と3つの注意点

GeoJSONは、点、線、面といった地図上の形状と、それに紐づく属性情報を扱いやすい形式でまとめられる地理空間データ形式です。現場位置、管理区域、調査範囲、点検対象、境界線、施工範囲などをWeb地図上で確認したい実務では、GeoJSONを使うと、位置と業務情報を同じ画面で共有しやすくなります。一方で、GeoJSONをLeafletで表示するだけなら簡単に見えても、座標順序、座標系、データ量、属性設計、表示スタイルを理解していないと、地物が想定外の場所に出る、表示が重い、クリックしても必要な情報が見えない、現場説明に使いにくいといった問題が起こります。この記事では、GeoJSONをLeafletで表示する基本手順と、実務でつまずきやすい3つの注意点を、初めて導入する担当者にも分かりやすい流れで解説します。

目次

• GeoJSONとLeafletでできることを整理する

• GeoJSONを表示する前に準備するデータ

• LeafletでGeoJSONを表示する基本手順

• 属性情報をポップアップやスタイルに活用する

• 注意点1 座標の順序と座標系を取り違えない

• 注意点2 データ量と表示速度を意識して設計する

• 注意点3 現場で使える属性設計と更新運用にする

• GeoJSON表示を業務で活用するためのまとめ

GeoJSONとLeafletでできることを整理する

GeoJSONをLeafletで表示する目的は、単に地図上に図形を載せることではありません。実務で重要なのは、位置情報と業務情報を同じ画面で確認できる状態にすることです。たとえば、点検箇所を点で表示し、路線や配管や境界を線で表示し、施工範囲や管理区域を面で表示すれば、図面や一覧表だけでは分かりにくかった空間的な関係を直感的に把握できます。

GeoJSONでは、地物の形状を表すgeometryと、名称や管理番号、種別、状態、日付、担当者、備考などを入れられるpropertiesを組み合わせて扱えます。この構造により、同じ地図上に表示するデータであっても、表示色を種別ごとに変えたり、クリック時に詳細情報を表示したり、条件によって絞り込んだりできます。単なる画像として地図を貼る場合と異なり、地物をデータとして扱える点が大きな利点です。

Leafletは、ブラウザ上で地図を表示し、その上にマーカー、線、ポリゴンなどを重ねるための軽量な地図表示ライブラリです。GeoJSONをレイヤとして読み込む機能が用意されているため、基本的な点、線、面であれば、複雑な描画処理を書かなくても地図上に重ねられます。大規模なWebアプリを最初から作らなくても、簡単な確認画面や社内用の閲覧ページを作れるため、現場管理、調査、設計確認、台帳閲覧などで利用しやすい仕組みです。

ただし、GeoJSONをLeafletで表示する場合、すべてのデータがそのまま正しく表示できるわけではありません。RFC 7946に沿ったGeoJSONでは、座標は経度、緯度の順で記述します。一方、現場での会話や表計算ソフトでは緯度、経度の順で扱われることも多く、取り違えると地物がまったく違う場所に表示されます。また、平面直角座標系やローカル座標で作られたデータを、そのまま経緯度として読み込むと正しい位置には出ません。Web地図に表示する前に、GeoJSONの中身がどの座標値で、どの順序で、どの精度で作られているかを確認することが大切です。

実務担当者がGeoJSONを扱う場面では、作成元もさまざまです。現地計測データ、CADやGISからの書き出し、台帳データ、外部から受領した地物データ、調査アプリで取得した位置情報など、出所によってデータの粒度や属性名、座標系、精度が異なります。そのため、Leafletで表示する作業は、単なるプログラム実装ではなく、データ整理と表示設計を含む業務プロセスとして考える必要があります。

特に現場説明や社内共有で使う場合は、表示された図形が正しいか、背景地図との位置関係に違和感がないか、クリックしたときに必要な情報が見えるか、スマートフォンやタブレットでも操作できるかを確認する必要があります。地図表示は見た目が分かりやすいため、少しの位置ズレや属性の誤表示でも、利用者に誤解を与えやすい面があります。だからこそ、基本手順と注意点を押さえたうえで構築することが重要です。

GeoJSONを表示する前に準備するデータ

GeoJSONをLeafletで表示する前に、まずGeoJSONファイルそのものを確認します。拡張子がGeoJSONであっても、中身が正しい形式になっていなければ表示できません。先頭から終わりまでJSONとして壊れていないか、FeatureCollectionの中にFeatureが並んでいるか、各Featureにgeometryとpropertiesが含まれているかを確認します。点であればPoint、線であればLineStringやMultiLineString、面であればPolygonやMultiPolygonが使われます。

点データの場合は、座標が一組で済むため比較的確認しやすいですが、線や面では複数の座標が連続します。面データでは、外周が閉じているか、穴を持つ場合に座標配列が正しく分かれているかが重要です。面が閉じていない、座標配列の階層が誤っている、不要な点が大量に含まれていると、表示が崩れたり、処理が重くなったりします。見た目だけでなく、データ構造として成立しているかを確認しておくことが必要です。

次に、座標値の単位と範囲を確認します。経緯度であれば、経度はおおむね東西方向を示す値で、緯度は南北方向を示す値です。日本国内の一般的な経緯度であれば、経度と緯度の数値範囲から大きな違和感に気づけます。一方、平面直角座標系や現場独自のローカル座標では、数値の桁や範囲が経緯度とは大きく異なります。このような座標をそのままLeafletに渡しても、一般的な背景地図上の正しい位置には重なりません。

表示前には、属性情報も整理しておきます。propertiesに入れる項目は、地図上で何を確認したいかによって決まります。管理番号、名称、種別、状態、更新日、担当部署、備考、写真や帳票への参照情報などが代表例です。ただし、何でも入れればよいわけではありません。属性が多すぎると、ポップアップ表示が読みにくくなり、データの更新管理も難しくなります。地図上で即座に確認したい情報と、別画面や別帳票で確認すればよい情報を分けることが大切です。

ファイルサイズも確認しておきたいポイントです。GeoJSONはテキスト形式のため扱いやすい一方、座標点数が増えるとファイルサイズが大きくなりやすい形式です。細かい曲線や高密度な境界、広域の面データをそのまま入れると、ブラウザで読み込む際に時間がかかり、地図操作も重くなることがあります。初期表示で必要な範囲だけに絞る、線や面の頂点数を適切に削減する、用途ごとにファイルを分けるなど、表示速度を意識した準備が必要です。

また、データの正しさを確認するためには、最初から全件を表示するのではなく、少量のサンプルデータで表示確認を行うのが安全です。点が期待する場所に出るか、線が背景地図と合うか、面が正しく塗られるか、クリックしたときに属性が表示されるかを確認します。サンプルで問題がなければ、件数を増やして表示速度や操作性を確認します。いきなり大きなファイルを読み込むと、表示されない原因が形式なのか、座標系なのか、データ量なのかを切り分けにくくなります。

外部ファイルとしてGeoJSONを読み込む場合は、ファイルの置き場所や配信設定も確認します。ローカル環境では表示できても、公開環境や社内サーバーではファイルパス、権限、文字コード、別ドメインからの読み込み制限などで取得できないことがあります。GeoJSONの内容だけでなく、ブラウザから正しく読み込める状態にあるかを確認しておくと、原因切り分けがしやすくなります。

LeafletでGeoJSONを表示する基本手順

LeafletでGeoJSONを表示する基本の流れは、地図表示領域を用意し、地図を初期化し、背景地図を設定し、GeoJSONを読み込んでレイヤとして追加する、という順序です。まず、Webページ内に地図を表示する領域を作ります。地図領域には高さを指定する必要があります。高さが指定されていないと、地図を読み込んでいても画面上では何も表示されないように見えることがあります。

次に、Leafletを読み込み、地図オブジェクトを作成します。地図の中心座標とズーム段階を設定し、初期表示する地域を決めます。ここで指定する中心座標も、GeoJSONと同じく座標順序に注意が必要です。GeoJSONの座標配列は経度、緯度の順ですが、Leafletの地図中心やLatLngを配列で指定する場面では緯度、経度の順で扱います。この違いは初心者がつまずきやすい部分です。ライブラリ側の指定形式と、GeoJSONファイル内の指定形式を混同しないようにします。

背景地図を表示したら、GeoJSONをレイヤとして追加します。GeoJSONの中身をJavaScript内に直接書く方法もありますが、実務では外部ファイルとして管理し、読み込む形にすることが多いです。社内確認用の小さなデータであれば直接埋め込みでも動作確認はできますが、更新や差し替えを考えると、データと表示処理を分けておいた方が管理しやすくなります。

基本的な表示は、GeoJSONデータを読み込み、LeafletのGeoJSONレイヤ作成機能に渡し、地図に追加するという形です。点データであれば既定ではマーカーとして表示され、線や面であれば既定の線色や塗りで表示されます。ただし、業務で使う場合は既定表示のままでは情報が不足することが多いため、種別ごとの色分け、線の太さ、面の透明度、クリック時の情報表示を設定していきます。

たとえば、点検箇所の状態が未確認、確認済み、要対応に分かれている場合、それぞれの状態に応じて色や形を変えると、地図を見ただけで優先度が分かります。施工範囲を面で表示する場合は、塗りつぶしを濃くしすぎると背景地図が見えにくくなるため、透明度を調整します。路線や境界線を表示する場合は、背景地図や他のレイヤと重なっても見える線幅や色にする必要があります。

GeoJSONの表示位置が想定通りであることを確認したら、地図の表示範囲をGeoJSONに合わせる処理を入れると便利です。固定の中心座標とズームだけで運用すると、別地域のGeoJSONに差し替えたときに地物が画面外に出ることがあります。GeoJSONレイヤの範囲を取得し、地図表示をその範囲に合わせれば、データを切り替えたときにも目的の地物を見つけやすくなります。

また、複数のGeoJSONを同時に表示する場合は、レイヤの重なり順を意識します。面データを上に重ねると点や線が見えにくくなることがあります。広い面は下に、線や点は上に表示するなど、利用者が確認しやすい順序にします。表示切り替えが必要な場合は、レイヤごとにオンオフできる仕組みを用意すると、地図が見やすくなります。

背景地図を使う場合は、地図タイルの利用条件や著作権表示にも注意します。社内確認だけのつもりで作った画面でも、関係者に共有したり、資料化したりすることがあります。利用する背景地図ごとの規約や必要な表示を確認し、後から差し替えや修正が必要にならないようにしておくことが大切です。

属性情報をポップアップやスタイルに活用する

GeoJSONの強みは、形状だけでなく属性情報を一緒に持てることです。LeafletでGeoJSONを表示する際には、このpropertiesを活用することで、単なる図形表示から業務用の確認画面へ発展させられます。クリックした地物に名称や管理番号を表示するだけでも、地図上の対象物を一覧表と照合しやすくなります。

ポップアップに表示する情報は、利用者がその場で判断するために必要な項目に絞るのが基本です。点検業務であれば、対象名、状態、点検日、対応要否、備考などが候補になります。施工管理であれば、工区名、施工予定日、進捗、担当、確認結果などが考えられます。境界や区域を扱う場合は、区域名、面積、種別、更新日、出典区分などが必要になることがあります。

ただし、ポップアップに長文を詰め込みすぎると、スマートフォンやタブレットで見づらくなります。特に現場利用では、画面サイズ、手袋をした操作、屋外での視認性、通信環境なども考慮する必要があります。重要な項目を上に置き、補足情報は短くまとめ、詳細は別の管理画面や帳票で確認する設計が現実的です。

属性情報は、表示スタイルにも使えます。種別ごとに線色を変える、状態ごとに面の色を変える、重要度に応じてマーカーの大きさを変えるなど、地図を見ただけで判断できる情報量を増やせます。たとえば、要確認の地物だけ目立つ色にし、確認済みの地物は控えめに表示すれば、作業者は次に見るべき場所を把握しやすくなります。

このとき注意したいのは、属性値の表記ゆれです。同じ意味の状態でも、未確認、未点検、未実施、確認前のように表記が揺れていると、条件分岐が複雑になり、意図したスタイルが当たらないことがあります。GeoJSONを作る段階で、属性名と属性値のルールを決めておくことが重要です。表示処理側で無理に吸収するより、データ側を整える方が長期的には安定します。

ポップアップに属性値を表示する場合は、セキュリティ面にも注意が必要です。外部から受け取ったGeoJSON、複数人が編集する台帳、入力フォームから作られたデータでは、属性値に想定外の文字列が入ることがあります。属性値をそのままHTMLとして差し込む設計にすると、不正なタグやスクリプトを表示してしまうリスクがあります。業務用の閉じた画面であっても、表示前にエスケープする、信頼できない入力をHTMLとして扱わない、必要な項目だけを表示するという考え方が安全です。

また、属性情報には機密性の高い情報を入れすぎないことも大切です。GeoJSONはテキスト形式なので、ファイルを開けば中身を確認できます。社外共有や関係者共有に使う場合、個人情報、契約情報、内部メモ、未公開情報などをそのままpropertiesに含めるとリスクになります。地図表示に必要な最小限の情報に絞り、公開範囲に応じてデータを分ける運用が安全です。

属性を活用した表示は便利ですが、最初から複雑に作り込みすぎる必要はありません。まずは名称と種別を表示し、次に状態による色分けを追加し、必要に応じて絞り込みや検索を追加するという段階的な進め方がよいです。実務では、利用者が実際に見たい項目が運用開始後に変わることも多いため、データ構造を拡張しやすくしておくことが重要です。

注意点1 座標の順序と座標系を取り違えない

GeoJSONをLeafletで表示する際、最も多い失敗の一つが座標の順序と座標系の取り違えです。GeoJSONの座標は、RFC 7946に沿う場合、経度、緯度の順で記述します。一方、地図画面の中心を指定する場面や、現場で会話するときには、緯度、経度の順で扱うことが少なくありません。この違いを意識せずにデータを作ると、地物が海外や海上など、まったく関係のない場所に表示されることがあります。

たとえば、緯度を先に、経度を後に入れてしまうと、本来の位置から大きく外れます。数値としてはどちらも一見それらしく見えるため、形式チェックだけでは気づきにくい問題です。特に、表計算ソフトや台帳からGeoJSONを作る場合、列名が緯度、経度の順で並んでいることが多いため、GeoJSON化する処理で経度、緯度の順に入れ替える必要があります。

座標系の違いも重要です。Leafletで一般的なWeb地図に重ねる場合、GeoJSONはWGS 84の経緯度として扱う前提で準備するのが基本です。しかし、測量成果や設計図面から出力したデータは、平面直角座標系やローカル座標で管理されていることがあります。このようなデータは、見た目には座標値の集合でも、地球上の経緯度ではありません。そのままGeoJSONとして読み込んでも、背景地図とは合いません。

実務では、座標系の情報がファイル名やメモにしか残っていないこともあります。受け取ったGeoJSONや変換前データについて、どの座標系で作られたものか、変換済みなのか、測地系の指定は何かを確認する習慣が必要です。特に、複数の部署や外部関係者からデータを受け取る場合、同じ現場のデータでも座標系が混在していることがあります。

位置が少しだけずれる場合も注意が必要です。まったく違う場所に表示される場合はすぐに異常と分かりますが、数十センチから数メートル程度のズレは、背景地図の精度、測量精度、変換処理、作成時期の違いなど、複数の要因が関係します。現場での位置確認に使う場合は、背景地図に合って見えるかだけでなく、基準点、既知点、現地で確認できる構造物などと照合することが大切です。

また、GeoJSONの座標は3番目の値として高さや標高に相当する値を含めることができますが、一般的な2次元地図表示では高さを直接表現しないことが多いです。高さ情報を属性として扱うのか、座標の3番目の値として保持するのか、表示では使わず別の確認に使うのかを決めておきます。高さが必要な業務では、平面位置だけを見て判断すると不十分な場合があります。

座標に関するトラブルを防ぐには、変換前、変換後、表示後の三段階で確認するのが有効です。変換前に元データの座標系を確認し、変換後にGeoJSON内の経度緯度の順序と数値範囲を確認し、表示後に背景地図や既知点と重ねて確認します。小さな確認を省略すると、後工程で大きな手戻りにつながりやすくなります。

注意点2 データ量と表示速度を意識して設計する

GeoJSONは扱いやすい形式ですが、大量データの表示には注意が必要です。点が数十件、数百件程度であれば問題になりにくいですが、数千件以上の点や、頂点数の多い線、複雑な面データを一度に読み込むと、ブラウザの表示が重くなることがあります。地図が開くまで時間がかかる、ズームや移動が遅い、クリックの反応が悪いといった状態になると、実務では使われにくくなってしまいます。

特に面データは、見た目以上に処理負荷が大きくなりやすいです。境界が細かく、不要な頂点が多い場合、地図上ではほとんど見分けがつかない細部まで描画しようとして重くなります。表示目的が概要把握であれば、必要以上に細かい形状を持たせないことが重要です。詳細確認用のデータと、地図表示用の軽量データを分ける運用も有効です。

線データでも同じことが言えます。道路、河川、配管、電線、境界線などを広域で表示する場合、すべての線を一度に読み込むと操作性が落ちます。対象範囲を分割し、必要な地域だけを読み込む、ズーム段階に応じて表示するデータを変える、線の頂点を適切に間引くなどの工夫が必要です。

点データの場合は、件数が多くなるとマーカーの描画数が問題になります。点検箇所や設備台帳をすべてマーカーで表示すると、密集地域では点が重なり、地図として読みにくくなることがあります。件数が多い場合は、ズーム段階に応じて表示を切り替える、密集した点をまとめて表示する、条件で絞り込むなどの設計が必要です。

データ量の問題は、表示速度だけでなく通信量にも関係します。現場でスマートフォンやタブレットを使う場合、通信環境が安定しているとは限りません。大きなGeoJSONファイルを毎回読み込む設計では、地図表示までに時間がかかり、作業の流れを止めてしまうことがあります。屋外利用や移動中の確認を想定するなら、初期表示を軽くし、必要なデータだけを段階的に読み込む方が実用的です。

また、GeoJSONファイルを分割する場合は、分け方のルールも重要です。地域別、工区別、地物種別、業務年度別など、更新しやすく、利用者が理解しやすい単位にします。分割しすぎると管理が煩雑になり、まとめすぎると表示が重くなります。業務でどの単位で閲覧し、どの単位で更新するかを基準に決めると失敗しにくくなります。

表示速度を確認するときは、開発者の高性能なパソコンだけでなく、実際に利用する端末や通信環境で試すことが大切です。社内では快適に動いても、現場の端末では重いということは珍しくありません。さらに、背景地図、GeoJSON、属性表示、写真や帳票へのリンクなどを組み合わせると、全体の体感速度は変わります。実運用に近い条件で確認することが重要です。

注意点3 現場で使える属性設計と更新運用にする

GeoJSONをLeafletで表示する仕組みは、最初に表示できた時点では完成ではありません。実務で使い続けるためには、属性設計と更新運用が重要です。表示したい情報が増えるたびに場当たり的に項目を追加すると、属性名が増えすぎたり、同じ意味の項目が複数できたり、古い項目と新しい項目が混在したりします。その結果、表示処理が複雑になり、データの信頼性も下がります。

まず決めるべきなのは、各地物を一意に識別する管理番号です。名称だけで管理すると、同じ名称の地物がある場合や、名称変更があった場合に混乱します。管理番号を持たせておけば、台帳、写真、点検記録、図面、報告書などと連携しやすくなります。GeoJSONを単独の地図表示ファイルとして扱うのではなく、業務データの一部として管理する考え方が必要です。

次に、属性名のルールを決めます。日本語の属性名でも扱えますが、システム連携や長期運用を考える場合は、短く分かりやすい英数字の項目名にし、表示時に日本語ラベルへ変換する方法もあります。どちらを選ぶ場合でも、同じ意味の項目名を複数作らないことが大切です。たとえば、状態を表す項目がstatus、state、conditionのように混在すると、表示条件の設定や集計が面倒になります。

属性値の選択肢も標準化します。状態や種別を自由入力にすると、入力者ごとの表記ゆれが発生します。地図表示の色分けや絞り込みに使う項目は、あらかじめ選択肢を決めておくのが有効です。未確認、確認済み、要対応などのように運用上必要な区分を整理し、不要に細かくしすぎないことも重要です。区分が多すぎると、利用者が判断に迷い、表示も複雑になります。

更新運用では、誰が、いつ、どのデータを更新するかを決めておく必要があります。GeoJSONファイルを複数人が手作業で編集すると、古いファイルを上書きしてしまったり、一部の地物だけ更新漏れになったりすることがあります。更新元となる台帳や管理表を決め、そこからGeoJSONを出力する流れにすると、データの整合性を保ちやすくなります。

また、現場で得た情報をどう反映するかも考えておきます。地図で確認した結果、位置が違う、属性が古い、対象物が追加された、状態が変わったといった修正が発生します。このとき、現場からの指摘をどこに記録し、誰が承認し、いつGeoJSONへ反映するのかが決まっていないと、地図表示と実態が徐々にずれていきます。地図は一度作って終わりではなく、更新され続ける業務資料として扱う必要があります。

現場で使いやすいGeoJSON表示にするには、画面上の見やすさだけでなく、データの信頼性を保つ仕組みが欠かせません。管理番号、更新日、更新者、確認状態などを適切に持たせることで、利用者は表示内容がいつの情報なのかを判断できます。古い情報なのか、最新確認済みなのかが分からない地図は、現場判断に使いにくくなります。

さらに、社外共有や発注者説明に使う場合は、内部向け属性と外部向け属性を分けることも必要です。社内では詳しい管理情報が必要でも、外部共有では簡略化した情報だけで十分な場合があります。用途ごとにGeoJSONを出し分ける、表示項目を切り替える、共有範囲に応じて不要な情報を削除するなど、情報管理の観点も取り入れます。

GeoJSON表示を業務で活用するためのまとめ

GeoJSONをLeafletで表示する基本は、地図表示領域を用意し、Leafletで地図を初期化し、背景地図を設定し、GeoJSONをレイヤとして追加するというシンプルな流れです。小さなサンプルデータであれば、比較的短い手順で点、線、面を地図上に重ねられます。しかし、実務で安定して使うためには、表示できることだけで満足せず、座標、属性、データ量、更新運用まで含めて設計することが重要です。

特に注意すべきなのは、座標の順序と座標系です。GeoJSONでは経度、緯度の順で座標を記述する一方、Leafletの中心座標指定や現場での会話では緯度、経度の順が使われることがあります。また、測量や設計のデータが平面直角座標系やローカル座標で管理されている場合、そのまま一般的なWeb地図に重ねることはできません。表示位置に違和感があるときは、まず座標の順序、座標系、変換処理を確認することが大切です。

次に、データ量と表示速度を意識する必要があります。GeoJSONは扱いやすい反面、座標点数が多いデータや件数の多いデータでは、ブラウザ表示が重くなることがあります。現場で使う地図は、開けばすぐに確認できることが重要です。表示目的に合わせてデータを軽量化し、範囲や用途ごとに分割し、必要な情報だけを読み込む設計にすると、利用者にとって扱いやすい地図になります。

さらに、属性設計と更新運用も欠かせません。GeoJSONのpropertiesに何を入れるかによって、地図の使いやすさは大きく変わります。管理番号、名称、種別、状態、更新日など、業務で判断に使う項目を整理し、表記ゆれを防ぎ、更新ルールを決めておくことで、地図表示の信頼性を保てます。地図上に表示された情報がいつのものか、誰が確認したものか、どの台帳と対応しているかが分かる状態にしておくことが、現場利用では重要です。

GeoJSONとLeafletを組み合わせると、現場データや管理データをWeb地図上で見やすく共有できます。点検箇所の確認、施工範囲の把握、区域管理、ルート確認、台帳情報の可視化など、さまざまな用途に応用できます。ただし、地図表示は見た目が分かりやすい分、位置ズレや古い属性情報があると誤解を生みやすい面もあります。導入時には、少量データで検証し、実際の端末で操作性を確認し、運用に合わせて改善していくことが大切です。

今後、GeoJSONを単なる閲覧用データとしてではなく、現場で取得した位置情報や写真、図面情報と連携させて使うことで、確認作業の効率はさらに高まります。現場で取得した位置をもとにGeoJSONを作成し、地図上で確認し、関係者に共有する流れを整えれば、机上のデータと現地の状況をつなぎやすくなります。重要なのは、便利な表示画面を作ることだけではなく、座標の根拠、属性の意味、更新の責任範囲を明確にし、現場で安心して使える地図データとして運用することです。