GeoJSONは、地物の形状と属性をひとつのデータとして扱いやすく、Web地図や業務用の位置情報管理で広く使われる形式です。点、線、面をまとめて扱えるため、現地調査結果、設備台帳、境界情報、点検記録、施設管理データなどを地図上に重ねて確認する用途に向いています。一方で、件数が多いGeoJSONをそのまま画面に表示すると、読み込みに時間がかかったり、地図操作が重くなったり、端末によってはブラウザが固まったように見えることがあります。
「geojson 使い方」を調べている実務担当者にとって重要なのは、表示できるかどうかだけではありません。現場で使える速度で表示できるか、拡大縮小や移動をしても待たされないか、属性検索や確認作業に支障が出ないかまで含めて考える必要があります。大容量GeoJSONを扱うときは、データ作成、属性整理、表示範囲、ズーム段階、描画方法、運用ルールを分けて見直すことが大切です。
表示範囲を絞り込んで一度に読ませる量を減らす
GeoJSONの大容量表示が遅くなる原因のひとつは、利用者が最初に見る範囲よりもはるかに広いデータを一度に読み込んでしまうことです。たとえば、画面では市区町村の一部だけを表示しているのに、県全域や複数案件分の点検データをまとめて読み込むと、通信、解析、描画のすべてに負荷がかかります。GeoJSONはJSON形式のテキストデータとして扱いやすい一方、配信方法やデータ量によってはファイルサイズが大きくなりやすいため、最初に読ませる範囲を抑える考え方が重要です。
実務では、まず「画面に最初に必要な情報は何か」を決めることが出発点になります。すべての地物を最初から表示するのではなく、初期表示では対象区域の概要だけを見せ、詳細は拡大時や検索時に読み込む形にすると、操作開始までの待ち時間を短くできます。現地調査の結果を地図に載せる場合でも、全案件を常に読み込む必要があるとは限りません。案件番号、工区、年度、施設種別、点検日などで対象を絞り、利用者が今確認したい範囲だけを表示する設計にすることで、無駄な読み込みを減らせます。
地図の移動に合わせて表示範囲内のGeoJSONだけを取得する方法も有効です。このときは、画面の範囲に完全一致させるよりも、少し余裕を持った周辺範囲まで先読みする方が、地図を少し動かしたときの再読み込みを減らせます。ただし、余裕を大きく取りすぎると結局データ量が増えるため、対象地物の密度や利用者の操作範囲に合わせて調整することが大切です。点が密集している都市部、線が長く続く道路や河川、面が複雑な区域データでは、それぞれ適した範囲の切り方が異なります。
表示範囲を絞るときは、行政区域や工区単位だけでなく、地図画面の表示範囲、縮尺、検索条件を組み合わせると実用的です。たとえば、広域表示では区域の代表点や概要ポリゴンだけを表示し、拡大した段階で個別の地物を表示する流れにすると、利用者は全体像と詳細の両方を確認しやすくなります。これは単に高速化のためだけではなく、画面上の情報過多を防ぐ意味でも有効です。大容量データをすべて見せることが親切とは限らず、必要な段階で必要な粒度を見せる方が、実務では判断しやすくなります。
また、表示対象の範囲を絞る前提として、GeoJSONに範囲判定しやすい属性を持たせておくことも重要です。工区名や区域名が自由入力でばらついていると、絞り込み条件として使いにくくなります。部署ごとに表記が違う、年度の書き方が違う、施設種別の分類が統一されていないと、データを分ける処理にも影響します。表示速度の問題は、地図画面だけでなく、元データの管理方法とも深く関係しています。
大容量GeoJSONを扱う場合、最初に「全部を読み込んでから画面側で非表示にする」という発想を避けることが大切です。画面に出さないデータであっても、読み込み、解析、メモリ保持の負荷は発生します。表示しないなら最初から読まない、必要になったら読む、不要になったら保持しすぎないという考え方に変えるだけでも、体感速度を改善しやすくなります。
属性情報を整理してGeoJSON自体を軽くする
GeoJSONが重くなる理由は、座標点の数だけではありません。各地物に付いている属性情報が多すぎる場合も、ファイルサイズや処理負荷が増えます。実務用データでは、調査メモ、管理番号、写真名、担当者名、点検結果、補足説明、内部管理用コードなど、多くの項目を持たせたくなる場面があります。しかし、地図表示に使わない項目まで毎回GeoJSONに含めると、表示に必要のない情報まで通信し、ブラウザ側で読み込むことになります。
まず確認したいのは、その画面で本当に必要な属性だけをGeoJSONに入れているかです。地図上で色分けに使う項目、ラベル表示に使う項目、クリック時の簡易確認に使う項目、検索条件に使う項目は必要性が高い情報です。一方で、詳細帳票でしか使わない長文メモや、別画面で確認すればよい履歴情報まで含めると、ひとつひとつの地物が重くなります。大容量データでは、地物の件数が多いほど属性項目の増加が全体サイズに直結します。
属性名の付け方も見直し対象です。GeoJSONでは各地物が同じ属性名を繰り返し持つため、極端に長い項目名はファイル全体の肥大化につながります。もちろん、意味が分からないほど短くしすぎると運用時に混乱しますが、画面表示用のデータでは、項目名を一定のルールで短くし、別途項目定義を管理する方法も考えられます。重要なのは、誰が見ても意味が分かることと、表示用として過剰に冗長でないことのバランスです。
値の持たせ方にも注意が必要です。同じ意味の値が「未確認」「未確認です」「未実施」「確認前」のように混在していると、表示時の分類処理が複雑になります。分類が増えるほど色分けやフィルタ条件も複雑になり、利用者が結果を判断しにくくなります。表示速度だけでなく、実務上の見やすさを考えても、属性値は選択式に近い形で統一する方が扱いやすくなります。
写真や帳票への参照情報をGeoJSONに入れる場合も、入れすぎには注意が必要です。画像そのものや長い説明文をGeoJSON内に持たせるのではなく、必要な識別子や参照先を持たせ、詳細確認時に別途読み込む形にすると、地図表示用データを軽くできます。地図画面は、まず位置と状態を素早く確認するための入口として設計し、詳細情報は利用者が選択したときに取りに行く構成にすると、初期表示の負荷を抑えやすくなります。
また、不要な小数桁もファイルサイズを大きくします。座標の桁数は精度に関わるため慎重に扱う必要がありますが、表示用途に対して過剰な桁数を保持している場合は、必要精度を確認したうえで整理する余地があります。特に、広域の見た目確認や概略表示では、測量成果そのものと同じ精度を表示データに持たせる必要がない場合があります。ただし、境界確認や施工位置確認など、座標精度が業務判断に直結する用途では、安易な丸めは避けるべきです。表示用と原本管理用を分ける考え方が安全です。
大容量表示を軽くするには、GeoJSONを単なる保存形式として見るのではなく、「画面表示に必要な情報だけを持つ配信用データ」として考えることが効果的です。原本データには詳細情報を残し、表示用GeoJSONでは必要な項目に絞る。これにより、速度だけでなく、画面の見通しやデータ更新時の確認もしやすくなります。
ズーム段階に応じて表示する情報を切り替える
大容量GeoJSONを扱うときに見落とされがちなのが、ズーム段階ごとの表示設計です。地図を大きく引いた状態では、細かな点、複雑な線、細分化された面をすべて表示しても、利用者は内容を読み取れません。それにもかかわらず、全地物を描画しようとすると、画面は重くなり、見た目も混雑します。広域では概要を、詳細では個別情報を表示するという段階的な考え方が必要です。
たとえば、点データが数万件ある場合、広域表示で全点を表示すると、点が重なって黒い塊のように見えることがあります。この状態では、正確に場所を把握することも、個別の点を選択することも難しくなります。広域では件数のまとまりや代表位置を示し、拡大したら個別点を表示する設計にすると、利用者は全体の分布を把握しながら詳細へ進めます。これは速度対策であると同時に、情報設計の改善でもあります。
線データでも同じ考え方が使えます。道路、管路、河川、境界線などの線形データは、広域表示では細かな折れ点や短い枝線まで表示しても判読しにくい場合があります。広域では主要な線だけを表示し、拡大に応じて支線や詳細な形状を追加することで、描画負荷を抑えながら視認性を保てます。面データの場合も、広域では区域の外形や分類だけを示し、詳細な区画や属性は拡大時に表示する方が扱いやすくなります。
ズーム段階ごとに表示内容を切り替える場合は、どの縮尺で何を表示するかを業務目的から決めることが大切です。単に「重いから非表示にする」のではなく、利用者がその縮尺で何を判断するのかを基準にします。広域では分布や件数、対象範囲を確認する。中域では工区や施設群を確認する。詳細では個別地物の属性や位置を確認する。このように利用場面を分けると、表示すべき情報と省略してよい情報が整理しやすくなります。
ラベル表示も速度と視認性に大きく影響します。すべての地物に常時ラベルを表示すると、文字描画の負荷が増え、地図上も読みづらくなります。ラベルは詳細ズーム時だけ表示する、選択した地物だけ表示する、重要度の高いものだけ表示するなど、条件を設けるとよいです。特に長い名称や説明文を地図上に直接出すと、画面を占有しやすくなります。ラベルは短く、詳細はクリック後の情報欄で見せる方が実務では使いやすいことが多いです。
また、表示切り替えを行うときは、利用者が混乱しないようにする必要があります。縮尺を変えた瞬間に情報が突然消えると、「データがなくなった」と誤解されることがあります。そのため、広域では簡略表示になっていること、拡大すると詳細が表示されることが自然に分かる画面設計が望ましいです。凡例や表示条件の説明を整えておくと、データの有無と表示制御の違いを区別しやすくなります。
GeoJSONを大容量のまま一律表示するより、ズーム段階ごとに役割を変える方が、速度と使いやすさの両方を改善できます。重要なのは、詳細を削ることではなく、必要な場面で必要な詳しさを出すことです。表示の粒度を業務判断の流れに合わせれば、利用者は待たされにくくなり、確認作業も進めやすくなります。
点・線・面の形状を用途に合わせて単純化する
GeoJSONの表示速度に大きく影響する要素として、座標点の数があります。点データであれば件数そのものが問題になりますが、線や面ではひとつの地物の中に含まれる頂点数が増えるほど描画が重くなります。境界線や道路縁、河川形状、敷地外周、区域ポリゴンなどは、元データの作り方によって非常に細かな折れ点を持つことがあります。画面上では違いがほとんど見えない細部でも、描画処理では座標として扱われるため、数が多ければ負荷になります。
形状の単純化とは、表示目的に応じて不要な細かい頂点を減らし、見た目や判断に影響しにくい範囲でデータを軽くすることです。ただし、単純化は慎重に行う必要があります。境界や施工位置など、正確な形状が業務上の根拠になるデータでは、原本を変更してしまうと問題になります。そのため、原本データと表示用データを分け、表示用のGeoJSONだけを単純化する考え方が安全です。
単純化の程度は、利用目的によって変えるべきです。広域で区域の位置関係を確認するだけなら、細かな凹凸を省略しても支障が少ない場合があります。一方で、用地境界、構造物位置、施工範囲の確認などでは、少しのずれが判断に影響する可能性があります。このような場合は、詳細ズーム時には原本に近い形状を表示し、広域表示では軽量化した形状を使うなど、段階的に使い分けるとよいです。
面データでは、穴を含む形状や複雑な外周を持つ形状に注意が必要です。複数の区域をひとつの地物として持たせている場合や、細長い面が大量にある場合は、描画負荷が高くなりやすくなります。表示上の目的が分類や範囲確認であれば、広域では代表的な外形や簡略化した面を使い、詳細表示で正確な区画を確認する方が現実的です。面の重なりが多い場合は、透明度や塗り分けの設定も描画負荷や視認性に影響するため、必要以上に複雑な表現を避けることも大切です。
線データでは、非常に短い線分が連続している場合や、見た目には直線に近いのに多数の頂点が含まれている場合があります。現場で取得した軌跡や既存図面から変換したデータでは、このような状態になりやすいです。表示用途では、直線に近い部分の頂点を整理するだけでも軽くなることがあります。ただし、曲線部や重要な折れ点を削りすぎると、現地の形状と違って見えるため、単純化後の見た目確認は欠かせません。
点データの場合は、形状の単純化というよりも、まとめ表示や代表点化が有効です。近接する点を一定範囲でまとめる、同じ施設に紐づく複数点を代表点で見せる、重要度や状態に応じて表示対象を変えるといった工夫が考えられます。点が多いほど個別のクリック判定や描画が増えるため、すべてを同じ重要度で表示しないことが大切です。
形状を軽くする作業では、単にファイルサイズだけを見るのではなく、業務上の許容範囲を確認する必要があります。表示用に軽くした結果、位置がずれて見える、隣接する面との関係が変わる、線が交差して見えるといった問題が起きると、利用者の判断を誤らせる可能性があります。特に施工、点検、境界、維持管理に関わるデータでは、速度と正確性のバランスを明確にしておくことが重要です。
大容量GeoJSONでは、精密さをすべての場面で同じように出す必要はありません。原本の正確性を守りながら、表示用データでは必要な粒度に整える。この考え方を持つことで、速度を改善しつつ、実務で安心して使える地図表示に近づけます。
読み込みと描画のタイミングを分けて体感速度を上げる
大容量GeoJSONの表示では、実際の処理時間だけでなく、利用者が感じる待ち時間も重要です。すべてのデータを読み込み、解析し、描画が終わるまで画面が変わらない設計では、利用者は「遅い」「止まった」と感じやすくなります。処理そのものを軽くすることに加えて、読み込みと描画のタイミングを分け、先に操作できる部分を出す工夫が必要です。
まず有効なのは、初期表示で最低限必要な情報だけを先に表示することです。背景地図や対象区域の概要、検索条件、凡例などを先に見せ、詳細なGeoJSONは後から段階的に読み込む構成にすると、利用者は画面が動いていることを認識できます。すべてが表示されるまで空白の画面を見せるより、先に全体の枠組みを出す方が体感速度は上がります。
読み込み中であることを分かりやすく示すことも大切です。大容量データの処理では、数秒の待ち時間が発生することがあります。そのとき、何も表示されないと利用者はエラーなのか処理中なのか判断できません。読み込み中の状態、対象件数、絞り込み条件、表示準備中であることを画面上で伝えるだけでも、操作の不安は減ります。業務用の画面では、速さだけでなく、今何が起きているかが分かることも使いやすさに直結します。
描画を一度に行わない工夫もあります。たとえば、地図の移動や拡大縮小のたびにすぐ全データを再描画すると、操作中に何度も処理が走り、画面が引っかかる原因になります。利用者が操作を終えたタイミングで表示を更新する、一定時間内の連続操作では最後の状態だけを反映するなど、処理のタイミングを調整すると、無駄な再描画を減らせます。これは特に、点の件数が多いデータや複雑な面データで効果が出やすい考え方です。
属性検索やフィルタ変更でも同じです。検索条件を一文字入力するたびに全GeoJSONを再処理すると、件数が多い場合に負荷が大きくなります。入力が落ち着いた後に検索する、条件確定後に表示を更新する、候補だけを先に絞るなど、利用者の操作に合わせた処理設計が必要です。表示速度の改善は、データ量だけでなく、操作イベントの扱い方にも左右されます。
また、地物をクリックしたときの詳細表示も、最初からすべての詳細属性を持たせるのではなく、選択時に必要な情報を読み込む構成にすると軽くできます。地図上では名称、種別、状態などの最小限の属性だけを持たせ、詳細な点検履歴、写真情報、帳票情報は選択後に取得する形です。これにより、初期表示のGeoJSONを軽くしつつ、必要な詳細確認は確保できます。
端末性能の違いも考慮が必要です。同じGeoJSONでも、高性能な端末では問題なく動く一方、現場用の端末や古い端末では動作が重くなることがあります。社内で検証するときに開発用の高性能環境だけで確認すると、現場での体感速度を見誤る可能性があります。実際に利用する端末、通信環境、同時に開く画面数を想定して確認することが大切です。
読み込みと描画のタイミングを分ける目的は、単に処理を遅らせることではありません。利用者が必要な操作を早く始められるようにし、重い処理を必要なタイミングに限定することです。大容量GeoJSONを実務で使うなら、技術的な処理速度だけでなく、利用者が待たされていると感じる場面を減らす設計が欠かせません。
更新しやすいデータ分割と運用ルールを決める
GeoJSONの大容量表示を安定させるには、データをどのように分割し、どの単位で更新するかを事前に決めておくことが重要です。最初は小さなデータでも、案件が増え、調査年度が重なり、施設数が増えると、ひとつのGeoJSONに何でも追加してしまいがちです。その結果、表示が遅くなるだけでなく、更新作業や不具合確認も難しくなります。
データ分割の考え方には、区域別、工区別、年度別、地物種別、業務段階別などがあります。どの単位がよいかは、利用者がどのように検索し、どの範囲を確認するかによって変わります。たとえば、現場担当者が工区単位で見ることが多いなら工区別の分割が適しています。年度ごとの成果確認が中心なら年度別の分割が扱いやすくなります。点検対象と施工対象を同じ画面に重ねる必要があるなら、地物種別で分けておくと表示制御がしやすくなります。
分割の粒度は細かければよいわけではありません。細かく分けすぎると、管理するファイル数が増え、更新漏れや参照ミスが起きやすくなります。逆に大きすぎると、表示時に不要なデータまで読み込むことになります。実務では、利用頻度が高い単位、更新責任者が把握しやすい単位、画面表示で絞り込みやすい単位を組み合わせて決めるとよいです。データ分割は表示速度だけでなく、運用の継続性にも関わります。
更新ルールも欠かせません。誰が、いつ、どの元データからGeoJSONを作成するのか、表示用に軽量化する場合はどの処理を行うのか、属性項目を変更するときは誰が確認するのかを決めておかないと、同じ画面で新旧の形式が混在することがあります。属性名が変わる、分類値が増える、座標系の前提が変わると、表示処理や検索条件に影響します。大容量データほど、ひとつの変更が広い範囲に波及しやすくなります。
ファイル名や管理名の付け方も重要です。表示用、原本用、確認用、過年度用が分かりにくいと、誤ったGeoJSONを表示してしまうおそれがあります。特に、軽量化した表示用データと精度を保持した原本データを分ける場合は、用途の違いが明確に分かる名前にするべきです。表示が速いからといって、表示用データを正式な成果や判断根拠として誤用しないように注意が必要です。
データ更新後の確認では、ファイルサイズ、地物件数、属性項目、座標範囲、表示速度を確認すると安心です。更新前と比べて急にファイルサイズが大きくなっている場合、不要な属性が追加されている、座標点が過剰に増えている、同じ地物が重複しているといった原因が考えられます。表示が遅くなってから原因を探すより、更新時点で確認項目を決めておく方が、問題を早く見つけられます。
また、大容量GeoJSONを複数人で扱う場合は、作業者ごとの判断に任せすぎないことが大切です。ある担当者は属性を多く入れ、別の担当者は形状を細かく残し、また別の担当者は表示用に削るという状態では、画面ごとの動作や見た目が安定しません。データ作成手順、軽量化の基準、属性項目の定義、表示確認の方法を文書化しておくと、担当者が変わっても品質を保ちやすくなります。
大容量表示の問題は、画面側の工夫だけで解決しようとすると限界があります。データが増え続ける前提で、分割、更新、確認、保管のルールを決めておくことが、長期的な速度維持につながります。GeoJSONを使った地図表示は、作って終わりではなく、データが増えるほど運用設計の重要性が高まります。
まとめ
GeoJSONの大容量表示を遅くしないためには、単に高性能な環境に頼るのではなく、データ量、表示範囲、属性、形状、描画タイミング、運用ルールを総合的に見直すことが大切です。GeoJSONは扱いやすい形式ですが、すべての情報をそのまま詰め込んで一度に表示すると、実務で使いにくい重い地図になってしまいます。特に、現場調査、設備管理、点検記録、施工確認のようにデータが増え続ける業務では、最初から軽く使うための設計をしておく必要があります。
最初に意識したいのは、表示しないデータを読み込まないことです。対象範囲、工区、年度、種別、検索条件で絞り込み、利用者が今必要としている情報だけを画面に出すようにします。次に、GeoJSONに含める属性を整理し、表示や検索に使わない項目を持たせすぎないようにします。さらに、ズーム段階ごとに概要表示と詳細表示を切り替え、形状も用途に応じて表示用に整えることで、速度と視認性を両立しやすくなります。
読み込みと描画のタイミングを工夫することも、体感速度の改善に役立ちます。すべての処理が終わるまで待たせるのではなく、先に必要な画面を表示し、詳細は段階的に読み込む設計にすると、利用者は作業を始めやすくなります。加えて、データ分割や更新ルールを整えておけば、案件や年度が増えても表示速度を維持しやすくなります。
「geojson 使い方」を実務で考えるときは、形式の書き方だけでなく、どのように軽く表示し、どのように更新し続けるかまで含めて設計することが重要です。大容量データを無理に一画面へ詰め込むのではなく、目的に合わせて段階的に見せることで、地図は確認しやすく、動作も安定しやすくなります。現場で取得した位置情報、写真、点検記録などを地図上で扱う場合も、原本データと表示用データを分け、必要な範囲と粒度で表示する運用を整えることが、継続して使いやすいGeoJSON活用につながります。