GeoJSONをWeb配信する時のキャッシュ設定と容量対策5つ

GeoJSONは、点・線・面などの地理空間情報をWeb上で扱いやすい形式です。構造が読みやすく、ブラウザやサーバー側の処理とも相性が良いため、地図表示、施工範囲の共有、設備管理、点検記録、現地確認用データの配信など、幅広い場面で使われます。一方で、GeoJSONはJSON形式のテキストデータであるため、座標点数や属性情報が増えるとファイル容量が大きくなりやすく、配信方法を誤ると表示が遅い、通信量が多い、更新したはずのデータが反映されない、といった問題が起こります。

この記事では、GeoJSONをWeb配信する実務担当者向けに、キャッシュ設定と容量対策で確認したい5つの考え方を整理します。単にファイルを軽くするだけでなく、更新頻度、利用者の閲覧環境、地図上で必要な範囲、ブラウザ側の再読み込み挙動まで含めて、安定して使える配信設計を考えていきます。

目次

• GeoJSON配信でキャッシュと容量対策が重要になる理由

• 対策1：更新頻度に合わせてキャッシュ方針を分ける

• 対策2：範囲と用途に合わせてファイルを分割する

• 対策3：座標桁数と属性項目を見直して容量を減らす

• 対策4：圧縮配信とHTTPヘッダーで転送量を抑える

• 対策5：更新・差し替え・無効化の運用ルールを決める

• GeoJSON配信で起こりやすい失敗と確認ポイント

• まとめ：GeoJSONは軽さと更新性を両立して配信する

GeoJSON配信でキャッシュと容量対策が重要になる理由

GeoJSONは、Webで地理情報を扱ううえで便利な形式です。座標と属性がひとつのテキストデータとしてまとまっているため、人が中身を確認しやすく、アプリケーション側でも読み込みやすいという特徴があります。例えば、現場境界、工区範囲、道路中心線、埋設物の位置、点検対象設備、撮影位置、出来形確認点などをGeoJSONにしてWeb地図上へ重ねれば、関係者が同じ情報を見ながら確認できます。

しかし、GeoJSONは便利な反面、Web配信では注意が必要です。座標点数が多い線や面、複雑なポリゴン、多数の点データ、長い属性名、不要な説明文を含んだデータをそのまま配信すると、ファイル容量が大きくなります。ブラウザはGeoJSONを受け取ったあと、JSONとして解析し、地図上の図形として描画します。そのため、通信に時間がかかるだけでなく、読み込み後の処理や描画にも負荷がかかります。

特に実務では、最初は数十点や数百点だったデータが、運用が進むにつれて数千点、数万点に増えることがあります。点検記録や現場写真の位置情報、施工履歴、測量点、設備台帳などを同じ考え方で追加していくと、いつの間にかひとつのGeoJSONが重くなり、地図画面の初期表示が遅くなります。社内の高速な回線では問題なく見えても、現場のモバイル回線や地下・山間部・建物周辺の通信環境では表示待ちが長くなり、実務で使いにくくなることがあります。

もうひとつ重要なのがキャッシュです。キャッシュとは、一度取得したデータをブラウザや中継サーバーなどに一時保存し、次回以降の読み込みを速くする仕組みです。GeoJSONのように何度も参照されるデータでは、キャッシュを活用すると通信量を減らし、表示速度を改善できます。一方で、キャッシュの設定を誤ると、更新したデータが利用者の画面に反映されにくくなることがあります。

たとえば、施工範囲や規制範囲、設備点検の結果など、最新状態が重要なGeoJSONを長期間キャッシュさせてしまうと、利用者は古い情報を見て判断してしまう可能性があります。反対に、ほとんど更新されない背景データや過去の記録データを毎回再取得させると、無駄な通信が増え、表示速度も落ちます。つまり、GeoJSON配信では、単純にキャッシュを長くすればよいわけでも、毎回最新取得にすればよいわけでもありません。データの性質に合わせて、キャッシュの長さと更新確認の仕組みを分けることが大切です。

