GeoJSONのLineStringを使う前に知るべき基本4つ

目次

• LineStringは点ではなく線を表すための形状

• 座標の順序と単位を取り違えない

• LineStringで表せるものと表せないものを分けて考える

• 実務で使う前に確認したいデータ品質と現場連携

• まとめ

LineStringは点ではなく線を表すための形状

GeoJSONを扱うとき、最初に理解しておきたいのが、LineStringは「線」を表すための形状だということです。GeoJSONには、点、線、面などを表すGeometry型が用意されています。その中でLineStringは、複数の座標点を順番につないで、道路中心線、境界線、配管ルート、電線ルート、歩行経路、測量線、施工管理上の確認ラインなどを表現するときに使われます。

LineStringは、単に点が複数あるだけのデータではありません。重要なのは、座標の並び順に意味があることです。たとえば、ある道路の起点から終点までを表す場合、最初の座標が起点側、最後の座標が終点側になります。途中の座標は、線の折れ曲がりやカーブの近似、地物の変化点を示します。つまり、LineStringは「点の集合」ではなく「順序を持った点列」です。この違いを理解していないと、表示したときに線が意図しない方向へ飛んだり、経路が逆になったり、途中で折れ方がおかしく見えたりします。

GeoJSONでLineStringを記述するときは、形状の種類をLineStringとして指定し、coordinatesに座標の配列を入れます。概念としては、coordinatesの中に「1点目、2点目、3点目……」という形で座標を並べ、それらが順番に結ばれて1本の線になります。LineStringとして成立するには、coordinatesに2点以上の位置が必要です。1点だけでは線にならないため、点を表したい場合はPointとして扱う必要があります。

実務では、LineStringを「線として見えるから問題ない」と判断しがちです。しかし、表示上は線に見えても、データとしての意味が整理されていないことがあります。たとえば、現場で取得した点をそのまま並べた結果、測定順と本来の路線順が一致していない場合があります。この場合、LineStringとして描画すると線がジグザグに交差したり、戻ったりすることがあります。図面や地図上で見たときに大きな違和感がなくても、延長計算、ルート確認、点検区間の管理、出来形確認などに使うと誤差や混乱の原因になります。

LineStringを使う前には、その線が何を表しているのかをはっきりさせることが大切です。道路の中心線なのか、境界線なのか、施工範囲の端なのか、点検対象のケーブルや管路のルートなのかによって、必要な精度、座標の密度、属性情報、更新方法が変わります。単に線を表示するだけなら粗い座標でも足りることがありますが、現場で位置確認に使うなら、座標の根拠や取得方法まで確認する必要があります。

また、LineStringは1本の連続した線を表すためのものです。複数の離れた線をまとめて扱いたい場合、それを無理に1本のLineStringとしてつなぐと、存在しない線分が間にできてしまいます。たとえば、離れた2本の道路区間や、分断された排水路、別々の点検対象を1つのLineStringにまとめると、表示上は間がつながって見えてしまうことがあります。このような場合は、複数の線を別々のFeatureとして持つ、またはMultiLineStringのような複数線を扱える形状として整理するほうが自然です。

LineStringの基本は単純ですが、実務での影響は大きいです。点の並び順、線の連続性、線が表す対象、属性との対応関係を整理しておくことで、後工程でのトラブルを減らせます。GeoJSONを地図表示だけでなく、測量、施工、維持管理、現場確認に使う場合は、LineStringを「見た目の線」ではなく「意味を持つ線データ」として扱う意識が必要です。

座標の順序と単位を取り違えない

GeoJSONのLineStringで特に間違えやすいのが、座標の順序です。多くの地図や住所検索の感覚では「緯度、経度」と言いたくなりますが、現在広く参照されるRFC 7946に準拠したGeoJSONでは、地理座標を「経度、緯度」の順で扱います。つまり、日本国内の位置であれば、先に東西方向を示す経度、次に南北方向を示す緯度を入れる考え方です。この順序を逆にすると、位置が大きくずれたり、まったく別の場所に飛んだりします。

たとえば、本州、北海道、四国、九州など日本の多くの地域を扱う場合、緯度はおおむね30度台から40度台、経度は120度台から150度台に入ることが多くなります。これを逆にしてしまうと、経度として30度台、緯度として130度台のような不自然な値になり、緯度として扱える範囲を超えてしまいます。表示ソフトによってはエラーになったり、何も表示されなかったり、別の解釈で表示されたりします。LineStringの座標が1点でも逆になっていると、その点へ向かって線が大きく飛ぶため、見た目にも異常が出やすくなります。

