GeoJSONのMultiPolygonを扱うときの6つの確認

GeoJSONを地図表示や現地調査データの管理に使うとき、Point、LineString、Polygonまでは理解できていても、MultiPolygonでつまずくことがあります。MultiPolygonは、複数の面をひとつの地物として扱える便利な形状です。一方で、座標配列の階層、外周と穴の区別、分割された区域の意味、面積や重なりの扱いを誤ると、表示ずれ、集計ミス、現場での確認漏れにつながります。この記事では、「geojson 使い方」を調べている実務担当者に向けて、MultiPolygonを扱う前に確認したい6つの視点を、実務で迷いやすいポイントに沿って整理します。

目次

• MultiPolygonの構造をPolygonの集合として理解する

• 座標配列の階層と経度緯度の順番を確認する

• 外周と穴の扱いを誤らないようにする

• 分離した区域をひとつの地物として扱う理由を確認する

• 表示、検索、面積計算で起きやすいズレを確認する

• 現地調査や施工管理で使う前に運用ルールを決める

• まとめ

MultiPolygonの構造をPolygonの集合として理解する

GeoJSONのMultiPolygonを扱うときに最初に確認したいのは、MultiPolygonが単に「大きな多角形」を意味するのではなく、複数のPolygonをひとつのGeometryとしてまとめた形状であるという点です。GeoJSONでは、地物の形を表すGeometryの種類として、点、線、面、複数の点、複数の線、複数の面などがあります。その中でMultiPolygonは、複数の面を一体の地物として表現したいときに使われます。

たとえば、同じ所有者に属する土地が道路や水路を挟んで離れている場合、行政区域が島しょ部を含んでいる場合、同じ管理対象の敷地が複数の区画に分かれている場合などは、見た目には複数の面に分かれていても、属性としてはひとつの対象として扱いたいことがあります。このようなとき、ひとつのFeatureに対してMultiPolygonを設定すると、属性情報を重複させずに複数の面をまとめて管理できます。

PolygonとMultiPolygonの違いを曖昧にしたまま扱うと、後工程で不具合が起きやすくなります。たとえば、地図上で複数の面が表示されているのに、属性表では一行だけに見えることがあります。これは必ずしも不具合ではなく、MultiPolygonが複数の面をひとつのFeatureとして保持しているために起きる見え方です。逆に、複数のPolygonを別々のFeatureとして持つデータでは、地図上の見た目が似ていても、属性表では複数行に分かれます。この違いを理解していないと、面積集計、選択処理、検索処理、帳票出力の結果が想定と合わない原因になります。

実務では、まず「この複数の面は本当にひとつの地物として扱うべきか」を確認することが重要です。同じ名前、同じ管理番号、同じ所有者、同じ工区、同じ調査対象として扱うなら、MultiPolygonが適している場合があります。一方で、現場で別々に確認する必要がある区画、工程が異なる範囲、管理担当が異なる範囲を無理にひとつのMultiPolygonにまとめると、作業指示や写真管理で混乱しやすくなります。

MultiPolygonは、複数の面をひとつに見せるだけの表示形式ではありません。ひとつのFeatureとして属性を共有する構造であり、データの意味そのものに関わります。そのため、GeoJSONを作成するときも、既存データを読み込むときも、MultiPolygonが使われている理由を確認することが欠かせません。特に外部から受け取ったデータでは、作成者が便宜的にMultiPolygonへ変換している場合もあります。表示上は問題なく見えても、属性単位と現場管理単位が一致していないことがあるため、データの構造と業務上の単位を照らし合わせる必要があります。

GeoJSONの使い方として重要なのは、見た目だけで判断しないことです。地図上で離れた面が同じ色で表示されているからといって、それが必ず同じFeatureとは限りません。反対に、別々の場所にある面がひとつのFeatureとしてまとめられていることもあります。MultiPolygonを扱う場面では、地図表示、属性情報、業務上の管理単位の三つを合わせて確認することで、後工程の誤解を減らせます。

座標配列の階層と経度緯度の順番を確認する

