GeoJSONのリング方向でポリゴン崩れを防ぐ4確認

GeoJSONを使って区域、敷地、施工範囲、点検範囲、管理区画などを扱うとき、見た目には単純な面データに見えても、内部では座標列の並び方が重要になります。特にポリゴンでは、外周と穴のリング方向がそろっていなかったり、リングが閉じていなかったり、経度と緯度の順番を取り違えていたりすると、表示時に面が欠ける、穴が塗りつぶされる、想定外の大きな面が現れる、境界線だけ見えて面が表示されないといった崩れが起きることがあります。この記事では、geojson 使い方を調べている実務担当者に向けて、ポリゴン崩れを防ぐために確認したい4つの基本を整理します。

目次

• GeoJSONのポリゴンは点ではなくリングで面を表す

• 確認1 外周リングと穴リングの向きを分けて確認する

• 確認2 座標順序とリングの閉じ忘れを確認する

• 確認3 交差・重複・極端な頂点を確認する

• 確認4 入出力後に面の意味が変わっていないか確認する

• 現場データでGeoJSONを扱うときの注意点

• まとめ

GeoJSONのポリゴンは点ではなくリングで面を表す

GeoJSONは、地図上の点、線、面をJSON形式で表現するためのデータ形式です。点であれば座標を1組持つだけなので比較的わかりやすいですが、ポリゴンは複数の座標を順番に並べたリングによって面を表します。ここでいうリングとは、始点と終点が同じ座標になっている閉じた線のことです。たとえば敷地境界や施工範囲の外周をぐるりと一周するように座標を並べ、その最初の点を最後にも再度置くことで、ひとつの閉じた面として扱えるようになります。

GeoJSONのポリゴンで重要なのは、座標そのものだけではありません。どの順番で座標が並んでいるか、外周と内側の穴がどう区別されているか、リングが正しく閉じているかが、面としての意味を左右します。実務では、測量データ、設計データ、台帳データ、現場で記録した境界データなどを変換しながら使う場面があります。その途中で座標列の順序が変わったり、穴の扱いが失われたりすると、同じ座標を使っているはずなのに表示結果が変わることがあります。

GeoJSONのPolygonでは、coordinatesの中にリングの配列を入れます。最初のリングが外周を表し、2つ目以降のリングが穴を表します。つまり、外周が1つだけの単純な面であればリングは1本ですが、池、建物中庭、除外区域、掘削しない範囲などを内側に持つ面では、外周リングに加えて穴リングが必要になります。MultiPolygonになると、このポリゴン構造が複数並ぶため、確認すべき階層がさらに増えます。

ポリゴン崩れが起こる原因の多くは、見た目の線だけを見て面の構造を確認していないことです。境界線が閉じて見えていても、GeoJSON内部でリングとして閉じていなければ、面として正しく扱えない場合があります。また、外周と穴の順番が入れ替わっていれば、穴として抜けるはずの部分が面として塗られたり、外周として扱うべき範囲が意図しない内側リングとして扱われたりすることがあります。地図上で一見正しく見えるデータでも、別の環境に渡した途端に崩れるのは、この内部構造の解釈が揃っていないためです。

GeoJSONを実務で扱うときは、ポリゴンを単なる線の集合として見ないことが大切です。面には、外周、穴、リング方向、閉合、座標順序、自己交差の有無という複数の条件があります。これらをまとめて確認することで、表示環境や変換処理が変わっても意味が崩れにくいデータになります。

確認1 外周リングと穴リングの向きを分けて確認する

GeoJSONのポリゴンで最も混乱しやすいのが、リング方向です。現行のGeoJSON仕様では、外周リングは反時計回り、穴リングは時計回りとされます。これは右手法則と呼ばれる考え方に基づくもので、面の内側をどちら側とみなすかを座標の並び順で示すものです。一方で、過去のデータや互換性を考慮して、リング方向が仕様どおりでなくても読み込める環境もあります。そのため、画面に表示されたことだけを根拠に、リング方向まで正しいと判断しないことが重要です。

