GeoJSONのMultiPolygonで境界が崩れる時の確認6項目

GeoJSONを扱う実務では、地物の形状そのものは正しいはずなのに、地図上で境界が欠ける、穴が塗りつぶされる、隣接する区域がずれる、離れたポリゴンが意図せず結ばれる、といった表示崩れに悩まされることがあります。特にMultiPolygonは、複数の面を一つの地物として扱える形式である一方、座標配列の階層、外周と内周の関係、リングの閉じ方、座標順序、座標参照系、精度、データ変換の過程が乱れると、見た目の境界に影響が出やすい形式です。

この記事では、geojsonで検索している実務担当者に向けて、MultiPolygonの境界が崩れるときに確認したい6項目を整理します。単に「データが壊れている」と見るのではなく、仕様上の構造、作成時の編集ミス、変換時の丸め、表示側の解釈差、元データとの照合までを順番に見直すことで、原因を切り分けやすくなります。

目次

• MultiPolygonの配列構造が正しいか確認する

• 外周リングと内周リングの扱いを確認する

• 座標順序と座標参照系のずれを確認する

• リングの閉じ忘れと自己交差を確認する

• データ変換時の丸めと簡略化を確認する

• 現地境界・元データ・表示結果を照合する

MultiPolygonの配列構造が正しいか確認する

GeoJSONのMultiPolygonで境界が崩れる場合、最初に確認したいのは座標配列の階層です。MultiPolygonは、複数のPolygonを一つのgeometryとして格納する形式です。そのため、単独のPolygonよりも配列の入れ子が一段深くなります。この階層がずれると、表示側や変換処理が外周と内周を正しく解釈できなかったり、本来別々の面であるべき区域を誤ったまとまりとして読んだりする原因になります。

Polygonの場合、座標は面を構成するリングの集合として表現されます。最初のリングが外周を表し、それ以降のリングが穴などの内周を表します。一方、MultiPolygonでは、そのPolygonの集合をさらにまとめます。つまり、MultiPolygonでは「複数のPolygonがあり、それぞれのPolygonの中に複数のリングがあり、それぞれのリングの中に座標点がある」という階層になります。この考え方を外してしまうと、見た目では座標が並んでいるように見えても、geometryとしては別の意味になってしまいます。

実務で起きやすいのは、Polygonとして作った座標列をMultiPolygonに変換するときに、配列を一段追加し忘れるケースです。見た目の文字列だけを追っていると、角括弧の数が多く、どこがPolygon単位で、どこがリング単位なのか分かりにくくなります。その結果、本来は一つのPolygonに含めるべき外周リングが、MultiPolygon内の別Polygonとして扱われたり、逆に別々の島状ポリゴンが一つのPolygonの内周として解釈されたりします。これが起きると、境界線が飛んだり、塗りの範囲が意図と異なったり、穴が不自然な位置に出たりします。

確認するときは、まずgeometryのtypeが本当にMultiPolygonになっているかを見ます。typeがMultiPolygonであるにもかかわらず、coordinatesの階層がPolygonのままになっていないかを確認します。逆に、typeがPolygonなのにcoordinatesだけがMultiPolygon相当の階層になっている場合もあります。この不一致は、地図表示の失敗や読み込みエラーだけでなく、一部の処理ではすぐにエラーとして表面化せず、後工程で境界崩れとして見えることがあります。

次に、MultiPolygon内の各Polygonが独立した面として成立しているかを確認します。複数の飛び地を一つの地物として扱う場合、それぞれの飛び地は別々のPolygonとして格納します。隣接していない区域を一つの外周リングに無理にまとめると、座標点同士を結ぶ直線が地図上に現れ、道路、河川、他区画を横切る不自然な境界になることがあります。これは、座標の並びとしては連続しているため、表示側が「線で結ぶべき点列」として処理するためです。

また、propertiesの内容とgeometryの構造が一致しているかも見ておきたい点です。たとえば、一つの行政区域、一つの筆、一つの管理範囲を表すためにMultiPolygonを使う場合、propertiesはその集合全体の属性を持つことになります。ところが、データ加工の途中で別々の地物を無理に一つのMultiPolygonにまとめると、属性上は一つでも、形状としては複数の意味が混ざることがあります。境界崩れの調査では、見た目だけでなく、どの単位を一つのFeatureとして扱うべきかも合わせて確認する必要があります。