MultiPolygonで最もつまずきやすいのが、座標配列の階層です。GeoJSONでは座標を配列で表しますが、Geometryの種類によって配列の深さが変わります。Pointはひとつの位置、LineStringは位置の並び、Polygonは線形リングの並び、MultiPolygonはPolygon座標配列の並びになります。つまりMultiPolygonでは、複数のPolygonがあり、その中に外周や穴を表すリングがあり、そのリングの中に座標列があり、各座標が経度と緯度の組として並ぶ、という多段構造になります。

この階層を正しく理解していないと、データを読み込む処理で一部の座標だけを取り出してしまったり、Polygonとして扱うべき部分をLineStringのように解釈してしまったりします。特に、単純なPolygonを前提にした処理をMultiPolygonへそのまま適用すると、最初の面だけが表示され、残りの面が欠落することがあります。地図上で一部の区域だけ表示されない問題が起きた場合は、座標配列の階層を正しくたどれているかを確認する必要があります。

RFC 7946に準拠するGeoJSONでは、位置を表す配列の先頭二つの要素は経度、緯度の順番で記述します。日常的な地図の説明では「緯度、経度」と言うことが多いため、実装時に順番を逆にしてしまうミスが起きやすい点に注意が必要です。日本国内のデータで経度と緯度を逆にすると、まったく別の場所に表示されたり、表示範囲外になったりします。MultiPolygonでは座標数が多く、階層も深いため、最初の数点だけを見て問題なさそうに見えても、途中で混在している座標があると発見が遅れます。

座標順の確認では、数値の範囲を見ることも有効です。日本周辺の経度はおおむね120から150程度、緯度はおおむね20から50程度の範囲に収まります。もし最初の値が30台で、次の値が130台のように見える場合は、緯度経度の順番で入っている可能性があります。もちろん対象地域によって範囲は変わりますが、作業対象が国内の特定地域であれば、座標値の感覚を持っておくことで早期に異常へ気づきやすくなります。

MultiPolygonでは、複数のPolygonそれぞれに座標列があります。そのため、ひとつ目のPolygonだけが正しく、二つ目以降のPolygonで座標順やリングの閉じ方が崩れていることもあります。データを結合したり変換したりした後は、全体の件数だけでなく、各Polygonの座標数、先頭座標と末尾座標の一致、極端に遠い座標が混入していないかを確認することが大切です。

リングの閉じ方も重要です。PolygonやMultiPolygonの各リングは閉じたLineStringとして表現され、最初の座標と最後の座標は同じ値である必要があります。これが欠けていると、表示用の処理では自動的に閉じてくれることがあっても、検証処理や面積計算では不正な形状として扱われる場合があります。見た目では閉じているように表示されても、データとして正しいとは限りません。特に、別形式からGeoJSONへ変換した直後や、座標を間引いた後は、リングが正しく閉じているかを確認しておくべきです。

座標配列の階層を確認する際は、「MultiPolygon、Polygon、リング、座標列、座標値」という順番で頭の中に構造を置くと整理しやすくなります。実務では、表示できるかどうかだけでなく、後から検索、集計、判定、出力に使える構造になっているかが重要です。GeoJSONの使い方を安定させるためには、まずこの配列構造を正しく読むことが基本になります。

外周と穴の扱いを誤らないようにする

MultiPolygonを扱うときは、外周と穴の違いを必ず確認する必要があります。Polygonはひとつの面に見えますが、内部に除外範囲を持つことがあります。たとえば、敷地の中に対象外の区画がある場合、区域の中に池や別所有地がある場合、工事範囲から除外する建物周辺がある場合などです。このような除外範囲は、Polygonの中の内側リングとして表現されます。MultiPolygonでは、複数のPolygonそれぞれが外周と穴を持つ可能性があるため、構造の確認がさらに重要になります。

外周と穴を取り違えると、地図上の塗りつぶし結果が大きく変わります。本来は除外されるべき範囲が塗られてしまったり、反対に対象範囲全体が穴として扱われて見えなくなったりします。表示だけならすぐに気づくこともありますが、面積計算や包含判定では見落としやすくなります。たとえば、点が対象区域内にあるかを判定するとき、穴の中にある点は外側として扱うべきですが、穴を無視すると対象内と誤判定してしまいます。