たとえば、外周リングが時計回りになっていて、穴リングも時計回りになっている場合、人間の目では外周と穴がある面に見えても、処理側から見ると外周と穴の意味が不安定になることがあります。ある環境では表示できても、別の環境では穴が消える、面が反転して見える、外側全体が塗られるといった不具合が発生する可能性があります。特に、複数のツールや独自システムをまたいでGeoJSONを受け渡す場合、リング方向の統一は安全側の確認として重要です。

外周リングと穴リングを確認するときは、まずcoordinatesの階層を見て、最初のリングが本当に外周になっているかを確認します。外周はポリゴン全体を囲む境界であり、穴はその内側で除外したい領域です。データ作成時に線を選択した順番や変換処理の仕様によって、穴のリングが先頭に来てしまうことがあります。この場合、面の意味そのものが変わるため、リング方向以前にリングの配置順を直す必要があります。

次に、外周リングの座標列を地図上で追ってみます。経度を横軸、緯度を縦軸として見たとき、座標を順番にたどって面の内側が左手側に来るなら反時計回り、右手側に来るなら時計回りと考えると、実務上は判断しやすくなります。穴リングでは逆に、穴として抜きたい領域の内側が右手側に来るように並べます。数字だけで判断する場合は、リング面積の符号を計算して向きを判定する方法もあります。担当者が毎回目視で追うのは負担が大きいため、データ受け入れ時や出力前の検査処理で自動判定できるようにしておくと安定します。

ただし、リング方向は、向きが違うから必ず表示できないという単純な話ではありません。互換性のために、仕様と逆向きのリングでも読み込める環境はあります。そのため、表示されなかった原因をリング方向だけに決めつけるのも危険です。大切なのは、外周と穴の役割がデータ内で明確になっているか、仕様に沿った方向へ整えられているか、変換後も同じ構造が維持されているかを確認することです。

現場の管理範囲では、穴を使うケースが意外に多くあります。たとえば施工対象区域の中に除外する建物、舗装しない緑地、立入禁止の設備範囲、掘削対象外の既設構造物がある場合、それらを穴リングとして表現することがあります。このとき、穴の方向が外周と同じになっていると、後工程で単なる内側の線として扱われたり、穴ではなく別ポリゴンとして解釈されたりする可能性があります。ポリゴン崩れを防ぐ第一歩は、外周と穴を別物として扱い、それぞれのリング方向を確認することです。

確認2 座標順序とリングの閉じ忘れを確認する

RFC 7946に準拠するGeoJSONでは、地理座標は経度、緯度の順で記述します。地図や測量の会話では緯度、経度の順で話すことが多いため、ここで取り違えが起きやすくなります。たとえば日本周辺の座標で、本来は経度が130度台、緯度が30度台や40度台になるべきところを逆に入れてしまうと、緯度の値が有効範囲を超えたり、地図上で想定外の場所に扱われたりします。ポリゴンの場合、すべての頂点が同じ誤りを持つため、形が少し崩れるというより、表示不能や大きな位置ずれとして現れることがあります。

座標順序の誤りは、リング方向にも影響します。経度緯度を逆にした座標列では、見かけ上の形だけでなく、面積計算や方向判定も期待と異なる結果になります。そのため、リング方向を確認する前に、座標の順序が正しいかを必ず確認する必要があります。特に、表計算形式、CSV、測量機器の出力、図面由来の座標、独自システムの座標をGeoJSONへ変換するときは、項目名だけで判断せず、実際の値の範囲を見て確認することが大切です。

リングの閉じ忘れも、ポリゴン崩れの代表的な原因です。GeoJSONの線とポリゴンの違いは、面として閉じたリングを持つかどうかにあります。Polygonのリングでは、最初の座標と最後の座標が同じ値である必要があります。目視上は最後の点が始点の近くにあって閉じているように見えても、数値として同じ座標が最後に入っていなければ、閉じたリングとして扱えない場合があります。作図環境では自動で閉じて見せてくれることがありますが、データとして閉じているとは限りません。

閉じ忘れを確認するときは、外周リングだけでなく穴リングも対象にします。外周は正しく閉じていても、穴リングの終点が始点と一致していないと、穴だけが消えたり、面が不正と判定されたりすることがあります。また、閉じるために最後へ追加する座標は、始点と同じ経度緯度の組である必要があります。わずかな丸め誤差で別座標になっている場合、処理系によっては同一点とみなされないことがあります。

