GeoJSONを現場記録、点検結果、施工範囲、管理区域、ルート情報などの共有に使っていると、最初は扱いやすかったデータが、いつの間にか重く、見づらく、修正しにくい状態になることがあります。特に負担になりやすいのが、coordinatesに大量の座標が並んでいるケースです。点、線、面の情報を正しく残すためには座標配列が必要ですが、座標点が多すぎると、表示が遅くなったり、ファイル容量が大きくなったり、編集時にどこを直しているのか分かりにくくなったりします。
GeoJSONは構造が比較的シンプルな形式ですが、シンプルだからこそ、座標配列の増え方を放置すると管理しづらくなります。この記事では、geojsonで検索する実務担当者に向けて、整理前に確認すべき見極めと、座標配列が多すぎる時に使いやすい5つの整理方法を解説します。単に点を減らすだけではなく、精度、再利用性、共有しやすさ、更新しやすさを保ちながら整える考え方を扱います。
整理前に座標配列が多すぎる状態を見極める
GeoJSONの座標配列を整理する前に、まず確認したいのは、本当に座標点が多すぎるのか、それとも必要な情報として多くなっているだけなのかという点です。座標配列が長いという理由だけで機械的に削減すると、境界線、道路線形、点検ルート、施工範囲などの意味が変わってしまうことがあります。整理の目的は、データを軽くすることだけではありません。実務で扱いやすくしながら、必要な形状情報を残すことが重要です。
GeoJSONでは、Point、LineString、Polygon、MultiPoint、MultiLineString、MultiPolygonなどの形状ごとにcoordinatesの構造が異なります。Pointであれば座標の組は基本的に一つですが、LineStringでは線を構成する複数の座標が並びます。Polygonでは外周線や穴を表すために、さらに配列が入れ子になります。Multi系の形状では、複数の線や面が一つのGeometry内にまとまるため、見た目以上に座標配列が長くなることがあります。まずは、どのGeometry typeで座標が増えているのかを確認することが出発点です。
座標配列が多すぎると感じる場面には、いくつかの典型があります。地図上で表示した時に線や面の表示が遅い、ファイルを開くまでに時間がかかる、共有時に容量が大きくて扱いにくい、テキストとして確認した時に全体構造が追いづらい、修正箇所を探すだけで時間がかかる、といった状態です。これらは座標点数だけが原因とは限りませんが、座標配列が肥大化している場合には、整理によって改善できる可能性があります。
一方で、座標点が多いこと自体に意味がある場合もあります。曲線に近い形状を細かく表している場合、複雑な境界を正確に残している場合、現地で取得した軌跡を時系列に近い形で保存している場合などです。このようなデータを単純に軽量化すると、後から検証できる情報が失われることがあります。したがって、整理前には、対象データが表示用なのか、記録用なのか、計算用なのか、共有用なのかを分けて考える必要があります。
表示用のGeoJSONであれば、多少の簡略化を行っても利用目的に合う場合があります。たとえば、広域地図で施工範囲の概略を見せるだけなら、細かい凹凸まで保持する必要はないかもしれません。一方、現地確認や境界確認に使うデータであれば、わずかな座標のずれが判断に影響することもあります。この違いを整理せずに、すべてのGeoJSONを同じ基準で軽くしようとすると、実務上のトラブルにつながりやすくなります。
座標配列が多すぎるかどうかを判断する際は、点数、容量、表示速度、編集性、利用目的の5つをセットで見ると整理しやすくなります。点数が多くても表示や共有に問題がなければ、急いで減らす必要はありません。逆に、点数はそれほど多くなくても、Polygonが複雑に入れ子になっていて編集ミスが起きやすいなら、構造を整理したほうがよい場合があります。見た目の長さだけではなく、運用上の負担を基準に判断することが大切です。
また、GeoJSONは人が読めるテキスト形式である一方、座標配列が長くなると目視確認の利点が薄れます。coordinatesの閉じ括弧がどこに対応しているのか分かりにくくなり、FeatureCollection全体の構造も追いにくくなります。特に複数人で管理する場合、担当者ごとに編集方法が異なると、座標配列の順序や桁数、改行の入れ方がばらつきます。その結果、差分確認や修正内容の把握が難しくなります。
整理に入る前の段階では、元データを複製しておくことも欠かせません。座標配列の削減や分割は、元に戻しにくい作業になることがあります。表示用に簡略化したデータと、現地取得時の元データを同じものとして扱うと、後から根拠を確認したい時に困ります。したがって、座標配列の整理は、元データを保全したうえで、利用目的に合わせた派生データを作る作業として捉えると安全です。
形状の目的に合わせて座標点を間引く
座標配列が多すぎる時に最も分かりやすい整理方法は、不要な座標点を間引くことです。ただし、ここでいう間引きは、単純に一定間隔で座標を削除することではありません。線や面の意味を保ちながら、表示や共有に必要な精度へ調整する作業です。GeoJSONでは、LineStringやPolygonの座標点が多いほど、形状を細かく表現できますが、そのぶんファイル容量や処理負荷も増えます。目的に合わない細かさになっている場合は、座標点を整理する効果が大きくなります。
たとえば、現地で取得した移動軌跡をそのままLineStringにした場合、短い距離の中に非常に多くの座標点が含まれることがあります。歩行や車両移動の揺れ、停止時の微小な位置変化、不要な折り返しなどがそのまま残ると、実際に見せたいルートよりも細かなブレが目立つことがあります。点検経路の概略を共有する用途であれば、細かな揺れをすべて残すより、ルートとして意味のある曲がり角や分岐点を残したほうが分かりやすくなります。
Polygonでも同じです。施工範囲や管理区域を示す面データで、外周の細かな凹凸まで座標化されている場合、広域表示ではほとんど見えない部分が大量の座標として残ることがあります。もちろん、境界確認や数量計算に使う場合は慎重な扱いが必要ですが、概要図や共有用の地図に載せるだけなら、細部を簡略化したデータを別に用意する考え方が有効です。重要なのは、元の面積や形状の印象を大きく変えない範囲で整理することです。
座標点を間引く際には、どの点が形状の特徴を支えているかを見る必要があります。直線に近い部分に多数の点が並んでいる場合、途中の点を減らしても形状の見え方はあまり変わりません。一方、角、折れ点、曲線の変化点、交差部、接続部などは、少ない点数でも形状の意味を決める重要な部分です。これらを不用意に削ると、線が別の位置を通っているように見えたり、面の外周が本来より内側または外側に変わったりします。
また、Polygonでは各リングが閉じた線として扱える状態になっている必要があります。座標点を整理する時に、外周線の最後の座標を誤って削除したり、始点と終点が対応しない状態にしたりすると、面として扱えないデータになることがあります。穴を持つPolygonでは、外周リングと内側リングを混同しないことも大切です。座標配列が多い時ほど、どの配列が外周で、どの配列が内側の穴なのかを確認しながら作業する必要があります。
間引きの基準は、利用する縮尺や表示範囲によって変わります。狭い範囲で詳細確認を行うデータと、広い範囲で全体把握を行うデータでは、必要な座標密度が違います。広域表示では、画面上で判別できない細部を削っても支障が少ない場合がありますが、近距離で確認するデータでは、同じ削減率でも影響が大きくなります。したがって、座標点の整理は一律の割合で行うのではなく、用途別に許容できる粗さを決めることが実務上は安全です。
座標を間引いた後は、必ず表示確認を行います。テキスト上で座標数が減っていても、地図上で形状が崩れていれば意味がありません。整理前と整理後を同じ範囲、同じ縮尺で見比べ、線の通り方、面の外周、隣接データとの重なり、接続部のずれを確認します。特に道路沿い、敷地境界付近、構造物周辺、点検対象物の近くでは、わずかな変化が誤解につながることがあります。表示速度だけで判断せず、形状の意味が保たれているかを確認することが欠かせません。
間引きは、元データを壊さずに別ファイルとして行うのが基本です。たとえば、記録用のGeoJSON、編集用のGeoJSON、表示用のGeoJSONを分けると、精度と軽さを両立しやすくなります。表示用だけを軽くしたいのに元データを直接編集してしまうと、後から詳細な位置情報が必要になった時に戻せません。座標配列を減らす作業は便利ですが、削除した座標は情報として失われるため、目的ごとのデータ管理が重要になります。
Featureを分割して管理単位を小さくする
座標配列が多すぎる原因は、一つのGeometryに座標を詰め込みすぎていることにある場合があります。特に長いLineStringや大きなPolygon、複数の区域をまとめたMultiPolygonでは、一つのFeatureが非常に大きくなり、編集や確認が難しくなります。このような時は、座標点を減らすだけでなく、Featureそのものを分割して管理単位を小さくする方法が有効です。
たとえば、点検ルートを一つのLineStringとして全区間つなげている場合、どこか一部を修正するだけでも長い座標配列の中から該当箇所を探さなければなりません。区間ごと、日付ごと、担当範囲ごと、路線ごとにFeatureを分けておけば、修正対象が見つけやすくなります。データ全体の座標数は同じでも、一つひとつのFeatureが短くなることで、編集性と確認性は大きく改善します。
Polygonでも、離れた複数の管理区域を一つのMultiPolygonにまとめるより、区域ごとにFeatureを分けたほうが扱いやすいことがあります。MultiPolygonは、複数の面を一つのGeometryとして表せる構造ですが、実務上は各区域に別々の名称、管理番号、点検日、担当者、状態区分を持たせたい場面が多くあります。その場合、一つのFeatureにまとめてしまうと、属性情報を細かく付けにくくなります。座標配列を整理するだけでなく、情報の単位としてFeatureを見直すことが大切です。
Featureを分割する時は、どの単位で管理すると後から探しやすいかを考えます。施工範囲なら工区、点検記録なら対象物、ルートなら区間、管理区域ならエリア、調査結果なら調査日や調査班などが候補になります。分割単位が細かすぎるとFeature数が増えすぎて別の管理負担が出ますが、大きすぎると座標配列が肥大化して修正が難しくなります。実務では、地図上で選択した時に意味のあるまとまりとして理解できる単位が目安になります。
分割のメリットは、座標配列が短くなることだけではありません。属性情報を整理しやすくなる点も重要です。GeoJSONでは、Featureごとにpropertiesを持たせることができます。Featureを適切に分けると、各形状に対して名称、分類、状態、作成日、更新日、担当、備考などを対応させやすくなります。逆に、一つのFeatureに複数の意味を持つ形状を詰め込むと、propertiesが曖昧になり、後から検索や絞り込みを行いにくくなります。
ただし、Featureを分割する時には、線や面の接続関係に注意が必要です。連続した線を区間ごとに分ける場合、区間の端点がずれていると、地図上ではわずかな隙間や重なりが生じることがあります。面を分割する場合も、隣接する境界が一致していないと、重複や隙間が発生する可能性があります。座標配列を短くするための分割であっても、空間的な整合性を崩さないように確認する必要があります。
Feature分割後は、idやpropertiesの命名ルールもそろえると管理が楽になります。たとえば、区間番号、エリア名、日付、分類などを一定の形式で持たせると、後から検索や並べ替えがしやすくなります。座標配列の整理と属性の整理を同時に行うことで、単に軽いGeoJSONではなく、実務で再利用しやすいGeoJSONになります。特に複数人で扱うデータでは、Featureごとの意味が明確であることが品質管理につながります。
また、分割したGeoJSONを一つのFeatureCollectionとしてまとめるか、用途別に複数ファイルへ分けるかも検討します。すべてを一つのファイルにまとめると共有は簡単ですが、ファイルが大きくなりすぎる場合があります。用途別、範囲別、期間別にファイルを分けると、必要な部分だけを読み込めるため、表示や編集の負担を抑えられます。ただし、ファイルが増えすぎると管理が煩雑になるため、フォルダ構成やファイル名のルールもあわせて決めておくと安心です。
属性情報と座標情報の役割を分ける
座標配列が多すぎるGeoJSONを確認すると、本来は属性情報として持てばよい内容まで、形状や座標で表現しようとしているケースがあります。GeoJSONは地理形状と属性情報を一緒に扱える形式です。coordinatesは位置や形状を表すためのものであり、propertiesは名称、分類、状態、説明、管理番号などを表すためのものです。この役割分担が曖昧になると、座標配列が必要以上に複雑になります。
たとえば、同じ点検対象に対して状態の違いを線の細かい分割だけで表現しようとすると、LineStringが不自然に細かく分かれたり、似たような座標配列が何度も登場したりすることがあります。本来は一つの区間として扱える形状に対して、状態区分をpropertiesに持たせれば、座標配列を増やさずに情報を整理できます。形状で表すべきものと、属性で表すべきものを分けるだけで、GeoJSON全体が見通しやすくなります。
Polygonでも、管理区域の種類、確認状況、作業予定、優先度などを面の形状で無理に分ける必要がない場合があります。もちろん、実際に範囲が異なるなら別のPolygonとして表す必要がありますが、同じ範囲に対する状態や説明であれば、propertiesに記録したほうが簡潔です。座標配列は位置と形状の根拠であり、説明文や分類情報まで座標構造に押し込むと、更新時に余計な手間が発生します。
属性情報を活用する時は、propertiesの項目名を分かりやすく統一することが重要です。担当者ごとにname、title、label、area_nameのように似た意味の項目が混在すると、後から利用する時に迷います。GeoJSON自体はpropertiesの中身を自由に決められるため便利ですが、自由度が高い分、運用ルールがないとばらつきやすくなります。座標配列を整理するタイミングで、propertiesの項目も見直すと、データ全体の品質が上がります。
座標配列を減らしたい時には、重複している形状がないかも確認します。同じ地点や同じ線形を、目的別に何度も別Featureとして保存している場合、propertiesの持たせ方を工夫することで重複を減らせることがあります。たとえば、同じ管理区間に複数の確認結果を持たせたい場合、確認結果を別ファイルや別の属性構造で管理する方法もあります。ただし、一つのFeatureに履歴情報を詰め込みすぎると別の見づらさが出るため、現在表示したい情報と履歴として残したい情報を分ける考え方が必要です。
また、座標配列が多く見える原因として、不要な高さ情報が含まれている場合もあります。標準的なGeoJSONでは、位置は経度、緯度の順で扱い、必要に応じて3つ目の値として高さや標高を含めることがあります。しかし、実務上高さを使わないデータで毎回3つ目の値が入っていると、ファイル容量や見た目の複雑さが増します。高さ情報が本当に必要か、表示用データでは省略できるか、あるいは別の属性として管理したほうが分かりやすいかを確認するとよいです。
一方で、時刻、精度、取得方法、点検者、計測機器などの情報は、座標配列へ無理に含めるより、propertiesや別データとして管理するほうが扱いやすい場合が多くあります。現地記録として意味を持つ情報であれば、単に表示を軽くするために削除するのではなく、どこに残すかを決めることが重要です。表示用のGeoJSONでは省略し、元データや記録用データでは保持するという分け方が現実的です。
属性情報と座標情報を分けることは、将来の更新にも効きます。座標を修正しなくても属性だけを更新できる状態であれば、作業ミスを減らせます。逆に、状態変更のたびに座標配列まで触る運用になっていると、関係ない形状まで壊してしまう可能性があります。GeoJSONを実務で長く使うなら、coordinatesはなるべく安定した形状情報として扱い、変わりやすい情報はpropertiesや別管理に回す設計が扱いやすいです。
座標桁数と形式をそろえて読みやすくする
GeoJSONの座標配列が多すぎると感じる時、座標点の数だけでなく、座標値の桁数や表記のばらつきが見づらさを増やしていることがあります。座標値に必要以上の小数桁が並んでいると、同じ点数でもファイル全体が長く見えます。また、桁数がFeatureごとにばらばらだと、差分確認や目視確認がしにくくなります。座標配列を整理する際には、点数の削減だけでなく、座標表記の統一も重要です。
標準的なGeoJSONとして地図サービスやGISで共有する場合、座標は経度、緯度の順で扱うことを前提にします。実務では緯度、経度の順に慣れている人も多いため、変換や手入力の際に順序を取り違えるミスが起きやすくなります。座標配列が大量にあると、一つひとつを目視で確認することは難しくなります。だからこそ、整理の段階で座標順序を統一し、propertiesやファイル名、管理メモなどにも座標系や作成条件を残しておくことが有効です。
小数桁数については、目的に応じた精度を考える必要があります。桁数を減らせばファイルは軽くなり、見た目もすっきりしますが、位置の精度も変わります。逆に、必要以上に細かい桁数を残しても、利用目的によっては実質的な意味が少なく、管理負担だけが増えることがあります。たとえば、広域表示用の概略データと、現地確認用の詳細データでは、求める精度が異なります。どの用途で使うGeoJSONなのかを決めてから、桁数を調整することが大切です。
桁数をそろえる時には、すべての座標を同じ丸め方で処理することが重要です。一部だけ手作業で丸めたり、Featureごとに異なる基準で変換したりすると、隣接する線や面の端点がわずかにずれることがあります。特に、複数のPolygonが境界を共有している場合、片方だけ丸め方が違うと、重なりや隙間が発生することがあります。座標配列の整理は、見た目を整えるだけではなく、空間的な整合性を保つ作業でもあります。
形式の統一では、改行やインデントも実務上の読みやすさに影響します。GeoJSONは機械処理しやすい形式ですが、人が確認する場面も少なくありません。座標配列が長い場合、一行に詰め込むと全体が追いにくくなります。一方、すべての座標を細かく改行すると、ファイルの行数が非常に多くなり、別の意味で扱いづらくなることもあります。確認用、保管用、受け渡し用で整形の仕方を変える考え方もあります。
ただし、整形によって中身の意味が変わるわけではありません。改行や空白を整理しても、座標点数や形状そのものが変わらなければ、表示負荷の改善は限定的です。見やすさの改善と、データ量の削減は分けて考える必要があります。座標配列が多すぎて編集しづらいだけなら整形が有効ですが、表示や読み込みが重い場合は、座標点の間引き、Feature分割、ファイル分割などもあわせて検討する必要があります。
また、座標形式の変換時には、座標系の取り違えに注意します。標準的なGeoJSONとして外部共有する場合は、経度緯度の座標を前提にしたほうが互換性を保ちやすくなります。一方、社内処理や変換前データでは、平面直角座標系やローカル座標の値を扱っている場合もあります。元データの座標系を確認せずにGeoJSONへ変換すると、地図上で位置が大きくずれることがあります。座標配列を整理する時は、桁数や点数だけでなく、どの座標系を前提にしたデータなのかを確認することが欠かせません。
表記をそろえることは、差分確認にも役立ちます。座標桁数や整形ルールがばらばらだと、実際には少ししか変更していないのに、ファイル全体が大きく変わったように見えることがあります。逆に、桁数、項目順、改行ルールがそろっていれば、どのFeatureのどの座標が変わったのかを追いやすくなります。複数人でGeoJSONを更新する現場では、見た目の統一がそのまま確認作業の効率につながります。
更新前の元データと整理後データを分けて残す
座標配列を整理する時に最も避けたいのは、元データを上書きしてしまい、後から確認できなくなることです。GeoJSONの座標配列を間引く、桁数を丸める、Featureを分割する、属性構成を変えるといった作業は、便利である一方、元の情報を失う可能性があります。表示用には十分でも、後から詳細確認や再計算が必要になった時に、整理後データだけでは根拠が足りないことがあります。
そのため、座標配列が多すぎるGeoJSONを整理する場合は、更新前の元データ、作業中の編集データ、公開または共有用の整理後データを分けて残す運用が安全です。元データは、現地取得時点や受領時点の状態を保管するものです。編集データは、不要点の確認、Feature分割、属性整理などを行う作業用です。整理後データは、利用目的に合わせて軽量化したり、見やすく整えたりしたものです。この区別があるだけで、後からの説明や再作成がしやすくなります。
ファイル名にも、整理の段階が分かる情報を入れておくと便利です。たとえば、作成日、対象範囲、用途、版数、整理済みであることを示す語などを一定の順序で付けると、どれが最新で、どれが元データなのかを判断しやすくなります。名前の付け方が担当者ごとに違うと、座標配列を整理したつもりでも、古いファイルを再利用してしまったり、未整理のファイルを共有してしまったりすることがあります。
整理作業の内容を記録しておくことも重要です。どの範囲の座標点を減らしたのか、どの基準で桁数を丸めたのか、どのFeatureを分割したのか、どのpropertiesを変更したのかが分からないと、後から品質確認がしにくくなります。長い説明でなくても、整理日、作業者、整理目的、主な変更点、元ファイル名が分かれば、再確認の手がかりになります。GeoJSONの中に管理用の属性を持たせる方法もありますが、共有先によっては不要な情報になるため、別の管理メモとして残す方法も考えられます。
整理前後の比較も欠かせません。座標点数が減った、ファイル容量が小さくなった、表示が軽くなったという確認だけでは不十分です。線が本来のルートから外れていないか、面の外周が大きく変わっていないか、穴や内側リングが消えていないか、Featureの属性が入れ替わっていないかを確認します。特にPolygonの整理では、閉じた構造が保たれているか、隣接する面との関係が崩れていないかを見る必要があります。
複数人で作業する場合は、誰がどの段階のデータを編集してよいのかを決めておくと安全です。元データは原則として編集しない、作業用データで整理を行う、共有用データは確認後に出す、という流れを徹底するだけでも、誤更新を減らせます。GeoJSONはテキストとして簡単に開けるため、ちょっとした修正を直接行いやすい形式です。しかし、その手軽さが原因で、どの版が正しいか分からなくなることもあります。運用ルールを決めておくことが、座標配列の整理を継続しやすくします。
また、整理後データだけを見て判断しないことも大切です。表示用に軽量化したGeoJSONは、見やすさを優先している場合があります。そのデータをもとに詳細な位置判断や数量判断を行うと、意図しない誤差が入り込むことがあります。整理後データには、用途を明示する情報を持たせると安全です。たとえば、概略表示用、共有確認用、編集用、記録保管用といった用途が分かれば、利用者が誤った目的で使うリスクを下げられます。
座標配列の整理は、一度行って終わりではありません。現場の記録が増える、点検範囲が広がる、管理対象が増える、過去データを統合する、といったタイミングで再び座標配列は増えていきます。最初に元データと整理後データの分け方を決めておけば、データが増えた時にも同じ考え方で対応できます。逆に、都度その場の判断で整理していると、ファイルごとに精度や構造がばらつき、後から統合しにくくなります。
まとめ
GeoJSONの座標配列が多すぎる時は、単純に座標点を減らすだけではなく、なぜ多くなっているのかを見極めることが大切です。表示用として細かすぎるのか、現地記録として必要な細かさなのか、一つのFeatureに詰め込みすぎているのか、属性で管理すべき情報まで座標で表そうとしているのかによって、取るべき整理方法は変わります。GeoJSONは構造が分かりやすい反面、運用ルールがないまま使い続けると、coordinatesが肥大化し、編集や共有の負担が増えやすい形式でもあります。
まずは、座標配列が多すぎる状態を、点数、容量、表示速度、編集性、利用目的の面から確認します。そのうえで、用途に応じて座標点を間引き、必要に応じてFeatureを分割し、propertiesで管理できる情報は属性として整理します。さらに、座標桁数や表記形式をそろえ、元データと整理後データを分けて残すことで、軽さと信頼性を両立しやすくなります。特に実務では、後から説明できること、再確認できること、他の担当者が迷わず扱えることが重要です。
GeoJSONの整理で気を付けたいのは、軽量化と正確性を対立させないことです。すべてのデータを重いまま残せば安全というわけではなく、共有や表示に支障が出れば実務では使いにくくなります。一方で、軽くすることだけを優先して元の位置情報を失うと、記録としての価値が下がります。記録用、編集用、表示用、共有用といった目的ごとのデータを分け、必要な精度を保ちながら扱いやすくすることが、GeoJSON運用の現実的な整理方針です。
現場で取得した位置情報をGeoJSONとして扱う場合は、取得段階から整理しやすい形を意識しておくと、後工程の負担を減らせます。点検対象、ルート、範囲、写真記録などを位置情報と結び付けて管理するなら、取得時点で座標の意味や属性をそろえておくことが重要です。使用するアプリや測位機器、変換ツールがどの座標系、座標順序、桁数、属性形式で出力するのかを確認し、元データを残したうえで用途別にGeoJSONを整理すると、共有後の誤解や手戻りを抑えやすくなります。