GeoJSONのPolygonでは、座標配列の最初のリングが外周で、続くリングが穴です。MultiPolygonでは、それぞれのPolygonの中で同じ考え方が適用されます。そのため、リングの順番が崩れていると、外周と穴の関係が正しく伝わりません。別形式から変換したデータでは、穴が別のPolygonとして分離されていたり、リングの順番が期待どおりでなかったりすることがあります。データ変換後は、穴を持つ地物をいくつか選んで、表示結果と属性上の意味が一致しているかを確認する必要があります。

外周と穴の問題では、リングの向きも注意点になります。RFC 7946では、外周は反時計回り、穴は時計回りとする右手系の規則が示されています。一方で、過去のGeoJSONデータとの互換性を考慮し、実装によっては向きが規則どおりでないPolygonも受け入れることがあります。そのため、表示できることだけを根拠に正しいデータだと判断せず、重要な業務で使うデータでは、検証処理で形状の妥当性を確認し、穴が正しく認識されているかをチェックすることが望ましいです。

また、穴が外周の外に出ている形状、穴同士が重なっている形状、外周と穴が不自然に接している形状などは、処理によって扱いが難しくなります。現場のデータでは、境界線の微小なずれや、測量結果の丸めによって、見た目には問題がなさそうでも幾何的には不正な形状になることがあります。MultiPolygonは複数の面を含むため、ひとつの面に小さな不整合があるだけでも、全体の処理が失敗することがあります。

実務で外周と穴を確認する際は、対象範囲の塗りつぶしだけでなく、穴の位置にある点や写真、調査記録がどのように判定されるかも見るとよいです。たとえば、除外範囲内の点が対象内として集計されていないか、穴の部分に作業指示が出ていないか、現地確認の対象から外すべき範囲が正しく除外されているかを確認します。地図表示だけで終わらせず、実際の業務処理に近い形で確認することで、外周と穴の取り違えによるミスを減らせます。

MultiPolygonでは、ひとつのFeatureの中に複数のPolygonがあり、それぞれが複数のリングを持つことがあります。構造が深くなるほど、人の目だけで完全に確認するのは難しくなります。だからこそ、データ作成時には外周と穴のルールを統一し、変換後には代表的な地物だけでなく、穴を含む地物、分離した面を含む地物、境界が複雑な地物を優先して確認することが重要です。

分離した区域をひとつの地物として扱う理由を確認する

MultiPolygonを使う実務上の大きな理由は、分離した区域をひとつの地物として扱えることです。しかし、この便利さは同時に注意点でもあります。離れた面をひとつのFeatureにまとめると、属性管理は楽になりますが、現場作業や工程管理では分かりにくくなることがあります。そのため、MultiPolygonを使う前に、なぜ分離した区域をひとつの地物として扱うのかを明確にしておく必要があります。

たとえば、同じ管理番号を持つ複数の敷地をひとつの対象として扱う場合、MultiPolygonは有効です。属性情報を一か所にまとめられるため、名称、管理者、分類、調査日、備考などを重複して持たせる必要がありません。地物単位で検索したときにも、複数の面をまとめて選択できます。区域全体の面積をまとめて集計したい場合にも、ひとつのFeatureとして扱えることは便利です。

一方で、分離した区域ごとに作業日が異なる場合、担当者が異なる場合、現地での進入経路が異なる場合、写真や点検結果を個別に管理したい場合は、ひとつのMultiPolygonにまとめるよりも、複数のPolygon Featureとして分けた方が実務に合うことがあります。属性が同じだからといって無条件にMultiPolygonにするのではなく、現場でどの単位で確認し、どの単位で記録し、どの単位で報告するかを基準に判断することが大切です。

MultiPolygonを扱うときには、地物の単位と作業の単位が一致しているかを確認します。地物の単位とは、データ上ひとつのFeatureとして扱う単位です。作業の単位とは、現場で確認する単位、施工する単位、点検する単位、報告する単位です。この二つがずれていると、データとしては正しくても、運用で混乱します。たとえば、地図上でひとつの対象を選択したときに遠く離れた複数の区域が同時に選ばれると、担当者がどの場所を確認すればよいのか迷うことがあります。