手作業でGeoJSONを編集している場合は、括弧の対応、カンマの位置、座標列の区切りも重要です。JSONとして有効でも、GeoJSONのgeometryとして意味が間違っているデータはあります。読み込みエラーが出ないから正しいとは限らず、表示結果が不自然な場合は、配列のまとまりを一つずつ追うことが大切です。特に境界線が一部だけ斜めに飛ぶ場合や、離れた区域が線でつながる場合は、座標点の並び順とPolygon単位の分割に問題がある可能性があります。

MultiPolygonの構造確認は、境界崩れの調査の土台です。ここを飛ばして座標精度や表示設定だけを見ても、原因にたどり着けないことがあります。まずはtypeとcoordinatesの階層が一致しているか、各Polygonが外周と内周を正しく持っているか、飛び地が正しく分かれているかを確認することで、後続の確認作業が進めやすくなります。

外周リングと内周リングの扱いを確認する

MultiPolygonの境界が崩れる原因として多いのが、外周リングと内周リングの扱いの混乱です。GeoJSONのPolygonでは、最初のリングが外周を表し、次のリング以降が内周、つまり穴を表します。MultiPolygonでもこの考え方は同じで、各Polygonの中で最初のリングが外周、以降が内周です。この順序を誤ると、本来塗られるべき区域が抜けたり、穴であるべき部分が塗りつぶされたりします。

内周リングは、池、建物の中庭、除外区域、飛び地ではない空白部分などを表すときに使われます。ただし、内周は外周の内部に存在している必要があります。外周の外にあるリングを内周として入れてしまうと、処理系によっては無視されたり、意図しない面として扱われたり、全体の面が壊れたように見えることがあります。離れた区域を追加したい場合は、内周ではなく別のPolygonとしてMultiPolygon内に追加します。

実務では、面データを編集する過程で、外周と内周の関係が崩れることがあります。たとえば、元のデータでは穴として扱われていた部分を別データから差し引いた後、リング順序だけが入れ替わる場合があります。また、境界線を分割・結合したときに、内周リングが外周リングとして出力されることもあります。こうした状態では、見た目の座標点は正しい場所にあるのに、塗りの判定が変わってしまうため、境界が崩れたように見えます。

確認の基本は、各Polygonの最初のリングが本当に外周かどうかを見ることです。座標点の範囲を確認し、最初のリングがそのPolygon全体を囲む大きな輪になっているかを確認します。次に、2番目以降のリングがその外周の内側に収まっているかを見ます。もし2番目以降のリングが外周の外側にある場合、それは内周として扱うべきではなく、別Polygonとして分けるべき可能性があります。

また、穴の扱いでは、リングの向きも確認対象になります。GeoJSONでは外周と内周の向きについて仕様上の考え方がありますが、過去のデータや処理系との互換性により、向きが完全にそろっていなくても読み込まれる場合があります。その一方で、変換、検証、面積計算、空間演算の段階では、向きの不整合が問題として表面化することがあります。境界が崩れている場合は、外周と内周の座標の回り方が利用しているツールや出力ルールに沿っているかを確認すると、原因が見つかることがあります。

ただし、リングの向きだけに注目しすぎるのは危険です。境界崩れの主因が、向きではなくリングの階層や内外関係にある場合も多いためです。たとえば、穴として扱うべきリングが最初に来ていれば、向きを直しても根本的な問題は解決しません。外周と内周の確認では、リングの順序、位置関係、向き、閉じ方をまとめて見ることが重要です。

境界が崩れている箇所だけでなく、その周辺のPolygonも確認しましょう。隣接する区域の一方だけに穴があり、もう一方の境界がそれに追従していない場合、重なりや隙間が発生することがあります。見た目には一つの境界線に見えていても、データ上は別々の座標列で構成されていることがあるため、片方だけを修正すると不整合が残ります。境界を共有するデータでは、隣接面との整合も欠かせません。

内周リングを含むMultiPolygonは、単純な外周だけの面よりも崩れ方が分かりにくい傾向があります。表示上は「一部が抜けている」「塗りが不自然」「境界が重なっている」と見えても、原因はリングの順番、内周の位置、向き、外周との包含関係など複数考えられます。まずは各Polygonごとに、最初のリングが外周であり、以降のリングがその外周内の穴になっているかを確認することが大切です。