座標順序の問題は、表計算ファイル、測量データ、写真の位置情報、図面から抽出した座標、現場アプリから出力したデータなどを変換するときに起きやすいです。元データでは緯度、経度の順で管理されているのに、GeoJSONへ変換するときにそのまま流し込んでしまうと、LineStringとしては正しい構文でも、位置としては間違ったデータになります。GeoJSONは、構文が合っていれば必ず実務上正しいというものではありません。構文の正しさと座標の正しさは別問題です。

次に注意したいのが、座標の単位と座標参照系です。RFC 7946に準拠したGeoJSONでは、座標はWGS 84の経度・緯度を10進度で扱う前提です。一方、現場の測量や設計では、メートル単位の平面直角座標やローカル座標を使うことが多くあります。平面座標のX、Yをそのまま標準的なGeoJSONの経度、緯度として入れてしまうと、地図上の正しい位置には表示されません。逆に、経度・緯度のデータをメートル単位の平面座標として扱うと、距離や面積の計算が大きく狂います。

この違いは、LineStringの長さを求めるときにも重要です。経度・緯度は角度の値であり、そのまま単純な平面距離として扱うことはできません。緯度方向と経度方向では、同じ0.0001度でも地表上の距離が異なります。特に、延長管理、施工数量、点検距離、掘削範囲、ケーブル長、道路延長などを求める場合、表示用のGeoJSONと計算用の座標処理を分けて考える必要があります。地図上で線が正しい位置に見えても、距離計算の方法が不適切であれば、数量や判断に影響します。

高さを含む座標にも注意が必要です。GeoJSONでは、経度、緯度に加えて3つ目の値として高さを持たせることがあります。RFC 7946では、この3つ目の値はWGS 84楕円体からの高さをメートルで表すものとして扱われます。ただし、実務で受け渡されるデータでは、地盤高、標高、構造物上面、測定機器の位置、補正済みの高さなど、意味が混ざりやすい部分でもあります。高さを入れたからといって、自動的に3D施工管理に使えるわけではありません。高さの基準、単位、測定方法、補正の有無を確認しておくことが大切です。

LineStringでは、各座標点の間が座標参照系上の直線で結ばれると考えるのが基本です。これは、地球の曲面に沿った最短経路と常に同じという意味ではありません。実際の道路や水路、ケーブル、境界が曲線であっても、GeoJSON上では複数の点を細かく置くことで近似します。そのため、どのくらいの間隔で点を置くかも重要です。点が少なすぎると、曲線が角張って表現され、実際のルートから外れて見えることがあります。点が多すぎると、データ量が増え、表示や処理が重くなることがあります。用途に応じて、表示の滑らかさとデータの扱いやすさのバランスを取る必要があります。

座標の精度も見落とせません。小数点以下の桁数が多いほど見た目には精密に見えますが、元の測定精度を超える桁数に意味があるわけではありません。数値だけ細かくても、取得方法が粗ければ実際の位置精度は高くありません。逆に、高精度な測量データを扱う場合は、変換や丸め処理によって必要な精度が失われないように注意が必要です。GeoJSONのLineStringを現場の判断に使うなら、座標の桁数だけでなく、測定方法、補正方法、更新日、座標系の扱いまで確認することが大切です。

LineStringで表せるものと表せないものを分けて考える

LineStringは便利な形状ですが、何でもLineStringで表せばよいわけではありません。GeoJSONを実務で使うときは、LineStringが得意な対象と、別の形状で扱うべき対象を分けて考える必要があります。ここを曖昧にすると、後からデータを集計したり、検索したり、現場で確認したりするときに扱いづらくなります。

LineStringが得意なのは、線状に連続する対象です。道路の中心線、歩道の端部、河川や水路の中心、排水管や通信管のルート、架空線や地中線の概略ルート、境界確認の補助線、測量の観測ライン、施工時の通り芯などが代表的です。これらは、起点から終点までのつながりがあり、途中の折れ点や曲がりを座標点として表すことで、地図上に分かりやすく表示できます。

一方で、幅を持つ対象をLineStringだけで表すと、情報が不足することがあります。道路、河川、敷地、施工範囲、規制範囲、掘削範囲などは、実際には幅や面積を持っています。中心線だけをLineStringで表すことはできますが、それだけでは端部や範囲を正確に表したことにはなりません。たとえば、道路中心線のLineStringがあっても、道路幅員、歩道幅、側溝位置、官民境界などは別の情報として持たせる必要があります。

境界線を扱う場合も注意が必要です。敷地境界や行政上の区画線のように、線そのものが意味を持つ場合はLineStringで扱えます。しかし、閉じた範囲を表したい場合は、線を閉じるだけではなく、面として扱うべきかを検討する必要があります。閉じたLineStringは見た目には囲いのように見えますが、データ上は面積を持つ範囲として扱われるとは限りません。範囲内外の判定、面積計算、塗りつぶし表示、重なり判定などを行うなら、Polygonのような面としてのデータ構造を選ぶほうが適しています。

