Project PLATEAU by MLIT

PLATEAU／CityGML座談会（前編）

入賞者＆関係者が語るPLATEAU裏話 3D都市モデルの成果物への多様な落とし込み方

重くない状態でシミュレーションし、3Dモデルにフィードバック

――第1回のハッカソンから約半年後、2021年7月のハッカソンでは変化があったのでしょうか。まず、「巨災対」チームの米田さん、安黒さんいかがでしたか？

米田 将氏
システムエンジニア。普段は国のシステム開発に携わる。第2回ハッカソンでは安黒氏と参加し、ゴジラが東京上陸した場合のシミュレーション「わりと本気でゴジラ対策してみる」がグランプリを受賞

安黒 翔氏
現在修士2年生。第2回ハッカソンに米田氏と同じチームで参加

米田：最初はUnityを使おうぜ、ということでUnityへ取り込む作業をやっていきました。アプローチとしては、3Dモデルを使ってシミュレーションをさせようとしたのですが、データが重すぎて時間がかかりすぎる等の問題が出てきて。どうしようかと考えた結果、いったん重くない状態に変換してからシミュレーションし、3Dモデルにフィードバックして実装する方法に至りました。具体的には、いったんCityGMLをCSV形式に変換して、いろいろなデータと合わせて計算し、その結果を3Dモデルで表現しています。やはり若干、地理空間系の知識は必要だと感じています。

安黒：今回のハッカソンは2日間の集中開発だったので、私はアプリ開発には携われませんでした。1週間くらいの期間があれば、そのあいだに勉強して開発にもっと携われたかもしれないので、そういう企画もあるといいと思いました。

巨災対の「わりと本気でゴジラ対策してみる」。映画『シン・ゴジラ』をもとにした、ゴジラ東京上陸のシミュレーション。

石丸：CityGMLからCSVに変換されていますが、ものすごく大きなデータになったのでは？

米田：全部の場所を読み込んだわけではなく、ゴジラが通るルートに限定し、その中でも要所要所をピックアップしたので、それほど大きくはなりませんでした。CityGMLのデータをざっと眺めたところ、場所によってデータの属性があったりなかったりしたので、そのままGISに取り込むよりもExcelで統計的に計算するほうが手っ取り早いと考えました。存在しないデータは、平均値で補うなどして処理しています。

黒川：CSVを使っているのにはびっくりしました。自分がやりたい目的に対して、工夫の幅がすごく広い。私はこのゴジラの作品がすごく好きで、ハッカソンでこのような成果が出てよかったと思っています。普段からGISを触っている人だけではない、幅広いアイデアを持っている方たちが参加してくれて、目に見える形で表現してくれたことにすごく感動しています。

尾石：アイデアシートのゴジラが破壊する、というものから、最終的には被害額を算出するところまでグレードアップされていて、ハッカソン的に面白いなと思いました。

石丸：被害額の算定にあたり、不動産の平均価格が使われていますが、これはオープンデータがあるんですか？　

米田：実は、ウェブクローラーをスクリプトで書いて、不動産サイトから港区の不動産データを取りまくりました。一歩間違えるとDoS攻撃とみなされてしまうので、1時間当たりの件数を制限するなど、用心してやりました。

奈良：すべての物件が載っているわけではないのですが、国交省から「不動産取引価格情報」として中古マンション・中古住宅の購入者に3カ月ごとに大規模アンケートを取ったデータが公開されています。こうしたデータを使って地域ごとの不動産価格を算出するモデルは作れるかもしれませんね。

内山：国交省のサイト内にもまだみなさんに使われていない知られざるオープンデータがたくさんあるので、発掘していきたいですね。ちなみに、さきほどおっしゃっていた、データが重いというのは、FBXとCityGMLのどちらが重かったですか？

米田：FBXはUnityに取り込むときに重いと感じました。CityGMLはFBXほどではありませんが、QGIS（オープンソースのGISソフト）で読み込むときに若干重かったので、時間がとられそうなのでチーム内で相談して、全部はやめようという話になりました。

内山：FBXの重さは我々も問題意識を持っています。ポリゴン数が多いから重いのですが、パーツごとにポリゴンが分かれているのが良さなので、数を減らすわけにもいかない。でもやはり使いづらいですよね。Twitterでもよく重いという声が聞かれます。米田さんのように開発者のマシンでもキツいとなると、考えないといけないですね。

米田：ただ、今回はシミュレーションがメインなので、CityGMLさえあれば計算結果は出せました。ただ、ハッカソンでは発表用の画面を作らなくてはならなかったので、FBXの重さが辛かったですね。

於保：FBXが重い原因は、きちんと分析する必要があると思っています。どの段階で重いのか。Unityに読み込むときに重いのか、レンダリングが重いのか、それぞれに別の解決策があるので、分析して対応を取っていくのがいいでしょう。データはそれぞれの特徴があるので、FBXは重いけれどいいところはもちろんありますし、適切な形にコンバートして動かしていくことは重要です。CityGMLというオリジナルのデータに価値があり、さまざまなデータにコンバートしていけることが大事なので、うまく考えていければ。

