GeoJSONから面積を計算する時に押さえる5つの基礎

GeoJSONは、区域、筆界、敷地、道路、施設範囲、調査対象エリアなどを地図上で扱うために便利なデータ形式です。現場調査や台帳整理、設計資料の確認、行政資料の二次利用などでGeoJSONを受け取った時、面積もそのまま簡単に出せると思いがちですが、実務では注意が必要です。見た目には同じポリゴンでも、座標の解釈、投影方法、穴の扱い、境界の閉じ方、単位、精度管理によって、計算結果は変わります。特に、緯度経度のまま単純な平面計算をしてしまうと、面積の単位や値が実務に使えないものになることがあります。この記事では、geojsonで検索して面積計算の基本を確認したい実務担当者に向けて、公開前の資料確認や現地管理に使いやすい形で、押さえるべき基礎を整理します。

目次

• GeoJSONの面積計算は座標の意味を確認するところから始める

• 緯度経度のまま面積を計算しない

• ポリゴンの外周と穴の扱いを確認する

• 単位、丸め、誤差の扱いを決めてから結果を見る

• 現地確認と属性管理まで含めて面積を使う

GeoJSONの面積計算は座標の意味を確認するところから始める

GeoJSONから面積を計算する時に最初に確認したいのは、そのデータが何を表しているかです。GeoJSONは地物の形状と属性をまとめて扱える形式であり、点、線、面を表現できます。面積計算で主に対象になるのは、区域を表すPolygonまたはMultiPolygonです。Polygonは一つの面、MultiPolygonは複数の面を一つの地物としてまとめた形です。例えば一つの敷地が道路で分断されている場合や、複数の調査区画を一つの管理単位として扱う場合には、MultiPolygonとして表現されることがあります。

ここで注意したいのは、GeoJSONに入っている座標値そのものが面積を直接持っているわけではないという点です。GeoJSONは境界線を構成する点の並びを記録しているだけであり、面積はその点列をどの座標系でどう解釈するかによって後から計算されます。見た目として地図上にきれいな区域が表示されていても、計算に使う座標の意味を誤ると、面積値は簡単にずれます。

GeoJSONでは、座標は一般的に経度、緯度の順で記録されます。日常的な表現では緯度、経度の順で言うことが多いため、ここを取り違えると位置が大きく変わります。日本国内のデータであれば、経度はおおむね120度台から150度台、緯度はおおむね20度台から40度台に収まることが多いため、値の並びを見るだけでも違和感に気づける場合があります。ただし、現場の担当者が毎回座標値を目視で判定するのは現実的ではありません。データを受け取った段階で、座標の並び、座標系、測地系、作成元、更新日、対象範囲を確認する運用にしておくことが大切です。

また、GeoJSONには属性情報も含まれます。属性には地番、区画番号、施設名、調査日、分類、面積値などが入っていることがあります。しかし、属性として入っている面積値と、形状から再計算した面積値が一致するとは限りません。過去に別の図面から転記された面積、登記や台帳上の面積、現況測量に基づく面積、概算で入力された面積が混在している場合もあります。したがって、GeoJSONから面積を計算する場合は、属性に既存の面積値があるかどうかを確認しつつ、それが何に基づく値なのかを分けて考える必要があります。

実務でよくある失敗は、地図画面に表示された区域を見て、そのまま面積計算ボタンを押し、出てきた数値だけを成果として扱ってしまうことです。これでは、面積値がどの座標系で計算されたのか、穴や重複が考慮されているのか、平方メートルなのか別の単位なのか、説明できなくなる可能性があります。面積を報告書、積算、用地確認、点検範囲管理、関係者説明に使うなら、計算前の条件を残すことが重要です。

GeoJSONの面積計算は、単なる数値処理ではなく、空間データの意味を整理する作業です。区域の形状が正しいか、属性が実態と合っているか、座標の順番が正しいか、単一の面なのか複数面なのか、境界が閉じているかを確認してから計算に進むことで、後工程での手戻りを減らせます。特に、別部署や外部から受け取ったGeoJSONを使う場合は、自分たちの作業環境で表示できたことだけを根拠にせず、面積計算に耐えるデータかどうかを確認する姿勢が必要です。

緯度経度のまま面積を計算しない