また、分岐のあるネットワークを1本のLineStringで表すのも避けたほうがよい場合があります。道路網、配管網、ケーブル網のように、途中で分岐したり合流したりする対象は、複数の線分と接続点で管理するほうが自然です。1本のLineStringは基本的に一本筆書きのような連続線です。分岐を無理に1本で表すと、同じ点を何度も通ったり、実際には存在しない接続線ができたりして、ネットワークとしての意味が壊れます。

LineStringを使うときは、属性情報との対応も重要です。たとえば、道路中心線であれば路線名、区間番号、管理者、起点、終点、幅員、舗装種別、更新日などを属性として持たせることがあります。管路であれば管種、口径、埋設深さ、施工年度、点検日などが考えられます。LineStringは形状を表しますが、実務で必要なのは形状だけではありません。線が何を意味し、どの区間にどの属性が対応するのかが分かるようにしておく必要があります。

属性と形状の粒度が合っていない場合も問題になります。たとえば、1本のLineStringの途中で舗装種別が変わる、管径が変わる、管理者が変わる、点検状態が変わる、といったケースがあります。このとき、1本のLineStringに1つの属性だけを付けると、途中の変化を表現できません。区間ごとに属性が変わるなら、LineStringを適切な位置で分割し、区間単位で管理することが必要です。逆に、細かく分割しすぎると、全体の連続性が見えにくくなり、管理が煩雑になります。

実務でよくあるのは、表示用に作ったLineStringを、そのまま管理用、計算用、現場誘導用に使ってしまうことです。表示だけなら、ある程度簡略化された線でも十分なことがあります。しかし、現場で位置を確認する、延長を算出する、出来形と比較する、施工範囲を判断する、といった用途では、表示用の簡略線では不足する場合があります。用途ごとに求められる正確さが違うため、同じLineStringでも「何に使える線なのか」を明確にしておくことが大切です。

LineStringは、地図や図面の中で直感的に分かりやすい形状です。その分、つい多くの意味を背負わせてしまいがちです。しかし、線はあくまで線であり、面、点、ネットワーク、属性、時間変化、精度情報まで自動的に表してくれるものではありません。LineStringで表すべき対象を見極め、足りない情報は別の形状や属性として補うことで、GeoJSONのデータは実務に耐えやすくなります。

実務で使う前に確認したいデータ品質と現場連携

GeoJSONのLineStringを実務で使う前には、データ品質を確認する必要があります。見た目に線が表示されているだけでは、現場で使える状態とはいえません。特に、測量、施工管理、維持管理、点検、災害対応、設備管理などでは、座標の正確さや更新状態が判断に直結します。LineStringの品質確認は、単なるデータチェックではなく、現場作業の手戻りを減らすための準備です。

まず確認したいのは、線が正しい場所にあるかどうかです。背景地図や図面と重ねたときに、道路、境界、設備、施工対象と大きくずれていないかを見ます。ただし、背景側にも誤差や古さがあるため、重ねて合っているように見えるだけで安心してはいけません。重要な判断に使う場合は、元の測量成果、座標の取得方法、現場での確認結果と照らし合わせる必要があります。

次に、線の連続性を確認します。LineStringの途中に不自然な飛び、戻り、交差、重複、極端に長い線分がないかを見ます。現場で取得した点を並べ替えずに変換した場合、測定順の乱れによって線が行ったり来たりすることがあります。複数の区間を誤って1本につないだ場合、離れた場所が直線で結ばれることもあります。こうした異常は、地図の縮尺を変えながら確認すると見つけやすくなります。

点の密度も品質に関わります。曲がりが多い場所で点が少なすぎると、線が実際の形状から外れます。逆に、ほぼ直線の区間に点が過剰に多いと、データが重くなり、処理の負担が増えます。現場で使うLineStringでは、必要な変化点を残しながら、不要な点を整理する考え方が必要です。ただし、点を間引く場合は、元データを消してしまうのではなく、用途別に表示用と原本用を分けて管理するほうが安全です。

属性情報の不足もよくある問題です。LineStringだけが存在していても、それが何の線なのか、いつ作られたのか、誰が確認したのか、どの工区や区間に属するのかが分からないと、実務では使いにくくなります。特に複数人でデータを共有する場合、属性が不足していると、同じ線を見ても人によって解釈が変わります。地物名、区間名、作成日、更新日、測定方法、管理状態、注意事項など、最低限必要な属性を決めておくことが大切です。

