🛣️

オープンデータの道幅について調べた

2024/12/11に公開

この記事はFOSS4G Advent Calendar 2024 の11日目の記事です

運転しやすい道を検索する処理の条件で道幅が必要だった

運転しやすい道を検索するロジックを作る機会がありました。その時の検索条件で道幅が必須だったので色々調べました。
結論から言うと、オープンデータの中に道幅の判別に使えるデータはありましたがデータ量が少なかったり誤データが多くまともに使えませんでした。
その時に調べたことをまとめておきます。

なぜ道幅が必須なのかを簡単に説明するとこんな道を弾くためです。
image.png酷道

オープンデータの道幅に関するデータ

オープンデータから道幅を判別できるかもと思った方法は5つありました。

  • OpenStreetMap
    1. widthタグ
    2. lanesタグ
    3. highwayタグ
    4. yh:WIDTHタグ
  • 国土地理院
    • 基盤地図情報の道幅線と中央線を組み合わせる事で道幅を計算する

OpenStreetMap

width タグ

名前の通り道幅を表すタグで計測方法は道路両側の縁石間までになっていて単位はmです。
このデータを使用できれば嬉しいのですが問題がありデータが極端に少ないです。
以下はその例で、左側がある条件に合致する道路の区間データで、右側は左側のデータからwidthタグを含むものだけを絞り込んだデータになります。

元データ 元データからwidthタグを含むものを抜き出したやつ
元データ 元データからwidthタグを含むものを抜き出したやつ

ほかにも道幅の推定を表すタグにest_widthというものがあります。
こちらはwidthタグより計測方法がゆるいのでデータが増えるのかと思いきやそうではありませんでした。

元データ 元データからwidthタグを含むものを抜き出したやつ
元データ 元データからest_widthタグを含むものを抜き出したやつ

lanes タグ

こちらは道路の車線の数を表すタグです。
一般的な片側1車線の道路なら2となり1度に1台しか通行できない道は1となります。
このタグで判別できるのは車線数だけなので道幅の長さを正確には判別できませんが、2車線あればある程度の道幅があると判断する事ができます。
このタグは付与されている箇所が多く肌感全体の1/5くらい付与されています。

元データ 元データからlanes=2で絞り込んだもの
元データ 元データからlanes=2で絞り込んだもの

ですが、完璧な精度ではないのでlanes=2とされている道がこんな酷道なんて事もあったりします。
元データlanes=2

highway タグ

こちらは道路の種別を表していて重要な道路~重要でない道路を識別するためのタグです。
このタグは全ての道に割り当てられているのでデータ量が多いのが特徴です。
highway=residential(住宅へのアクセスとして機能する道路)は以下のような細い道なので、このタグからある程度細い道を除外する事ができます。

highway=residential StreetViewのURL
original StreetViewのURL

yh:WIDTH タグ

OpenStreetMapの中には企業が提供したデータも含まれおり企業が独自データと掛け合わせて分析するような時に提供してくれるらしいです。
そのデータの1つに道幅を表すyh:WIDTHタグがあります。
こちらはデータの精度はとてもよいのですがデータがとても少ないです。

元データ 元データからyh:WIDTHタグありで絞り込んだもの
元データ 元データからyh:WIDTHタグありで絞り込んだもの

国土地理院

道幅縁と道中央線を組み合わせて計算する

国土地理院が提供しているデータの中に道路縁道路中心線があり、そこから道幅を計算する事ができます。詳しい計算方法はこちらを御覧ください。
道幅縁とは道の縁をなぞった線の事です。これはただの線で道の内側か外側かの判別ができないので中央線とかけ合わせる事で内側の判定を行います。中央線から垂直に法線を上限に伸ばし衝突するまでの距離を計算する事で道幅の計算が行えます。

道幅縁のサンプル 道幅線と道中央線を重ねたもの
道幅縁のサンプル 道幅線と道中央線を重ねたもの
中央線から垂直に法線をのばしたもの。赤い区間×2が道幅
中央線から垂直に法線をのばしたもの。赤い区間×2が道幅

道幅縁と中央線のデータは全道路のものが公開されているのでデータ量は膨大です。なのでこれを使えば全ての道幅を求められると思っていました。
ですが問題が2つあります。

問題1

道幅縁には機械的に作図されている所人の手で作図された所の2パターンがあり、機械的に作図された所は道幅が正しくない。

機械的に作図されている箇所 人の手で細かく作図されたであろう箇所。
機械的に作図されている箇所幅は10mとなっているがStreetViewで確認すると・・・・ 人の手で細かく作図されたであろう箇所。

これは予想ですが、ベースの道幅線は機械的に幅を割り当ていてそこから少しづつ手で書いて直してと思われます。というのも、機械的に割り当てられているような道は幅の平均が10m前後になる事が多いので。
なので、細かく作図されている道に関しては正しい道幅を計算できますが機械的に作図された所は計算しても意味のない値になってしまいます。

問題2

道が交差していると道幅縁が重なってしまい正確な幅が計算できない。
中央線から伸ばした法線が衝突するまでの距離を道幅としているのでどうしても誤差がでてしまいます。

赤い線が中央線と道幅縁から計算した道幅赤い線が中央線と道幅縁から計算した道幅

まとめ

  • OpenStreetMap
    • width タグ
      • 道幅の長さを表すタグ。データが少ない。
    • lanes タグ
      • 車線数を表すタグ。データが多い(全体の1/5くらい)。道幅の長さは判別できないが広いか狭いかの判別には使える。誤データも含まれている。
    • highway タグ
      • 道路種別を表すタグ。全道に割り当てられているのでデータ量が多い。細い道を弾くのに使える。
    • yh:width タグ
      • 企業が提供した道幅の長さを表すタグ。精度は高いがデータが少ない。
  • 国土地理院
    • 道幅縁と道中央線を組み合わせて道幅を計算できる
      • 道幅縁が実物の長さと異なっている事が多い。
      • 交差している道の計算は難しい

結論

これらのデータを酷使して道幅の絞込みを行うとデータがほぼ残りません。なおかつ誤データも含まれるので細い道も抽出されてしまいます。
なので現状のオープンデータでは道幅を正しく判別する事ができません。

自分で車線に関するデータを作りました

自分で車線数に関するデータを作りました。道幅は難しかったので車線数のみです。
青(2車線), オレンジ(1か2車線), 赤(1車線)

作成したデータ ズーム
作成したデータ データをズーム

データの作成方法は目的の区間(LineString)を大量に作成するロジックを作り、そのLineStringを衛星画像と重ねて1座標ずつ目視で作成しました。
目視チェックを効率化するために専用アプリを作りました。
少しわかりにくいですが、ビュワーに目的の区間のLineStringが表示されていて右側リストにはそのポイントとマッピングを行った道幅の区分値が表示されています。
https://www.youtube.com/watch?v=9yBJeybOmWg
アプリのソースはこちらから
https://github.com/ritogk/gsi-width-mapper/tree/main

さいごに

なんか無料で善意で作られたデータに文句ばかり言うような形になってしまい申し訳ありません。
自分でデータを作ってみてデータ作りって大変だなあと思いました。

GitHubで編集を提案

Discussion