自治体こそ頼るべきオープンデータ可視化。 問われるのは活用のセンス ~アカデミア研究開発事例~【中編】

ゲームエンジンを使った都市空間シミュレーションを多数制作している文教大学情報学部情報システム学科の川合康央研究室。川合康央教授に、PLATEAUを使ったプロジェクトの実際、そして、ゲームエンジンで活用する際のポイントについて聞いた。
(中編 / 全3編)

写真:
森 裕一朗
文・編集:
大澤 文孝
編集:
北島 幹雄 (ASCII STARTUP)
Share
  • 川合 康央
    川合 康央
    文教大学 情報学部 情報システム学科 教授 学科長

PLATEAUのデータは前加工してデータを軽くする

――PLATEAUのデータを、どのようにしてUnity上に持ってきているのでしょうか。

川合

FBXとOBJ、CityGMLを、それぞれ使っています。地域によっては、CityGMLしかないところもあるので。

――FBXやOBJは、PLATEAUから直接提供されているファイルを使っていますか?

川合

そのまま使っているケースもあれば、自分で変換しているケースもあります。CityGMLからの変換については、PLATEAUのマニュアルにも載っていますし、有志が作った、「突っ込んだらOBJになる」というすごく便利なツールもあります。Blenderのパーサーを作っている人もいます。いろいろあって、うまく動かないときもあるんですけれども。

CityGML

都市スケールの分析・シミュレーションに必要なセマンティクスを記述できる地理空間データのための唯一の標準データフォーマット。GISの国際標準化団体であるOGC(Open Geospatial Consortium)で規格化された、都市空間を三次元的に表現するためのオープンな標準化データ交換形式。建物や地形などに関するさまざまなスキーマを含むXML形式として構成されている。PLATEAUでは、3D都市モデルの表現に、このCityGMLを採用している。FBXとOBJは、CityGML形式のデータを、それぞれ3Dソフトで使いやすいように加工した形式。

――過去の論文を拝見すると、Blenderでポリゴン数を削減して軽量化を図ったとありますが、こうした工夫について教えてください。

画像提供:川合 康央 氏

川合

そのときの論文は、PLATEAUではなく地理院地図を使っていたころです。OpenStreetMapと組み合わせていたのですが、重複する頂点がたくさんあるのです。同じ座標にポリゴンがいくつも重なっているとか、ディテールがきちんと作られているんだけども、見えないだろうというところもありました。そこでBlender上で、ある距離よりも短い間にある2点は、一緒のものだとして考えて合わせる手法をとりました。

こうした考え方は、PLATEAUでも使います。とはいえPLATEAUのデータは、同じ頂点がほとんどありません。大きい範囲内でも4点ぐらいしか重複しておらず、本当にきれいなデータを作っていると感動しました。

ただ逆に、建物のごちゃごちゃした部分は、省略しようと思ったら省略してよいわけなので、遠景で見るような、たとえば、可視化ビジュアライゼーションするような場合は、ポリゴン数を削減することがあります。

――PLATEAUには、建物・橋・道路など、さまざまなデータが収録されていますが、どのデータを利用していますか。

川合

これまで使ってきたのは、建物と道路と地形と橋です。立体的な構造物は、かなり使います。今後は、土地利用や災害想定などのレイヤーもうまく活用できそうだと考えています。

建物については、LOD1、LOD2のそれぞれがあって、整備されている範囲もそれぞれ違います。LOD2が提供されている地域では、LOD2を使うと、みなさんテンションが上がるので使いたいところですが、広域になると重たいので、広い範囲で作る場合は、あえてLOD1を使います。

LOD(Level Of Detail)

3D都市モデルの詳細度のこと。建物のLODは下図のとおり定義されており、LOD1は直方体のモデル(俗に豆腐モデルとも呼ばれる)。LOD2は屋根や壁などの形状、そしてテクスチャも付いたモデル。

――都市計画シミュレーションでは、木や街灯、道路標識がありますが、どのように作ったのでしょうか。

川合

基本的には、手作りです。もともとは写真をもとに手作業で作っていましたが、最近は点群データが取れますし、フォトグラメトリもあります。特に樹木では、比較的昔から、フォトグラメトリモデルを使っていました。とはいえ点群データは、やはり重たいので、それをどう軽量化させていくのかが課題です。

たとえば、過去の景観を作るシミュレーションの例では、立木については、実際にお寺さんに生えている木をフォトグラメトリで撮って、本物を加工しています。逆に人工物、街灯や電柱や電線は、手作業で作ってしまったほうが早いです。ケースバイケースで、メーカーさんによっては図面を公開しているところもありますし、実際にある交差点であれば、そこに行って測定しています。

またUnityの中にも、アセットが多少あります。日本の景観や交通標識などのアセットを使うこともありますし、3Dモデルを販売しているところでも、土地構造物は比較的共通利用できるものでもあるので、そういったものも利用することもあります。

アセット

Unityのストアのなかで購入できる3Dモデルやプログラムなどの構成要素。有償のものも無償のものもある。