更新管理も重要です。現場の状況は変わります。施工前、施工中、施工後で線の位置や意味が変わることがあります。仮設ルート、掘削予定線、出来形線、撤去済み設備、更新済み管路などを同じ見た目で混在させると、誤認の原因になります。LineStringには、現況、計画、施工中、完了、廃止などの状態を区別できる情報を持たせると、現場での判断がしやすくなります。

ファイルの受け渡しでは、文字コードや属性名の揺れにも注意が必要です。日本語の属性名や地物名を使う場合、環境によって文字化けすることがあります。また、同じ意味の項目が「路線名」「線名」「名称」のように複数の名前で管理されると、集計や検索がしづらくなります。組織内で使うGeoJSONであれば、属性名のルールをある程度そろえておくと、後の活用が楽になります。

現場連携を考えるなら、LineStringを机上で作って終わりにしないことも大切です。地図上では合っているように見えても、現場では見通し、障害物、高低差、立入制限、施工中の仮設物などによって確認しづらいことがあります。LineStringを現場に持ち出して確認する場合は、現在地との関係、線までの距離、進行方向、周辺の目印などを分かりやすく確認できる状態にしておく必要があります。

特に、スマートフォンやタブレットでGeoJSONを確認する場合、画面上の線と実際の位置がどの程度一致しているかが重要になります。端末単体の位置情報では、用途によっては精度が足りないことがあります。たとえば、概略確認や事前把握であれば十分でも、境界付近の確認、埋設物の位置確認、施工位置の誘導、出来形の確認に使うには、より高い位置精度が求められます。LineStringそのものが正しくても、現場で自分の位置がずれていれば、判断はずれてしまいます。

GeoJSONのLineStringは、現場でのデータ共有の入口として扱いやすい形式です。しかし、現場で本当に使うためには、データ形式だけでなく、位置精度、運用ルール、更新管理、端末での見え方、作業者への伝え方まで含めて設計する必要があります。地図に線を載せるだけでなく、その線を現場の人が迷わず使える状態にすることが、実務での価値につながります。

まとめ

GeoJSONのLineStringは、複数の座標点を順番につなぎ、線状の地物やルートを表すための基本的な形状です。構造はシンプルですが、実務で使う場合は、単に線が表示されるかどうかだけで判断してはいけません。LineStringが何を表しているのか、座標の順序は正しいか、単位や座標系の考え方は合っているか、線の連続性や属性情報は適切かを確認する必要があります。

最初の基本は、LineStringを「順序を持った点列」として理解することです。点をただ集めたものではなく、1点目から最後の点までを順番につないだ線として扱います。そのため、点の並び順が変わると、線の意味も変わります。道路、管路、境界、点検ルートなどを表すときは、起点と終点、途中の変化点、区間の切り方を整理してからデータ化することが大切です。

次に、座標の順序と単位を間違えないことです。RFC 7946に準拠したGeoJSONでは、地理座標を経度、緯度の順で扱い、WGS 84の経度・緯度を10進度で記述します。緯度、経度の順で管理された元データをそのまま変換すると、位置が大きくずれる原因になります。また、経度・緯度は度単位の座標であり、現場の平面座標やメートル単位の設計座標とは扱いが異なります。距離や数量の判断に使う場合は、表示用の座標と計算用の処理を分けて考える必要があります。

さらに、LineStringで表せるものと表せないものを見極めることも重要です。線状の対象には向いていますが、幅を持つ範囲、閉じた面、分岐を持つネットワーク、属性が途中で変わる区間などは、LineStringだけでは十分に表現できない場合があります。用途に応じて、線を分割したり、面や点のデータと組み合わせたり、属性情報を整理したりすることで、実務に使いやすいGeoJSONになります。

最後に、データ品質と現場連携を確認することです。LineStringが正しい場所にあり、途中で不自然に飛んでおらず、必要な属性があり、更新状態が分かることは、現場で使うための重要な条件です。さらに、スマートフォンやタブレットで確認する場合は、端末側の位置精度も重要になります。線データが正しくても、現場で表示する現在地がずれていれば、施工位置や点検位置の判断を誤る可能性があります。

GeoJSONのLineStringは、図面や地図の情報を現場へつなぐための扱いやすい形式です。道路、境界、配管、電線、施工ライン、点検ルートなど、線として管理したい情報を共有しやすくできます。ただし、実務で安心して使うには、形式の理解だけでなく、測位精度と現場での確認方法まで含めて考えることが欠かせません。

現場でGeoJSONの線データを確認し、実際の位置と照らし合わせながら作業したい場合は、端末の測位精度、補正情報の有無、背景地図の精度、データ更新ルールを合わせて確認することが大切です。LineStringで整理したルートや境界、施工ラインを安全に活用するには、地図上の見た目だけでなく、現場での確認方法と運用ルールまで含めて設計しましょう。