GeoJSONから面積を計算する時に最も重要な基礎の一つが、緯度経度のまま単純な平面面積を求めないことです。GeoJSONで扱われる座標は、多くの場合、経度と緯度で表されます。経度と緯度は角度の単位であり、メートルではありません。そのため、経度差と緯度差をそのまま縦横の長さとして扱うと、平方メートルの面積にはなりません。

地球上では、緯度1度あたりの距離と経度1度あたりの距離は同じではありません。緯度方向の距離は比較的一定に近い一方、経度方向の距離は赤道付近では長く、高緯度になるほど短くなります。日本国内の範囲だけを見ても、北海道と沖縄では同じ経度差が表す地上距離が変わります。したがって、経度緯度の座標値をそのまま平面上のX座標、Y座標のように扱うと、地域によって面積の歪みが生じます。

実務で面積を平方メートルとして扱いたい場合は、目的に合った平面座標へ変換してから計算するのが基本です。日本国内の測量や設計に近い用途であれば、対象地域に合った平面直角座標系など、距離と面積を扱いやすい座標系に変換して計算する考え方が一般的です。広域の行政区域、流域、森林、農地、海岸部などを扱う場合は、対象範囲に応じて面積の歪みが小さくなる方法を選ぶ必要があります。小さな敷地の概算と、都道府県をまたぐ広域面積では、適した考え方が異なります。

ここで大切なのは、面積計算の目的を先に決めることです。現地の概略把握でよいのか、積算や発注数量に使うのか、法的な面積の根拠に近い扱いをするのか、社内比較用なのかによって、必要な精度や説明責任は変わります。概略用途なら簡易な計算でも足りる場面がありますが、成果として外部に提出する場合や数量判断に使う場合は、座標変換と計算条件を明記できる状態にしておくべきです。

また、GeoJSONを扱うソフトウェアや処理環境によって、内部で自動的に面積計算方法を切り替えるものもあれば、表示座標のまま単純に計算するものもあります。画面上に面積が表示されたからといって、必ず適切な地理計算が行われているとは限りません。使用している処理環境が、緯度経度データに対して地球の丸みを考慮するのか、平面座標への変換を前提としているのかを確認する必要があります。

特に注意したいのは、地図上で表示するための座標と、面積を正確に計算するための座標を混同することです。地図表示では、広く使われる表示用の投影方法によって、画面上の見やすさが優先されることがあります。しかし、表示に便利な座標表現が、面積計算に最適とは限りません。表示できることと、面積を正しく求められることは別の話です。

面積計算の手順としては、まずGeoJSONの座標が経度緯度であることを確認し、次に対象地域に合う平面座標へ変換し、そのうえでPolygonまたはMultiPolygonの面積を計算します。計算後は、単位が平方メートルで出ているか、ヘクタールや平方キロメートルへ換算する必要があるかを確認します。この流れを定型化しておけば、担当者が変わっても同じ基準で面積を扱えます。

GeoJSONの面積計算で大きな誤差が出る原因の多くは、複雑な数学以前に、座標の単位を誤っていることにあります。経度緯度は地球上の位置を表す角度であり、面積計算に使う長さではありません。この基本を押さえるだけでも、実務上のミスはかなり減らせます。

ポリゴンの外周と穴の扱いを確認する

GeoJSONの面積計算では、ポリゴンの外周と穴の扱いも重要です。Polygonは、一つまたは複数の線の輪で構成されます。最初の輪が外周を表し、その内側に続く輪が穴を表す構造です。外周は面積に加算され、穴は面積から差し引かれます。例えば、敷地の中に除外区域がある場合、建物の対象外部分がある場合、調査区域の中に立入不可範囲がある場合などは、穴として表現されることがあります。

見た目だけでは、穴が正しく認識されているか判断しにくいことがあります。地図画面では外周と内周が線で表示されていても、データ構造として穴になっていなければ、面積から差し引かれません。逆に、本来は独立した小さな区域であるものが穴として扱われてしまうと、面積が不自然に小さくなります。GeoJSONを受け取った時は、単に図形が表示されるかだけではなく、外周と内周の関係が正しく構造化されているかを確認する必要があります。

ポリゴンの点列が閉じているかも大切です。GeoJSONのポリゴンでは、輪の最初の座標と最後の座標が同じであることが求められます。閉じていない点列でも処理環境によっては自動的に補正して表示される場合がありますが、面積計算ではエラーになったり、想定外の結果になったりすることがあります。現場で受け取るデータの中には、編集途中の図形、手入力で作られた境界、変換処理で一部が崩れたデータが含まれることもあります。面積計算前に、ポリゴンとして有効かどうかを検査することが重要です。

