2023/10/16 渡邉研定例ゼミ

4文

目的: 本研究は、洪水被害発生時に通信インフラがダウンした状況でも、スマートフォンのブラウザアプリケーションを通じてハザードマップを閲覧可能とするシステムの提案を目的とする。

手法: Raspberry Piを活用してWeb地図サーバーを構築し、それをアクセスポイントとして設定する。無線通信（Wi-Fi通信」を利用し、イントラネット内のスマートフォン（クライアント）に対してブラウザ経由でハザードマップを表示するシステムを実現する。

検証: 通信インフラがダウンした洪水被害のシナリオを想定し、オフライン環境で以下の検証を実施する:

Raspberry Piとスマートフォンの接続性と通信速度を定量的に評価し、ストレスなく地図を表示できるかを確認する。
接続時の消費電力を定量的に測定し、避難時間に耐え得る性能かどうかを評価する。
被験者に本ハザードマップを通じて適切な避難ルートの想定が行えるかを評価する。

結論: 提案された地図システムは、洪水被害時に通信インフラがダウンしても、スマートフォンのブラウザアプリケーションを通じてハザードマップを表示できることが確認された。

先週からのアップデート

その節で何を書くかの見出し作成

https://github.com/ShogoHirasawa/2023-syuron/issues/11#issuecomment-1742339382

ハザードマップ URL

https://shogohirasawa.github.io/UNVT_for_Tokyo-to/

標高タイルを作成

オフライン環境で標高タイルを表示できるように、URLでタイルデータを取得するのではなく、タイルデータを自作しローカル環境でも稼働できるように設計。

タイルデータ: https://github.com/ShogoHirasawa/UNVT_for_Tokyo-to/tree/Todai2evacuationCenter/DEMtiles

凡例の表示/非表示の実装

クリックをした際に避難所の詳細を表示

検証の再考

避難ルートを表示している状態で、避難者が目的地にたどり着くのは大方想像できる範囲ではあるので、検証する価値が低い。一方で、本ハザードマップは既存のハザードマップとは違い、傾斜を表示できていることからこの点が避難者が避難ルートを検討する上でどのように作用するのかを検証したほうが面白いかも。検証者は10人はほしい。

引用元: https://www.city.bunkyo.lg.jp/bosai/bosai/bousai/Panfu/hazard/hazard.html

メモ

目的の部分は以下の通りにするとよいかも

本研究では、洪水被害発生時に通信インフラがダウンした状況でも、スマートフォンのブラウザアプリケーションを通じてハザードマップを閲覧可能とするシステムを提案する。

手法の部分で起伏差を考慮したハザードマップの文言を入れる。
被験者ではなく、"参加者"を使う
ルートを書き込んで、置けるといいかも。
複数グループと単独で考案するので分けて検証
起伏のデータをどうやって作成したかを盛り込む
避難訓練で使うシーンを想定する
洪水被害のときにオフラインになるの？ここの条件設定を詰めること（無理のないシーン設定すること）
4G/5G通信のみでしか使えない人
3Dで見せるor赤色立体地図を使って一般の人でも使えるようにすること
すでにオフライン環境下での水害被害を想定。

手法の部分の修正

Raspberry Pi上で動作するWeb地図サーバーにWi-Fi接続してブラウザ経由でハザードマップを表示するシステムを実現する。

既存の避難グッツがどれくらいの稼働時間があるのかを閾値の参考にする

頂いたコメント

前回言いそびれたのですが…
洪水が発生して通信インフラがダウンする状況で、ハザードマップが必要になることってあるのでしょうか…？その場合はすでに逃げ遅れてないでしょうか？
では、誰のためのシステムなのでしょうか
（という点は、もしうちのボスが審査に入ったら絶対突っ込まれると思います）

ShogoHirasawa / 2023-syuron