また、MultiPolygonでは中心点や代表点の扱いにも注意が必要です。複数の面が離れている場合、単純に幾何的な中心を求めると、どの面の上にもない場所が代表位置になることがあります。ラベル表示、ピン表示、一覧からの地図移動、現地ナビゲーションなどで代表点を使う場合、中心が対象外の場所に出ると使いにくくなります。必要に応じて、代表点を別属性として持つ、最も大きい面の内部に代表点を置く、現場で使う入口付近の点を管理するなどの工夫が必要です。

検索処理でも、MultiPolygonのまとまり方は影響します。たとえば、ある範囲内に含まれる地物を検索するとき、MultiPolygonの一部だけが範囲にかかっている場合に、そのFeature全体を対象とするのか、それとも該当する面だけを対象とするのかを決めておく必要があります。帳票や一覧で表示するときも、ひとつのFeatureとして一行にするのか、分離した面ごとに明細を出すのかによって、利用者の理解が変わります。

分離した区域をひとつにまとめる判断は、データ設計の問題です。GeoJSONの形式としてMultiPolygonが使えるからといって、それが常に最適とは限りません。実務では、属性の一貫性、現場での確認単位、集計単位、更新頻度、責任分界、報告書の形式を考えて決める必要があります。後から分割や統合を行うこともできますが、運用開始後に地物単位を変えると、過去の写真、点検記録、コメント、承認履歴との対応が崩れることがあります。

MultiPolygonを使う場面では、ひとつにまとめることで何が楽になるのかと、ひとつにまとめることで何が分かりにくくなるのかを両方確認することが重要です。この確認を行うことで、GeoJSONを単なる地図表示用データではなく、現場業務に耐える管理データとして扱いやすくなります。

表示、検索、面積計算で起きやすいズレを確認する

MultiPolygonは、表示できているように見えても、検索や面積計算でズレが出ることがあります。これは、地図表示、空間検索、面積計算がそれぞれ異なる前提で処理されるためです。GeoJSONの使い方として、画面に表示できた時点で安心してしまうのは危険です。実務で使う場合は、表示、検索、計算の三つを分けて確認することが重要です。

まず表示では、複数の面がすべて描画されているかを確認します。MultiPolygonの最初のPolygonだけが表示され、二つ目以降が欠落する不具合は、処理側がPolygonを前提にしているときに起きやすい問題です。また、座標配列の階層をひとつ浅く読んでしまうと、線として表示されたり、形状が崩れたりすることがあります。地図上で代表的な地物だけを見るのではなく、複数の面を持つFeature、穴を持つFeature、座標数が多いFeatureを選んで確認することが大切です。

次に検索では、点がMultiPolygonの内部にあるか、線や面がMultiPolygonと交差しているか、指定範囲内にMultiPolygonが含まれるかといった判定が問題になります。特に、穴を持つMultiPolygonでは、穴の中を対象外として扱えるかが重要です。また、分離した面のうち一部だけが検索範囲に入っている場合に、Feature全体を対象として返すのか、該当部分だけを抽出するのかを明確にしておく必要があります。検索結果を現場作業に使う場合、この違いが作業範囲の誤認につながることがあります。

面積計算では、さらに注意が必要です。GeoJSONの座標は経度緯度で表されることが多く、角度単位の座標をそのまま平面上の距離単位のように扱って面積を計算すると、目的に合わない結果になる場合があります。面積を実務で使う場合は、対象地域や目的に合った投影座標系へ変換するか、測地線に基づく計算方法を使うなど、計算方法を確認する必要があります。単に地図上に表示するだけなら経度緯度で十分な場面もありますが、施工範囲、調査面積、管理面積などの数値を扱う場合は、計算の前提を明確にしなければなりません。

