PLATEAUの3D都市モデルからバス停の形状を推定出来るか

そのバス停には屋根はあるのか? ベンチはあるのか?

初めて訪れるバス停に「座って待てるベンチ」はあるか。これは高齢者にとって非常に重要な情報です。
また、近年の猛暑や雨雪を考慮すると「屋根の有無」も欠かせません。ベビーカーを利用する親子連れにとっても、屋根や日陰の存在は大きな安心材料になります。

もし、こうした「バス停の屋根やベンチ」といった設備情報がデータとして広く公開されていれば、誰もがより安心して移動できる社会になるのではないでしょうか。

きっかけ

現在、バス停の位置情報はGTFS(またはGTFS-JP)などのオープンデータとして広く普及しています。しかし、これらは緯度・経度を示す「点」のデータに過ぎず、 そのバス停に屋根があるのか、どれくらいの広さなのか といった物理的な設備情報は含まれていません。

「点ではなく、設備の形状がわかるデータはないか」。そう考えたとき、PLATEAU(Project PLATEAU)の3D都市モデルが目に留まりました。PLATEAUは建物や道路だけでなく、都市設備も3Dモデルとして整備しています。「もしここにバス停の形状が含まれていれば、屋根の有無や大きさも判別できるのではないか?」と考えたのです。

3Dモデルからバス停の設備情報を推定するなんて、アプローチとしては「流石に筋が悪そうだ」と思いつつも、半分は技術的な興味から検証に踏み切りました。

結論から書くと、 データの抽出そのものは成立したものの、そこから何か実用的なことを言うには足りなかった というのが正直なところです。

結論

問い	答え
バス停を特定できるか	できる。frn:CityFurniture の frn:function = 8010
屋根の有無は分かるか	属性には無い。ただし、ジオメトリから幾何的に導出すれば分かる
停留所名は取れるか	取れない。名称属性が存在しない
東京23区で何件取れるか	193 オブジェクト。ただし、これはバス停の数ではない
広域の分析に使えるか	使えない

以下、まず停留所がどう定義されているかを整理し、その後に躓いた 4つのポイント を挙げます。4つともデータの構造そのものに起因しており、実装側の工夫ではどうにもならないものでした。

1. 停留所はどこにどう定義されているか

PLATEAUにおける「停留所」の定義は、大きく3つの層に分かれています。

層	何が書かれているか
標準製品仕様書	都市設備という概念、地物型 frn:CityFurniture、持てる属性とLOD
コードリスト XML	「停留所」という 日本語名称 とコード値 8010 の対応
実データ (CityGML)	座標と、コード値 8010

仕様書における定義

出典は『3D都市モデル標準製品仕様書 第5.1版』の「4.14 都市設備モデルの応用スキーマ」です。都市設備そのものは以下のように定義されています(原典は OGC 21-006r2)。

都市設備とは、都市の屋外(道路、住宅街、広場、造成地等)に設置されている、移動しない小規模な設備である(例:街路灯、道路標識、交通信号機、花壇、広告板、ベンチ、バス停)。

ここで 「屋外」と書かれている点が後で大きく効いてきます (後述)。建築物に付属する設備は frn:CityFurniture ではなく bldg:BuildingInstallation として扱われるためです。

frn:CityFurniture が持てる属性は、作成日・区分(frn:class)・種類(frn:function)・用途・名称・ジオメトリ程度しかありません。このうち停留所を識別できるのは frn:function だけです。名称にあたる gml:name は実データでは未使用でした。

形状はLOD1とLOD3の2つを持ちます。LOD1は「外周を一律の高さで押し出した立体」、つまり箱です。LOD3が実際の形を表すため、屋根の有無を判定するにはLOD3が必要になります。

コードリストと実データにおける表現

実は「停留所」という日本語が現れるのは、codelists/CityFurniture_function.xml の中だけです。

コード	名称	実データでの出現
8010	停留所	23区で193件
4010	上屋	0件
4000	建造物	0件

バス停の屋根を特定するなら 4010(上屋) が使えそうに見えますが、実データでは1件も使われておらず、上屋も標識柱も一律に 8010 でした。 種類の内訳は、コード上では区別されない のです。

実データ側にあるのは、この数値コードと座標だけです。

<frn:CityFurniture gml:id="frn_a472d972-b10b-4f37-a593-f1fa29339e7f">
  <core:creationDate>2024-03-15</core:creationDate>
  <frn:class codeSpace="../../codelists/CityFurniture_class.xml">9999</frn:class>
  <frn:function codeSpace="../../codelists/CityFurniture_function.xml">8010</frn:function>
  <frn:lod1Geometry>...</frn:lod1Geometry>
  <frn:lod3Geometry>...</frn:lod3Geometry>
</frn:CityFurniture>

そのため、CityGMLを「バス停」「停留所」で検索しても1件もヒットしません。PLATEAU GIS Converter (nusamai) を通せばコードリストが解決され properties.function が ["停留所"] になるので、最初にこちらを通すのが得策です。

2. 整備範囲が区域の1%しかない

これが一番効きました。東京23区のうち、都市設備モデルを整備しているのは11区だけです。