また、自己交差にも注意が必要です。境界線が自分自身と交差している図形は、見た目には面のように見えても、どの部分を内側とみなすかが曖昧になります。たとえば、点列の順序が乱れて蝶のように交差した形になっている場合、計算される面積は処理環境によって変わることがあります。境界点を結ぶ順序が正しいか、不要な折り返しがないか、隣接する区画との境界が重複していないかを確認しておくと安心です。

MultiPolygonの場合は、複数の面を合算する考え方になります。ただし、複数の面が重なっている場合に単純合算すると、重複部分を二重に数える可能性があります。管理上は別の区域として登録されていても、実際の空間上では重なっていることがあります。例えば、調査範囲と施工範囲、管理区域と規制区域、既存図面と現況図面を重ねた時に、重複や隙間が見つかることがあります。面積を出す前に、合算対象なのか、重複を取り除く対象なのかを明確にする必要があります。

外周と穴、重複と隙間の確認は、面積計算だけでなく、現地作業の手戻り防止にもつながります。図面上では一つの区域として扱われていたのに、現地では除外すべき構造物があった、境界線が水路や道路の中心線とずれていた、隣接地との境に小さな隙間があったということは珍しくありません。GeoJSONの形状を確認する段階で、外周、内周、重複、隙間、自己交差を点検しておくことで、面積値に対する説明力が高まります。

面積計算を自動化する場合でも、ポリゴンの妥当性チェックは省略しない方がよいです。大量のGeoJSONを一括処理する時ほど、一つひとつの形状を目視で確認するのは難しくなります。そのため、閉じていないポリゴン、自己交差しているポリゴン、面積が極端に小さいポリゴン、異常に大きいポリゴン、穴の数が多すぎるポリゴンなどを検出し、確認対象として分ける仕組みが有効です。結果の一覧だけを見るのではなく、異常値を拾える運用にしておくことが、実務での信頼性を支えます。

GeoJSONから面積を計算する時、数式やツールの使い方に意識が向きがちですが、実際には入力図形の品質が結果を大きく左右します。外周と穴の扱いを理解し、ポリゴンとして正しい形になっているかを確認することは、面積計算の前提そのものです。

単位、丸め、誤差の扱いを決めてから結果を見る

GeoJSONから面積を計算した後は、単位、丸め、誤差の扱いを決める必要があります。面積値は単に数字として出せばよいものではありません。平方メートルで扱うのか、ヘクタールで扱うのか、平方キロメートルで扱うのかによって、読み方も報告の粒度も変わります。小規模な敷地や施工範囲であれば平方メートルが扱いやすく、農地や森林、広い区域ではヘクタールが使いやすい場合があります。広域の統計や概略説明では平方キロメートルの方が適していることもあります。

単位を決めずに面積値だけを共有すると、誤解が起こります。例えば、同じ10000という数字でも、平方メートルなのか、平方キロメートルなのか、ヘクタール換算前の値なのかで意味がまったく違います。資料に面積値を記載する時は、必ず単位を併記し、必要に応じて換算の考え方も統一します。社内で扱う台帳、調査表、報告書、図面注記の単位がばらばらだと、後から比較や集計をする時に手間が増えます。

丸め方も重要です。面積計算では、小数点以下まで細かい値が出ることがあります。しかし、座標データ自体の精度や調査方法を考えずに細かい桁まで表示すると、実際以上に正確であるように見えてしまいます。現地で取得した境界点の精度、元図面の縮尺、変換時の誤差、ポリゴン編集時の丸めなどを考慮し、表示桁数を決める必要があります。概算面積であれば整数平方メートルや一定桁で丸める方が自然な場合がありますし、詳細な数量管理では小数点以下の扱いを明確にする必要があります。

ここで避けたいのは、計算結果の小数点以下の桁数をそのまま信頼性の高さと勘違いすることです。処理環境は数値として細かい桁まで返すことができますが、その桁まで現地の形状が保証されているとは限りません。元データが概略図から作られている場合、境界点の位置が数十センチから数メートル程度ずれていることもあります。その場合、面積値を小数点以下まで出しても、実務上の意味は薄いです。面積の桁数は、データの由来と用途に合わせるべきです。