座標の丸めにも注意が必要です。現場で取得した座標や設計から変換した座標は、小数点以下の桁数が多くなることがあります。出力時に桁数を丸めると、隣接する頂点が同じ座標になったり、細い穴や細長いポリゴンがつぶれたりする可能性があります。逆に、必要以上に桁数を増やしても、元データの精度を超える意味はありません。実務では、用途に必要な精度を保ちつつ、丸めによってリングの閉合や形状が壊れていないかを確認することが重要です。

もうひとつ見落としやすいのが、高さ情報を含む座標です。GeoJSONでは、座標に経度、緯度に加えて高さの値を持たせることがあります。面の表示や2次元的な内外判定では、基本的に水平位置が中心になりますが、高さ値が混在しているデータを変換するとき、3つ目の値が消えたり、別の属性として扱われたりすることがあります。高さ付きの現場データを扱う場合は、ポリゴンの平面形状が正しいことと、高さ情報をどの工程で使うのかを分けて確認すると混乱を避けやすくなります。

座標順序と閉合の確認は、リング方向よりも前に行うべき基礎点検です。座標が正しい位置を示していなければ、方向を直しても意味はありません。リングが閉じていなければ、外周と穴の関係も安定しません。GeoJSONの使い方に慣れていない段階では、まず経度緯度の順番、始点終点の一致、不要な重複点、丸め後の形状維持を確認するだけでも、多くのポリゴン崩れを防げます。

確認3 交差・重複・極端な頂点を確認する

リング方向が正しく、座標順序も合っていて、始点と終点が閉じていても、ポリゴンが実務上そのまま使えるとは限りません。リングの途中で線が交差している場合、面の内側と外側を一意に判断できなくなることがあります。これを自己交差と呼びます。たとえば、座標列の順番を誤って一部だけ飛ばしてしまうと、蝶ネクタイのような形になり、ポリゴンとして不正または不安定に扱われることがあります。見た目には面らしく表示されることもありますが、面積計算、重なり判定、穴の処理、切り出し処理で問題が起きやすくなります。

自己交差は、現場で取得した点を後から並べ替えるときに発生しやすい不具合です。点群や測点をもとに範囲を作る場合、単純に取得時刻順や番号順でつなぐと、実際の外周順にならないことがあります。特に、測点を往復で取得したり、途中で測り直したり、境界の一部を後から追加したりすると、座標列が外周を一周する順番から外れます。その結果、外周リングのつもりでも線が内部を横切り、ポリゴンが崩れます。

重複点も注意が必要です。リング内に同じ座標が何度も出てくるだけで必ず不正になるわけではありませんが、連続する同一点や極端に近い点が多いと、方向判定や簡略化処理で不安定になることがあります。特に、外周上に小さな折り返しができている場合、面の一部が細い針のように突き出したり、穴と外周が接したりして、処理環境によって結果が変わります。見た目ではほとんど気づかない微小な形状でも、面演算では大きな差になることがあります。

極端に短い辺や、ほぼ一直線上に並ぶ不要な頂点も確認対象です。現場で高頻度に取得した境界データをそのままGeoJSONにすると、細かすぎる頂点が大量に含まれることがあります。頂点数が多いだけなら問題ない場合もありますが、近接点が密集していると、表示の負荷が増えたり、丸めや変換で頂点の前後関係が崩れたりします。必要な精度を保ちながら簡略化する場合も、簡略化後に自己交差が生じていないか、穴が外周の外へ出ていないかを確認する必要があります。

穴リングと外周リングの位置関係も重要です。穴は外周の内側に収まっている必要があります。穴が外周の外側にあったり、外周と交差していたり、外周の辺と長く重なっていたりすると、穴として正しく扱えないことがあります。また、複数の穴同士が重なっている場合も注意が必要です。面としては除外したい範囲が複数あるだけに見えても、重なった穴をどう解釈するかは処理によって差が出る可能性があります。

MultiPolygonでは、さらに別の問題が起こります。複数のポリゴンが含まれるため、それぞれの外周と穴の構造を個別に確認しなければなりません。離れた複数の施工範囲を1つのデータとして表す場合には便利ですが、外周が重なっていたり、片方のポリゴンがもう片方の内側へ入り込んでいたりすると、後工程で意図と違う扱いになることがあります。単に複数面をまとめたいのか、ひとつの面に穴を持たせたいのかを整理してからデータ構造を選ぶことが大切です。