PLATEAUだけのデータを使うなら簡単。ほかのデータと組み合わせると複雑化する

――PLATEAUとほかのデータとを組み合わせる場合の注意点について教えてください。

川合

PLATEAUを使う場合は、PLATEAUのデータだけを使ったほうが安全といえば安全です。国土地理院やOpenStreetMapなどの、さまざまなデータを組み合わせると、大変になることがあります。

これまでは、さまざまなデータを組み合わせざるを得ない状況でした。地理院地図だけでは完結できないので、ほかのデータを組み合わせるわけですが、その調整が大変でした。PLATEAUのように、ひとつの標準化された規格に則って、こうした3Dデータを集約していく事業は、とても助かります。

――前編では、地図の位置が合わないときは、4点を無理やり合わせるというようなお話もされていましたが。

川合

地図屋さんからすると怒られる話で、実際、GISなどの専門家や学会などで、じつはものすごく怒られたことがあります。「そんなものはおかしい。地球は丸い」「お前らは地球を平面だと思っているんだ」と(笑)。そのあたりも難しい部分です。

――ですが現実的には、そうしないと結局、データとして合わない場面もありますよね。

川合

用途によると思います。少し広範囲で見せようとすれば、球面であることを考慮する必要があります。しかしたとえば、ある交差点1個の範囲であれば、地球は別に平面であっても問題ないので、むしろ、そこでの交通事故をどう再現するかというところに注力すべきだと思います。

PLATEAUを地理空間情報以外のどういったデータと組み合わるのか

――シミュレーションシステムで、PLATEAUとよく組み合わせて使う地理空間情報を教えてください。

川合

相変わらず、地理院地図はよく使います。OpenStreetMapも参考にしています。

人流データや津波の浸水データなどは、地方自治体が公開しているデータを使っています。それぞれが、自治体都市計画図や用途地域などを持っているので、それらを組み合わせていきます。昔からやっていたことですが、それらをPLATEAUに乗せていけると思います。

組み合わせるデータは、プロジェクトによって、さまざまです。過去の景観シミュレーターであれば、古地図や古写真、浮世絵も参考にします。ドライブシミュレーターであれば、たとえば、交通事故マップなどで、警視庁がオープンデータにしているものがあります。渋谷駅周辺の実際の交通事故がヒートマップになっていて、拡大していくと、実際の事故のデータセットがあります。警視庁だけでなく、県警のデータなども見ながら、実際の地図に落としていくだけではなく、ここで歩行者が本当に飛び出してきたというところを使っていきます。

PLATEAUの活用という意味では、「地理空間情報以外のどういったデータと組み合わるのか」という部分も問われます。そのセンスのようなものがこれからは必要になってくると思います。

ヒートマップ

ある区画に対する数値の大小を色の濃度で可視化したもの。

――事故データなどセンシティブな情報の入手は難しそうですね。

川合

警視庁のデータは、ダウンロードできません。警察との共同研究というかたちで入手しました。交通事故だけではなく、たとえば、犯罪系のマップなどもあるので、さまざまな用途に使えると考えています。

ただ難しいところは、こうしたデータを地図と結び付けることを嫌がる事業者の方も多いことです。ヒートマップが真っ赤になっている犯罪地域のデータを見て、その地域で賃貸などをやられている業者にやめてくれと言われるという話もあります。

それこそ東日本大震災後に、津波のハザードマップが一回り大きくなって、一番問題になったのは地権者さんです。市議会に、その新しいハザードマップはちょっとおかしいのではないかという陳情もありました。地方自治体さんも、だいぶ苦労されたようです。

Unityナビメッシュ機能でのシミュレートは、さまざまなことを迅速に試せる

――ドライブシミュレーターでも、避難シミュレーションでも、道路上を動くと思うのですが、それをどう処理しているのか、教えてください。

川合

Unityの「ナビメッシュ」という機能を使っています。この機能は、昔から使っていました。

本来の用途としては、ゲームのキャラクターがおかしなところへ行かないように移動範囲を限定するものですが、CADデータや3D都市モデルのデータに対してもナビメッシュを貼ることができます。 エージェントが道路上を動くようにするには、まず、都市モデルの道路に対してナビメッシュを貼ります。それからエージェントが最初にいる場所とゴールを作り、その上を自由に歩けて、ランダムで動くように設定します。そうするとエージェントは、最短経路でゴールに向かいます。移動できる範囲を面で指定し、初期の位置とゴールを指定すれば、人でも車でも何でも動きます。

津波シミュレーションのときは、都市の中にこうしたエージェントをランダムにばらまいて、そこから一番近い津波避難ビルに向かって、道路のメッシュの上を最短距離で動けというコードを書いています。

また追加のルールとして、収容定員を避難対象のビルに設定しました。実際の避難もそうなのですが、これ以上入れないということもありますし、小中学校が津波避難指定場所となっていても、開校時間中であれば生徒がいるため、外の人は入れてはいけないということもあります。

