GeoJSONをWeb地図上に表示する作業は、ファイルを読み込んでレイヤーを追加するだけに見えます。しかし実務では、座標の扱い、形状データの整合、属性情報の整理、表示順、処理速度、更新時の確認方法がそろっていないと、地物が表示されない、位置がずれる、色分けが効かない、動作が重くなるといった問題が起きやすくなります。特に「geojson 使い方」を調べている実務担当者にとって大切なのは、コードの書き方だけでなく、表示前にどこを確認すれば手戻りを減らせるかを理解しておくことです。
この記事では、GeoJSONをMapLibreで表示するときに確認したい実務上のポイントを6つに整理します。単なる技術メモではなく、現場データ、台帳データ、区域データ、点群から抽出した位置情報、写真位置、調査記録などをWeb地図で扱う場面を想定し、公開前や共有前に見落としやすい点まで含めて解説します。
座標値と座標順序が地図表示に合っているか確認する
GeoJSONを地図に表示するときに最初に確認したいのは、座標値そのものと座標の並び順です。Web地図でGeoJSONを扱う場合、座標は経度、緯度の順で記述されるのが基本です。緯度、経度の順で作られたデータをそのまま読み込むと、地物が想定外の場所に表示されたり、まったく見えない位置に飛んでしまったりします。日本国内のデータであれば、経度はおおむね120度台から150度台、緯度は20度台から40度台に収まることが多いため、数値の並びを見るだけでも異常に気づける場合があります。
実務では、測量データ、設計データ、台帳データ、現地調査アプリから出力したデータなど、さまざまな経路でGeoJSONが作られます。そのため、作成元によって座標系や座標順序が異なる可能性を前提にしておく必要があります。平面直角座標系のようなメートル単位の座標を、そのまま経度緯度として扱ってしまうと、Web地図上では正しい位置に表示できません。GeoJSONとして読み込める形式になっていても、MapLibre上で表示しやすい経度緯度の座標値へ変換されているとは限らないため、表示前に必ず確認することが大切です。
座標値の確認では、まず代表点を数点選び、地図上の位置と現地や図面上の位置が合っているかを見ます。点データであれば、施設や調査地点が正しい場所に落ちているかを確認します。線データであれば、道路、河川、境界線、配管ルートなどの方向や接続関係に不自然な折れや反転がないかを確認します。面データであれば、区域が想定する範囲を囲んでいるか、極端に大きな面になっていないか、隣接区域との関係がおかしくないかを確認します。
また、座標変換を行ったデータでは、変換条件の記録も重要です。どの座標系からどの座標系へ変換したのか、変換に使用した基準や設定は何か、変換前の元データを保管しているかを残しておくと、後から位置ずれが見つかった場合に原因を追いやすくなります。表示結果だけを見て調整を繰り返すと、どこで誤差が入ったのか分からなくなり、別の担当者が確認できないデータになってしまいます。
地図上に表示したときのズームレベルも確認対象です。広域表示では正しく見えていても、拡大すると道路中心線からずれていたり、敷地境界の一部が重なっていたりすることがあります。反対に、細部だけを見ていると、全体の位置が大きくずれていることに気づけない場合もあります。最初に広域で全体位置を確認し、その後に代表箇所を拡大して確認する流れにすると、座標値の問題を発見しやすくなります。
GeoJSONの表示で起きるトラブルの多くは、見た目の設定よりも座標の前提違いから始まります。色や線幅を調整する前に、まず地物が正しい場所にあるかを確認することが、最も基本的でありながら重要な作業です。
GeoJSONの基本構造と形状タイプを確認する
次に確認したいのは、GeoJSONの基本構造です。GeoJSONは、地物のまとまり、個別の地物、形状、属性情報を一定の形式で表現します。地図表示でよく使われるのは、複数の地物をまとめたFeatureCollectionです。この中に、点、線、面などの形状を持つFeatureが入ります。表示できない場合や一部だけ表示されない場合は、座標値だけでなく、この構造が正しく組まれているかを確認する必要があります。
点データは、調査地点、施設位置、写真撮影位置、基準点、設備位置などの表示に向いています。線データは、道路中心線、水路、境界線、ルート、配線経路などに使われます。面データは、敷地、区域、用途範囲、管理範囲、災害想定区域などを表すときに使われます。ひとつのGeoJSONの中に複数の形状タイプが混在している場合もありますが、表示設定を分けずに扱うと、点だけが意図通りに表示され、線や面が表示されないといった問題が起こることがあります。
MapLibreでGeoJSONを表示する際は、データの読み込み元と表示レイヤーを分けて考える必要があります。GeoJSONはデータソースとして読み込み、その中の形状タイプや属性条件に応じて、点用、線用、面用のレイヤーを設定します。ひとつのデータに点と線と面が混在している場合は、それぞれに対応する表示設定を用意するのが基本です。点の地物に面用の表示設定を当てても、期待した見た目にはなりません。
面データでは、ポリゴンの閉じ方も重要です。区域を表す面は、外周が正しく閉じている必要があります。始点と終点が一致していない、座標列の順序が崩れている、穴あき形状の内側と外側の関係が不適切といった状態では、表示が乱れることがあります。見た目上は一部だけ欠けて見えたり、想定外の範囲が塗りつぶされたりする場合もあります。データ作成時には問題が見えにくくても、Web地図上で塗りつぶし表示をしたときに初めて気づくことがあります。
線データでは、線が途中で切れていないか、不要な重複がないか、極端に短い線分が混ざっていないかを確認します。道路や経路のように連続性が重要なデータでは、見た目のつながりだけでなく、データ上の区切り方も後の検索や選択に影響します。たとえば、一本の路線として扱いたいのか、区間ごとに属性を分けたいのかによって、GeoJSONの作り方は変わります。
点データでは、同じ座標に複数の地物が重なっていないかも確認します。写真、調査記録、設備点検結果などを地図化すると、同じ場所に複数の記録が集中することがあります。重なりがあると、地図上では一つの点しか見えず、背後にある情報に気づけないことがあります。この場合は、属性で件数をまとめる、拡大時に分かれるようにする、一覧表示と連動させるなど、表示方法を工夫する必要があります。
GeoJSONの構造確認では、ファイルが読み込めるかどうかだけで判断しないことが大切です。読み込み自体は成功していても、形状タイプと表示設定が合っていなければ、利用者にとっては「表示されないデータ」と同じです。表示したい地物がどの形状タイプなのか、形状に合ったレイヤーを用意しているか、面や線の構造に不自然な点がないかを確認することで、地図上での見え方が安定します。
属性情報を表示や検索に使いやすい形に整える
GeoJSONは位置情報だけでなく、各地物に属性情報を持たせられる点が大きな特徴です。属性情報には、名称、分類、管理番号、状態、日付、担当、写真番号、区域種別、点検結果などを入れることができます。Web地図上で色分けをしたり、クリック時に情報を表示したり、条件で絞り込んだりする場合、この属性情報の設計がとても重要になります。
まず確認したいのは、属性名の統一です。同じ意味の項目に対して、ある地物では「name」、別の地物では「名称」、さらに別の地物では「施設名」のように項目名がばらついていると、表示設定や検索条件を組むときに扱いにくくなります。実務では、複数の担当者や複数のシステムから出力したデータをまとめることが多いため、項目名の統一は早い段階で行う必要があります。
次に、値の表記ゆれを確認します。たとえば状態を表す属性で、「確認済」「確認済み」「済」「完了」が混在していると、同じ意味であっても条件分岐では別の値として扱われます。分類や状態を色分けに使う場合は、値の候補をあらかじめ決めておき、不要な表記ゆれを減らすことが大切です。特に公開用や共有用の地図では、利用者が見て意味を理解しやすい表記にそろえる必要があります。
数値として扱う項目と文字として扱う項目も整理しておきます。延長、面積、標高、数量、点検回数などは数値として使う場面が多い項目です。一方で、管理番号やコードのように見た目は数字でも、先頭のゼロが意味を持つものは文字として扱った方がよい場合があります。数値と文字の扱いが混在すると、並び替えや条件判定で意図しない結果になることがあります。
日付情報も実務ではよく使われます。調査日、更新日、点検日、撮影日などを属性に入れる場合、日付の形式を統一しておくと、後から絞り込みや更新管理に使いやすくなります。和暦、西暦、スラッシュ区切り、ハイフン区切り、年月だけの表記などが混在していると、見た目の確認はできても、処理には向かないデータになります。地図表示だけでなく、一覧表や検索機能と連携する予定がある場合は、日付形式の統一を意識しておくと安全です。
クリック時に表示する情報も、属性設計と関係します。すべての属性をそのまま表示すると、利用者にとって必要な情報が埋もれてしまいます。反対に、表示項目が少なすぎると、地図上で確認したい内容が分からなくなります。実務では、利用者が最初に見たい情報、詳細確認で必要な情報、管理者だけが使う情報を分けて考えると整理しやすくなります。名称、分類、状態、更新日などは地図上で見せ、内部管理用のコードや作業メモは必要に応じて別画面や詳細表示に回す方法もあります。
複雑な入れ子構造の属性にも注意が必要です。元データに配列やオブジェクト形式の情報が含まれている場合、地図の表示条件や検索条件でそのまま扱いにくいことがあります。MapLibreで表示やフィルターに使う項目は、文字列、数値、真偽値などの扱いやすい値に整理し、詳細情報は必要に応じて別データや詳細画面に分けると運用しやすくなります。
属性情報は、地図の見た目だけでなく、運用後の使いやすさを左右します。最初は単に点や区域を表示するだけでも、後から検索、色分け、集計、更新管理を行いたくなることは少なくありません。そのときに属性名や値がばらばらだと、データの作り直しが必要になります。GeoJSONをMapLibreで表示する前に、属性情報が表示や検索に使える形になっているかを確認しておくことが、後工程の手戻りを減らします。
レイヤー設定と表示順を用途に合わせて確認する
GeoJSONを読み込んだ後は、どのように見せるかをレイヤー設定で決めます。MapLibreでは、データソースを追加しただけでは地図上の見た目は決まりません。ソースを参照するレイヤーを用意し、点、線、面などの形状に合った表示方法を設定する必要があります。点であれば円や記号、線であれば色や太さ、面であれば塗りつぶしや外枠を指定します。実務で見やすい地図を作るには、単に表示されることだけでなく、利用者が必要な情報を迷わず読み取れるかを確認する必要があります。
面データを表示する場合は、塗りつぶしの濃さに注意します。管理区域や調査範囲を強く塗りすぎると、背景地図や他の線情報が見えにくくなります。一方で薄すぎると、区域の存在に気づきにくくなります。外枠線を併用すると、塗りつぶしを控えめにしても範囲を読み取りやすくなります。区域の種類が複数ある場合は、色だけに頼らず、凡例や属性表示で意味を補うことも重要です。
線データでは、線幅と表示順が見やすさに大きく影響します。道路、境界、配管、ルートなどを重ねる場合、重要な線が背景や他の線に埋もれないように調整します。線が細すぎると拡大しなければ見えず、太すぎると位置精度が分かりにくくなります。特に境界や中心線のように位置そのものが重要なデータでは、太さを強調しすぎると誤解につながることがあります。
点データでは、地図の縮尺に応じた見え方を確認します。広域表示で大量の点を出すと、画面が点で埋まり、分布の傾向も個別情報も読みにくくなることがあります。反対に、拡大時に点が小さすぎると、クリックしにくくなります。点の大きさ、表示開始の縮尺、重なりの扱いを確認し、利用者がどの縮尺で何を見たいのかに合わせて調整します。
レイヤーの表示順も重要です。一般的には、面を下に置き、その上に線、さらに上に点を重ねると情報が読み取りやすくなります。ただし、用途によっては例外もあります。たとえば、調査範囲の面よりも境界線を強く見せたい場合、外枠線を上に重ねる必要があります。点検地点を最優先で見せたい場合は、点レイヤーが他の地物に隠れないようにします。表示順が適切でないと、データ自体は存在していても利用者からは見えない状態になります。
属性に応じた色分けを行う場合は、分類数を増やしすぎないことも大切です。分類が多すぎると、色の違いを覚えられず、凡例を見ても判断しにくくなります。点検状態のように、未確認、確認中、確認済み、要対応といった段階を示す場合は、利用者が直感的に理解できる順序や意味を意識します。色だけで判断させるのではなく、クリック時の属性表示や一覧との連動で補うと、誤読を減らせます。
また、表示条件を設定する場合は、条件から漏れる地物がないかを確認します。たとえば特定の分類だけを表示する設定にしたとき、属性値の表記ゆれによって一部の地物が表示されないことがあります。表示されない原因がレイヤー設定なのか、属性値の不一致なのか、形状タイプの違いなのかを切り分けられるようにしておくと、修正が早くなります。
レイヤー設定は、見た目を整える作業であると同時に、情報の優先順位を決める作業です。GeoJSONの中に含まれる情報をすべて同じ強さで表示すると、かえって使いにくくなります。何を最初に見せたいのか、どの情報は詳細確認でよいのか、背景との関係をどうするのかを確認しながら設定することで、実務で使いやすい地図に近づきます。
データ量と描画負荷を事前に確認する
GeoJSONは扱いやすい形式ですが、データ量が多くなると表示速度や操作性に影響が出ることがあります。点の数が多い、線や面の頂点数が多い、属性情報が過剰に入っている、不要な地物が含まれているといった場合、読み込みに時間がかかったり、地図の移動や拡大縮小が重くなったりします。実務で共有する地図では、作成者の環境では問題なく動いても、利用者の端末や通信環境では扱いにくいことがあります。
まず確認したいのは、GeoJSONファイルの容量です。容量が大きい場合、原因が地物数なのか、頂点数なのか、属性情報なのかを分けて見ます。点データが大量にある場合は、広域表示で全件を出す必要があるかを検討します。線や面のデータが重い場合は、細かすぎる頂点が含まれていないかを確認します。背景地図の上で概略確認する用途であれば、必要以上に細かい形状を持たせても、表示負荷が増えるだけになることがあります。
面データでは、境界線の頂点が非常に多い場合があります。詳細な境界をそのまま表示すると、拡大時には正確に見える一方で、広域表示では処理が重くなることがあります。用途に応じて、表示用の軽量データと管理用の詳細データを分ける考え方も有効です。公開や共有で使う地図では、利用者が求める精度と操作性のバランスを取る必要があります。
属性情報の持たせすぎにも注意が必要です。GeoJSONの各地物に大量の属性を入れると、ファイル容量が増えます。地図上で表示しない内部メモ、重複した説明文、別資料で管理すべき詳細情報まで含めると、読み込みや処理の負荷が増すだけでなく、データの見通しも悪くなります。地図表示に必要な属性、検索や色分けに必要な属性、詳細画面で必要な属性を整理し、GeoJSONに入れるべき情報を絞ることが大切です。
表示負荷を確認する際は、実際の利用環境に近い条件で試すことが重要です。作成者の高性能な端末や高速な通信環境だけで確認すると、現場や外出先での使用感を見落とすことがあります。地図を開いた直後の読み込み時間、拡大縮小したときの反応、点や面をクリックしたときの応答、複数レイヤーを同時に表示したときの動きなどを確認します。特に現地で使う地図の場合、通信が不安定な場所でも最低限の確認ができるかを考えておく必要があります。
データを分割する方法も検討できます。広域全体のデータを一つのGeoJSONにまとめると管理は単純になりますが、表示時には重くなる場合があります。区域別、用途別、縮尺別に分けることで、必要なときに必要な範囲だけを読み込めるようになります。ただし、分割しすぎると管理が複雑になるため、更新頻度や利用目的に合わせて判断する必要があります。
また、地図表示では、最初からすべてを表示しない設計も有効です。広域では集約した情報を見せ、拡大したときに個別の点や詳細な線を表示する方法です。これにより、利用者は全体像を把握しやすくなり、処理負荷も抑えやすくなります。実務では、全件表示が必ずしも最善ではありません。どの縮尺でどの情報が必要かを整理し、表示条件を設計することが重要です。
GeoJSONをMapLibreで表示するときは、正しく表示されることと快適に使えることを分けて確認する必要があります。読み込みに成功していても、操作が重ければ実務では使われにくくなります。データ量、頂点数、属性量、表示条件、利用環境を総合的に確認し、必要に応じて軽量化や分割を行うことで、地図の使い勝手を大きく改善できます。
更新・共有・運用時の確認ルールを決めておく
GeoJSONを地図に表示できたら終わりではありません。実務では、データの更新、担当者間の共有、関係者への確認、公開後の修正が発生します。そのため、初回表示の段階から運用時のルールを決めておくことが大切です。表示だけを優先して作ったデータは、後から更新履歴や責任範囲が分からなくなり、修正時に混乱しやすくなります。
まず決めておきたいのは、元データと表示用データの関係です。台帳や調査記録を元にGeoJSONを作る場合、どちらを正とするのかを明確にします。GeoJSONを直接編集する運用なのか、元データを修正してからGeoJSONを再出力する運用なのかが曖昧だと、同じ地物に対して複数の内容が存在してしまいます。地図上の表示だけを直したつもりでも、元データには反映されていないという状態は、実務でよくあるトラブルです。
更新日や更新者の記録も重要です。すべての地物に細かい履歴を持たせる必要があるとは限りませんが、少なくともデータ全体の作成日、更新日、作成元、更新担当を確認できるようにしておくと、後から判断しやすくなります。点検結果や現地調査のように時間の経過で意味が変わるデータでは、いつの情報なのかが分からないと、利用者が誤った判断をする可能性があります。
共有前には、表示範囲と公開範囲を確認します。内部確認用の地図には問題なく含められる情報でも、外部共有では伏せるべき情報が含まれている場合があります。個別の管理番号、担当者名、詳細なメモ、未確定の判断、内部向けのコメントなどは、共有先によって扱いを変える必要があります。GeoJSONはテキスト形式で中身を確認できるため、地図上に表示していない属性でもファイル内には残っている場合があります。共有前には、表示される情報だけでなく、ファイルに含まれる属性情報も確認することが大切です。
ファイル名や版管理も軽視できません。似た名前のGeoJSONが複数あると、どれが最新か分からなくなります。日付、対象範囲、用途、版数などを含めた命名ルールを決めておくと、差し替え時のミスを減らせます。特に複数人で更新する場合は、作業中のファイルと公開用のファイルを混同しないようにする必要があります。
表示確認のチェック手順も運用ルールに含めます。更新後に、全体位置、代表地点、属性表示、色分け、表示順、クリック動作、絞り込み条件を確認する流れを決めておくと、担当者が変わっても品質を保ちやすくなります。毎回すべてを詳細に確認するのが難しい場合でも、最低限の確認点を決めておくことで、重大な表示ミスを防ぎやすくなります。
また、利用者からの指摘をどのように反映するかも決めておくと安心です。地物の位置が違う、属性が古い、区域の範囲が異なる、表示が重いといった指摘があったとき、誰が内容を確認し、どのデータを修正し、いつ反映するのかを明確にします。指摘をその場限りで修正すると、履歴が残らず、同じ問題が再発することがあります。
GeoJSONをMapLibreで表示する取り組みは、最初は小さな地図表示から始まっても、運用が進むほど関係者やデータ量が増えていきます。初期段階で更新ルール、共有ルール、確認ルールを整えておけば、後から大きな手戻りを避けやすくなります。地図は見える化の道具であると同時に、情報管理の入口でもあります。表示できたかどうかだけでなく、継続して正しく使えるかを意識することが重要です。
まとめ
GeoJSONをMapLibreで表示するときは、単にファイルを読み込むだけでなく、座標、構造、属性、レイヤー、データ量、運用ルールを順番に確認することが大切です。最初に座標値と座標順序を確認し、地物が正しい位置に表示されているかを見ます。次に、点、線、面の形状タイプとGeoJSONの構造を確認し、表示設定と合っているかを整理します。そのうえで、属性情報を検索や色分けに使いやすい形に整え、レイヤーの見え方や表示順を用途に合わせて調整します。
さらに、データ量が多い場合は、表示速度や操作性にも注意が必要です。頂点数や属性情報が多すぎると、読み込みや操作が重くなることがあります。実際の利用環境に近い条件で確認し、必要に応じて軽量化や分割を検討します。最後に、更新や共有のルールを決めておくことで、地図を一度作って終わりにせず、継続して使える情報基盤として運用しやすくなります。
GeoJSONは、位置情報を扱う実務において使いやすい形式です。一方で、使いやすいからこそ、座標や属性の前提を曖昧にしたまま地図化してしまうこともあります。表示結果に違和感が出てから原因を探すよりも、最初に確認項目を決めておく方が効率的です。特に、現場調査、写真位置の管理、設備点検、区域管理、台帳整備などでは、地図上で見える情報がそのまま判断材料になるため、データの正確さと見やすさの両方が求められます。
これからGeoJSONを使った地図表示を実務に取り入れる場合は、まず小さな範囲で確認し、座標、属性、表示、運用の流れを固めてから対象範囲を広げると進めやすくなります。現地で取得した位置情報や写真情報を地図上で扱う場面では、取得から表示、共有までの流れを意識することが重要です。スマートフォンや現場記録アプリで取得した位置情報を後から地図や台帳と組み合わせる場合も、GeoJSONの座標、属性、更新ルールをそろえておくことで、MapLibreを使った地図運用に展開しやすくなります。