整備しているのは千代田区、中央区、港区、新宿区、台東区、墨田区、江東区、品川区、渋谷区、杉並区、豊島区。残る12区には1件も存在しません。しかも整備している区であっても、対象は主要駅の周辺だけに限られています。

区	対象エリア	整備面積 (LOD3)	区域面積	整備率
千代田区	東京駅、秋葉原駅	0.06km2	11.66km2	0.5%
中央区	東京駅、日本橋駅	0.22km2	10.21km2	2.2%
新宿区	新宿駅	0.11km2	18.22km2	0.6%
渋谷区	渋谷駅、代々木駅	0.08km2	15.11km2	0.5%

CityGMLから function=8010 を数え上げた結果が、23区全体で 193 オブジェクト でした。

ここで致命的になるのは、件数の少なさそのものよりも 「データが欠落している場所に偏りがある」 ことのほうです。PLATEAU にオブジェクトが無いことは、現地にバス停が無いことを意味しません。

仮にこのデータから「屋根のあるバス停」を推定出来たとしても、それは実のところ「東京駅や新宿駅、渋谷駅の駅前」でしかありません。

3. 1オブジェクトは1バス停ではない

193 という数字にも罠がありました。8010 のオブジェクトは「バス停1件」ではなく、「バス停を構成する部品」の単位で登録されています。しかも、その分割の仕方が一定ではありません。

渋谷区のあるメッシュで見つけた実例を挙げます。以下の3つのオブジェクトは水平距離 0.00m、つまり完全に同じ位置に立っています。

gml:id	寸法	高さの範囲	実体
08f23a8f	幅 8cm	0.00 - 2.01m	門型フレーム (2 本脚 + 上部アーチ)
cc5bbcda	幅 2cm	0.70 - 1.97m	掲示板 (時刻表・路線図)
d36439dd	40 x 50cm、厚さ 2cm	2.03 - 2.53m	標識板

これら3つが合わさって1本のバス停標識になります。日本のどこにでもある、あの形です。

ところが同じメッシュ内、同じ creationDate のデータに、分割されていない個体も混ざっています。64dbc60b は 0.23 x 0.28 x 3.02m で1オブジェクトで完結しています。さらに、 71m の連続上屋がポール7本を覆っている ケースも見つかりました。この場合は1オブジェクトが複数の乗り場にまたがることになります。

対応	実体
オブジェクト = 停留所	単独で立っているポール
オブジェクト < 停留所	部品に分割されている (上の3件など)
オブジェクト > 停留所	71m の連続上屋が乗り場7箇所をまたぐ

そして致命的なことに、 どれに該当するかを示す属性はありません 。地物をグループ化する grp:CityObjectGroup も 0 件でした。「この上屋とこのポール群で1つの停留所である」という情報がデータのどこにも存在せず、幾何的に推定するしかありません。

このメッシュには28オブジェクトが存在しましたが、形状を見て数え直すと実態は 約7箇所のバス停 に過ぎませんでした。桁を掴む目的でこの比率を当てはめるなら、193 オブジェクトの実態は数十箇所。 東京23区全体で数十箇所 ということになります。

統計では気づけず、3Dで見て分かった

正直に書くと、最初はこの構造に気づかず「乗り場 190 箇所、うち屋根あり 93 箇所 (48.9%)」という集計を出してしまっていました。幅 2cm の掲示板を、独立した標識柱として数えていたわけです。

寸法の分布を見ても、近接ペアの数を数えても、この誤りには気づけませんでした。気づいたのは、CityGML を Wavefront OBJ に書き出して 3D ビューアで眺めた時です。同じ場所に細長い物体が3つ重なっているのが見えて、初めて理解できました。

「集計を出す前に一度形を見る」。今回得たものの中で、これが一番応用が効く教訓でした。

4. 別の場所では別の地物型になっている

東京駅のバス停を PLATEAU VIEW で眺めていて、決定的なことに気づきました。同じ東京駅のバス停の上屋が、丸の内側と八重洲側で「別の地物型」に分類されているのです。

場所	区	地物型	区分
丸の内側	千代田区	bldg:Building	普通無壁舎
八重洲側	中央区	frn:CityFurniture	function = 8010 (停留所)

同一メッシュ、同一のデータ作成日でありながら扱いが違います。そして厄介なことに、 標準製品仕様書上はどちらの解釈も成立してしまいます 。都市設備の定義には「バス停」が例示されている一方で、建築物の区分には「普通無壁舎(壁のない建物)」が存在するためです。仕様違反ではなく、純粋な解釈の違いです。

丸の内側は「建物」として登録されているため、指定建蔽率 80、指定容積率 900 といった建物用の属性が付与されています。指定建蔽率を持ったバス停です。そして、これがバス停であることを示す情報はどこにもありません。「普通無壁舎」には駐輪場の屋根も、公園の東屋も、ガソリンスタンドも含まれるため、ここからバス停だけを取り出す手がかりが存在しないのです。

念のため、このメッシュの frn を東西で分けて数えてみたところ、丸の内側は 88 件すべてが路面標示であり、8010 は 0 件でした。つまり frn:function=8010 だけを抽出する方針では、千代田区側のバス停が丸ごと欠落することになります。