容量対策も同じです。ファイルをただ削ればよいのではなく、業務で必要な精度、表示に必要な属性、利用者が一度に見る範囲、更新しやすさを考えて整理する必要があります。座標の桁数を過剰に持たせていないか、地図表示に不要な属性まで配信していないか、全地域のデータを一度に読み込ませていないか、更新頻度の違うデータをひとつのファイルにまとめていないかを確認することで、GeoJSONのWeb配信はかなり扱いやすくなります。

GeoJSONをWeb配信する時のポイントは、軽量化、キャッシュ、分割、更新運用を別々に考えないことです。容量を減らせば通信は軽くなりますが、更新運用が複雑になる場合があります。キャッシュを効かせれば表示は速くなりますが、差し替え方法を決めておかないと古いデータが残ります。ファイルを分割すれば必要な範囲だけ読み込めますが、管理ルールが曖昧だと配信漏れや参照ミスが起こります。実務では、これらを一体として設計することが重要です。

対策1：更新頻度に合わせてキャッシュ方針を分ける

GeoJSONをWeb配信する時、最初に考えたいのは更新頻度です。すべてのGeoJSONに同じキャッシュ設定を使うと、更新が反映されにくいデータと、毎回読み込む必要のないデータが混在してしまいます。まずは、配信するGeoJSONを、頻繁に更新されるデータ、たまに更新されるデータ、ほとんど更新されないデータに分けて考えることが大切です。

頻繁に更新されるデータには、当日の作業範囲、通行規制、点検ステータス、現場で追加された観測点、作業者が確認する最新の施工情報などがあります。このようなデータは、古い情報が表示されると業務判断に影響します。そのため、キャッシュ時間を短くする、または更新確認を行いやすい設定にする必要があります。ブラウザが毎回完全に再取得する必要があるとは限りませんが、少なくともデータが変わった時に新しい内容へ切り替わる仕組みが必要です。

たまに更新されるデータには、月次で更新される設備台帳、竣工後に修正される施設情報、一定期間ごとに見直す区域情報などがあります。この場合は、短すぎるキャッシュにすると毎回無駄な通信が発生しますが、長すぎるキャッシュにすると更新時の反映確認が難しくなります。更新日や版番号をファイル名や参照URLに含める方法を使うと、通常時はキャッシュを効かせながら、更新時には新しいデータを読ませやすくなります。

ほとんど更新されないデータには、過去の測量結果、確定済みの区域、背景として使う固定的な図形、年度単位で保管する記録などがあります。このようなデータは長めにキャッシュさせることで、表示速度と通信量の両方を改善できます。特に、複数の画面や複数の利用者が同じGeoJSONを繰り返し参照する場合、キャッシュの効果は大きくなります。

実務でよくある失敗は、更新頻度が違う情報をひとつのGeoJSONにまとめてしまうことです。例えば、ほとんど変わらない道路境界と、日々変わる点検ステータスを同じファイルに入れると、更新のたびに大きなファイル全体を再配信することになります。さらに、固定情報には長いキャッシュを効かせたいのに、可変情報が混ざっているため短いキャッシュにせざるを得なくなります。結果として、通信量も増え、キャッシュの効果も弱くなります。

そのため、GeoJSONを配信する前に、データの役割を分けることが重要です。形状データはあまり変わらないが、状態だけが変わるのであれば、形状と状態を別ファイルにする考え方があります。表示に必要な最小限の属性だけを形状側に持たせ、詳細情報や進捗情報は別のデータとして取得する構成にすれば、重い形状データを何度も再取得しなくて済みます。