座標順序と座標参照系のずれを確認する

GeoJSONで境界が大きく崩れる場合、座標順序や座標参照系のずれが原因になっていることがあります。GeoJSONの位置は、基本的に経度、緯度の順で扱います。ところが、実務で扱う測量データ、表計算データ、台帳データ、独自形式の座標データでは、緯度、経度の順で管理されていることもあります。この順序を取り違えると、地物がまったく別の場所に飛んだり、形状が反転したように見えたりします。

座標順序の問題は、単純な点データでは比較的気づきやすいものです。位置が明らかに違う場所に出るためです。しかし、MultiPolygonでは、複数の座標点がまとまって動くため、一見すると形状らしきものが表示される場合があります。そのため、境界が崩れているのではなく、座標の解釈が根本的に違っていることに気づきにくくなります。特に狭い範囲のデータや、経度と緯度の数値がどちらも似た桁に見える地域では注意が必要です。

座標参照系の違いも重要です。現在広く参照されるGeoJSONの仕様では、座標はWGS 84の経度・緯度を前提に扱われます。一方、現場や設計、測量の実務では、平面直角座標系、ローカル座標、独自の図面座標を使っていることがあります。これらを適切に変換せずにGeoJSONのcoordinatesに入れると、表示側は経度緯度として解釈し、不自然な位置や形状になります。数値としては正しくても、座標系が違えば地図上の意味は変わります。

たとえば、現場の平面座標では、XとYの値がメートル単位で管理されることがあります。この値をそのままGeoJSONに入れると、経度や緯度としては妥当でない数値になったり、表示可能な範囲外に飛んだりします。また、ローカル座標を仮の原点からの距離として持っている場合、外観上はきれいな面でも、地理空間上では位置を特定できません。このような場合は、GeoJSON化の前に、どの座標系からどの座標系へ変換したのかを記録しておく必要があります。

確認作業では、まず座標値の範囲を見ます。対象地域の概略位置と照らし合わせ、経度と緯度の数値が妥当な範囲にあるかを確認します。次に、座標の順序が経度、緯度になっているかを確認します。もし元データが緯度、経度の順で管理されていた場合、変換時に入れ替え処理が必要です。単純な文字列置換や列名だけの判断ではミスが起きやすいため、実際の地点を数点選んで照合すると確認しやすくなります。

座標参照系の変換では、変換前後の基準を明確にしておくことが大切です。元データの座標系、使用した変換条件、変換後の座標系、変換日時、処理方法を記録しておけば、境界崩れが起きたときに追跡しやすくなります。複数の部署や外部データを組み合わせる場合、同じ「座標」と呼んでいても、実際には別の基準で作られていることがあります。データ結合後に境界が合わない場合は、この前提差を疑う必要があります。

また、座標順序や座標系の問題は、境界の一部だけでなく全体に影響することがあります。全体が大きくずれる場合は座標参照系の違い、南北や東西が入れ替わるように見える場合は座標順序の違い、局所的にゆがむ場合は変換条件や元データの混在を疑います。特定のPolygonだけがずれている場合、そのPolygonだけ別の座標系から作られている可能性もあります。MultiPolygonでは複数の面を一つにまとめるため、由来の違う面が混入していないかも確認が必要です。

地図上の境界が崩れて見えると、どうしても形状データそのものを疑いがちです。しかし、座標の順序や座標参照系が違っていれば、形状の構造が正しくても正しい場所には表示されません。GeoJSONを扱うときは、coordinatesの数値が何を意味しているのか、どの順序で並んでいるのか、どの基準から変換されたのかを必ず確認しましょう。

リングの閉じ忘れと自己交差を確認する

GeoJSONのPolygonやMultiPolygonでは、リングが閉じていることが重要です。リングとは、面の外周や内周を構成する座標点の列です。面として成立するためには、最初の座標点と最後の座標点が同じ位置である必要があります。閉じていない場合、ツールによってはエラーになったり、補完された線が意図しない境界になったりすることがあります。

