GeoJSONの使い方を調べていると、Point、LineString、Polygonだけでなく、GeometryCollectionという形式に出会うことがあります。GeometryCollectionは、複数のジオメトリを1つのgeometryとしてまとめられる形式です。たとえば、1つの点、1本の線、1つの面を同じジオメトリ要素の中に入れたい場合に使えます。
一方で、実務で安易に使うと、地図表示、属性管理、検索、編集、データ変換、検査作業で扱いにくくなることがあります。GeoJSONは見た目だけでなく、運用設計も重要なデータ形式です。GeometryCollectionは「複数の形状を入れられるから便利」と考えるだけで使うと、あとから修正しにくいデータになりやすい点に注意が必要です。
この記事では、geojson 使い方を調べている実務担当者に向けて、GeometryCollectionを使う前に確認したい5つの注意点を整理します。
GeometryCollectionの役割をFeatureCollectionと混同しない
GeometryCollectionを使う前に最初に確認したいのは、GeometryCollectionが何をまとめるための形式なのかという点です。GeoJSONには、Point、MultiPoint、LineString、MultiLineString、Polygon、MultiPolygon、GeometryCollectionなどのジオメトリ型があります。これらは、地物の形そのものを表すための種類です。
GeometryCollectionは、その名前のとおり、複数のジオメトリを1つのジオメトリとしてまとめるための型です。たとえば、1つのデータの中にPointとLineStringを同時に含めることができます。さらに、Polygonを含めることもできます。つまり、点、線、面のように性質の異なる形状を、同じジオメトリ要素の中に入れられる形式です。
ここで混同しやすいのが、FeatureCollectionです。FeatureCollectionは、複数のFeatureをまとめるための形式です。Featureは、geometryとpropertiesを持つ単位です。geometryには形状を入れ、propertiesには名称、管理番号、点検日、状態、分類などの属性情報を入れます。つまり、FeatureCollectionは複数の地物を束ねる器であり、GeometryCollectionは1つのgeometry内で複数の形状を束ねる器です。
実務でよくある誤解は、「点と線と面をまとめたいからGeometryCollectionにする」という判断です。たしかに形式としては可能ですが、業務データとしては必ずしも最適とは限りません。点検記録、道路施設、境界確認、設備管理、施工範囲、調査結果などでは、点、線、面それぞれに別の属性や管理単位が必要になることが多いためです。この場合、GeometryCollectionに押し込むよりも、FeatureCollectionの中に複数のFeatureを作り、それぞれのFeatureに適切なgeometryとpropertiesを持たせたほうが管理しやすくなります。
たとえば、ある現場の点検対象として、設備位置をPoint、点検ルートをLineString、作業範囲をPolygonで表したいとします。この3つをGeometryCollectionに入れると、1つのgeometryとしてはまとまります。しかし、設備位置の点検結果、ルートの通行可否、作業範囲の管理区分を別々に記録したい場合、属性をどこに持たせるかが難しくなります。GeometryCollection内の個々のジオメトリは、通常のFeatureのように個別のpropertiesを直接持つ構造ではありません。そのため、どの形状にどの属性が対応するのかを、別のルールで管理しなければならなくなります。
一方、FeatureCollectionであれば、設備位置のFeature、点検ルートのFeature、作業範囲のFeatureを分けて作れます。それぞれのFeatureに管理番号、名称、種別、確認日、担当者、状態などを持たせることができます。後から検索、抽出、色分け、編集、集計を行う場合も、Feature単位で処理しやすくなります。
GeometryCollectionは、複数の形状を1つの地物として扱う必要がある場合に向いています。たとえば、1つの対象物を表すために点と線を組み合わせる必要があり、それらが常に一体として扱われる場合です。ただし、そのような場面でも、本当にGeometryCollectionでなければならないかを確認することが重要です。単に「複数の図形を1つのファイルに入れたい」という目的であれば、FeatureCollectionで十分なことが多いからです。
GeoJSONの使い方では、データをどう表示するかだけでなく、どう更新し、どう検索し、どう引き継ぐかまで考える必要があります。GeometryCollectionは表現力のある型ですが、管理単位を曖昧にしやすい型でもあります。まずは、まとめたいものが「複数のFeature」なのか、「1つのFeature内の複数ジオメトリ」なのかを整理してから使うことが大切です。
属性をどこに持たせるかを先に決める
GeometryCollectionで特に問題になりやすいのが、属性情報の扱いです。GeoJSONでは、属性情報は基本的にFeatureのpropertiesに持たせます。Point、LineString、Polygonなどのgeometryそのものは、形状を表す部分であり、名称や状態、点検結果などの業務情報を直接持つ場所ではありません。
GeometryCollectionもgeometryの一種です。そのため、GeometryCollectionの中に入っているPointやLineStringやPolygonは、個別のpropertiesを持つFeatureではありません。ここを理解しないまま使うと、あとから「この点は何を意味するのか」「この線の管理番号はどれか」「この面の状態はどこに書くのか」という問題が起きます。
たとえば、1つのGeometryCollectionに、設備の位置を表すPoint、配線経路を表すLineString、管理区域を表すPolygonを入れたとします。Featureのpropertiesには、対象名や点検日を入れることはできます。しかし、そのpropertiesはGeometryCollection全体に対する属性です。中に入っているPointだけの属性、LineStringだけの属性、Polygonだけの属性を自然に分けて持たせる構造ではありません。
もちろん、propertiesの中に独自の配列や識別子を作り、GeometryCollection内のジオメトリの順番と対応させる方法は考えられます。たとえば、1番目のジオメトリは設備位置、2番目は経路、3番目は範囲というように、別途ルールを決めることは可能です。しかし、この方法は実務では慎重に扱う必要があります。順番が変わったとき、データを編集したとき、変換処理を行ったときに、対応関係が崩れるおそれがあるためです。
属性と形状の対応関係が崩れると、地図上では正しく見えていても、管理データとしては危険です。点検結果が別の形状に紐づいたり、範囲情報が経路情報として扱われたりする可能性があります。特に、複数人でデータを更新する場合や、外部のシステムへ受け渡す場合は、独自ルールに依存した構造ほど説明や検証の手間が増えます。
実務で扱いやすいのは、属性が必要な単位ごとにFeatureを分ける方法です。設備位置には設備位置のFeature、経路には経路のFeature、範囲には範囲のFeatureを作り、それぞれにpropertiesを持たせます。この構造であれば、データを見た人が、どの属性がどの形状に対応しているかを理解しやすくなります。検索条件も作りやすく、地図表示で色分けする場合も処理が単純になります。
GeometryCollectionを使う場合は、全体に対する属性だけで十分かどうかを確認しましょう。たとえば、複数の形状がすべて同じ対象物を構成しており、個別の属性を分ける必要がない場合は、GeometryCollectionでも運用できる可能性があります。逆に、形状ごとに種別、状態、担当、更新日、備考などを分けたい場合は、GeometryCollectionではなくFeatureを分けるほうが安全です。
属性設計では、現在必要な情報だけで判断しないことも大切です。最初は名称と種別だけで足りるように見えても、運用が始まると点検履歴、更新履歴、異常区分、写真番号、承認状態などを追加したくなることがあります。そのときにGeometryCollectionの中で形状単位の属性管理を始めると、構造が複雑になりがちです。
GeoJSONの使い方で失敗しないためには、形状のまとめ方よりも先に、属性の持たせ方を決めることが重要です。GeometryCollectionは形状をまとめる機能であって、属性を細かく分けて管理するための機能ではありません。後工程での検索、集計、点検、修正、共有を想定し、属性が必要な単位とgeometryの単位をそろえることが、扱いやすいGeoJSONを作る基本になります。
表示や編集に対応できるかを確認する
GeometryCollectionを使う前には、利用する地図表示環境や編集環境で正しく扱えるかを確認する必要があります。GeoJSONとして形式が正しくても、すべての表示環境や編集機能がGeometryCollectionを同じように扱えるとは限りません。点、線、面を個別に表示できる環境でも、GeometryCollectionにまとめた途端に表示や編集が期待どおりにならないことがあります。
たとえば、Point、LineString、PolygonをそれぞれFeatureとして持つGeoJSONであれば、点は点の見た目、線は線の見た目、面は面の見た目として分けて設定しやすくなります。色、線幅、塗り、ラベル、クリック時の表示情報なども、Featureの属性に応じて制御しやすくなります。
しかし、GeometryCollectionに複数種類のジオメトリを入れると、表示側では1つのFeatureとして扱われることがあります。その場合、点、線、面に対して個別のスタイルを当てにくくなる可能性があります。表示環境によっては、GeometryCollection内の一部だけが表示される、一部のスタイルが反映されない、クリック判定が分かりにくくなる、といった問題が出ることもあります。
編集作業でも注意が必要です。点を移動したいだけなのに、GeometryCollection全体を選択する必要がある場合があります。線だけを修正したい場合や、面だけを削除したい場合でも、内部構造を理解していないと操作を誤りやすくなります。単純なFeatureであれば、対象の点、線、面を選んで編集できますが、GeometryCollectionでは、内部のジオメトリをどのように編集できるかが環境に左右されます。
実務では、データ作成者とデータ利用者が同じとは限りません。作成担当者はGeometryCollectionの構造を理解していても、閲覧や修正を行う担当者が同じ理解を持っているとは限りません。特に、現場確認、点検記録、社内共有、発注者提出、協力会社との受け渡しなどでは、誰が開いても意味が分かりやすい構造にしておくことが重要です。
GeometryCollectionを使う場合は、事前に小さなサンプルデータを作り、実際に表示、クリック、検索、編集、保存、再読み込みを試すことをおすすめします。GeoJSONの文法チェックだけでは不十分です。文法上は正しいのに、運用上は使いにくいデータになることがあるためです。
確認したいのは、まず全ジオメトリが表示されるかどうかです。Point、LineString、Polygonなど、含めたい型がすべて表示されるかを確認します。次に、スタイルを分けられるかどうかを見ます。点だけ色を変えたい、線だけ太くしたい、面だけ半透明にしたいといった要件がある場合、GeometryCollectionで対応できるかを確認する必要があります。
さらに、クリックや選択時の挙動も確認しましょう。GeometryCollection内のどの形状をクリックしても同じ属性が表示されるのか、個別の形状を識別できるのか、ラベル表示はどこに出るのかといった点は、現場での使いやすさに直結します。地図上で一応表示されているだけでは、実務データとして十分とは言えません。
データ編集後に構造が保たれるかも重要です。表示環境や編集環境によっては、保存時にGeometryCollectionが別の形式へ変換されたり、内部の順番が変わったり、対応していない要素が失われたりする可能性があります。とくに、複数の環境をまたいでGeoJSONを扱う場合は、作成時、編集時、共有時、再利用時のすべてで確認する必要があります。
GeoJSONの使い方としては、できるだけ単純で予測しやすい構造にすることが基本です。GeometryCollectionは表現力がある一方で、表示や編集の対応状況を確認せずに使うと、現場で扱いにくいデータになるおそれがあります。自分の環境で開けるかどうかだけでなく、関係者が同じように扱えるかまで確認してから採用しましょう。
座標順序とジオメトリ構造を崩さない
GeometryCollectionを使うときは、GeoJSONの基本的な座標ルールとジオメトリ構造をより丁寧に確認する必要があります。GeometryCollectionは複数のジオメトリを含められるため、単一のPointやLineStringよりも構造が複雑になりやすいからです。構造が複雑になるほど、括弧の階層、座標配列の深さ、型ごとの書き方を誤るリスクが高くなります。
GeoJSONでは、位置を表す座標の順序に注意が必要です。一般的には、経度、緯度の順で記述します。緯度、経度の順で入力してしまうと、地図上で意図しない場所に表示されることがあります。国内の位置を扱っているつもりでも、順序を誤ると遠く離れた地点として解釈される可能性があります。GeometryCollectionの中に複数のジオメトリがある場合、どれか1つだけ座標順序が間違っていても、見落としやすくなります。
Pointのcoordinatesは、1つの位置を表す配列です。LineStringのcoordinatesは、複数の位置を順番に並べた配列です。Polygonのcoordinatesは、外周や穴を表す線形リングの配列です。MultiPolygonになると、さらに階層が深くなります。GeometryCollectionでは、これらの異なる構造をgeometriesの中に並べるため、型ごとのcoordinatesの形を正しく保つことが重要です。
よくあるミスは、LineStringに必要な点数を満たしていないこと、Polygonの線形リングの始点と終点が一致していないこと、Polygonの配列階層を1段少なくしてしまうこと、Multi系のジオメトリと単一ジオメトリの構造を混同することです。GeometryCollectionの中に複数種類のジオメトリがあると、これらのミスが混在しやすくなります。見た目では一部だけ表示されているため、全体が正しいと勘違いすることもあります。
Polygonを扱う場合は、閉じた形状になっているかを確認する必要があります。面を表すには、外周の最初の座標と最後の座標が一致している必要があります。また、外周と内側の穴を扱う場合は、配列の意味を理解しておかなければなりません。GeometryCollectionにPolygonを含める場合、ほかのPointやLineStringに気を取られて、面の構造確認がおろそかになることがあります。
座標値の桁数や精度も実務では重要です。必要以上に細かい桁を保持するとデータ量が増え、編集時の見通しが悪くなることがあります。一方で、丸めすぎると位置の再現性が下がります。点検記録や現地確認では、用途に応じた精度を決め、データ作成時と更新時で同じ方針にそろえることが大切です。GeometryCollectionに複数種類のジオメトリを入れる場合も、座標精度の考え方を全体で統一しておく必要があります。
また、GeometryCollectionの中に空のジオメトリや不完全なジオメトリを残さないことも大切です。作成途中のデータでは、後から入れる予定のPointやPolygonを空のまま置いてしまうことがあります。しかし、共有データや公開データとして扱う場合、空の要素は表示や変換で問題を起こす原因になりやすいです。不要なジオメトリは削除し、必要なジオメトリは正しい構造で完成させてから共有するようにしましょう。
GeometryCollectionそのものの構造も確認が必要です。typeにGeometryCollectionを指定し、geometriesにジオメトリの配列を持たせます。各ジオメトリには、それぞれtypeとcoordinatesが必要です。ただし、GeometryCollectionの中にGeometryCollectionを入れるような入れ子構造は、扱いが複雑になりやすいため、実務では慎重に判断したほうがよいです。入れ子が深くなるほど、表示、編集、変換、検証の負担が大きくなります。
データ検証では、GeoJSONとしての形式確認だけでなく、業務上の意味確認も行いましょう。座標が正しい範囲に入っているか、現場の位置と合っているか、点と線と面の関係が妥当か、不要な重複がないかを見ます。GeometryCollectionでは複数のジオメトリが1つにまとまっているため、全体の関係性も確認する必要があります。
GeoJSONの使い方で大切なのは、文法上の正しさと業務上の正しさを分けて確認することです。GeometryCollectionは文法上正しく書けても、座標順序、配列階層、面の閉じ方、精度、空要素、入れ子構造の扱いを誤ると、実務では使いにくいデータになります。複数の形状をまとめるからこそ、個々のジオメトリを単独で見ても正しい状態にしておくことが欠かせません。
変換や共有で扱いやすい形式かを判断する
GeometryCollectionを使う前には、そのGeoJSONをどこまで流通させるのかを考える必要があります。自分だけが一時的に使うデータであれば多少複雑な構造でも問題になりにくいかもしれません。しかし、社内で共有する、別部署へ渡す、現場担当者が確認する、外部の関係者へ提供する、別形式へ変換する、といった流れがある場合は、GeometryCollectionが扱いやすい形式かどうかを慎重に判断する必要があります。
実務のデータは、作成した時点で終わりではありません。地図で表示し、属性を確認し、修正し、別の管理表と照合し、報告資料に使い、次回点検の基礎データとして再利用することがあります。その過程で、GeoJSON以外の形式へ変換することもあります。GeometryCollectionはGeoJSONのジオメトリ型として定義されている形式ですが、変換先や利用環境によっては、点、線、面が混在した1つのジオメトリを扱いにくいことがあります。
たとえば、点だけを抽出したい場合、GeometryCollectionの中からPointだけを取り出す処理が必要になります。線だけを別レイヤーにしたい場合も、LineStringだけを抽出しなければなりません。Polygonだけを面データとして集計したい場合も同様です。最初からFeatureを分けておけば簡単に処理できる内容でも、GeometryCollectionにまとめていると、分解処理が必要になります。
分解処理そのものは可能ですが、問題は属性の扱いです。GeometryCollectionを複数のFeatureに分解したとき、元のpropertiesをすべてのFeatureにコピーするのか、ジオメトリごとに別の属性を付け直すのか、元の順番をどう保持するのかを決めなければなりません。このルールが曖昧なまま変換すると、同じ対象物を表していたはずのデータが、意味の分かりにくい複数要素に分かれてしまうことがあります。
共有時には、受け取る側の理解も重要です。GeometryCollectionに慣れていない担当者がデータを開いた場合、なぜ1つのFeatureに点と線と面が入っているのか分からないことがあります。属性表を見ても1行しかないのに、地図上には複数の形状が表示されるため、管理単位を誤解する可能性があります。データの構造を説明する資料が必要になり、結果として運用負荷が増えることもあります。
また、GeometryCollectionはデータの確認作業でも手間が増えます。FeatureCollectionであれば、Featureごとに件数を数えたり、種別ごとに抽出したり、属性の欠落を確認したりしやすいです。一方、GeometryCollectionでは、Feature数だけを見ても内部にいくつの形状があるか分かりません。実際の地物数や図形数を把握するには、geometriesの中まで見る必要があります。
データ品質管理の観点でも注意が必要です。たとえば、点検対象が100件あるはずなのに、Feature数は50件しかないという状況が起きた場合、GeometryCollectionの中に複数の形状が入っている可能性があります。このような構造は、件数確認や差分確認を難しくします。現場での抜け漏れ確認や納品前チェックでは、数え方が複雑になるほどミスが起きやすくなります。
GeometryCollectionを共有する場合は、ファイル内のルールを明確にしておく必要があります。何を1つのGeometryCollectionとしてまとめるのか、内部のジオメトリの順番に意味があるのか、属性は全体に対するものなのか、変換時には分解してよいのか、分解する場合はどの属性を引き継ぐのかを決めておくべきです。これらのルールがないまま共有すると、担当者ごとに解釈が変わってしまいます。
ただし、ルールを増やしすぎると、データ構造そのものが扱いにくい証拠でもあります。説明が長くなり、運用者が覚えなければならない独自ルールが増える場合は、GeometryCollectionを使わず、FeatureCollectionで単純に整理したほうがよいことが多いです。GeoJSONは人が読める形式でもありますが、だからといって複雑な構造を無理に運用しやすくできるわけではありません。
実務での共有を考えるなら、受け取る人が迷わず扱える構造が望ましいです。点は点、線は線、面は面として分かれており、それぞれに必要な属性が付いている構造のほうが、確認も修正も説明もしやすくなります。GeometryCollectionは、どうしても1つの地物として複数種類のジオメトリを保持したい場合に限って検討するくらいが安全です。
GeoJSONの使い方を考えるときは、作成時の便利さだけでなく、変換、共有、検査、再利用まで見通すことが大切です。GeometryCollectionを使うことで後工程が複雑になるなら、より単純な構造を選んだほうが、結果的に運用の品質が安定します。
まとめ
GeometryCollectionは、使ってはいけない形式ではありません。GeoJSONで表現できる正式なジオメトリ型の1つであり、複数のジオメトリを1つのまとまりとして扱いたい場合には役立ちます。ただし、便利そうに見えるから使うのではなく、使う理由が明確な場合に限定することが大切です。
GeometryCollectionを検討できるのは、複数のジオメトリが本当に1つの地物を構成しており、個別の属性を持たせる必要がない場合です。たとえば、ある対象を表すために点と線の両方が必要で、それらが常に一体として扱われる場合です。点だけを別管理したり、線だけを別更新したりする予定がなく、全体として同じ属性を持つなら、GeometryCollectionを検討できます。
また、一時的な処理や中間データとして使う場合もあります。複数の形状を一時的にまとめ、後で分解することが前提であれば、処理上の都合でGeometryCollectionを使うことは考えられます。ただし、この場合も最終的な共有データや管理データとしてそのまま残すかどうかは別問題です。中間処理では便利でも、運用データとしてはFeatureCollectionに整理したほうがよい場合があります。
一方で、形状ごとに別々の属性を持たせたい場合は、GeometryCollectionを避けたほうが安全です。点には点検結果、線には延長や通行状態、面には面積や範囲区分を持たせたいなら、Featureを分けるほうが自然です。属性単位と形状単位が合っていないデータは、後から扱いにくくなります。
点、線、面を別々に検索、集計、色分け、抽出したい場合も、GeometryCollectionは慎重に判断する必要があります。GeometryCollectionにまとめると、種類ごとの処理に分解が必要になります。最初から別Featureにしておけば、種別属性やgeometry typeで処理できます。実務では、見た目のまとまりよりも、抽出しやすさや確認しやすさが重要になる場面が多いです。
複数人で編集するデータにも注意が必要です。GeometryCollectionは内部構造を理解していないと、編集時に意図しない変更が入りやすくなります。担当者が点だけを直したつもりでも、全体の構造や順番が変わってしまう可能性があります。運用者のスキルや作業環境に差がある場合は、できるだけ単純なFeature構造にしておくほうが安全です。
長期管理するデータにも、GeometryCollectionは慎重に使うべきです。短期的には問題がなくても、数か月後や数年後にデータを見返したとき、なぜこの構造にしたのか分からなくなることがあります。担当者が変わると、独自ルールは引き継がれにくくなります。長く使うデータほど、一般的で読みやすい構造にしておくことが重要です。
納品や外部共有を前提とするデータでも、GeometryCollectionは事前確認が必要です。受け取り側がGeometryCollectionを想定していない場合、データ確認や取り込みで問題が起きる可能性があります。形式として正しいことと、相手の運用で使えることは同じではありません。提出先や共有先に形式指定がある場合は、その条件を優先し、曖昧な場合は単純なFeatureCollectionで整理するほうが無難です。
GeometryCollectionを使うか迷ったときは、内部のジオメトリを個別に管理する必要があるかを考えます。必要があるなら、GeometryCollectionではなくFeatureを分けるべきです。次に、属性は全体に対するものだけで足りるかを確認します。足りないなら、やはりFeature単位に分けるほうが適しています。さらに、表示、編集、変換、共有で問題が起きないかを確認します。どこかで説明や独自処理が必要になるなら、採用は慎重に考えたほうがよいです。
実務で扱うGeoJSONは、正しく書けることよりも、迷わず使えることが大切です。GeometryCollectionは、複雑な表現を可能にする一方で、管理単位を曖昧にしやすい形式です。GeoJSONの使い方に慣れていない段階では、まずFeatureCollectionを基本に考え、必要な場合だけGeometryCollectionを検討する流れが安全です。
GeoJSONのGeometryCollectionは、点、線、面など複数種類のジオメトリを1つのgeometryとしてまとめられる形式です。表現としては便利ですが、実務で使う場合は注意点も多くあります。特に、FeatureCollectionとの違い、属性の持たせ方、表示や編集の対応状況、座標構造、変換や共有のしやすさを事前に確認することが重要です。
GeometryCollectionは、単に複数の図形を1つにまとめたいから使うものではありません。複数のジオメトリが本当に1つの地物を構成しており、個別の属性管理が不要で、利用環境でも問題なく扱える場合に検討する形式です。点、線、面を別々に管理したい場合や、検索、集計、色分け、編集、共有を重視する場合は、FeatureCollectionでFeatureを分けるほうが扱いやすいことが多いです。
GeoJSONの使い方で大切なのは、データを作った瞬間だけでなく、後から見る人、更新する人、変換する人、共有先で使う人のことまで考えることです。GeometryCollectionを使うときは、便利さだけで判断せず、運用全体で本当に必要かを確認しましょう。構造が単純で、属性と形状の対応が分かりやすく、誰が見ても扱いやすいGeoJSONほど、現場の記録や点検管理では長く使いやすくなります。