キャッシュ設定では、HTTPヘッダーの考え方も押さえておくと実務で判断しやすくなります。Cache-Controlは、ブラウザや中継環境に対して、どの程度キャッシュしてよいかを伝える代表的な情報です。max-ageを使うと、指定した期間は保存済みデータを利用できます。no-cacheは保存を禁止する意味ではなく、利用前に更新確認を行わせる設定として使われます。保存自体を避けたい場合はno-storeを検討しますが、一般公開の静的なGeoJSONでは過剰になることもあるため、データの性質に合わせて判断する必要があります。

また、ETagやLast-Modifiedのような更新確認の仕組みを利用すると、データが変わっていない時は本文を再転送せずに済む場合があります。これにより、最新性を確認しながら通信量を抑えることができます。頻繁に更新されるGeoJSONでも、毎回大きな本文を返すのではなく、変更がない場合は軽い応答で済ませる設計にすれば、利用者が多い場合でも負荷を抑えやすくなります。

重要なのは、キャッシュを技術設定だけで決めないことです。現場でどの程度の遅延なら許容できるのか、更新直後に必ず全員へ反映させる必要があるのか、多少古くても問題ない参照用データなのかを整理したうえで、設定を選ぶ必要があります。GeoJSONのWeb配信では、データの性質を見極めることが、キャッシュ最適化の第一歩になります。

対策2：範囲と用途に合わせてファイルを分割する

GeoJSONの容量対策で効果が大きいのが、ファイル分割です。ひとつのGeoJSONにすべての地物を詰め込むと、利用者が画面上で一部の範囲しか見ていなくても、全体のデータを読み込むことになります。全国、都道府県、市区町村、工区全体、施設全体など、対象範囲が広いほどこの問題は大きくなります。

地図画面では、利用者が常に全データを見ているわけではありません。最初は広域を表示し、その後に特定の現場や設備へ拡大することが多いです。この時、最初から詳細なGeoJSONを全部読み込むと、初期表示が遅くなります。広域表示では簡略化したデータを使い、拡大した時に詳細データを読み込むようにすると、体感速度を改善できます。

ファイル分割の考え方には、地域単位、図面単位、工区単位、レイヤー単位、縮尺単位があります。地域単位では、行政区域やメッシュ状の区画に分けて、現在表示している範囲に関係するファイルだけを読み込みます。図面単位では、管理図や施工図ごとにGeoJSONを分けます。工区単位では、施工範囲や担当範囲ごとに分けることで、現場担当者が必要な情報だけを扱えます。

レイヤー単位の分割も実務では有効です。点、線、面を同じファイルに入れるのではなく、境界線、管理点、設備点、作業範囲、注意箇所などの用途別に分けると、表示の切り替えや更新がしやすくなります。点検ステータスだけ頻繁に更新される場合は、そのレイヤーだけを短いキャッシュにし、固定的な設備位置は長めにキャッシュすることもできます。

縮尺単位の分割では、広域用と詳細用を分けます。広域表示では、細かい頂点をすべて描画しても画面上では違いが見えにくい場合があります。そのような時は、広域用に簡略化したGeoJSONを用意し、拡大時だけ詳細なGeoJSONを読み込む構成にします。これにより、最初の読み込みが軽くなり、利用者が必要な場面だけ詳細情報を取得できます。

ただし、分割しすぎにも注意が必要です。ファイルを細かく分けすぎると、読み込みリクエストの数が増え、管理も複雑になります。特に通信環境が不安定な現場では、小さなファイルを多数取得するより、ある程度まとまった単位で取得したほうが安定する場合があります。分割の目的は、単にファイル数を増やすことではなく、不要なデータを読ませないことです。

分割単位を決める時は、利用者の操作を想像すると判断しやすくなります。利用者が最初に見る範囲はどこか、どの縮尺で詳細情報が必要になるか、検索結果から個別地点へ移動するのか、現場ごとに閲覧するのか、一覧性が重要なのかを考えます。業務の導線に合わせて分けることで、読み込み速度と運用しやすさを両立できます。