交差や重複の確認は、目視だけでは限界があります。拡大表示しても見えないほど小さな折り返しや、ほぼ重なった線分が残っていることがあるためです。実務では、データを受け入れる時点で形状検査を行い、自己交差、リング未閉合、穴の外周外配置、連続重複点、極端な微小辺を検出する流れを作っておくと安心です。GeoJSONは軽量で扱いやすい形式ですが、面データとしての健全性を自動的に保証してくれるわけではありません。使う側が形状の品質を確認する必要があります。

確認4 入出力後に面の意味が変わっていないか確認する

GeoJSONのポリゴン崩れは、作成時だけでなく入出力のタイミングでも起こります。ある環境で作ったGeoJSONを別の環境へ読み込み、編集し、再度出力したときに、リング方向、座標桁数、穴の順序、MultiPolygonの階層が変わることがあります。画面上ではほとんど同じに見えても、内部のcoordinates構造が変わっていれば、後続の処理で違う結果になる可能性があります。

特に注意したいのは、PolygonとMultiPolygonの変換です。単一の面として扱っていたデータが、出力後にMultiPolygonになっていることがあります。逆に、複数の面をまとめたMultiPolygonが、結合処理によってPolygonに変わることもあります。どちらが正しいかは用途によりますが、データ構造が変わったことに気づかず後工程へ渡すと、属性の紐づきや面積集計、選択処理に影響します。見た目だけでなく、geometry typeも確認する必要があります。

穴の扱いも入出力で変化しやすい部分です。穴リングが正しく保持されていれば、外周の内側に除外範囲として残ります。しかし、変換時に穴が別ポリゴンへ分離されたり、単なる線として出力されたりすると、面の意味が変わります。施工範囲から除外すべき場所が塗りつぶされてしまえば、数量計算や作業指示の前提が変わります。穴を含むデータでは、出力後に内側が本当に抜けているかを必ず確認してください。

座標参照の考え方も確認が必要です。現行のGeoJSON仕様に沿って一般的なWeb地図や外部システムへ渡す場合、座標はWGS 84の経度緯度として解釈される前提で扱うのが安全です。一方、実務では平面直角座標や独自のローカル座標で管理しているデータを変換する場面があります。ローカル座標をそのままGeoJSONのcoordinatesに入れたファイルは、関係者間で明確な取り決めがある閉じた運用では使える場合がありますが、汎用のGeoJSONとして地図表示に渡すと、想定外の場所に表示されたり、表示できなかったりします。変換前後で、座標値が何を意味しているかを明確にしておくことが大切です。

面積確認も有効です。出力前後でポリゴンの面積が大きく変わっていれば、リング方向、穴、座標順序、座標系、単位のいずれかに問題がある可能性があります。面積は見た目よりも変化に気づきやすい指標です。施工範囲、管理区域、除外範囲など、面積に意味があるデータでは、入出力前後の面積を比較するだけでも異常検知に役立ちます。ただし、経度緯度のまま単純な平面面積を出すと誤差が出るため、面積計算に適した座標変換や測地計算の方法を使う必要があります。

属性との対応も見逃せません。GeoJSONでは、geometryだけでなくpropertiesに名称、種別、管理番号、日付、担当区分などを入れることがあります。ポリゴンを分割、結合、再出力したときに、属性がどの面に残っているかを確認しないと、形は正しくても意味がずれることがあります。たとえば、外周の向きや穴の向きは直っていても、施工区画名が別のポリゴンに付いてしまえば、実務上は誤ったデータになります。

入出力後の確認では、元データと変換後データを重ねて見ることが有効です。境界線が一致しているか、穴が残っているか、外周が反転していないか、不要な面が増えていないかを確認します。さらに、geometry type、リング数、頂点数、面積、属性数を比較すると、目視だけではわからない変化を発見しやすくなります。GeoJSONの使い方で失敗しないためには、作成時の確認だけでなく、受け渡し後の確認までを一連の作業に含めることが重要です。

現場データでGeoJSONを扱うときの注意点