リングの閉じ忘れは、手作業で座標を編集したときや、線データから面データを生成したときに起こりやすい問題です。外周の最後の点を最初の点に戻す処理が抜けると、最後の点と最初の点を結ぶ線が発生します。この線が本来の境界と一致していれば目立ちませんが、点列の並びが途中で切れていた場合、区域を横切る線が現れたり、塗りの範囲が三角形状に崩れたりします。

閉じているように見えても、数値のわずかな違いで閉じていない場合があります。たとえば、最初の座標が小数点以下まである値で、最後の座標が丸められた値になっていると、見た目には同じ場所でもデータ上は別点として扱われます。表示縮尺によっては問題が見えないこともありますが、検証や空間演算ではエラーの原因になることがあります。MultiPolygonではリングが複数あるため、一つでも閉じていないリングがあると、そのPolygon全体の扱いに影響する場合があります。

自己交差も境界崩れの大きな原因です。自己交差とは、一つのリングが自分自身と交差している状態です。たとえば、座標点の順序を誤って、蝶結びのような形になると、どちら側が面の内側なのか判定しにくくなります。表示側によっては一部が塗られなかったり、反対側が塗られたり、境界線だけは表示されるのに面が正しく表示されなかったりします。

自己交差は、座標点の順序ミスでよく発生します。境界点を時計回りまたは反時計回りに順番に並べるべきところを、途中の点を飛ばしたり、別の辺の点を挿入したりすると、線が交差します。地図上で見ると、境界線がジグザグに飛ぶ、対角線が入る、細長い三角形が出るといった症状として現れます。特に、元データを複数の線分から結合して面を作る場合、線分の接続順序が崩れると自己交差しやすくなります。

また、重複点や極端に近い点も確認しましょう。同じ座標点が連続している場合や、ほぼ同じ位置に多数の点がある場合、面の処理が不安定になることがあります。通常の表示では問題が見えなくても、簡略化、面積計算、境界抽出、他データとの重ね合わせで不具合が出ることがあります。細かすぎる点列は精密に見えますが、元の精度を超えて細かい座標が入っている場合は、処理を難しくすることがあります。

リングの確認では、各Polygonの外周と内周を分けて見ます。まず、すべてのリングで最初の座標と最後の座標が一致しているかを確認します。次に、点列が境界に沿って自然な順番で並んでいるかを見ます。さらに、線分同士が不自然に交差していないか、極端に短い線分や重複点がないかを確認します。境界崩れの原因が一つではなく、閉じ忘れと自己交差が同時に起きていることもあります。

現場由来の境界データでは、角点の追加、削除、移動が繰り返されることがあります。その過程で、古い点が残ったまま新しい点が追加されると、外観上は近い位置に見えても、点列としては不自然な経路になります。編集後は、見た目だけでなく、座標点の順番とリングの成立条件を確認することが大切です。

リングの閉じ忘れや自己交差は、JSONの構文エラーとして必ず検出されるとは限りません。JSONとしては正しく、typeもcoordinatesも存在しているため、読み込み自体はできることがあります。しかし、面としての妥当性に問題があると、境界は正しく表現されません。構文の正しさと形状の正しさは別物だと考え、MultiPolygonでは各リング単位で確認する姿勢が必要です。

データ変換時の丸めと簡略化を確認する

MultiPolygonの境界が崩れる原因は、元データそのものではなく、変換や出力の過程にある場合もあります。GeoJSONは扱いやすい形式ですが、元の測量データ、図面データ、空間データ、台帳データなどから変換する際に、小数点以下の丸め、座標の間引き、形状の簡略化、不要点の削除が行われることがあります。この処理が目的に対して粗すぎると、境界の細部が失われ、隣接面との整合が崩れます。

座標の丸めは、ファイルサイズを小さくしたり、不要な桁を削減したりする目的で行われます。適切な丸めであれば問題になりにくい一方、対象範囲や必要精度に対して粗すぎる丸めを行うと、境界点が本来の位置からずれます。直線に見える境界では目立ちにくいものの、細かな折れ点、狭い通路、境界のくびれ、細長い区域では影響が大きくなります。複数のPolygonが接する境界では、一方だけが丸められると隙間や重なりが発生します。

簡略化も注意が必要です。境界線の点数を減らす処理は、表示速度やデータ容量の面では有効です。しかし、簡略化の許容値が大きいと、実際の境界に必要な点まで削除されます。特に、細長い区画、複雑な筆界、入り組んだ管理範囲、河川や道路に沿った境界では、少しの点削除でも形状が変わることがあります。MultiPolygonでは、複数の面ごとに簡略化の影響が異なるため、一部の面だけが崩れて見えることもあります。