ファイル分割では、ファイル名やURLの設計も重要です。どの地域、どのレイヤー、どの版、どの縮尺のデータなのかが分かる命名にしておくと、管理しやすくなります。反対に、data.geojsonのような名前を何度も使い回すと、キャッシュの影響で古いデータが残っているのか、新しいデータに変わったのか判断しにくくなります。実務では、更新日、版番号、範囲名、レイヤー名などを組み合わせて、配信ファイルを識別しやすくすることが大切です。

また、分割したGeoJSONを読み込むための索引データを用意する方法もあります。最初に軽い一覧データを取得し、そこに各GeoJSONの範囲、更新日時、参照先、表示条件を持たせておけば、アプリケーション側は必要なファイルだけを選んで読み込めます。この索引データ自体は小さく保ち、更新頻度に応じて短めのキャッシュにすることで、重い詳細データを効率よく扱えます。

GeoJSON配信では、ひとつの大きなファイルを作って終わりではなく、どの単位で読み込ませるかを設計することが重要です。必要な時に必要な範囲だけ取得できる構成にすれば、容量が増えても表示速度の低下を抑えやすくなります。

対策3：座標桁数と属性項目を見直して容量を減らす

GeoJSONの容量を増やす大きな要因は、座標と属性です。GeoJSONでは座標が数値として記録されますが、小数点以下の桁数が多いほど文字数が増えます。点数が少ないうちは大きな差に見えませんが、線や面の頂点が数万、数十万になると、桁数の違いだけでファイル容量が大きく変わります。

座標桁数を見直す時は、必要な精度を考える必要があります。Web地図で概要を確認するだけのデータに、過剰な小数桁が必要とは限りません。一方で、測量や施工確認、設備位置の照合など、現地での精度が重要なデータでは、安易に丸めると問題が起こる可能性があります。そのため、GeoJSONの用途ごとに、表示用データなのか、検査や記録に使う元データなのかを分けて考えることが大切です。

実務では、元データは高精度のまま保管し、Web配信用のGeoJSONだけ軽量化する方法が現実的です。元データを直接削ってしまうと、後から詳細確認が必要になった時に戻せません。配信用に座標桁数を調整したデータを別に作れば、表示速度を改善しつつ、原本の精度も保てます。この考え方は、施工データや測量データ、インフラ設備の位置情報など、後から証跡として確認する可能性がある情報では特に重要です。

属性項目の見直しも効果があります。GeoJSONでは、各地物にpropertiesとして属性情報を持たせることができます。名称、種別、管理番号、状態、日付、担当者、説明、写真参照、備考などを入れられますが、表示に使わない項目まで含めると容量が増えます。特に、同じ属性名が地物ごとに繰り返し書かれるため、地物数が多いほど影響が大きくなります。

Web地図で初期表示に必要な属性は、意外と限られています。たとえば、色分けに使う種別、クリック時に表示する名称、詳細画面へ移動するための識別子があれば十分な場合があります。長い説明文、内部メモ、更新履歴、複数の写真情報、帳票用の項目などは、初期表示用GeoJSONに含めず、必要になった時に詳細データとして取得する構成にできます。

属性名を短くする方法もありますが、やりすぎると保守性が落ちます。例えば、分かりやすい属性名を極端に短い記号へ変えると、後から見た担当者が意味を理解しにくくなります。容量を優先しすぎて運用ミスが増えると本末転倒です。属性名を整理する時は、不要項目を削ることを優先し、そのうえで命名の長さを適度に整えるのが安全です。

また、同じ情報を何度も持たせないことも重要です。全地物に同じ工事名、同じ地区名、同じ年度、同じ管理者名を持たせている場合、それらはファイル全体のメタ情報や別の索引データに持たせられる可能性があります。各地物に必要なのは、その地物ごとに異なる情報です。共通情報と個別情報を分けることで、GeoJSONの容量を抑えられます。