GeoJSONは、Web地図や業務システムで扱いやすい形式ですが、現場データをそのまま入れれば安全に使えるというものではありません。現場では、取得時の精度、座標系、測点の順番、編集履歴、除外範囲、属性情報が複雑に絡みます。特に施工範囲や点検範囲をGeoJSON化する場合、ポリゴン崩れは単なる表示不良ではなく、作業範囲の誤認につながる可能性があります。

まず、点を取得する段階で外周を一方向に回る運用を決めておくと、後の整理が楽になります。外周を途中で逆走したり、内側の点を混ぜたりすると、座標列をポリゴン化するときに自己交差が起きやすくなります。現場で点を記録する人と、後でGeoJSONを作る人が別の場合は、どの順番で取得した点なのか、どの点が外周でどの点が穴なのかを記録しておくことが重要です。

次に、図面や設計データから作成したポリゴンと、現地で取得したポリゴンを混在させる場合は、基準の違いに注意します。図面上ではきれいな矩形でも、現地取得データでは微妙なずれや曲がりが出ることがあります。これらを無理に結合すると、細い隙間や重なり、微小な自己交差が発生することがあります。GeoJSON化する前に、どちらのデータを基準にするのか、どの程度の差を許容するのかを整理しておくと、後工程で迷いにくくなります。

また、ポリゴンの単純化を行う場合は、表示の軽さだけで判断しないことが大切です。頂点数を減らすとデータは軽くなりますが、境界の意味が変わる可能性があります。道路境界、敷地境界、掘削範囲、保全範囲などでは、わずかな境界の変化でも実務上の意味が変わることがあります。表示用の簡略化データと、記録用・判断用の元データを分けて管理すると安全です。

現場写真や点群、測点情報とGeoJSONを組み合わせる場合は、ポリゴンだけで完結させない視点も必要です。面としての範囲はGeoJSONで扱い、実際の状況確認には位置付き写真や3次元的な記録を組み合わせることで、境界の根拠を確認しやすくなります。ポリゴンが崩れていなくても、現場の地物と合っていなければ実務では使えません。データ形式の正しさと、現場状況との整合性は別々に確認する必要があります。

GeoJSONを共有する際は、作成条件を簡単に残しておくことも有効です。どの座標系から変換したのか、外周と穴をどのように定義したのか、座標の丸めを行ったのか、どの時点の現場を表すのかがわかれば、受け取った側も判断しやすくなります。逆に、GeoJSONファイルだけを渡してしまうと、表示はできても意味の確認に時間がかかります。現場で使うデータほど、ファイル形式だけでなく運用ルールが重要になります。

まとめ

GeoJSONのポリゴン崩れを防ぐには、リング方向だけを見ればよいわけではありません。外周リングと穴リングの向き、座標順序、リングの閉合、自己交差や重複、入出力後の構造変化をまとめて確認する必要があります。特に外周は反時計回り、穴は時計回りという仕様を意識しておくと、複数の環境で扱っても意味が崩れにくいデータになります。

実務でGeoJSONを使う場面では、画面に表示されたかどうかだけで判断しないことが大切です。表示環境によっては、不完全なポリゴンでも補正して見せてくれる場合があります。しかし、そのデータを別の処理に渡したとき、面積計算、重なり判定、穴の扱い、属性管理で不具合が出ることがあります。GeoJSONは軽量で便利な形式だからこそ、内部構造を確認する習慣が必要です。

今回の4確認を作業フローに入れておくと、施工範囲、管理区域、点検範囲、除外範囲などを扱うときのトラブルを減らせます。まず外周と穴の役割を整理し、次に座標順序と閉合を確認し、そのうえで交差や重複を検査し、最後に入出力後の意味が変わっていないかを確認します。この順番で見れば、どこでポリゴン崩れが起きたのかを切り分けやすくなります。

現場データでは、GeoJSONの正しさに加えて、現地との整合性も欠かせません。境界がどこにあるのか、除外範囲が何を意味するのか、取得した座標がどの基準に基づくのかを明確にすることで、データは単なる地図表示ではなく、現場判断に使える情報になります。位置情報をより確実に記録し、現場の範囲や写真、点群と結びつけて管理したい場合は、スマートフォンを活用した高精度な現場記録へつなげる選択肢として、LRTK Phoneの活用も検討しやすくなります。