誤差の扱いでは、座標変換による誤差、測量や入力による誤差、境界解釈による誤差を分けて考えると整理しやすくなります。座標変換による誤差は、適切な座標系を選ぶことで抑えられます。測量や入力による誤差は、現地での取得方法や元資料の精度に依存します。境界解釈による誤差は、どの線を区域境界とみなすか、中心線を使うのか端部を使うのか、除外区域を含めるのかどうかといった判断に関係します。これらを一つの面積値だけで表現しようとすると、説明が難しくなります。

面積値を比較する場合も注意が必要です。二つのGeoJSONから計算した面積が違う時、その差が実際の区域変更を意味するとは限りません。片方は緯度経度のまま計算され、もう片方は平面座標に変換されているかもしれません。片方は穴を差し引き、もう片方は穴を無視しているかもしれません。境界点の間引きや簡略化が行われている場合もあります。面積差を議論する時は、同じ計算条件で再計算したうえで比較することが大切です。

また、GeoJSONの座標は小数で記録されます。座標値の桁数が少ないと、点の位置が丸められ、細かい境界形状が失われることがあります。特に小さな区画や細長い区域では、座標の丸めが面積に影響しやすくなります。データを圧縮したり、地図表示用に軽量化したりする過程で、点が間引かれている場合もあります。表示用に簡略化されたGeoJSONを面積計算に使うと、元の詳細形状とは異なる面積になる可能性があります。

実務では、計算用データと表示用データを分ける考え方も有効です。表示用データは軽く扱いやすいことが重視され、計算用データは形状精度が重視されます。Web画面や共有資料で素早く見せるためのGeoJSONと、成果面積を算出するためのGeoJSONを同じものとして扱うと、思わぬ誤差につながることがあります。どのデータを正式な面積計算に使うのかを決めておくと、後で結果を追跡しやすくなります。

単位、丸め、誤差の扱いは、面積計算の最後に考えるものではなく、計算前に決めておくべき条件です。結果を見てから都合よく桁数を変えると、資料間の整合性が崩れます。平方メートルで整数表示にするのか、小数第何位まで出すのか、概算値として扱うのか、正式な数量として扱うのかを事前に決めることで、面積値を安心して共有できます。

現地確認と属性管理まで含めて面積を使う

GeoJSONから面積を計算できるようになると、地図上の区域管理は大きく効率化します。しかし、実務で重要なのは、計算した面積をどう使うかです。面積値は単独で存在するものではなく、現地状況、写真、調査記録、属性情報、更新履歴と結びついて初めて意味を持ちます。特に、施工管理、点検、用地確認、災害調査、維持管理などでは、地図上の面積と現場の実態が一致しているかを確認することが欠かせません。

GeoJSON上の区域は、机上で作成された図面や既存台帳をもとにしている場合があります。そのため、現地には図面にない構造物、仮設物、植生、段差、立入制限、舗装範囲の違い、水路や法面の変化が存在することがあります。面積計算の結果だけを見て判断すると、実際に作業できる範囲や管理すべき範囲とずれる可能性があります。面積を業務に使うなら、現地確認で境界や対象範囲を点検し、必要に応じてGeoJSONを更新する流れを作ることが大切です。

属性管理も重要です。GeoJSONには、地物ごとに属性を持たせることができます。面積計算の結果を属性として保存する場合は、計算日、計算方法、使用した座標系、単位、丸め条件、担当者、元データの版を一緒に管理すると、後から確認しやすくなります。単にareaという項目に数値だけを入れると、その面積がいつ、どの条件で計算されたものなのか分からなくなります。更新が繰り返される現場では、面積値の由来を追えることが実務上の安心につながります。

また、面積を属性として持たせる場合、形状が変更された時に面積値も更新される運用にしておく必要があります。ポリゴンの境界を編集したのに、属性の面積値が古いまま残っていると、地図上の形状と表の数値が一致しません。この不一致は、報告書作成や数量集計の段階で混乱を生みます。形状編集後に自動または手順化された再計算を行い、更新日も合わせて記録することが望ましいです。

現地写真との連携も有効です。面積計算の対象範囲がどのような状態だったのかを写真で残しておけば、後から境界判断や除外範囲の説明がしやすくなります。特に、草木で境界が見えにくい場所、施工前後で状態が変わる場所、一時的な資材置場、災害後の変状範囲などでは、位置情報付きの写真が役立ちます。GeoJSONの区域と写真の撮影位置を関連づけることで、面積値だけでは伝わらない現場の状況を補足できます。