形状の簡略化も検討できます。線や面の頂点が非常に多い場合、表示上の見た目を大きく変えずに頂点数を減らせることがあります。ただし、境界線、法的範囲、施工範囲、出来形確認に関係する形状では、簡略化によって意味が変わる可能性があります。表示用の簡略化データと、正式な記録データを分けることが重要です。特に、曲線に見える部分や複雑な境界では、簡略化後の形状が現地実態とずれていないか確認する必要があります。

点データが多い場合は、地図上で一度にすべて表示する必要があるかを考えます。数万点の観測点や写真位置をそのまま表示すると、通信量だけでなく描画負荷も高くなります。広域では集約表示にし、拡大した時だけ個別点を表示する構成にすると、操作性が改善します。GeoJSONそのものを軽くするだけでなく、どのタイミングでどの粒度のデータを表示するかを考えることが大切です。

容量を減らす作業では、削除してよい情報と残すべき情報を明確にする必要があります。現場での確認、社内共有、発注者への説明、将来の維持管理など、GeoJSONが使われる場面を想定し、表示に必要な情報と保管に必要な情報を分けます。配信用データは軽く、元データは正確に残すという役割分担が、実務では扱いやすい方法です。

対策4：圧縮配信とHTTPヘッダーで転送量を抑える

GeoJSONはJSON形式のテキストデータであるため、圧縮との相性が良い形式です。座標や属性名など、同じような文字列が繰り返し出てくるため、圧縮配信を行うことで転送量を減らせる場合があります。ファイル自体の中身を見直すことも大切ですが、Web配信時には圧縮が有効になっているかを確認することも欠かせません。

圧縮配信とは、サーバー側でGeoJSONを圧縮し、ブラウザ側で展開して利用する仕組みです。利用者が受け取る通信量は小さくなりますが、ブラウザ上では通常のGeoJSONとして扱えます。特に、座標点数が多いGeoJSONや属性が多いGeoJSONでは、圧縮による効果が大きくなりやすいです。

ただし、圧縮だけに頼るのは避けるべきです。圧縮すれば通信量は減りますが、ブラウザが受け取った後に解析するGeoJSONの量そのものは変わりません。つまり、圧縮で転送は軽くなっても、読み込み後の解析や描画が重いままの場合があります。大量の図形を一度に描画して操作が重くなる場合は、圧縮だけでなく、分割、簡略化、属性削減、表示制御も合わせて行う必要があります。

HTTPヘッダーでは、Content-Typeを適切に設定することも基本です。GeoJSONをWeb配信する場合は、application/geo+jsonを使うと、GeoJSONとしてのデータ種別を明示できます。実装環境によってはapplication/jsonとして扱われることもありますが、GeoJSONとして配信する意図を明確にするなら、配信側で適切なメディアタイプを設定するほうが安全です。

Cache-Controlも重要です。更新頻度に応じて、短時間だけキャッシュするのか、長期間キャッシュするのか、利用前に更新確認を行うのかを決めます。固定的なGeoJSONでは長めのキャッシュが有効です。ファイル名に版番号や更新日を含め、新しい版ではURL自体を変える運用にすれば、長期キャッシュでも更新時に新しいデータを読み込ませやすくなります。

一方で、同じURLのまま中身だけを差し替える運用では、長期キャッシュが問題になることがあります。利用者のブラウザが古いGeoJSONを使い続け、更新が反映されない場合があるためです。同じURLを使い続ける必要がある場合は、キャッシュ時間を短めにする、更新確認を行わせる、または参照時に版情報を付けるなどの工夫が必要です。

ETagやLast-Modifiedを使った条件付きリクエストも、GeoJSON配信では有効です。ブラウザが前回取得したデータの情報を持っておき、次回アクセス時にサーバーへ変更有無を確認します。変更がなければ本文を再送せず、変更がある場合だけ新しいGeoJSONを返します。これにより、最新性を保ちながら転送量を抑えられます。

