GeoJSONは、地物の位置情報と属性情報をひとつのテキスト形式で扱えるため、現地調査、区画管理、施設台帳、農地管理、工事範囲の整理、災害対応の記録など、さまざまな実務で使われています。点や線だけでなく、Polygonを使えば敷地、施工範囲、管理区域、調査対象範囲のような「面」を表現できます。そのため、「geojson 使い方」を調べている実務担当者の中には、Polygonを作成し、その面積を集計したり、台帳に転記したり、関係者へ共有したりしたい方も多いはずです。
ただし、GeoJSONのPolygonを使った面積管理では、単に座標を囲めば正しい面積が出るわけではありません。座標の持ち方、座標参照の前提、リングの閉じ方、穴抜き範囲の扱い、属性値との整合、更新履歴の残し方などを誤ると、見た目は正しいのに面積だけがずれることがあります。さらに、画面上では同じ区域に見えても、面積計算の方法が異なると、台帳値、現地測量値、図面値、システム上の算出値が一致しないこともあります。
この記事では、GeoJSONのPolygon面積管理で押さえておきたい注意点を、実務で確認しやすい順に整理します。専門的な開発者だけでなく、現地調査データを扱う担当者、台帳更新を行う担当者、地図データを関係者へ渡す担当者にも伝わるように、実務上の判断ポイントを中心に解説します。
Polygonの面積管理では座標の前提を先にそろえる
GeoJSONでPolygonを扱うとき、最初に確認したいのは座標の前提です。GeoJSONのGeometryには座標の配列が入りますが、その座標がどのような基準で表されているのかを理解しないまま面積管理を始めると、後から数値の説明が難しくなります。特に、緯度経度の座標をそのまま平面上の距離のように扱ってしまうと、面積の計算結果が実務上の期待と合わないことがあります。
GeoJSONでは、多くの場合、座標は経度、緯度の順で記録されます。地図画面で見慣れている「緯度、経度」という言い方とは順番が逆になるため、手入力や表形式から変換するときに取り違えが起こりやすい点に注意が必要です。座標順序を誤ると、Polygonがまったく違う場所に表示されたり、極端に変形した形になったりします。見た目で異常に気づける場合もありますが、近い範囲の数値を扱う場合には気づきにくいこともあります。
面積管理では、座標の単位も重要です。緯度経度は角度の単位であり、メートルそのものではありません。一方、現場で扱う面積は平方メートルや平方キロメートルなど、距離に基づく単位で整理されることが一般的です。そのため、緯度経度のGeoJSONを使って面積を算出する場合には、計算処理の中で地球上の曲面を考慮するのか、一定の投影条件で平面に変換して計算するのかを決めておく必要があります。
小さな敷地や狭い作業範囲であれば、見た目上の差が小さいこともあります。しかし、対象範囲が広くなるほど、また南北方向や東西方向に長い区域になるほど、座標の扱いによる差が無視しにくくなります。行政区域、山林、農地、道路沿いの長い管理範囲などでは、同じPolygonでも計算方法によって面積値に差が出ることがあります。したがって、GeoJSONのPolygon面積を管理する場合は、どの座標を使い、どの計算前提で面積を出したのかをセットで残すことが大切です。
実務では、データを受け取った時点で「このGeoJSONは表示用なのか、面積算出にも使うのか」を分けて考えると整理しやすくなります。表示用であれば、地図上に重ねて確認できることが主な目的になります。一方、面積算出用であれば、境界の精度、座標の基準、計算方法、丸め方まで確認対象になります。表示できるから面積管理にも使える、という判断は避けたほうが安全です。
また、複数の部署や協力会社からGeoJSONを受け取る場合には、同じ名称の項目であっても作成方法が異なることがあります。あるデータは現地測量をもとに作られ、別のデータは既存図面をなぞって作られ、さらに別のデータは現地メモから概略作成されているかもしれません。これらを同じ精度のPolygonとして扱うと、面積管理の信頼性が下がります。面積を比較する前に、作成方法と利用目的を確認することが必要です。
GeoJSONの使い方としては、まずGeometryとPropertiesを分けて理解するとよいです。Geometryは形そのものを示し、Propertiesはその地物に付ける属性情報を示します。面積を管理する場合、Geometryから計算した面積をPropertiesに保存することがありますが、このときも「どの時点のGeometryから計算したのか」が重要になります。形状が更新されたのに面積属性が古いままだと、画面上のPolygonと台帳上の面積が食い違います。
Polygon面積管理では、最初から完璧な仕組みを作るよりも、座標の前提を明確にして、後から確認できる状態にすることが大切です。座標の順序、座標参照の考え方、計算単位、面積算出の方法、更新日を最低限そろえておけば、後で数値に疑問が出たときにも原因を追いやすくなります。
外周と穴抜きの扱いを誤ると面積が大きくずれる
GeoJSONのPolygonでは、単純な四角形や多角形だけでなく、外周の内側に除外範囲を持つ形も表現できます。たとえば、管理対象の敷地の中に対象外の建物、池、道路、既存施設、立入不可区域がある場合、外周だけでなく、内側の穴抜き範囲を含めてデータ化することがあります。この穴抜きの扱いを誤ると、面積が大きくずれる原因になります。
Polygonの座標配列では、外側の輪郭と内側の輪郭を分けて記録します。外側の輪郭だけを見れば大きな面に見えても、内側に除外すべき範囲がある場合、その分を差し引いた面積が管理対象になることがあります。ところが、穴抜き範囲を別のPolygonとして登録してしまったり、属性だけで「除外」と書いてGeometryには反映していなかったりすると、面積計算の方法によって結果が変わります。
実務では、見た目で穴が空いているように表示されていても、データ構造として正しく穴抜きになっているとは限りません。地図画面の描画設定や重ね順によって、対象外範囲が上に重なって見えているだけの場合もあります。この場合、外側のPolygonそのものは穴抜きされていないため、Geometryから面積を計算すると除外範囲を含んだ値になります。画面上の印象だけで面積値を判断しないことが重要です。
穴抜き範囲を扱う場合には、外周面積、除外面積、差し引き後の管理面積をどのように管理するかを決めておくと混乱を防げます。たとえば、台帳では差し引き後の面積だけを表示し、内部管理では外周面積と除外面積も保持しておく方法があります。こうしておけば、関係者から「なぜ見た目より面積が小さいのか」と聞かれたときに、対象外範囲を説明できます。
また、穴抜き範囲が複数ある場合には、すべての内側リングが同じ考え方で作られているかを確認する必要があります。ある穴は建物範囲、別の穴は道路範囲、さらに別の穴は調査不能範囲というように、除外理由が異なる場合があります。面積管理では、除外してよい理由が明確でないと、後から集計条件を変更したときに混乱します。穴抜きのGeometryだけでなく、除外理由をPropertiesに残す運用が有効です。
境界に接する除外範囲にも注意が必要です。完全に内側にある穴であれば理解しやすいですが、外周と接している範囲を穴として扱うのか、外周形状を分割して表現するのかは、データ作成方法によって変わります。不自然に接している内側リングや、外周と交差しているリングがあると、面積計算が不安定になったり、読み込み側でエラーになったりする場合があります。
さらに、複数のPolygonをまとめて扱う場合には、PolygonとMultiPolygonの違いにも注意が必要です。離れた複数の面をひとつの地物として管理したい場合、単独のPolygonを複数登録する方法と、複数面をひとつのGeometryとして持つ方法があります。面積集計の目的が、個別区画ごとなのか、ひとつの管理対象として合算するのかによって、適した持ち方が変わります。データ形式だけでなく、管理上の単位を先に決めることが大切です。
穴抜きや複数面の扱いは、現場の実態と台帳の考え方がずれやすい部分です。現地ではひとつの区域として認識されていても、データ上では複数の面に分かれていることがあります。逆に、台帳ではひとつの区画でも、現地では道路や水路で分断されている場合があります。GeoJSONのPolygon面積管理では、実際の土地や施設の見え方と、データ構造上の面の持ち方を一致させる意識が必要です。
座標順序とリングの閉じ方を確認して形状崩れを防ぐ
GeoJSONのPolygonでは、座標点を順番に並べて面の輪郭を作ります。このとき、座標の順序やリングの閉じ方に問題があると、Polygonが意図しない形で解釈されることがあります。面積管理では、わずかな形状崩れが面積値に影響するため、データを作成した後に構造面の確認を行うことが欠かせません。
Polygonのリングは、始点と終点が同じ座標で閉じられている必要があります。つまり、外周の最初の点と最後の点が一致して、ひとつの輪になる形です。画面上では閉じて見えていても、データ上で最後の座標が抜けていると、読み込み側が自動補正する場合もあれば、エラーとして扱う場合もあります。自動補正された場合でも、どのように補正されたかを意識しないまま面積計算に使うのは危険です。
座標点の並び順も重要です。外周の点を順番にたどったときに、線が途中で交差してしまうと、見た目では多角形のように見えても、正しい面として扱えないことがあります。たとえば、四隅の点を時計回りや反時計回りに並べるべきところを、対角線をまたぐ順番で並べてしまうと、蝶のように交差した形になります。このような自己交差したPolygonは、面積計算の結果が不安定になりやすく、システムによって解釈が異なることがあります。
リングの向きについても、運用上の確認が必要です。外周と穴抜きの向きは、データを読む処理によって判断材料になることがあります。すべての環境で同じように厳密に扱われるわけではありませんが、外周と内側リングの向きが混在していると、穴抜きが正しく反映されない、表示と計算が合わない、といった問題につながる可能性があります。データ作成後に、外周と穴抜きが期待どおりの向きで構成されているかを確認する運用が望ましいです。
手作業で座標を編集する場合には、点の追加、削除、移動のたびに形状が崩れる可能性があります。特に、既存のPolygonを複製して別区域を作る場合や、現地確認後に一部の境界だけを修正する場合は注意が必要です。ひとつの座標点を動かしただけでも、隣接する辺の角度が変わり、面積が変わります。境界点の移動が意図した修正なのか、誤操作なのかを確認できるように、修正前後の面積差を確認することが有効です。
また、小数点以下の桁数にも気を配る必要があります。GeoJSONはテキスト形式で座標を保存できるため、多くの桁数を保持できますが、変換や出力の過程で座標が丸められることがあります。狭い範囲のPolygonでは、座標の丸めが面積に小さな影響を与える程度で済むこともあります。しかし、細長い区域や境界点が多い区域では、丸めの積み重ねが無視できない差になることがあります。
一方で、必要以上に細かすぎる座標を保持すると、データ容量が大きくなり、共有や表示が重くなることがあります。面積管理に必要な精度と、運用上扱いやすいデータ量のバランスを考えることが大切です。現場で取得した細かな軌跡をそのままPolygon化すると、境界が細かく揺れた形になり、面積値にも細かな揺らぎが出ることがあります。管理対象として必要な境界なのか、取得時のばらつきなのかを判断し、必要に応じて整理することが必要です。
隣接するPolygon同士の境界にも注意が必要です。複数の区画を並べて管理する場合、隣り合う区画の境界が完全に一致していないと、重なりやすき間が発生します。見た目ではほとんど分からない細い重なりでも、面積を合算すると差が出ることがあります。全体面積と区画別面積の合計が合わない場合、こうした微小な重複やすき間が原因になっていることがあります。
GeoJSONのPolygonは、人が読める形式である一方、座標配列の順序に強く依存します。そのため、データを作る段階では、見た目の確認だけでなく、リングが閉じているか、自己交差がないか、隣接境界に重複やすき間がないかを確認することが重要です。面積管理の信頼性は、計算式だけでなく、Geometryそのものの健全性に支えられています。
見た目の面積と計算面積を同じものとして扱わない
GeoJSONのPolygonを地図上に表示すると、区域の広さを視覚的に把握できます。しかし、画面上で見えている広さと、計算によって求めた面積は、必ずしも同じ考え方で得られているわけではありません。面積管理でよくある誤解のひとつが、「地図上で正しく見えているから、面積も正しいはず」と判断してしまうことです。
地図画面では、表示の都合により、縮尺、投影、簡略化、線の太さ、塗りつぶしの表現などが影響します。小さな画面で広い範囲を表示している場合、細かな境界の曲がりや穴抜きが目立たないことがあります。逆に、拡大表示すると境界の揺れが大きく見えることもあります。表示は確認に役立ちますが、面積そのものを保証するものではありません。
計算面積は、どのGeometryを使い、どの計算方法で算出したかによって決まります。緯度経度をもとに曲面上の面積として計算するのか、平面座標に変換して計算するのか、簡略化前の形状を使うのか、簡略化後の形状を使うのかによって結果が変わります。画面表示用に軽量化したGeoJSONを面積計算に流用すると、本来の境界より粗い形状で面積を出してしまうことがあります。
実務では、表示用データと計算用データを分ける考え方が有効です。表示用データは、関係者が地図上で範囲を確認しやすくするためのものです。計算用データは、面積値の根拠として使うものです。両者が同じGeoJSONであっても問題ない場合はありますが、表示を軽くするために座標を減らしたり、境界を簡略化したりする場合には、計算用データを別に保持するほうが安全です。
また、線の太さや塗りつぶしの表現によって、画面上では隣接区域が重なっているように見えたり、逆にすき間があるように見えたりすることがあります。これは表示上の見え方であり、実際のGeometryとは異なる場合があります。面積差の確認では、画面の印象だけでなく、座標データ同士の重なり、境界の一致、合算面積の整合を確認する必要があります。
面積管理では、丸め処理も見落とされがちです。計算結果が1234.567平方メートルであっても、台帳には1234.57平方メートルと記録するのか、1235平方メートルと記録するのかによって、合計値が変わります。複数区画を個別に丸めてから合計する場合と、全体を合計してから丸める場合でも、わずかな差が出ることがあります。この差は間違いではなく、丸め方法の違いによるものですが、説明できるようにルール化しておく必要があります。
さらに、既存の台帳面積や図面記載面積と、GeoJSONから計算した面積が一致しないこともあります。台帳面積は過去の測量、図面作成、登記、設計、管理上の取り決めなど、さまざまな経緯で作られている場合があります。一方、GeoJSONの面積は現在のデータから機械的に計算した値です。両者が異なるからといって、すぐにどちらかが誤りとは限りません。どの面積を正式値として扱うのか、どの面積を参考値として扱うのかを決めておくことが重要です。
現場での説明では、「画面上の範囲」「Geometryから計算した面積」「台帳に登録する面積」を分けて表現すると誤解を減らせます。たとえば、画面上のPolygonは確認用、計算面積は算出値、台帳面積は承認済みの管理値というように役割を整理します。こうすることで、関係者が同じ数値を見ているつもりで別の意味を受け取る問題を防げます。
GeoJSONの使い方を実務に落とし込む際には、表示できることをゴールにせず、面積の根拠を説明できる状態にすることが大切です。見た目の確認は重要ですが、それだけでは面積管理として十分ではありません。計算方法、丸め方法、正式値との関係を整理しておくことで、後から数値の違いが出たときにも落ち着いて確認できます。
属性値の面積とGeometryからの計算値を分けて管理する
GeoJSONでは、Propertiesに面積値を属性として持たせることができます。たとえば、Polygonごとに管理番号、名称、用途、担当者、作成日、面積などを保存できます。この仕組みは非常に便利ですが、面積管理では、属性値として保存された面積と、Geometryからその場で計算した面積を混同しないことが重要です。
Propertiesに入っている面積値は、必ずしも現在のGeometryから計算されたものとは限りません。過去に計算した値がそのまま残っている場合もあれば、別資料から転記された値である場合もあります。現地確認後にPolygonの境界を修正したにもかかわらず、Propertiesの面積を更新していないと、形状と属性が不一致になります。画面上では修正後のPolygonが表示されているのに、一覧表では古い面積が表示されるという問題が起こります。
この混乱を防ぐには、面積属性の意味を明確にしておく必要があります。ひとつの方法は、Geometryから計算した面積、台帳に登録する面積、参考として残す過去面積を別項目に分けることです。項目名は組織内で分かりやすいものに統一し、どの項目が正式な管理値なのかを明確にします。単に「area」とだけ書かれた項目があると、それが計算値なのか、登録値なのか、概算値なのか判断しにくくなります。
また、面積の単位も属性として分かるようにしておくことが望ましいです。数値だけが入っていると、平方メートルなのか、平方キロメートルなのか、別の単位なのかが分かりません。特に、複数のデータを統合する場合、単位の違いは重大なミスにつながります。面積値を保存するなら、単位の前提を仕様書や項目説明に残し、必要に応じて属性にも単位を示す項目を用意します。
面積値の更新タイミングも重要です。Geometryを編集したら自動で面積を再計算する運用なのか、担当者が確認後に更新する運用なのかを決めておかないと、データの信頼性が揺らぎます。自動計算は便利ですが、計算方法が固定されているか、穴抜きや複数面を正しく扱えるか、丸めルールが合っているかを確認する必要があります。手動更新は柔軟ですが、更新漏れが起こりやすくなります。
属性値の面積を使って集計する場合には、欠損値や異常値にも注意が必要です。面積が空欄のPolygon、ゼロになっているPolygon、極端に大きい値や小さい値を持つPolygonが混じっていると、合計値や平均値が不正確になります。データを受け取ったら、面積属性の有無、数値形式、単位、異常値を確認することが大切です。
Geometryから計算した値と属性値を比較するチェックも有効です。両者が完全に一致する必要がない場合でも、差が一定以上あるPolygonを抽出できれば、更新漏れや入力ミスに気づきやすくなります。たとえば、属性面積と計算面積の差が大きいものを確認対象にする運用にすれば、すべてを目視確認するより効率的です。
ただし、差があること自体をすぐに誤りと決めつけないことも重要です。台帳面積が正式値であり、Geometryは概略形状として使っている場合、差が出るのは当然です。逆に、Geometryを正式な面積算出根拠としている場合は、属性値との差は修正対象になる可能性があります。どの値を正とするかは、業務目的によって変わります。
GeoJSONのPropertiesは自由度が高いため、項目名や値の入れ方がばらつきやすい部分です。面積管理を継続的に行うなら、最低限の入力ルールを決めておく必要があります。面積値の項目名、単位、計算日、計算方法、正式値か参考値か、更新者、確認状態を整理しておくと、データを受け渡す際の誤解が減ります。
属性値とGeometryの関係を明確にしておくことは、GeoJSONを単なる地図表示データから、実務で使える管理データへ引き上げるための重要なポイントです。形状と数値が一致しているか、または一致していない理由が説明できるかを確認することで、Polygon面積管理の信頼性を高められます。
更新履歴と現地確認の記録を残して後から説明できる形にする
GeoJSONのPolygon面積管理では、データを作った瞬間だけでなく、更新後の説明責任も重要です。現場の境界、施工範囲、管理区域は、調査の進行、設計変更、協議結果、現地状況の変化によって更新されることがあります。更新のたびに面積が変わる可能性があるため、いつ、誰が、なぜ、どの範囲を修正したのかを残しておくことが大切です。
更新履歴がないGeoJSONは、現在の形状を見ることはできても、過去の面積差を説明しにくくなります。たとえば、前回の集計では5000平方メートルだった範囲が、今回の集計で4950平方メートルになっていた場合、境界修正によるものなのか、穴抜き追加によるものなのか、計算方法の変更によるものなのか、単なる入力ミスなのか判断できません。面積管理では、数値の変化理由を追える状態にしておく必要があります。
Propertiesに更新日や更新理由を持たせる方法もありますが、更新履歴をすべてひとつのGeoJSONに詰め込みすぎると、データが扱いにくくなることがあります。運用としては、現在有効なGeoJSONとは別に、変更履歴、確認記録、差分メモを管理する方法も考えられます。重要なのは、後から確認したときに、面積が変わった理由をたどれることです。
現地確認の記録も面積管理に大きく関わります。Polygonの境界は、机上の図面や既存データだけで作る場合と、現地で確認して作る場合があります。現地で取得した点や歩行記録、写真、メモがある場合、その情報がどの境界修正に反映されたのかを残しておくと、後から説明しやすくなります。特に、草地、山林、造成前の土地、仮設範囲、災害現場などでは、現地状況が変わりやすいため、確認日の記録が重要です。
面積管理では、確定値と暫定値を分けることも必要です。現地確認前のPolygon、関係者確認中のPolygon、承認済みのPolygonが混在すると、誤った面積を集計に使うおそれがあります。Propertiesに確認状態を持たせる、ファイル名や管理番号で区別する、承認済みデータだけを集計対象にするなど、運用上の工夫が求められます。
また、面積値を報告書や台帳へ転記する場合には、どの版のGeoJSONから算出した値なのかを残しておくことが大切です。GeoJSONを上書きし続ける運用では、過去に提出した面積の根拠が失われることがあります。提出時点のデータを保存しておけば、後から問い合わせがあった場合にも、当時のPolygonと面積を確認できます。
複数人で作業する場合には、編集ルールの共有が欠かせません。ある担当者は境界点を細かく追加し、別の担当者は簡略化して管理するというように、編集方針がばらつくと、面積値の変化が編集者の癖に左右されます。どの程度の細かさで境界を持つのか、現地確認後にどのように修正するのか、面積差がどの程度なら確認対象にするのかを決めておくと、品質が安定します。
更新履歴を残すことは、作業を増やすためではなく、後戻りや説明の負担を減らすためのものです。面積値は、関係者の判断や費用配分、施工範囲、管理責任の確認に関わることがあります。そのため、後から「なぜこの面積になったのか」を説明できることが重要です。GeoJSONのPolygon面積管理では、現在の形状だけでなく、そこに至った経緯も管理対象として考える必要があります。
GeoJSONのPolygon面積管理を現場で使いやすくするまとめ
GeoJSONのPolygonは、面の範囲を共有しやすく、属性情報も一緒に持てる便利な形式です。しかし、面積管理に使う場合は、表示用の地図データとして扱うだけでは不十分です。座標の前提、外周と穴抜き、リングの閉じ方、計算方法、属性値、更新履歴を整理してはじめて、実務で説明できる面積管理に近づきます。
最初に大切なのは、座標の前提を明確にすることです。GeoJSONの座標は、多くの場合、経度、緯度の順で記録されます。緯度経度をそのまま面積計算に使うのか、別の座標条件に変換して計算するのかを決めないまま運用すると、同じPolygonでも異なる面積が出る可能性があります。表示できることと、面積値が正しく説明できることは別の問題として考える必要があります。
次に、Polygonの構造を確認することが重要です。外周だけでなく穴抜き範囲がある場合、その扱いを誤ると管理面積が大きく変わります。離れた複数の面をひとつの管理対象として扱う場合も、個別面積と合算面積の関係を整理しておく必要があります。現場ではひとつの区域に見えても、データ上では複数のGeometryに分かれていることがあるため、管理単位を明確にすることが欠かせません。
リングの閉じ方や座標順序も見落とせません。Polygonは座標点の並びで形が決まるため、始点と終点が一致していない、線が自己交差している、隣接区画に微小な重複やすき間がある、といった問題が面積計算に影響します。地図上でそれらしく見えるだけでなく、データ構造として正しい面になっているかを確認することが必要です。
また、見た目の面積と計算面積を同一視しないことも大切です。画面表示では、縮尺や描画設定、簡略化の影響を受けます。面積値は、どのGeometryを使い、どの計算方法で、どの丸めルールに基づいて算出したかによって変わります。表示用データと計算用データを分ける考え方を持つことで、共有しやすさと数値の信頼性を両立しやすくなります。
Propertiesに面積を保存する場合は、その面積が何を意味するのかを明確にしましょう。Geometryからの計算値なのか、台帳上の正式値なのか、概算値なのか、過去の参考値なのかが分からないと、後から判断に迷います。単位、計算日、計算方法、確認状態をあわせて管理することで、属性値と形状の不一致を発見しやすくなります。
そして、更新履歴を残すことも重要です。現地確認や設計変更、協議結果によってPolygonが変われば、面積も変わる可能性があります。いつ、なぜ、どの範囲を修正したのかが分かる状態にしておけば、過去の面積との差を説明しやすくなります。提出済みデータや承認済みデータは、後から確認できるように版を分けて保存しておくと安心です。
GeoJSONのPolygon面積管理を実務で安定させるには、難しい仕組みを最初から作るよりも、確認すべき前提をそろえることが効果的です。座標、Geometry、面積属性、計算方法、更新履歴を一体で見ることで、単なる地図表示から、説明できる面積管理へと進められます。
現場で取得した位置情報をすばやく整理し、Polygonや面積管理に活用したい場合は、現地での記録精度と後工程でのデータ整理をつなげることが重要です。スマートフォンを使った現地計測や位置情報付きの記録を業務に取り入れたい方は、GeoJSONを扱う前段階の現地データ取得手段として、LRTK Phoneの活用も検討すると、現場確認から面積管理までの流れを整理しやすくなります。