実務で気をつけたいのは、隣接する面を別々に簡略化するケースです。元データでは同じ境界線を共有していたとしても、別々に簡略化すると、片方の境界点だけが削除され、もう片方には残ることがあります。その結果、境界が一致しなくなり、わずかな隙間や重なりができます。表示縮尺によっては目立たないこともありますが、面積集計や重ね合わせ処理では問題になります。共有境界があるデータでは、簡略化の順序と方法を慎重に決める必要があります。

座標変換時の精度設定も確認しましょう。座標参照系を変換する際、小数点以下の桁数や丸め方法が処理ごとに異なると、元に戻したときに完全には一致しない場合があります。何度も変換を繰り返すと、わずかな誤差が蓄積することもあります。境界データは一度ずれると、後から原因を追うのが難しくなるため、元データ、変換後データ、共有用データを分けて管理し、どの段階で形状が変わったかを確認できるようにしておくことが大切です。

また、GeoJSONを出力する処理の中で、無効な形状を自動修正する機能が働くことがあります。自動修正は便利ですが、意図しない形に変わることもあります。たとえば、自己交差を解消するために一部のリングが削除されたり、微小な穴が消えたり、重複するPolygonが統合されたりする場合があります。出力後の境界が元データと違う場合は、自動修正やクリーンアップ処理が入っていないかを確認しましょう。

変換時には、属性の結合や地物の統合にも注意が必要です。複数のPolygonを同じ属性でまとめる処理を行うと、内部境界が消え、一つの面または一つのMultiPolygonとして扱われる場合があります。内部境界を残したいのか、同一属性の面として一体化したいのかによって、正しい処理は変わります。境界が消えたように見える場合は、MultiPolygonの問題ではなく、統合処理で内部境界が削除された可能性もあります。

ファイルサイズを抑えるために座標桁数を減らす場合でも、公開目的と業務目的を分けて考える必要があります。概要表示だけでよいデータと、現地境界の確認に使うデータでは、求められる精度が違います。見た目の軽さだけを優先すると、現場で必要な境界情報が失われることがあります。逆に、不要に細かい座標を残しすぎると、表示や処理が重くなり、別の問題が発生します。重要なのは、目的に応じて許容できる精度を決め、その範囲で変換することです。

境界崩れを調査するときは、元データと変換後のGeoJSONを比較します。形状がどの段階で変わったのかを見れば、原因を絞り込めます。元データでは正しいのにGeoJSON化後に崩れるなら、変換設定、丸め、簡略化、統合、出力時の自動修正を確認します。GeoJSON化前から崩れているなら、元の編集や座標管理に問題がある可能性があります。この切り分けを行うことで、やみくもな修正を避けられます。

現地境界・元データ・表示結果を照合する

GeoJSONのMultiPolygonで境界が崩れるとき、最終的に重要なのは、現地境界、元データ、表示結果の三つを照合することです。データ構造や座標系を確認しても、業務上正しい境界になっているかは、元となる資料や現地情報と突き合わせなければ判断できません。特に境界データは、地図上できれいに見えることと、実務上正しいことが一致しない場合があります。

まず、元データが何を基準に作られているかを確認します。測量成果、設計図、台帳、過去の管理図、現地確認記録など、境界の根拠はさまざまです。同じ場所を表すデータでも、作成時期や目的が違えば、境界線の位置が異なることがあります。MultiPolygonに変換した後の見た目だけを見て修正すると、根拠のある境界を誤って動かしてしまう可能性があります。境界崩れの修正では、必ず元データの位置づけを確認しましょう。

次に、表示結果を複数の縮尺で確認します。広域表示では問題なく見えても、拡大すると隙間や重なりが見つかることがあります。逆に、拡大時には正しく見えても、縮小時の簡略表示で境界が欠けて見えることもあります。表示側の描画都合で一時的に崩れて見える場合と、GeoJSONデータそのものが崩れている場合を分けて考えることが大切です。特定の縮尺だけで崩れる場合は、表示用の簡略化や描画設定が影響している可能性があります。