ただし、条件付きリクエストが正しく働くには、サーバー側が更新判定を適切に返す必要があります。ファイルの中身が変わっているのに更新情報が変わらない、逆に中身が変わっていないのに毎回変更扱いになる、といった状態では効果が薄れます。配信後は、ブラウザの開発者向け確認機能などで、初回読み込み、再読み込み、更新後の読み込みが想定どおりになっているかを確認することが重要です。

また、GeoJSONを配信する時は、ヘッダーだけでなく、読み込み順序にも注意します。地図画面の初期表示で必ず必要なGeoJSONと、後から読み込めばよいGeoJSONを分けると、利用者が待つ時間を短くできます。最初に軽いデータで地図を表示し、詳細情報は必要なタイミングで取得することで、画面が固まったように見える状態を避けやすくなります。

Web配信では、通信量、解析時間、描画時間を分けて考えることが大切です。圧縮配信は通信量を減らします。キャッシュは再取得を減らします。ファイル分割は不要な読み込みを減らします。座標や属性の整理はデータそのものを軽くします。これらを組み合わせることで、GeoJSONの表示は安定しやすくなります。

対策5：更新・差し替え・無効化の運用ルールを決める

GeoJSONのWeb配信で見落とされがちなのが、更新運用です。初回公開時は問題なく表示できても、後からデータを修正した時に、どのファイルを差し替えるのか、キャッシュをどう扱うのか、利用者へいつ反映されるのかが決まっていないと、運用中に混乱します。特に、現場や関係部署が増えるほど、更新ルールの曖昧さは問題になりやすくなります。

まず決めたいのは、同じURLを維持するのか、更新ごとにURLを変えるのかです。同じURLを維持する方法は、参照先を変えなくてよいため運用が簡単に見えます。しかし、キャッシュが残っている場合、利用者によって新旧どちらのデータを見ているかが分かれやすくなります。更新頻度が高く、常に最新を見せたいデータでは、キャッシュ時間を短くするか、更新確認を確実に行う設定が必要です。

更新ごとにURLを変える方法では、ファイル名や参照パラメータに版番号、更新日、識別子などを含めます。新しいURLになれば、ブラウザは別のデータとして取得するため、長期キャッシュを使いやすくなります。固定的なデータや大きなGeoJSONでは、この方法が有効です。ただし、参照側の索引データや設定ファイルを更新する必要があるため、ファイル管理のルールが必要です。

更新運用では、索引データの考え方が役立ちます。画面側が直接すべてのGeoJSONファイル名を知っているのではなく、まず小さな索引データを読み込み、そこに現在使うべきGeoJSONのURLや版情報を書いておきます。索引データは短めのキャッシュにし、重いGeoJSON本体は長めにキャッシュする構成にすれば、更新時は索引だけを変えることで新しい本体へ誘導できます。

差し替え時には、古いファイルをすぐ削除するのではなく、一定期間残しておくことも検討します。利用者の画面や中継環境が古い索引を持っている場合、古いGeoJSONへの参照が一時的に残る可能性があります。その時にファイルが削除されていると、表示エラーになります。更新直後の混乱を避けるためには、古い版を一定期間保持し、参照がなくなった段階で整理する運用が安全です。

無効化の考え方も重要です。誤ったGeoJSONを配信してしまった場合、単に正しいファイルを上書きするだけでは、キャッシュに残った誤データが利用者側に残ることがあります。重大な誤りがある場合は、参照するURLを変える、索引データで対象ファイルを外す、短いキャッシュ設定に切り替えるなど、古いデータを使わせないための手順が必要です。

更新前の検証も欠かせません。GeoJSONはテキスト形式なので、一見すると簡単に編集できますが、括弧やカンマの欠落、座標順序の間違い、属性名の揺れ、文字コードの問題などで読み込みエラーが起こることがあります。配信前には、形式として正しいか、座標の向きや範囲が正しいか、想定した地図位置に表示されるか、容量が急に増えていないかを確認する必要があります。