シミュレーションでは、1つの避難ビルに行って入れなかった場合、どういう判断をするのかも見てみました。そうすると、このエリアに津波避難ビルがあるから大丈夫という計画を立てていても、満杯になってしまうと、次の避難場所が近くになく危険という場所もありました。

――今のお話を聞いていると、それができるのはゲームエンジンのメリットの一つだと思います。これがなかったら、自分で作らなければならないですね。

川合

まったく、その通りです。このシステムとわりと近い研究を、いま学生がやっています。横浜の建物を全部作って、駅を指定して、駅から最短経路でエージェントを動かして、駅からの距離に応じて、地価がどう変わるのかという研究です。ナビメッシュを使うと、いろいろなことができると思います。

――ナビメッシュはゲーム向けであり、いわゆる、従来の人流シミュレーションで設定できる経路選択モデルなどのシミュレーションモデルとは動きが違うと思います。昔からやっているようなトラディショナルな業界や行政に対して、「このシミュレーションは本当なのか」と聞かれたときに、どのように説明をしていますか。

川合

昔からのシミュレーション業界や地理業界の方などから見ると、ゲームエンジンは、「なんちゃってシミュレーションではないのか」ということは、言われます。

その一方で最近、建築学会などの分野では、基礎のシミュレーションモデルと同等のものをゲームエンジンで計算して比較し、これくらいは同等の精度であるとか、逆にこの部分はおかしいとか、そういう違いを調査し、調整のパラメータをゲームエンジンの中にフィードバックしていくことも盛んです。

シミュレーターでは、いろんなことを言われます。たとえば、津波避難シミュレーターでは、エージェントによって、歩く速度が違うだろうと言われました。そこで、児童や高齢者などで分ける、あるいは住民と観光客とで分けるようにしました。さらには、エージェント同士で会話して、「あそこの避難所はいっぱいだ」という情報も広がっていくでしょう。さまざまな想定がありますから、こうしたことは、ゲームエンジンでやっていけばよいと思います。

さらに、道路についても、地震が起きて津波が来るときに、道路が通れるとは限らない。建物が倒壊したり、車が通行止めになったりもします。何パーセントの確率で通れなくなりますといったところもシミュレーションできると面白いですね。

――むしろ、そうした開発をシミュレーションの中でできるゲームエンジンのほうが、より精緻にできる可能性があるのではないかということですね。

川合

そうです。理論的な部分はシミュレーション業界の方が、いろいろとやっているので、それをトライアンドエラーで可視化できていくようなことを目指しています。

自治体さんと話をして「具体的にわが街はどうすればいいのか」という話になったとき、理論的なシミュレーションでは、それをすぐに確認するのもなかなか難しい。コンサルタントに頼むのもお金がかかってしまうので、こうしたオープンデータを使って「ある程度粗いけれども、こういう雰囲気になるのではないか」というものを可視化して見せるというのは、役に立つのではないでしょうか。

まさに防災教育などもそうでしょう。厳密なシミュレーションとはちょっと違ってくる世界ではありますが、需要はあると思います。

学生が1年単位で取り組んで作るプロジェクト

――これらのシミュレーションは、どのぐらいの期間をかけて、何人ぐらいで構築したのでしょうか。

川合

ドライブシミュレーターですと、3人です。学生を含めて3人1チームで、1年間で作りました。1年目は、地理院地図を使いました。2年目はOpenStreetMapと組み合わせて作りました。今やっているのが、PLATEAUで完結できるシステムで、まさに作っているところです。

津波避難シミュレーションに関しては、基盤システムは私ともう一人の学生で最初に作りました。そこからは毎年恒例のプロジェクトになっていて、3人が1年くらいかけて地域を増やしていったり、エージェントのパラメータを、どんどん増やしていったり、ほかのことにも使えないかを考えたりしています。一度、水害のシミュレーションもやりましたが、うまくいきませんでした。

津波自体のシミュレーションもいろいろあります。津波が押し寄せてくるのは、それっぽく見せているだけで、実際には流体とか格子法とか、いろんな世界がそこにあって、そんなふうに津波は来ないぞとか、そのあたりも検証しています。

いずれにしても、水のような流体は、計算量がものすごく大きくなってしまいます。ですからゲームエンジンの中で、しかも都市モデルと一緒にリアルタイムに計算しようとすると大変なので、事前にほかの測定案の中で計算したものを、ゲームエンジンでは可視化するのみというアプローチになります。

人流可視化のほうは、いまOpenCVを使ったシミュレーターが面白いという話になっています。コロナ対策から始まったのですが、たとえば海水浴場で、今はこっちは混んでいるとか空いているとか、観光情報にも使えないかということで考えています。

OpenCVでひとつひとつ算出しているものを、Yoloを使うことで、もう少し密度を高くして取得できないかというところも含めて、もっと大規模にもっとリアルタイムにという形で監視できないかを模索しています。

基本的には、ゼミの学生が担当するので、制作期間は、1年という単位が基本です。プログラムが得意な学生、モデルが得意な学生などが、何人かでチームを組んで、それぞれの得意分野を活かして進めていきます。