MultiPolygonの面積を求めるときは、複数のPolygonの面積を合計し、各Polygonに穴がある場合は穴の面積を差し引く必要があります。穴を無視すると面積が大きくなり、複数の面の一部を取りこぼすと面積が小さくなります。表示上は同じように見えても、計算結果に差が出るため、代表的なサンプルで手計算に近い確認を行うことが有効です。特に境界が複雑な区域では、座標の間引きや丸めによって面積が変化することもあります。

座標の桁数や丸めも確認点です。GeoJSONでは座標に小数が使われますが、桁数そのものが測位精度や境界精度を保証するわけではありません。一方で、変換や保存の過程で座標値が過度に丸められると、境界位置がわずかにずれることがあります。小さなずれでも、境界線上の点の判定、隣接する区画との重なり、細長い形状の面積計算に影響する場合があります。データ容量を減らすために座標を間引く場合も、表示上は軽くなりますが、境界の再現性が下がる可能性があります。現地確認や施工管理で使うデータでは、必要な精度を満たしているかを事前に確認する必要があります。

重なりや隙間も実務で問題になりやすい点です。複数のPolygonが同じMultiPolygon内で重なっている場合、面積を単純に合計すると重複分が二重に計上されることがあります。隣接するはずの面の間に微小な隙間がある場合、点がどちらにも含まれないと判定されることがあります。見た目では線が重なっているように見えても、座標値としてはわずかに離れていることがあります。境界を基準に判定や集計を行う場合は、形状の妥当性を検証し、必要に応じて修正する運用が必要です。

表示、検索、面積計算の確認では、同じサンプルを使って複数の観点から見ることが有効です。画面上で正しく見えるか、特定の点が対象内と判定されるか、穴の中の点が対象外になるか、面積が想定範囲に収まるかを順番に確認します。これにより、GeoJSONのMultiPolygonを単に読み込めるだけでなく、実務で使える品質になっているかを判断しやすくなります。

現地調査や施工管理で使う前に運用ルールを決める

GeoJSONのMultiPolygonを現地調査や施工管理に使う場合、データ形式の理解だけでは不十分です。実際の現場では、誰がデータを作成し、誰が確認し、どのタイミングで更新し、どの記録と紐づけるかが重要になります。MultiPolygonは複数の面をひとつの地物として扱えるため、運用ルールが曖昧なままだと、確認済みの範囲、未確認の範囲、修正済みの範囲が分かりにくくなることがあります。

まず決めておきたいのは、Featureの単位です。複数の区画をひとつのMultiPolygonにまとめるのか、現地確認単位でPolygon Featureに分けるのかを明確にします。たとえば、帳票上は同じ管理番号でも、現場では別々に移動して確認する必要がある場合があります。このとき、管理番号を同じにしつつFeatureは分ける方法もあります。反対に、属性管理を優先してひとつのMultiPolygonにまとめ、面ごとの補足情報を別属性で管理する方法もあります。どちらが正しいかは業務によって異なるため、目的に合わせて決める必要があります。

次に、属性項目のルールを整えます。MultiPolygonは形状だけではなく、Featureのpropertiesに属性を持たせて使うことが一般的です。現地調査であれば、管理番号、名称、種別、確認状況、調査日、担当者、備考、写真との関連情報などが必要になる場合があります。施工管理であれば、工区、工程、設計値、出来形確認状況、是正状況などを持たせることがあります。属性名や値の表記がばらつくと、検索や集計が難しくなるため、入力ルールを統一することが重要です。

更新ルールも欠かせません。現地で境界が変更された場合、工事範囲が修正された場合、除外範囲が追加された場合、MultiPolygonのどの部分を修正したのかが分かるようにしておく必要があります。形状全体を上書きするだけでは、どの面が変更されたのか追跡しにくくなります。重要なデータでは、更新日、更新者、更新理由、変更前後の確認方法を残しておくと、後から判断の根拠を確認できます。

写真や点検記録と紐づける場合は、MultiPolygonの代表点だけに頼らない方が安全です。複数の面を持つFeatureでは、代表点が現場写真の撮影位置や確認位置と離れることがあります。撮影位置を点として記録し、その点がどのPolygon部分に含まれるかを判定する、または面ごとに補助的な識別情報を持たせるなどの工夫が必要です。特に、現場で「どの場所の写真か」を後から確認する業務では、Feature単位だけでなく、面ごとの位置関係が分かるようにしておくと安心です。