特に、複数担当者がGeoJSONを作成する場合は、出力ルールを決めておくことが重要です。座標の桁数、属性名、必須項目、ファイル命名、更新日、版番号、レイヤー種別などが担当者ごとに異なると、配信側や表示側で扱いにくくなります。最初にルールを決めておけば、後からデータが増えても管理しやすくなります。

配信後の監視も大切です。ファイル容量、読み込み時間、エラー発生、更新反映の状況を定期的に確認すると、問題が大きくなる前に対応できます。現場から地図が重い、更新されない、一部だけ表示されないと言われてから調査するのではなく、配信側で変化を把握しておくことで、安定した運用につながります。

GeoJSONの更新運用は、技術者だけの問題ではありません。現場担当者、管理者、データ作成者、閲覧者が同じ情報を見て判断するための仕組みです。誰が、いつ、どのデータを更新し、どのタイミングで公開し、問題があった時にどう戻すのかを決めておくことで、Web配信の信頼性が高まります。

GeoJSON配信で起こりやすい失敗と確認ポイント

GeoJSON配信でよくある失敗のひとつは、ファイル容量だけを見て判断してしまうことです。確かに容量は重要ですが、同じ容量でも、地物の数、頂点数、属性の量、描画方法によって体感速度は変わります。軽く見えるファイルでも、地物数が多すぎるとブラウザでの描画が重くなることがあります。逆に、容量がある程度大きくても、分割やキャッシュが適切であれば実務上問題なく使えることもあります。

もうひとつの失敗は、社内環境だけで確認して公開してしまうことです。社内の高速回線や高性能端末では問題なく表示できても、現場の通信環境や一般的な端末では読み込みが遅くなることがあります。Web配信するGeoJSONは、利用者が実際に使う環境に近い条件で確認することが大切です。特に、モバイル回線、低速回線、屋外、移動中、複数レイヤー同時表示などの条件では、問題が見つかりやすくなります。

更新が反映されない問題もよく起こります。作成者は新しいGeoJSONに差し替えたつもりでも、閲覧者の画面では古いデータが表示され続ける場合があります。この原因は、ブラウザキャッシュ、中継環境のキャッシュ、ファイル名の使い回し、索引データの未更新などさまざまです。更新後には、別端末や通常の閲覧状態で確認し、意図したデータが表示されているかを確認する必要があります。

座標の扱いも注意点です。RFC 7946に準拠したGeoJSONでは、座標は基本的にWGS84の経度、緯度の順で扱います。測量や図面の作業では、緯度、経度の順に見える表記や、平面直角座標系のような投影座標系を扱うこともあります。そのままWeb配信用のGeoJSONへ変換すると、座標順や座標系の違いによって、データがまったく違う場所に表示されることがあります。Web地図へ配信する場合は、必要に応じてWGS84の経度・緯度へ変換し、正しい位置に表示されるかを必ず確認することが基本です。

属性の増えすぎにも注意が必要です。便利だからといって、台帳の全項目をGeoJSONに入れると、容量が増えるだけでなく、情報管理上のリスクも高まります。Web地図で表示する必要がない内部情報や個人情報に近い項目、公開範囲を限定すべき情報は、配信データに含めない判断が必要です。GeoJSONはテキストとして中身を確認しやすいため、見えてはいけない属性が含まれていないかを公開前に確認することが大切です。

また、ファイル分割後の参照漏れも発生しやすい問題です。地域単位やレイヤー単位で分けた場合、索引データに登録されていないファイル、古い版を参照しているファイル、削除済みのファイルを参照している設定が残ることがあります。分割数が増えるほど、人手だけで管理するのは難しくなります。配信前に、参照先の存在確認、ファイル容量の確認、更新日時の確認、表示範囲の確認を行う流れを作ると安全です。