整備事業者ごとに解釈が違うのはオープンデータでは珍しくありませんが、道路を挟んだ両側で違うとなると、広域で一貫した抽出ルールを書くこと自体が極めて困難になります。

5. 大きいターミナルほど載っていない

バスタ新宿を調べました。結果は 0 件でした。

4F が高速バスのりば、3F がおりばという「建物内」のバスターミナルです。周辺の frn 19 件はすべて路面標示で 8010 は 0 件、該当メッシュの bldg も maxLod=2 で LOD4 は存在しませんでした。

1章の定義に戻りましょう。都市設備とは「都市の 屋外 に設置されている設備」です。建物内ののりばは、定義上そもそも都市設備ではないのです。

では建築物モデル側にあるかというと、仕様書において建築物の屋内空間は LOD4 でしか表現されない ことになっています。現在、23区の建築物モデルは LOD2.2 までしか整備されておらず、都市設備モデルを持つ区をいくつか調べても LOD4 は1件も見つかりませんでした(23区内で LOD4 が整備されているのは地下街モデルのみです)。したがって、建物内の乗り場は原理的に取得できません。

規模の大きいターミナルほど建物内に配置される傾向があるため、結果として 「大きい乗り場から順に欠落する」 という強い偏りが生じます。「規模と設備の関係」といった、いかにも知りたい方向の分析をやろうとすると、まさに知りたい側がすっぽり抜け落ちてしまうわけです。

なお、CityGML 3.0 では LOD4 が廃止され、LOD0~3 が屋内にも適用されるようになります。PLATEAU が移行すればこの前提は変わりますが、移行時期は示されていませんし、枠組みが変わったとしても実際に屋内が整備されなければ結果は同じです。

6. それでも取れたもの

否定的な話が続きましたが、技術的に成立した部分も確かに存在します。3章で述べた誤りはあくまで「数え方」の問題であり、個々のオブジェクトの形状を見る限りにおいては十分に有用です。

• 座標と個々の寸法は使えます。 幅・奥行・高さ・接地面積は、部品分割の問題とは独立しています。出典が車載写真レーザ測量 (MMS) であるため、走行路から見える範囲の形状は素直に取得できている印象でした(現地実測との突合はしていないため、絶対精度は評価していません)。
• 屋根の有無は判定できます。 ほぼ水平(Newell 法による単位法線の |nz| > 0.85)かつ bounding box の上部にある面を「屋根面」とみなせば判定できます。ただし面積の絶対値は信頼度が低いです。個体によっては LOD3 に「屋根の板」しか入っておらず、3D で見ると宙に浮いた板になっているためです。
• ポールが上屋の下にあるかも判定できます。 ただし判定に「接地面」を使ってはいけません。71m の上屋は柱でしか地面に接しておらず、実測した接地面は 0.05 x 0.10m しかありませんでした。屋根面の水平投影を使う必要があります。

要するに、 「1件ずつミクロに見る分には信頼できるが、マクロに集計した瞬間に使えなくなる」 という性質を持っています。

なぜ効果が出なかったのか

技術的なデータ抽出は成立したのに、成果物としての価値が出ませんでした。理由を整理すると以下になります。

1. 母数が小さすぎる。 東京23区全体で実質数十箇所しかなく、統計的な主張ができるボリュームではありません。
2. 欠落が系統的。 「整備範囲の偏り」「地物型の解釈の違い」「建物内の除外」という3種類の偏りが重なっています。しかもどれも「屋根のある大きなバス停」を欠落させる方向に働くため、後から補正のしようがありません。
3. 数える単位が定まらない。 1オブジェクトが何を指すのかがデータ側から決まらないため、そもそも「何を数えているのか」を定義できません。
4. 名前が無い。 GTFS 等と突合するには位置による空間結合が必要になり、そこにも誤差と手間が乗ります。

「形状が取れるか?」への答えは Yes ですが、「形状を取って何かが言えるか?」への答えは No でした。データが存在することと、そのデータを使って何かが言えることは全くの別問題です。

誤解のないように補足すると、これは PLATEAU の欠陥という話ではありません。都市設備モデルはあくまで「街並み(特に駅前)の 3D 表現」のために整備されているのであって、「全国のバス停台帳」を作るために整備されているわけではないのです。データの用途を取り違えたのは、検証を試みたこちら側でした。

次にやるなら

• 用途を絞る 「東京駅周辺のバス停を 3D で可視化する」といった特定エリアの個別事例であれば、PLATEAU のデータは十分に威力を発揮します。広域の統計を狙った時点で無理がありました。
• 屋根の判定は別データで 屋根の有無を知るだけなら、航空写真の解析や OpenStreetMap の shelter=yes タグのほうが広く取得できる可能性があります。網羅性の検証は別途必要ですが、母数は期待できます。
• bldg 側の「普通無壁舎」を拾うか 4章の欠落を埋める方向です。ただし千代田区の bldg だけでも 21 ファイル(1.88GB)あり、バス停を特定する属性が無い以上、位置による絞り込みが前提になります。労力に見合うかは疑わしいところです。