EARS (Earthquake Alert and Report System):a Real Time Decision Support System for

Earthquake Crisis Management

takano

@mtknnktm

1

概要

• 地震の規模や場所は既存のセンサーではわかるが、被害の内容や規模は実際に人が見てみないとわからない。

• しかし、行政にとって住民に素早くアラートを出すことは重要である。

• したがって地震直後であってもある程度被害の概要を把握できようにすることは重要である。

• そのために、地震に直接的に関連する人の生の情報をTwitterから取得できるシステムを開発した。

2

問題設定

• システムのユーザ– INGV (イタリアの地球物理学火山国立研究所)

• 地震発生直後のINGVの役割– 地震の2, 5, 10, 30分後に情報を提供する

– 目的は問題のある地域の特定とそれの情報提供。ただし、実際にヤバイかどうかは今のセンサーだけだと確認できない。

• 【目的】 INGVのための意思決定支援ツールの提供– ソーシャルセンサーとして人々のTweetを使い、被害状況に関する情報をINGVの中の人が得られるようにする。

3

設計と実装 –概要

1. データを収集して

2. フィルタリングして

3. 地震イベントを検知して

4. 被害評価をして

5. アプリで表示

4

データ収集

• データの収集にはTwitterのStreaming APIを使用

• Streaming APIではキーワードの設定が必要

• キーワードの選定

–候補を先行研究と地震に関連する単語から9個選定

–候補単語の頻度と地震イベントの相関を示さないも

のを削除

→2ヶ月頑張って「earthquake, tremor（のイタリア語版）」の

2つに絞った

5

データ収集

• 「地震遭遇者の生の声がしりたい」という目的に対してキーワードに向かない単語の特徴

– 特殊すぎる（いろんな情報が欲しいので）• wreckage, crack

– 公式発表で使用される（個人ではあまり使われない）• seism, magnitude

– 包括的すぎる（地震と関係ないことが多い）• shakes, shaking

• 選択した単語は言語特有の問題なので他の状況では使えず、汎用性はない

6

データフィルタリング

• ノイズを除去したい

• ノイズの2つの源泉 [M. Avvenuti, et al., 2014]

–異なる意味で検索キーワードが使用されている場合

–過去の地震を指している場合

• 2段階のデータクリーニングでなんとかする

7

データフィルタリング第一段階

• 本研究の地震イベントの検知におけるTwitter利用の特性– 知りたいのはイタリア国内の一次情報。拡散とか二次情報は不要。→この段階での目的:自発的で独立したメッセージのみ抽出

• やったこと1. Re-tweet, mentionを除去2. 過去地震情報アカウント（Bot?）の除去（ブラックリストによる）

3. 同じ単語が使用される別の言語（スペイン語・ポルトガル語）のTweetの除去

4. 偽アカウントの除去 [S. Cresci, et al., 2014]• 偽アカ1950個と通常アカ1950個を集めてきて、分類器作成これを使ってオンラインにブラックリストを作成

8

データフィルタリング第二段階

• この段階での目的: 進行中の地震と関連するツイートのみ抽出

• 進行中地震の関連ツイートの特徴– 通常より少ない句読点

– 俗語や攻撃的な言葉の使用

– 短い文章

– 怖がっている

• 進行中でない地震に関連するツイートの特徴– 過去の地震に関する言及や地震ニュースに言及するものなので、構造化され長い。そしてURLが含まれる。

9

データフィルタリング第二段階

• 以下を素性として決定木で分類器作成–文字・単語数

–句読点数

– URL数

– mention数

–スラング・攻撃的単語数

• 教師データは手動で作成

• 教師データの90%以上を正しく分類できた（10-fold-CV）

10

データフィルタリング結果

• およそ88%のTweetを削除

• ノイズに埋もれがちな小さな地震の時でも、フィルタリングによってtweetピークが検出できるようになった。

11

地震イベント検出

• バースト検出アルゴリズム[R. Ebina, et al, 2011]の簡易版を採用

– 1分間のTweet率が1週間のTweet率より10倍高かったらバーストとする

–正確さよりも検出率優先のため、かなり甘めのしきい値設定

12

被害評価

• 危機管理担当者への意思決定支援機能。– これによって評価専門の担当者が実際に実地に行って被害の評価しなくてもできるようにする。

• EARSは「座標、地名、n-gram」を情報として抽出する。– TagMe by Pica大学を使用して曖昧な地名から座標を抽出（テキストアノテーションや曖昧さ回避のサービス）

• 地震発生時には、メッセージの集合を拡張するために、自動的に地震に関連したメッセージをストリーミング収集する。– 地震が発生してそうな場所で生成・言及されたメッセージ収集のためにこの適応的接続を使用。

13

Webアプリ

• EARSはWebアプリとして提供

• 機能

–サマリ画面

–詳細画面

• 時系列推移

• 地理的情報

• メッセージ表示

14

Webアプリ –サマリ

15

INGVが検知した地震情報・赤: INGVが検出したがEARSでは未検出。・緑: INGV・EARS共に検出、かつ、担当者既読

EARSが検知した地震情報・橙: EARSが検出、かつ、担当者未読・緑: INGV・EARS共に検出、かつ、担当者既読

この画面で気になるものが有れば、詳細画面を確認する

Webアプリ –詳細

16

システムが収集したTweet数の時系

列推移。赤色の範囲は推定されたイベント期間で、物理的なイベント期間ではない。

Tweetの位置情報。赤が震源地、緑がTweet。横の

バーで分単位で見る時間を変えられる。

Tweet。位置情報のあるも

のは地球アイコンが表示。クリックすると地図上で強調表示される。

テスト

• 既存データを使ってテスト

– 70日分の全メッセージを3時間未満で処理できた

• 問題

– INGVで検出した地震をEARSでも検出できれば正解

–マグニチュード別で評価

17

テスト結果

• 全データだと小マグニチュードは全然検出できなかった–人が知覚できないので当然

→ Tweetデータから「人が知覚できた地震データ」のみを抽出→再テスト→ いい感じ

18

今後

• 悪意あるノイズツイートを防ぐ方法を強化すること

• Twitter以外の情報源（Facebookの公開投稿、Google検索データ）を利用すること

19