キャッシュを無効にすれば問題が解決すると考えるのも危険です。キャッシュを極端に短くすると、更新反映は分かりやすくなりますが、毎回通信が発生し、表示速度やサーバー負荷に影響します。特に、利用者が多い場合や、同じGeoJSONを何度も開く業務では、キャッシュを使わないことが大きな負担になります。大切なのは、キャッシュを切ることではなく、データの性質に応じて適切に効かせることです。

反対に、長期キャッシュを設定しているのに、ファイル名を変えずに上書きする運用も避けたいところです。固定データとして長期間キャッシュさせるなら、更新時にURLを変える前提にする必要があります。URLを変えないなら、更新確認を行わせる設定にする必要があります。この整合性が取れていないと、配信側では正しい設定をしたつもりでも、利用者側では古いデータが残ります。

実務で確認すべき観点は、表示前、表示中、更新後に分けると整理しやすくなります。表示前には、GeoJSONの形式、座標、容量、属性、圧縮、ヘッダーを確認します。表示中には、初期表示時間、拡大縮小時の重さ、クリック時の反応、複数レイヤー表示時の負荷を確認します。更新後には、新旧データの切り替わり、キャッシュの挙動、古いURLの扱い、利用者への反映状況を確認します。

GeoJSON配信は、作って公開するだけなら簡単に見えます。しかし、実務で継続的に使うには、速度、正確性、更新性、管理性のバランスが必要です。問題が起きてから個別に直すのではなく、最初から確認ポイントを決めておくことで、安定したWeb配信につながります。

まとめ：GeoJSONは軽さと更新性を両立して配信する

GeoJSONをWeb配信する時は、ファイルを置いて読み込ませるだけでは不十分です。座標や属性が増えれば容量は大きくなり、容量が大きくなれば通信、解析、描画に時間がかかります。さらに、キャッシュの設定を誤ると、表示は速くなっても更新が反映されない、または最新性を優先しすぎて毎回重い通信が発生するという問題が起こります。

大切なのは、GeoJSONの用途を整理することです。頻繁に更新されるデータなのか、固定的に参照されるデータなのか、広域表示で使うのか、詳細確認で使うのか、現場判断に直結するのか、記録として保管するものなのかによって、最適な配信方法は変わります。すべてをひとつのファイルにまとめ、すべてに同じキャッシュ設定を使うのではなく、役割ごとに分けて設計することが重要です。

この記事で整理した5つの対策は、互いに関係しています。更新頻度に合わせてキャッシュ方針を分ければ、古い情報の表示を防ぎながら通信量を抑えられます。範囲と用途に合わせてファイルを分割すれば、必要なデータだけを読み込ませることができます。座標桁数と属性項目を見直せば、GeoJSONそのものを軽くできます。圧縮配信とHTTPヘッダーを整えれば、転送量と再読み込みの負担を減らせます。更新・差し替え・無効化の運用ルールを決めれば、公開後の混乱を防げます。

特に実務では、配信用データと元データを分ける考え方が有効です。Web表示用のGeoJSONは軽く扱いやすくし、元の測量データや正式な記録データは精度を保って管理します。これにより、画面表示の速度と、業務上必要な正確性を両立しやすくなります。

GeoJSONは、地理情報を共有するための強力な形式です。しかし、データ量が増え、関係者が増え、更新頻度が上がるほど、配信設計の重要性も高まります。最初の段階でキャッシュ、容量、分割、更新運用を考えておけば、後から大規模な見直しをせずに済みます。

現場で取得した位置情報や点群、施工範囲、確認点などをWeb上で活用する場合も、GeoJSONの軽量な配信設計は重要です。高精度な位置情報を現地で扱い、取得したデータを分かりやすく共有したい場合は、スマートフォンやタブレットと連携して測位・記録・確認を進められるLRTK Phoneの活用も検討すると、GeoJSONを含む位置情報データの現場利用をより実務に近い形で進めやすくなります。