現地境界との照合では、代表点だけで判断しないことが重要です。境界の角点、曲がり点、隣接区域との接点、穴の周囲、飛び地の外周など、崩れやすい箇所を重点的に確認します。MultiPolygonでは、一つのFeatureに複数の面が含まれるため、主要な面だけを確認していると、飛び地や小さな除外区域の崩れを見落とすことがあります。小さなPolygonほど、丸めや簡略化の影響を受けやすいため注意が必要です。

元データとGeoJSONの比較では、座標値だけでなく、面の数やリングの数も確認します。変換前は3つの面があったのに、変換後は2つになっている場合、統合や削除が起きている可能性があります。穴の数が変わっている場合は、内周リングの扱いに問題があるかもしれません。境界の頂点数が大きく減っている場合は、簡略化が強すぎる可能性があります。見た目の差だけでなく、構造の差を確認すると原因を見つけやすくなります。

また、修正作業では、表示上の違和感をその場で手直しするだけでなく、修正理由を残すことが大切です。どのPolygonを修正したのか、何を根拠に座標を変更したのか、どの処理で出力したのかを記録しておくことで、後から同じ問題が起きたときに再確認できます。GeoJSONはテキスト形式で扱えるため、修正履歴を比較しやすい反面、手軽に変更できてしまうため、根拠のない修正も混入しやすい形式です。

業務フローとしては、元データを保管し、作業用データで修正し、公開用または共有用のGeoJSONを出力する流れを分けると安全です。元データを直接編集してしまうと、境界崩れの原因が元からあったのか、編集で発生したのか分からなくなります。作業用データでは検証や修正を行い、出力時には変換条件を固定します。公開用データでは、表示確認だけでなく、構造確認も行うと安心です。

最後に、現地で使うデータとしてGeoJSONを扱う場合は、画面上の境界と現地の位置関係を確認できる仕組みを整えておくと、判断ミスを減らせます。MultiPolygonの崩れは、机上のデータ確認だけで発見できることもありますが、現地の目印、構造物、管理範囲、測点との関係を見なければ判断できないこともあります。現場で確認した情報をデータ修正に戻す流れがあると、境界管理の精度を高めやすくなります。

GeoJSONのMultiPolygonは、複雑な区域や飛び地を扱ううえで有効な形式です。しかし、構造が正しいこと、座標が正しいこと、表示が正しいこと、業務上の境界が正しいことは、それぞれ別の確認項目です。境界が崩れたときは、配列構造、リングの扱い、座標順序、座標参照系、閉じ方、自己交差、丸め、簡略化、元データとの照合を順番に見ていくことが近道です。

まとめ

GeoJSONのMultiPolygonで境界が崩れるときは、単に表示環境の相性や一時的な描画不具合と決めつけず、データ構造から順番に確認することが大切です。まず、MultiPolygonとしてcoordinatesの階層が正しいかを見ます。次に、各Polygonの外周リングと内周リングが正しい順序と位置関係になっているかを確認します。そのうえで、座標の順序、座標参照系、リングの閉じ忘れ、自己交差、変換時の丸めや簡略化を見直します。

特に実務では、元データの作成目的や座標系が混在しやすく、GeoJSON化の時点で問題が表面化することがあります。元の境界データは正しいつもりでも、変換条件が違えば表示結果は崩れます。逆に、表示上は整って見えても、リング構造や内周の扱いに問題が残っている場合もあります。境界データを扱う際は、見た目の確認だけでなく、構造、座標、根拠資料、現地との整合をまとめて確認する姿勢が必要です。

MultiPolygonは、飛び地や複数区域を一つの地物として扱える形式です。その便利さの反面、配列の階層やリングの意味を誤ると、境界崩れの原因が見えにくくなります。境界が欠ける、穴が埋まる、線が飛ぶ、隣接面がずれるといった症状が出たら、今回紹介した6項目に沿って切り分けると、原因を整理しやすくなります。

現場で取得した位置情報や境界確認の記録をGeoJSON運用に活かすには、データを作る段階だけでなく、現地で確認し、記録し、後工程で照合できる流れが重要です。特定のツール名や表示結果だけに依存せず、元データ、変換条件、確認記録、修正履歴を残しておくことで、MultiPolygonの境界崩れを再発しにくい運用に近づけられます。