GeoJSONは、地図上の点、線、面を扱うときに便利なデータ形式です。業務で「geojson 使い方」を調べている方の多くは、地図表示、現地調査データの共有、施設管理、区域図の作成、位置情報付きデータの可視化などでGeoJSONを扱う場面に直面しているのではないでしょうか。GeoJSONは人が読める構造で扱いやすい一方、座標の桁数や頂点数、属性情報が多いまま保存されていると、ファイル容量が大きくなり、読み込みや表示が重くなることがあります。この記事では、GeoJSONの座標値の表現を調整して軽量化する代表的な4つの方法を、実務で判断しやすいように解説します。
GeoJSONが重くなる主な原因
GeoJSONは、地理空間データをJSON形式で表現するための形式です。点を表すPoint、線を表すLineString、面を表すPolygonなどのジオメトリを、属性情報と一緒にまとめて扱えるため、地図表示や位置情報の受け渡しに向いています。構造が比較的わかりやすく、テキストとして中身を確認できることも、実務で使われやすい理由のひとつです。
現在のGeoJSON仕様では、座標は原則としてWGS 84の経度・緯度を十進度で表します。座標配列では、基本的に経度、緯度の順に値が並び、必要に応じて高さを3番目の値として持つことがあります。この順序を取り違えると、地物がまったく別の場所に表示されるため、加工時には特に注意が必要です。
一方で、GeoJSONはテキスト形式で座標をそのまま保持するため、座標数が増えるほどファイルサイズが大きくなります。特に、道路、河川、敷地境界、行政区域、圃場、施工範囲、点群から抽出した外周線など、細かな形状を含むデータでは、座標の数が膨大になりやすいです。ひとつの面に数千点、数万点の頂点が含まれることもあります。
さらに、座標の小数点以下の桁数が必要以上に多い場合も、GeoJSONが重くなる原因になります。たとえば経度や緯度が小数点以下10桁以上で保存されている場合、見た目の地図表示や一般的な管理図面ではそこまで細かい表現が必要ないことがあります。にもかかわらず、すべての座標が長い数値のまま残っていると、ファイル全体では容量差が生じます。
GeoJSONが重いと、ブラウザ上の地図表示に時間がかかったり、編集画面の操作が遅くなったり、通信時に待ち時間が増えたりします。現場でスマートフォンやタブレットを使う場合は、通信環境が常に安定しているとは限りません。そのため、GeoJSONをただ保存するだけでなく、用途に合わせて軽量化しておくことが重要です。
ただし、軽量化は単純にデータを削ればよいというものではありません。座標値を粗くしすぎると、境界線がずれたり、面積計算に影響したり、現地での位置確認に使いにくくなったりします。実務では、ファイルサイズ、表示速度、測位精度、利用目的のバランスを考えながら調整する必要があります。
座標精度を調整する前に知っておきたい考え方
GeoJSONを軽量化する前に、まず「そのデータを何に使うのか」を整理することが大切です。同じGeoJSONでも、背景地図の上に概略範囲を表示するだけなのか、現地で境界確認に使うのか、面積や延長の集計に使うのかによって、必要な表現の細かさは変わります。
たとえば、施設の位置を地図上にピンで表示するだけなら、座標の小数点以下を過度に保持する必要はない場合があります。画面上でおおよその位置がわかればよいケースでは、数メートル程度の違いが業務上問題にならないこともあります。一方で、土地の境界、施工範囲、出来形管理、農地の区画、設備点検位置などでは、数十センチから数センチの違いが重要になる場合があります。
ここで注意したいのは、座標の桁数と測位精度は同じ意味ではないという点です。小数点以下の桁数は、座標値をどの細かさで表現しているかの目安にはなりますが、そのデータが実際にどれだけ正確に測られたかを保証するものではありません。高精度に見える長い小数でも、元の測位や図化の精度が低ければ、位置の信頼性は高くなりません。
経度緯度の小数点以下の桁数は、丸めによる位置の粗さを考えるときの参考になります。厳密には緯度や場所によって距離への換算は変わりますが、緯度方向では小数点以下5桁がおおむね約1メートル、6桁がおおむね約10センチ、7桁がおおむね約1センチの刻みに相当します。経度方向は緯度が高くなるほど同じ桁数でも実距離が短くなります。実務ではこの目安を参考にしながら、目的に対して過不足のない桁数を選びます。
また、GeoJSONの座標値を調整する作業は、元データに対して直接行うのではなく、複製したデータに対して行うのが安全です。元データは保管用、軽量化したデータは表示用や共有用というように役割を分けておくと、後から高精度データが必要になったときにも対応できます。
特に注意したいのは、軽量化済みのGeoJSONをさらに何度も加工しないことです。小数点以下の丸めや頂点の間引きは、繰り返すほど誤差が蓄積しやすくなります。作業のたびに前回の軽量化データを元にするのではなく、必要に応じて保管用の元データから再生成する流れにしておくと、品質を管理しやすくなります。
GeoJSONの軽量化は、単なるファイル圧縮とは違います。座標そのものの表現を変えるため、地物の位置や形状に影響する可能性があります。そのため、作業前に「表示用なのか」「分析用なのか」「現地確認用なのか」「保存用なのか」を明確にし、用途別に許容できる誤差を決めておくことが、失敗を防ぐ第一歩です。
方法1 座標の小数点以下の桁数を丸める
もっとも取り組みやすい軽量化方法は、座標の小数点以下の桁数を丸めることです。GeoJSONでは、座標が数値として大量に並びます。経度と緯度のそれぞれに長い小数が含まれている場合、その桁数を減らすだけでもファイルサイズを削減できます。
たとえば、ある地点の座標が小数点以下10桁以上で保存されているとします。地図上で大まかな位置を示すだけなら、小数点以下6桁程度でも十分な場合があります。この場合、すべての座標について小数点以下を6桁に丸めることで、各座標の文字数が短くなり、GeoJSON全体の容量も軽くなります。
小数点以下の桁数をどこまで残すかは、用途によって決めます。広域の施設分布図、営業エリアの可視化、概略的な現地案内であれば、小数点以下5桁から6桁程度を検討できます。比較的細かな位置確認が必要な点検位置、施工範囲、現地調査結果の共有であれば、小数点以下6桁から7桁程度を残すことが考えられます。より厳密な測量成果や境界管理で使う場合は、丸めによる影響を慎重に確認する必要があります。
座標の丸めは、点データだけでなく線や面にも効果があります。点データでは1地物あたりの座標数が少ないため効果は限定的ですが、線や面では頂点数が多いため、桁数を減らす効果が大きくなります。特に、複雑なPolygonやMultiPolygonを含むGeoJSONでは、丸めだけで扱いやすくなることがあります。
ただし、丸めには注意点があります。小数点以下を削りすぎると、隣り合う点が同じ座標になったり、細いポリゴンがつぶれたり、線の形状が不自然になったりすることがあります。特に幅の狭い道路、細長い水路、建物外周、狭い管理区域などでは、丸めによって形状の意味が変わる可能性があります。
実務では、いきなり全データを丸めるのではなく、まず一部のデータで試すのがおすすめです。丸め前後のGeoJSONを地図上に重ねて表示し、境界や線形のずれを確認します。見た目の差が小さく、業務上の判断に影響しない範囲であれば、その桁数を採用できます。面積や延長を使う場合は、丸め前後で数値がどの程度変わるかも確認しておくと安心です。
また、GeoJSONでは座標の順序にも注意が必要です。標準的なGeoJSONでは、座標は経度、緯度の順で並びます。処理時に緯度と経度を取り違えると、まったく違う場所に表示されることがあります。座標を丸める処理を行う際は、値の順序を変えず、数値部分だけを適切に処理することが重要です。
小数点以下の丸めは、GeoJSON軽量化の第一歩として試しやすい方法です。形状の頂点数は変えずに文字数を減らせるため、比較的影響を確認しやすい方法です。特に、表示用GeoJSONや共有用GeoJSONを作る場合は、まず座標の桁数を見直すだけでも、扱いやすさが変わることがあります。
方法2 不要な頂点を間引いて形状を単純化する
座標の桁数を丸めてもまだGeoJSONが重い場合は、不要な頂点を間引いて形状を単純化する方法を検討します。線や面の形状は、多くの頂点によって表現されています。曲がりくねった道路や複雑な区域境界では、わずかな形状変化を表すために非常に多くの点が並んでいることがあります。
地図表示の縮尺によっては、細かな頂点の違いが画面上ではほとんど見えないことがあります。たとえば全国や市区町村全体を表示する用途では、数十センチ単位の凹凸は視覚的に意味を持たない場合があります。このようなときは、見た目に大きな影響を与えない範囲で頂点を減らすことで、GeoJSONを軽量化できます。
形状の単純化では、直線に近い部分の中間点を削除し、曲がり角や形状の特徴を表す点を残します。これにより、地物の大まかな形を保ちながら座標数を減らせます。座標の桁数を丸める方法が「数値を短くする」軽量化であるのに対し、頂点の間引きは「座標の個数を減らす」軽量化です。複雑な線や面では、こちらのほうが大きな効果を得られることがあります。
ただし、頂点の間引きは丸めよりも形状への影響が大きくなりやすいです。しきい値を大きくしすぎると、本来残すべき曲がり角が消えたり、区域の外周が簡略化されすぎたりします。道路や河川のような線データでは線形が粗くなり、面データでは境界が実際より内側または外側にずれることがあります。
特に注意が必要なのは、隣接するポリゴン同士の境界です。別々の地物として単純化すると、本来ぴったり接していた境界に隙間や重なりが生じることがあります。行政区域、区画境界、敷地分割、管理エリアのように、隣接関係そのものが重要なデータでは、単純化後のトポロジーを確認する必要があります。見た目ではわかりにくくても、面積集計や重なり判定に影響する場合があります。
実務で頂点を間引く場合は、用途別に複数の軽量版を作るのも有効です。たとえば、広域表示用には強めに単純化したGeoJSONを使い、詳細確認用には元データに近いGeoJSONを使うという運用です。地図の縮尺に応じて読み込むデータを変えれば、表示速度と精度の両方を確保しやすくなります。
また、単純化の前後で必ず確認したいのが、面の形状が壊れていないかどうかです。Polygonでは外周リングが閉じている必要があり、穴を持つ場合は内側のリングも正しく維持されている必要があります。単純化によってリングが自己交差したり、穴が消えたりすると、地図表示や空間処理でエラーの原因になります。利用するツールやシステムによっては、リングの向きや妥当性チェックの扱いも確認しておくと安全です。
頂点の間引きは、GeoJSONを軽くするうえで強力な方法です。しかし、強力である分だけ、精度や形状の妥当性を確認する工程が欠かせません。表示を速くしたいのか、概略図として使いたいのか、現地の判断材料として使いたいのかを明確にしたうえで、単純化の強さを調整することが大切です。
方法3 用途別に必要なジオメトリだけを残す
GeoJSONを軽量化する3つ目の方法は、用途に対して不要なジオメトリを削ることです。座標精度の調整というと、小数点以下の桁数や頂点数に目が向きがちですが、そもそも表示や処理に必要のない地物が含まれている場合、それらを除外するだけでも軽量化につながります。
GeoJSONには複数のFeatureをまとめて格納できます。便利な反面、業務の過程でさまざまな地物をひとつのファイルに詰め込みすぎてしまうことがあります。たとえば、点検対象の設備だけを表示したいのに、過去の調査地点、参考範囲、非表示予定の区域、古いルート、作業メモ用の線などが同じGeoJSONに残っているケースです。このようなデータは、地図表示のたびに読み込まれるため、画面に出さないとしても処理負荷になります。
実務では、まずGeoJSONの利用場面を分けて考えます。現場で現在地と対象設備だけを確認する画面、管理者が全体状況を見る画面、報告用に区域を表示する画面、分析用に詳細な境界を扱う作業など、それぞれ必要な地物は異なります。すべての用途に同じGeoJSONを使おうとすると、不要な情報まで毎回読み込むことになります。
点データ、線データ、面データを分けることも有効です。点だけを表示したい画面で複雑なPolygonまで読み込む必要はありません。逆に、区域の塗り分けだけが目的なら、詳細な点検履歴の点群を同じファイルに含める必要はないかもしれません。用途別にGeoJSONを分割することで、必要な場面で必要な分だけ読み込めるようになります。
また、表示範囲によってデータを分ける方法もあります。広い地域を一度に扱うGeoJSONでは、地物数が多くなりがちです。都道府県単位、市区町村単位、地区単位、現場単位など、実務の操作単位に合わせて分割しておけば、必要な範囲だけを読み込めます。現場担当者が自分の担当区域だけを扱う場合、全域のGeoJSONを持たせる必要はありません。
この方法のメリットは、座標そのものを変更しなくても軽量化できる点です。座標の丸めや頂点の間引きと違い、残した地物については精度を保てます。そのため、精度を落としたくない業務データでも取り組みやすい方法です。特に、対象外の地物が多く含まれているGeoJSONでは、不要データの整理だけで改善できる場合があります。
ただし、分割しすぎると管理が複雑になります。ファイル数が増え、どれが最新なのかわかりにくくなることがあります。そこで、ファイル名や更新ルールを統一し、用途、対象範囲、作成日、精度の違いがわかるようにしておくことが大切です。たとえば、表示用、現場確認用、保管用といった役割を明確にしておくと、誤って軽量版を正式な保管データとして使ってしまうリスクを減らせます。
GeoJSONの軽量化は、座標を削ることだけではありません。必要なデータだけを残すことも、実務では効果的です。特に「地図が重い」「読み込みに時間がかかる」という問題がある場合は、座標精度の前に、不要なFeatureや用途に合わないジオメトリが混在していないかを確認するとよいでしょう。
方法4 属性情報と座標情報を分けて整理する
4つ目の方法は、属性情報と座標情報を分けて整理することです。GeoJSONでは、各Featureにpropertiesとして属性情報を持たせることができます。名称、管理番号、種別、住所、作業状況、担当者、日付、備考など、地図上の地物に関する情報をまとめて入れられるため便利です。
しかし、GeoJSONが重くなる原因は座標だけではありません。propertiesの中に長いテキストや大量の項目が含まれていると、ファイルサイズが大きくなります。特に、地図表示には使わない詳細説明、過去の作業履歴、内部メモ、帳票用の文章、複数の判定結果、重複した名称などが各Featureに入っていると、地物数に比例して容量が増えます。
地図上で必要なのは、必ずしもすべての属性ではありません。表示に必要なのは、地物を識別するためのID、分類、ラベル、色分けに使う状態値などに限られることが多いです。詳細な情報は、地物を選択したときに別のデータから取得する形にすれば、GeoJSON自体を軽くできます。
たとえば、GeoJSONには地物ID、名称、種別、表示用ステータスだけを残し、詳細な点検記録や長い備考は別データで管理する方法があります。地図表示時は軽いGeoJSONを読み込み、必要な地物をクリックまたは選択したときに、そのIDをもとに詳細情報を参照します。この考え方にすると、初期表示を軽くし、利用者が必要とする情報だけを段階的に表示できます。
また、属性名を短く整理することも軽量化につながります。GeoJSONでは、properties内のキー名も文字として保存されます。同じ長い項目名が数千件のFeatureに繰り返し現れると、それだけで容量が増えます。実務上わかりやすい名前を保つことは大切ですが、表示用データでは必要以上に長い項目名を避けるとよいでしょう。
ただし、属性名を短くしすぎると、後から見たときに意味がわからなくなることがあります。したがって、内部管理用の項目定義を別途用意し、どの項目が何を表すのかを明確にしておくことが重要です。地図表示用のGeoJSONでは短い項目名を使い、管理資料では正式な項目名と対応づけるという運用にすれば、軽量化と可読性の両立がしやすくなります。
座標情報と属性情報を分けるときは、IDの管理が非常に重要です。GeoJSON側のFeatureと、外部で管理する詳細情報が正しく対応していなければ、別の地物の情報を表示してしまう恐れがあります。IDは一意で、途中で変わらないものにする必要があります。名称や住所のように変更される可能性がある値をID代わりに使うと、後から不整合が起きやすくなります。
この方法は、特に地物数が多いデータに向いています。数十件程度のGeoJSONでは効果が小さいかもしれませんが、数千件、数万件のFeatureを扱う場合は、属性情報の整理だけでも表示速度や通信量に影響することがあります。座標精度の調整とあわせて、propertiesの中身を見直すことで、より実用的な軽量化ができます。
GeoJSONを扱い始めたばかりの段階では、つい「すべての情報をひとつのファイルに入れておけば便利」と考えがちです。しかし、運用が進むほどデータは増え、ファイルは重くなります。長く使う業務データほど、座標と属性を分ける設計が重要になります。
軽量化するときに起きやすい失敗
GeoJSONの軽量化では、いくつかの典型的な失敗があります。まず多いのは、ファイルサイズだけを見て精度を落としすぎることです。軽くなったとしても、現地確認で使えない、境界がずれている、面積が変わりすぎている、線が本来のルートから外れて見えるという状態では、業務データとしての価値が下がってしまいます。
特に、現場で使うGeoJSONでは、画面表示の速さだけでなく、現地の位置と地図上の表示がどれだけ一致するかが重要です。スマートフォンやタブレットで現在地と対象物を照合する場合、座標を丸めすぎると、利用者が「地図がずれている」と感じる原因になります。軽量化の目的が現場作業の効率化であるなら、操作性と位置精度の両方を確認する必要があります。
次に多いのは、元データを上書きしてしまう失敗です。軽量化処理をしたGeoJSONをそのまま正式データとして保存してしまうと、後から高精度のデータに戻せません。特に頂点を間引いたデータは、削除した頂点を正確に復元できないことがあります。必ず元データを別に保管し、軽量化版は用途を明記して管理することが大切です。
また、複数人で作業している場合、どのGeoJSONが最新なのかわからなくなることもあります。表示用、編集用、保管用、提出用などの区別が曖昧だと、軽量化済みのデータをさらに編集してしまったり、古いデータを現場に配布してしまったりします。ファイルの役割と更新ルールを決めておくことは、軽量化の技術そのものと同じくらい重要です。
座標参照系の扱いを誤ることもあります。標準的なGeoJSONではWGS 84の経度・緯度を使いますが、元データが平面直角座標系やWebメルカトルなど別の座標参照系で管理されている場合、変換の過程で座標の意味を取り違えることがあります。座標値を調整する前に、対象データがどの座標参照系で表現されているかを確認する必要があります。座標変換と小数点以下の丸めを同時に行う場合は、変換後の位置が正しいかを地図上で確認します。
さらに、見た目だけで判断してしまうことも失敗につながります。地図上では問題なさそうに見えても、面の自己交差、リングの向き、隣接ポリゴンの隙間、重複などが発生している場合があります。特に面データを軽量化した後は、地図表示だけでなく、必要に応じて面積や重なりの確認も行うと安全です。
軽量化後の確認では、代表的な地点だけでなく、複雑な形状の部分、狭い部分、境界が入り組んでいる部分、重要な施設が密集している部分を重点的に見ることが大切です。単純な形状では問題が出なくても、複雑な形状で崩れることがあります。実務で使う前に、問題が起きやすい箇所を意図的に確認しておくことで、現場でのトラブルを減らせます。
GeoJSONの軽量化は便利ですが、データの意味を変えてしまう可能性があります。軽量化後に何を確認するかを決めずに作業すると、見落としが起きやすくなります。小数点以下の桁数、頂点数、地物数、属性情報、表示速度、位置ずれ、面積差など、確認項目をあらかじめ整理しておくことが重要です。
業務で使いやすいGeoJSON運用の進め方
GeoJSONを実務で使いやすくするには、軽量化を一度だけの作業として考えるのではなく、運用の流れに組み込むことが大切です。データを作る人、確認する人、現場で使う人、報告書に使う人がそれぞれ異なる場合、誰にとっても扱いやすい形に整える必要があります。
まず、元データと利用データを分ける考え方を持ちます。元データはできるだけ高い精度で保管し、編集や再利用に備えます。一方、地図表示や共有に使うGeoJSONは、用途に合わせて軽量化します。この2種類を明確に分けることで、表示速度を改善しながら、必要なときには高精度データに戻れる状態を保てます。
次に、用途ごとの精度基準を決めます。たとえば、概略表示用は小数点以下5桁から6桁、現場確認用は小数点以下6桁から7桁、分析や記録用は元データに近い精度を保つ、といった考え方です。実際の基準は業務内容によって異なりますが、担当者ごとに判断がばらつかないように、社内やプロジェクト内で目安を共有しておくとよいでしょう。
また、データ量が多い場合は、縮尺別や範囲別のGeoJSONを用意することも効果的です。広域表示では簡略化したデータを使い、拡大したときに詳細データを表示する構成にすれば、利用者は快適に操作できます。現場作業では、担当エリアだけを端末に入れておくことで、通信量や読み込み時間を抑えられます。
属性情報についても、表示用と管理用を分けると運用しやすくなります。表示用GeoJSONには地図上で必要な最小限の属性だけを残し、詳細な履歴や帳票用の情報は別で管理します。これにより、初期表示を軽くしつつ、必要な情報には後からアクセスできます。地物IDを共通キーとして管理すれば、座標データと詳細情報を結びつけられます。
現場で使う場合は、軽量化後のGeoJSONを実際の利用環境で試すことも重要です。事務所の高速な通信環境では問題なく表示できても、現地では通信が不安定だったり、端末の性能が限られていたりすることがあります。現場に近い条件で読み込み時間、操作感、現在地との重なり、拡大縮小時の表示を確認しておくと、実運用での不満を減らせます。
さらに、更新作業の流れも決めておく必要があります。GeoJSONは一度作って終わりではなく、設備の追加、区域の変更、点検結果の更新、工事範囲の変更などに応じて更新されます。そのたびに手作業で軽量化すると、ミスや作業漏れが起きやすくなります。可能であれば、元データから表示用GeoJSONを生成する手順を決め、同じ条件で再作成できるようにしておくと安定します。
命名ルールも地味ですが重要です。軽量化前後のファイルが混在する場合、ファイル名だけで用途や精度がわかるようにしておくと、誤用を防げます。たとえば、保管用、表示用、現場用、広域用、詳細用などの区分がわかる名前にします。更新日や対象範囲も含めると、関係者が迷わず使えます。
GeoJSONの使い方を実務に定着させるには、技術的な処理だけでなく、判断基準と運用ルールが必要です。どの程度軽くするか、どの精度を残すか、誰が確認するか、どこに保存するかを決めておくことで、GeoJSONは単なる地図データではなく、業務で継続的に活用できる情報基盤になります。
まとめ
GeoJSONは、位置情報を扱う実務で便利な形式です。点、線、面を属性情報と一緒に扱えるため、地図表示、現地調査、設備管理、区域管理、作業範囲の共有など、さまざまな場面で活用できます。その一方で、座標の桁数が多すぎたり、頂点数が膨大だったり、不要な地物や属性情報を含みすぎたりすると、ファイルが重くなり、表示や共有に支障が出ます。
GeoJSONの座標値を調整して軽量化する方法として、まず取り組みやすいのは小数点以下の桁数を丸めることです。形状の頂点数を変えずに文字数を減らせるため、比較的影響を確認しやすい方法です。次に、複雑な線や面では、不要な頂点を間引いて形状を単純化する方法が有効です。ただし、形状の崩れや境界のずれが起きないように、軽量化後の確認が欠かせません。
さらに、用途別に必要なジオメトリだけを残すことも重要です。すべての地物をひとつのGeoJSONに詰め込むのではなく、点、線、面、対象範囲、利用場面ごとに整理することで、読み込みや表示を軽くできます。加えて、propertiesに含まれる属性情報を見直し、表示に必要な最小限の情報だけをGeoJSONに残すことで、さらに扱いやすいデータになります。
軽量化で大切なのは、ファイルサイズを小さくすることだけを目的にしないことです。現場で使うのか、概略図として見せるのか、分析や記録に使うのかによって、必要な精度は異なります。元データは高精度のまま保管し、表示用や共有用には用途に合わせた軽量版を作るという考え方が、実務では安全で効率的です。
GeoJSONを適切に軽量化できると、地図の表示が速くなり、共有しやすくなり、現場での確認作業もスムーズになります。特に、スマートフォンやタブレットを使って現地で位置を確認する業務では、データの軽さと必要な位置精度のバランスが作業効率に関わります。まずは元データを保管したうえで、用途ごとの許容誤差を決め、丸め、単純化、分割、属性整理を段階的に試すことから始めるとよいでしょう。