GeoJSONは、点、線、面などの地理情報を扱いやすい形式で表現できるデータ形式です。位置情報を含む業務では、地図上に表示するだけでなく、距離を測る、範囲内にある対象を抽出する、複数の面が重なる部分を確認する、線沿いの影響範囲を調べるといった空間分析が必要になる場面があります。Turf.jsは、GeoJSONデータを使った処理を行うための代表的なJavaScriptライブラリの一つとして知られています。
ただし、GeoJSONを空間分析に使う場合は、単にデータを読み込めば正しい結果が出るわけではありません。座標の順序、座標参照の前提、形状の種類、単位、面データの閉じ方、線や点の意味、処理前後の属性管理などを理解しておかないと、見た目は問題なくても分析結果が現場感覚と合わないことがあります。この記事では、「geojson 使い方」で調べている実務担当者に向けて、GeoJSONをTurf.jsで空間分析に使う際に押さえておきたい基本を6つに分けて解説します。
GeoJSONの構造を理解してから分析に使う
GeoJSONをTurf.jsで扱う前に、まずGeoJSONがどのような構造で地理情報を表しているのかを理解しておくことが大切です。GeoJSONは、地物を表すための形式であり、点、線、面などの形状情報と、それに付随する属性情報をまとめて扱えます。空間分析では、この形状情報をもとに距離や面積、重なり、包含関係などを判定していきます。
GeoJSONでは、個別の地物はFeatureとして扱われることが多く、その中にgeometryとpropertiesが含まれます。geometryは地理的な形状を表す部分で、Point、LineString、Polygonなどの種類があります。propertiesは属性情報を入れる部分で、名称、管理番号、分類、調査日、状態、担当区分など、実務で必要な情報を保持できます。複数のFeatureをまとめる場合はFeatureCollectionとして扱います。
空間分析を行うときは、geometryだけでなくpropertiesも重要です。たとえば、範囲内にある点を抽出するだけであれば座標だけで処理できますが、その点が何の施設なのか、いつ調査されたものなのか、どの管理区分に属するのかを確認するにはpropertiesが必要です。分析結果を現場で使うためには、処理後に属性情報が失われていないか、必要な項目が残っているかも確認しなければなりません。
GeoJSONの使い方でつまずきやすいのは、見た目の地図表示と分析用データの品質を同じものとして考えてしまう点です。地図上では点や線が表示されていても、geometryの種類が想定と違う、座標配列の階層が崩れている、Polygonの外周が閉じていない、属性名がばらばらになっていると、分析時にエラーが出たり、意図しない結果になったりすることがあります。表示できることと、分析できることは同じではないと考えるのが安全です。
実務では、GeoJSONを受け取った段階で、まずFeatureCollectionなのか単独のFeatureなのかを確認します。次に、geometryの種類が分析目的に合っているかを確認します。点を対象にした近接判定をしたいのに線データが混じっている、面積を計算したいのにPolygonではなくLineStringになっている、といった状態では、期待する処理ができません。データの形式を確認する作業は地味ですが、後工程の手戻りを防ぐうえで非常に重要です。
また、GeoJSONでは同じデータ内に複数種類のgeometryが含まれることもあります。管理対象としては便利な場合もありますが、空間分析では処理対象を明確に分けたほうが安定します。点だけを対象にする処理、線だけを対象にする処理、面だけを対象にする処理を分けることで、結果の解釈もしやすくなります。特に自動処理や定期処理に組み込む場合は、入力データの条件をあいまいにしないことが重要です。
GeoJSONをTurf.jsで使う基本は、まずデータを「地図に載せるもの」ではなく「計算に使う地理情報」として見ることです。どの地物が、どの形状で、どの属性を持ち、どの分析に使われるのかを整理してから処理を始めることで、分析結果の信頼性が高まります。
座標順序と座標系の前提をそろえる
GeoJSONを使ううえで特に注意したいのが、座標の順序です。GeoJSONの位置情報は、地理座標として扱う場合、一般に経度、緯度の順で記述します。日常的には緯度、経度の順で表現されることも多いため、手入力や別形式からの変換時に順序を逆にしてしまうミスが起こりやすくなります。座標順序が逆になると、地物がまったく別の場所に表示されたり、分析結果が大きくずれたりします。
たとえば、ある地点の座標を扱う場合、緯度と経度を入れ替えてしまうと、見た目で明らかにおかしい位置へ飛ぶことがあります。しかし、処理範囲が広い場合や、海外を含むデータを扱う場合には、誤りにすぐ気づけないこともあります。空間分析では、距離計算や範囲判定が座標値に依存するため、座標順序の誤りは非常に大きな問題になります。
座標系の前提も重要です。RFC 7946に沿ったGeoJSONでは、基本的にWGS 84の経度緯度として位置を扱う前提があります。一方で、現場の図面や測量成果では、平面直角座標や任意のローカル座標が使われることもあります。図面上の座標や現場で使うローカル座標を、変換条件を確認しないままGeoJSONに入れてしまうと、地理的な位置情報として正しく扱えない場合があります。Turf.jsで距離や面積を求める場合も、入力座標の前提を確認しておく必要があります。
実務では、測量成果、台帳データ、図面データ、現地調査データなど、さまざまな出所の位置情報を組み合わせることがあります。このとき、すべてのデータが同じ座標の前提で作られているとは限りません。あるデータは経度緯度、別のデータは平面直角座標、さらに別のデータは任意のローカル座標ということもあります。これらを確認しないままGeoJSON化すると、地図上の表示や空間分析の結果に不整合が生じます。
座標の前提をそろえるには、データの入手時点で座標の種類、単位、原点、方向、変換条件を記録しておくことが有効です。すでにGeoJSONになっているデータでも、どの基準で作られたものなのかを確認する必要があります。ファイル名や属性名だけでは判断できない場合もあるため、作成元の資料や変換時の設定を残しておくことが大切です。
また、座標値の桁数にも注意が必要です。経度緯度の小数点以下の桁数が少なすぎると、位置の精度が粗くなります。一方で、必要以上に細かい桁数があっても、元データの精度を超えた正確さを意味するわけではありません。空間分析では、数値として細かく見えることよりも、元データの精度、取得方法、用途に見合った扱いになっているかが重要です。
Turf.jsを使った処理そのものが適切でも、入力するGeoJSONの座標順序や座標系の前提が誤っていれば、結果は信頼できません。分析前には、代表点をいくつか確認し、想定した場所にあるか、他の基準データと重なるか、距離感が現場の感覚と一致するかを確認することが基本です。座標の前提をそろえることは、GeoJSONの使い方の中でも最初に押さえるべき重要な工程です。
点・線・面の性質に合わせて処理を選ぶ
GeoJSONで扱う地物には、点、線、面という基本的な性質があります。Turf.jsで空間分析を行う場合も、この性質に合わせて処理を選ぶ必要があります。点は位置を表し、線は経路や境界のような連続した形を表し、面は範囲や区域を表します。それぞれ意味が異なるため、同じ「近い」「重なる」「含まれる」という表現でも、実際に行う処理は変わります。
点データは、施設位置、写真撮影位置、調査地点、事故地点、基準点、設備位置などを表す場面でよく使われます。点に対する分析では、ある範囲内に点が入っているか、点同士の距離が近いか、最寄りの対象はどれか、といった処理が中心になります。点は単純に見えますが、属性情報との組み合わせが重要です。たとえば範囲内に点が入っていても、その点が調査対象なのか参考情報なのかによって、結果の扱いは変わります。
線データは、道路中心線、管路、河川、境界線、移動経路、調査ルートなどを表す場面で使われます。線に対する分析では、線の長さ、線と点の距離、線と面の交差、線同士の重なりなどを扱います。線は端点や折れ点の位置によって形が決まるため、簡略化されすぎていると実際のルートや境界とずれることがあります。長さや近接判定を行う場合は、線がどの程度細かく表現されているかも確認したいところです。
面データは、敷地、行政区域、施工範囲、影響範囲、危険区域、調査対象区域などを表す場面で使われます。面に対する分析では、点が面の中に入っているか、線が面を横切るか、面同士が重なるか、面積がどの程度か、といった処理を行います。Polygonでは外周リングが閉じた形状である必要があり、基本的には座標配列の始点と終点が一致します。また、穴のある面や複数の面をまとめたMultiPolygonでは、座標配列の構造が複雑になります。
点、線、面の性質を誤って扱うと、分析結果の意味が変わります。たとえば、道路を面ではなく線で表している場合、道路区域の中に施設があるかどうかを判定するには、線そのものではなく幅を持った範囲として扱う必要が出ることがあります。反対に、境界線のように線として意味を持つものを面に変換してしまうと、本来確認したい境界の位置があいまいになることがあります。
実務では、元データのgeometryがそのまま分析目的に合っているとは限りません。点を集計したいのか、線から一定距離以内を調べたいのか、面の中にある対象を抽出したいのかを先に決めてから、必要な形状に整えることが大切です。たとえば、線沿いの一定範囲を調べたい場合は、線データから範囲を生成して、その範囲と点や面を比較するという考え方になります。
また、ひとつの対象を複数の形状で扱うこともあります。道路であれば、中心線としての線データ、道路区域としての面データ、標識や施設としての点データが存在する場合があります。これらを同じ「道路データ」として一括りにするのではなく、それぞれが何を表しているかを明確にすることが、正しい空間分析につながります。
Turf.jsを使うと、GeoJSONの点、線、面に対してさまざまな処理を行えますが、処理を選ぶ前に、分析したい問いを整理することが重要です。「どこにあるか」「どれくらい近いか」「どの範囲に含まれるか」「どこが重なるか」「どれだけの面積か」という問いに対して、どのgeometryを使えば答えられるのかを考えることで、実務に使える分析結果になりやすくなります。
距離・面積・範囲判定の単位を確認する
GeoJSONをTurf.jsで空間分析に使うとき、距離や面積の単位を確認することは欠かせません。空間分析では、数値が出るとつい結果をそのまま信じたくなりますが、単位の理解があいまいなままだと、判定条件や説明資料に誤りが入りやすくなります。特に距離、面積、範囲判定は実務判断に直結しやすいため、どの単位で計算し、どの単位で表示するのかを明確にする必要があります。
距離計算では、点と点の距離、点と線の距離、線の長さなどを扱います。ここで重要なのは、入力データの座標が経度緯度であっても、出力される距離は処理で指定した単位や関数の仕様に従って扱う必要があるという点です。経度緯度の差をそのまま距離として読むことはできません。緯度方向と経度方向では、地表上の距離との対応が異なり、場所によっても変わります。そのため、距離として使う場合は、距離計算用の処理を通すことが基本です。
面積計算でも同じように、座標値から単純に面積を読み取ることはできません。面データの見た目が整っていても、計算方法や単位を確認しなければ、実務資料として使うには不十分です。面積を報告書や管理資料に転記する場合は、丸め方、表示単位、有効桁数、元データの精度をそろえておく必要があります。現地調査や図面由来のデータでは、取得精度や作成目的によって面積値の扱いが変わることもあります。
範囲判定では、ある点が面の中に入っているか、線が範囲と交差しているか、面同士が重なっているかを判定します。このような処理では、境界付近の扱いに注意が必要です。点が境界線上にある場合に内側と見るのか、外側と見るのか、判定処理や業務ルールによって解釈が変わることがあります。境界付近の対象は、単に処理結果だけで決めず、必要に応じて個別確認の対象にする運用が安全です。
単位の確認では、入力、処理、出力の3段階で考えると整理しやすくなります。入力段階では、GeoJSONの座標が想定した座標参照の前提に合っているかを確認します。処理段階では、距離や面積の計算に使う単位を確認します。出力段階では、利用者が読みやすい単位にそろえ、必要に応じて丸めや表記を統一します。この流れを決めておくと、同じデータから複数の担当者が別々に結果を出しても、数値のばらつきを抑えやすくなります。
実務では、判定条件を数値で設定する場面も多くあります。たとえば、ある対象から一定距離以内の点を抽出する、施工範囲内の写真だけを確認する、管理区域と重なる設備を洗い出すといった処理です。このとき、条件値の単位が明確でないと、抽出漏れや過剰抽出につながります。処理条件には、数値だけでなく単位と意図も記録しておくことが大切です。
また、分析結果を関係者へ共有する場合は、「計算結果として何が分かったのか」と「その数値をどのように解釈すべきか」を分けて説明すると伝わりやすくなります。たとえば、範囲内に含まれる点の数だけを示すのではなく、判定に使った範囲、距離条件、対象データ、集計時点をあわせて記載することで、後から結果を確認しやすくなります。
Turf.jsを使えば、距離や面積、範囲判定を効率よく処理できます。しかし、実務で重要なのは、処理できることそのものではなく、結果の単位と意味を正しく管理することです。GeoJSONの使い方を業務に定着させるには、計算前の条件確認と、計算後の説明のしやすさまで含めて設計することが必要です。
バッファや重なり判定で結果の意味を読み違えない
GeoJSONを使った空間分析でよく使われる考え方に、バッファと重なり判定があります。バッファは、点や線や面の周囲に一定距離の範囲を作る処理です。重なり判定は、複数の地物が交差しているか、重なっているか、片方がもう片方に含まれているかを確認する処理です。どちらも実務で役立つ処理ですが、結果の意味を正しく理解しておかないと、過大評価や見落としにつながることがあります。
バッファは、近接範囲を考えるときに便利です。たとえば、ある点から一定距離以内にある対象を抽出したい場合や、線沿いの影響範囲を確認したい場合に使えます。点からのバッファは円に近い範囲、線からのバッファは線に沿った帯状の範囲として考えられます。ただし、この範囲はあくまで計算上作成した範囲であり、現地の道路形状、地形、構造物、立入条件などをそのまま反映しているわけではありません。
線データからバッファを作る場合は、元の線が何を表しているかが重要です。道路中心線なのか、境界線なのか、調査ルートなのかによって、作成される範囲の意味が変わります。道路中心線から一定距離の範囲を作ったとしても、それが実際の道路区域と一致するとは限りません。幅員が場所によって変わる場合や、交差点、曲線部、分岐部がある場合は、単純なバッファだけでは現実の範囲を表しきれないことがあります。
面データの重なり判定では、重なっているかどうかだけでなく、どの程度重なっているかも重要になる場合があります。たとえば、管理区域と調査範囲が少しだけ接している場合と、大部分が重なっている場合では、実務上の意味が異なります。単に交差しているという結果だけでは判断が粗くなるため、必要に応じて重なり部分の面積や割合を確認することが有効です。
包含判定でも注意が必要です。点が面の中にあるかどうかを判定する処理はよく使われますが、境界線上の点や、座標精度が粗い点では判断が難しくなることがあります。現地で取得した位置情報には誤差が含まれるため、面の内外を厳密に二分するだけでは実態に合わない場合もあります。境界付近の点は、判定結果を絶対視せず、確認対象として抽出する運用も考えられます。
バッファや重なり判定を実務で使う場合は、分析結果を「確定情報」として扱うのではなく、「確認すべき対象を絞り込むための情報」として扱うほうが安全な場面があります。特に、法的な境界、権利関係、安全判断、施工可否判断などに関わる場合は、GeoJSONによる空間分析だけで結論を出さず、元資料や現地確認、関係者確認と組み合わせる必要があります。
また、複数の処理を重ねる場合は、各処理で発生する誤差や丸めの影響にも注意が必要です。たとえば、線からバッファを作り、そのバッファと面を重ね、その中に含まれる点を抽出するような処理では、元の線の精度、バッファ距離、面データの精度、点データの取得精度がすべて結果に影響します。処理が増えるほど、結果の見た目だけではなく、前提条件の記録が重要になります。
Turf.jsを使うと、バッファ作成、交差判定、包含判定、重なり部分の抽出などを比較的扱いやすく実行できます。しかし、処理の名前だけを見て使うのではなく、実務上その結果が何を意味するのかを考えることが重要です。空間分析の結果は、現場判断を助けるための材料です。結果をそのまま結論にするのではなく、データの精度、処理条件、業務目的に照らして読み解くことが、GeoJSONを安全に活用する基本です。
実務データとして扱いやすい形に整理する
GeoJSONをTurf.jsで分析した後は、結果を実務データとして扱いやすい形に整理することが重要です。空間分析は、処理を実行して終わりではありません。抽出された地物、作成された範囲、計算された距離や面積、重なり判定の結果を、確認、共有、再利用できる形に整えることで、初めて業務に活かせます。
まず意識したいのは、分析結果のpropertiesを整理することです。元の属性を残すのか、分析結果の属性を追加するのか、不要な項目を削除するのかを決めておく必要があります。たとえば、範囲内に含まれる点を抽出した場合、元の点ID、名称、分類、調査日などに加えて、どの範囲に含まれたのか、いつ判定したのか、どの条件で抽出したのかを属性として残しておくと、後から確認しやすくなります。
次に、ファイル名やデータ名の付け方も大切です。分析前のGeoJSON、処理途中のGeoJSON、分析後のGeoJSONが混在すると、どれが最新で、どれを共有すべきか分からなくなります。実務では、対象範囲、処理内容、作成日、版数などが分かる命名にしておくと管理しやすくなります。特に複数人で作業する場合は、ファイル名だけでなく、データ内の属性やメモにも処理条件を残しておくと安心です。
分析結果を再利用する場合は、geometryの種類も整理しておく必要があります。バッファ処理によって作成した面、重なり判定で抽出した面、点の抽出結果などを同じファイルにまとめると、後で使うときに意味が分かりにくくなることがあります。用途が異なる結果は、別ファイルや別レイヤーとして分けるほうが安全です。ひとつにまとめる場合でも、属性で種類を明確にしておくことが必要です。
データ量が多い場合は、処理速度や取り扱いやすさも考える必要があります。GeoJSONは人が読める形式で扱いやすい一方、大量の座標を含むとファイルサイズが大きくなりやすくなります。細かすぎる線や面をそのまま扱うと、表示や分析に時間がかかることがあります。ただし、形状を簡略化しすぎると、距離や面積、重なり判定に影響することがあります。簡略化を行う場合は、見た目の軽さだけでなく、分析目的に必要な精度を保てるかを確認することが大切です。
品質確認も欠かせません。分析後のGeoJSONを確認する際は、件数、geometryの種類、属性項目、座標の範囲、異常な位置に飛んでいる地物がないかを見ます。範囲抽出をした場合は、抽出件数が想定と大きく違っていないかを確認します。面積や距離を計算した場合は、極端に大きい値や小さい値がないかを確認します。異常値を見つけたら、処理条件だけでなく、元データに問題がないかまで戻って確認することが重要です。
また、分析結果を他の担当者に渡す場合は、データだけでなく、処理の説明を添えることが望ましいです。どの入力データを使い、どの条件で処理し、どの単位で数値を出し、どのような注意点があるのかを簡潔に残しておくと、受け取った側が誤解しにくくなります。GeoJSONはデータ形式としては扱いやすいものですが、業務上の意味は説明がないと伝わりにくいことがあります。
Turf.jsを使ったGeoJSON分析を実務に定着させるには、処理の自動化だけでなく、結果管理のルール化が必要です。入力データの確認、処理条件の記録、出力データの命名、属性の整理、品質確認、共有時の説明をひとつの流れとして整えることで、分析結果を継続的に使いやすくなります。GeoJSONの使い方を覚えるだけでなく、業務データとして残すところまで意識することが、現場で役立つ空間分析につながります。
まとめ
GeoJSONをTurf.jsで空間分析に使う場合、まずGeoJSONの構造を理解し、Feature、geometry、propertiesの役割を整理することが基本です。点、線、面のどの形状を使うのか、属性情報をどのように保持するのかを確認しておくことで、分析結果を実務で使いやすくなります。地図に表示できることと、空間分析に使えることは同じではありません。分析前のデータ確認が、結果の信頼性を大きく左右します。
次に、座標順序と座標系の前提をそろえることが重要です。GeoJSONでは地理座標を扱う場合、経度、緯度の順で座標を記述するのが基本であり、緯度、経度の順で入力してしまうと位置が大きくずれる原因になります。また、経度緯度のデータと平面座標やローカル座標を混在させると、距離や面積、範囲判定の結果が正しく解釈できなくなります。元データの基準、変換条件、精度を確認してから分析に使うことが大切です。
点、線、面の性質に合わせて処理を選ぶことも欠かせません。点は位置、線は経路や境界、面は範囲を表します。近接判定、長さの確認、面積計算、包含判定、重なり判定など、分析したい内容に応じて使うgeometryを選ぶ必要があります。同じ対象でも、中心線として扱うのか、区域として扱うのかによって、分析結果の意味は変わります。
距離や面積を扱う場合は、単位と丸め方を確認する必要があります。数値が出たからといって、そのまま実務判断に使えるとは限りません。入力座標、処理条件、出力単位、表示方法をそろえ、必要に応じて元データの精度も確認します。範囲判定では、境界付近の扱いに注意し、処理結果を絶対的な結論ではなく、確認対象を絞り込む材料として使う視点が大切です。
バッファや重なり判定は便利ですが、結果の意味を読み違えないことが重要です。線から作成した一定距離の範囲が、現実の道路区域や管理区域と一致するとは限りません。面同士が少し重なっている場合と大きく重なっている場合でも、実務上の判断は変わります。空間分析の結果は、データの精度、処理条件、現地状況、業務目的とあわせて解釈する必要があります。
最後に、分析結果を実務データとして整理することが大切です。処理後のGeoJSONには、元の属性だけでなく、判定条件や処理日、対象範囲、単位などを残しておくと再確認しやすくなります。ファイル名、属性名、版数、出力形式を整え、他の担当者が見ても意味が分かる状態にしておくことで、GeoJSONを一度きりの作業ではなく、継続的に使える業務データとして活用できます。
GeoJSONとTurf.jsを組み合わせると、位置情報をただ表示するだけでなく、距離、面積、範囲、重なり、近接関係などをもとにした実務的な分析がしやすくなります。ただし、正しい結果を得るには、データ形式、座標の前提、geometryの意味、単位、処理条件、出力管理を丁寧に確認することが必要です。特定の処理結果をそのまま確定判断に使うのではなく、元資料や現地確認と照合しながら、業務目的に合ったGeoJSONの使い方を整えていくことが大切です。