AR×VRにおいてPLATEAUの精度の高さが差別化につながる

――「ナイスガイズ」チームは、ハッカソンを振り返っていかがでしたか？

尾上兼透氏
XRエンジニア。第2回ハッカソンでチーム「ナイスガイズ」として参加した作品「ARライブ配信」が準グランプリを受賞

岡本享大氏
第2回ハッカソンにチーム「ナイスガイズ」に尾上氏とともに参加。普段は鉄道会社に勤務し、街づくりの仕事に従事。趣味はARの作品づくり

尾上：まず、PLATEAUの規格であるCityGMLをどうプロダクトに落とし込んでいったのかですが、私はXRエンジニアなので、今回のテーマには、あまりCityGMLとしては落とし込んでいないんです。というのも、PLATEAUをどう評価して使ったかというと、LOD2以降の精度のデータが高い部分を利用しています。GoogleのAPIで取得できる3Dデータは手軽な反面、精度に欠けるので、今回我々が作ったAR×VRのようなプロダクトにおいてはPLATEAUの精度の高さが差別化につながるポイントだと考えています。

LOD（Level of Detail）：CityGMLにおける概念で、同オブジェクトに関するすべての情報を一元的に管理・蓄積・利用することができるようになる。

岡本：少し付け足すと、（成果物のプレゼンでは）西新宿を舞台にしたのがよかったです。渋谷だと広告などの変動要素が多いのですが、西新宿は比較的変動要素が少なかったのと、コクーンタワーのようにアイコニックな建物があったことで、見つけやすかった。私はARの担当で、7月の炎天下で汗だくになりながらやっていたのですが、LOD2の精度が高いおかげか、初回でほぼ位置合わせができました。位置ずれがほとんどなく、4、5回のビルドでそれなりのクオリティーにオクルージョンできたのがよかったと思っています。

第2回ハッカソンで準グランプリを受賞したナイスガイズの「ARライブ配信」

石丸：位置合わせの際に、座標系の違いは問題になりませんでしたか？

尾上：今回は、事前に作成したコクーンタワーの特徴点データと3Dモデルを手作業で位置合わせしたので、座標変換については問題なかったです。APIでデータを送り、そこを起点に地理モデルをダウンロードする、といったものを作ろうとしたら問題になるかもしれませんね。

黒川：LOD2の品質の高さをうまく利用していただけたかなと思います。「西新宿だからうまくいった」というお話がありましたが、確かに、建物に看板など付属物をデータにするかしないかは判断に迷うところです。データを作る立場としてブレのない仕様をしっかり作っていかなくてはいけない、と再認識しました。看板などでも恒久的に設置されているものであれば作るほうがいい。ただ、それが恒久的に設置されているかどうかの判断は自動処理では難しいため、ある程度はサイズで判定していくことになります。そのあたりの判断基準が都市によってブレないようにする取り組みを進めています。

於保：今回はFBXで建物データを取り込んでますよね。その場合、平面直角座標系なので広域になるとズレてくるかも、と懸念していたのですが、このくらいの範囲なら問題なかったすか？

尾上：はい、問題なかったです。

於保：オクルージョンのデータとしては、非常にきれいなデータが入っているので使いやすいかと思います。特徴点マップを合わせるときも、正確な建物データがあると合わせやすいというのはすごく共感できました。完成したプロダクトもキャッチーで面白いので、興味深く拝見しました。

内山：尾上さんがやっているのは、位置合わせというよりも、マスク処理でLOD2を使っている、ということですよね。位置が移動しても追従するのは、ジャイロか何かを仕込んでいるんですか？

尾上：そこはImmersal Mapper（Immersal Ltd.がiOS・Androidで配信するカメラ・写真アプリ）の機能を使っています。カメラの映像から特徴点を取得し、インターバルで2秒ごとに位置合わせする機能が用意されているので、それをオンにしておけば、カメラの映像が奪われない限り、コクーンタワーを認識するたびに位置合わせが行われます。

内山：Immersal Mapperでマップを生成して位置合わせをする際、点群をうまくマスクするためにPLATEAUを使った、というわけですね。マスク処理や位置合わせそのものにPLATEAUが使えたらいいですけど、そうなるとハードルが高いですよね。PLATEAUをよりスケールしていくには、どういうデータだったらいいと思います？

尾上：緯度経度だけでピタッと位置があうようなものがあれば、カメラの情報すらいらなくなってありがたいと思います。どういう仕組みで成り立たせるかはわからないけれど、マップの3Dデータから位置合わせが行えれば、3Dモデルの精度が上がれば上がるほど位置合わせの精度も上がるので、実現できればすごいことになりますね。

内山：そのためには、テクスチャ―をきれいにとるとか、疑似テクスチャーを取るとか、形状を細かくすることになるが、それには費用がかかり、逆にPLATEAUがスケールしなくなっちゃう、というバランスが難しい。

黒川：形状を細かく作成するのは大変なので、特徴点の位置の正確さだけ上げればいいのかな、と考えています。