チームでGeoJSONを扱う場合は、データの版管理も欠かせません。同じ区域でも、初回調査版、修正版、承認版、施工後版など複数のデータが存在することがあります。どの版から面積を計算したのかが分からないと、関係者間で数値が食い違います。ファイル名だけに頼るのではなく、属性や管理台帳の中で版、作成日、更新理由を管理すると、面積値の信頼性が高まります。

面積計算の結果を外部に共有する場合は、図形と数値をセットで示すと分かりやすくなります。数値だけを伝えると、どの範囲を計算したのかが曖昧になります。逆に、地図だけを見せると、数量判断に必要な情報が不足します。GeoJSONの区域、計算面積、単位、計算条件、現地確認メモを一体として管理することで、社内外の説明がしやすくなります。

さらに、面積を使った判断では、対象範囲の定義を明確にすることが重要です。例えば、道路の補修範囲を面積で管理する場合、車道部分だけなのか、路肩や歩道を含むのか、既設構造物の控除を行うのかによって面積は変わります。敷地や調査範囲でも、境界線の中心を使うのか、構造物の外形を使うのか、立入不可部分を除くのかで結果が変わります。GeoJSONの形状作成ルールを業務内で統一しておくと、面積計算のばらつきを減らせます。

GeoJSONから面積を計算することは、単に地図データを数値化する作業ではありません。現地とデータをつなぎ、属性として管理し、更新履歴を残し、関係者が同じ前提で判断できる状態を作ることです。計算結果を一度出して終わりにするのではなく、現地確認、属性更新、版管理、写真記録まで含めて運用することで、面積データは実務に使える情報になります。

GeoJSONの面積計算を実務で安定させるまとめ

GeoJSONから面積を計算する時に押さえるべき基礎は、座標の意味、座標変換、ポリゴン構造、単位と誤差、現地管理の五つに整理できます。GeoJSONは便利な形式ですが、ファイルを読み込めば必ず正しい面積が得られるわけではありません。座標が経度緯度で記録されているのか、面積計算に適した平面座標へ変換しているのか、外周と穴が正しく扱われているのか、結果の単位や丸めが業務目的に合っているのかを確認する必要があります。

特に、緯度経度のまま平面計算をしてしまうミスは避けるべきです。経度と緯度は角度であり、メートル単位の座標ではありません。面積を平方メートルとして扱うには、対象地域や用途に合った計算方法を選び、条件を記録しておくことが重要です。また、ポリゴンが閉じているか、自己交差していないか、穴や複数面が正しく表現されているかを確認することで、計算結果の信頼性を高められます。

面積値は、単位や桁数をそろえて初めて比較しやすくなります。小数点以下まで細かく出るからといって、その桁まで現地精度があるとは限りません。元データの精度、作成方法、座標変換、境界判断を踏まえ、実務に合った表示桁数を決めることが大切です。さらに、面積を属性として保存する場合は、計算日、方法、単位、元データの版を残しておくと、後から説明しやすくなります。

現場で使う面積データは、机上のGeoJSONだけで完結しません。実際の境界、構造物、除外範囲、立入状況、施工前後の変化を確認し、必要に応じて形状や属性を更新することで、地図データと現地のずれを小さくできます。位置情報付き写真や現地メモと組み合わせれば、面積値の根拠をより分かりやすく残せます。

これからGeoJSONを使って面積計算を業務に取り入れるなら、まずは一つの標準手順を決めることをおすすめします。受領したGeoJSONの座標と形状を確認し、計算用の座標へ変換し、ポリゴンの妥当性を検査し、面積を計算し、単位と丸めを統一し、属性と現地記録に反映する流れです。この手順を社内で共有しておけば、担当者ごとの判断差を減らし、面積値を安心して使えるようになります。

現地で取得した位置情報や写真、点群、図面を一体で扱える環境が整うと、GeoJSONの面積計算はさらに実務に近づきます。現場で確認した範囲をその場で記録し、後から面積や属性と結びつけて管理できれば、調査、施工、維持管理の情報整理がしやすくなります。スマートフォンを活用して高精度な位置情報と現地記録を残したい場合は、LRTK Phoneのような現場向けの計測環境を組み合わせることで、GeoJSONを使った面積管理をより確かな業務フローへつなげられます。