端末やアプリケーションで閲覧する場合は、データ量にも注意します。MultiPolygonは座標数が多くなりやすく、境界が複雑な地物を多数含むと表示や検索が重くなることがあります。現場で使う端末では通信環境が安定しないこともあるため、必要以上に細かい座標を持ったデータは扱いにくくなる場合があります。ただし、軽量化のために単純化しすぎると、境界の再現性が落ちます。業務に必要な精度と動作の軽さのバランスを見て、現場用データと保管用データを分けることも検討できます。

また、現地で使う前には、対象地域の全データを一度に投入するのではなく、代表的な範囲で試験運用することが有効です。単純なPolygon、穴を持つPolygon、分離したMultiPolygon、境界が複雑なMultiPolygonを含めて確認すると、運用上の問題を早めに発見できます。画面表示、属性検索、写真登録、位置確認、帳票出力まで一連の流れで試すことで、データ形式だけでは見えない課題が分かります。

GeoJSONのMultiPolygonは、正しく使えば現地調査や施工管理の情報整理に役立ちます。しかし、形式として正しいことと、現場で使いやすいことは同じではありません。現場の担当者が迷わず使えるように、地物単位、属性ルール、更新ルール、写真や測位情報との紐づけ方を事前に決めておくことが、実務での失敗を減らすポイントです。

まとめ

GeoJSONのMultiPolygonは、複数の面をひとつの地物として扱える便利な形式です。離れた区域、穴を含む区域、複雑な管理対象をまとめて表現できるため、地図表示だけでなく、現地調査、施工管理、点検記録、区域管理など幅広い用途で活用できます。一方で、構造を正しく理解しないまま使うと、表示の欠落、面積の誤差、検索結果の誤判定、現場での確認漏れにつながることがあります。

確認すべき基本は、MultiPolygonをPolygonの集合として理解することです。ひとつのFeatureの中に複数の面が入り、それぞれの面が外周や穴を持つ可能性があります。座標配列は深い階層を持つため、Polygonを前提にした処理をそのまま使うと、一部の面だけを読み込んでしまうことがあります。経度緯度の順番、リングの閉じ方、外周と穴の順序、必要に応じたリングの向きを確認することが、安定したGeoJSON運用の出発点になります。

次に重要なのは、MultiPolygonを使う理由を明確にすることです。複数の面をひとつの地物として扱うことは、属性管理や集計を楽にする一方で、現場での作業単位とずれる場合があります。分離した区域をまとめるべきか、別々のFeatureとして管理すべきかは、表示の都合ではなく、調査、施工、点検、報告の流れに合わせて判断する必要があります。

さらに、表示できることだけで判断せず、検索や面積計算まで確認することが大切です。穴の中の点が対象外になるか、複数の面がすべて検索対象になるか、面積計算で穴や重なりが正しく扱われるかを確認します。経度緯度の角度座標をそのまま平面座標のように扱って面積を求めると目的に合わない結果になる場合があるため、数値を業務判断に使うときは計算方法にも注意が必要です。

現場で使う場合は、データ形式だけでなく運用ルールを整えることが欠かせません。Featureの単位、属性項目、更新履歴、写真や測位情報との紐づけ方を決めておくことで、MultiPolygonを実務に活かしやすくなります。特に、現地で取得した位置情報や写真と区域データを結び付ける場合は、代表点だけでなく、実際の撮影位置や確認位置との関係を分かりやすく管理することが重要です。

GeoJSONの使い方を現場業務に広げるなら、MultiPolygonの構造理解と同時に、正確な位置情報を取得し、地図上の区域や写真と結び付ける仕組みが役立ちます。現地で取得した位置を区域データと照合し、調査記録や施工確認を確実に残せる運用を整えることで、GeoJSONデータを机上の地図情報にとどめず、現場で使える実務データとして活用しやすくなります。