この記事は、防災アプリ Advent Calendar 2022 21日目の記事です。
whoami
こんにちは! 某高校3年のもぐもぐです。
趣味は散歩で、前に家から学校まで40kmほど歩いて帰りました。
近いうちに自転車で登校・下校したいな～ なんてことを考えています。
2022年春頃から地震関連アプリケーション EQMonitor を開発しています。
この記事では、開発中に得た緊急地震速報に関する情報と緊急地震速報の再配信用サーバの構成についてお伝えします。
少しでも地震、緊急地震速報について興味を持っていただけたら幸いです。
概要
- (ちょっとだけ)開発しているアプリの宣伝
- あなたの知らない緊急地震速報の世界
- EQMonitorで用いている緊急地震速報の再配信手段について
(ちょっとだけ)開発しているアプリの宣伝
EQMonitorは、Android向け 地震関連情報のアプリケーションです。
こちらよりAPKをダウンロードできます。
| 強震モニタ | 地震履歴一覧 | 地震履歴詳細 |
|---|---|---|
 |
 |
 |
このように、ざっくりと
- 緊急地震速報を受信し、揺れの状況をリアルタイムで表示
- 地震履歴の確認
ができます。
このアプリについては、防災アプリ Advent Calendar 2022 18日目の記事でも紹介していますので ぜひご覧ください。
APIKeyなどの機密情報を除くほぼすべてのコードをGitHub上で公開しているのでよかったら確認してみてください。
あなたの知らない緊急地震速報の世界
相当まとめて紹介しているので、事実と異なった表現をしている場合があります。
正しい情報は、参考資料より確認してください。
地震についてある程度調べている方々にとっては「なんと雑な紹介だ!」と思われるかもしれませんが何卒....
私が地震関連のアプリを開発すると決意してから、「あっ、緊急地震速報ってこういう仕組みで発表されていたんだ!」というような学びがありました。
みなさんご存じ緊急地震速報について紹介していきます。
気象庁はどのように緊急地震速報を発表しているのか
皆さんご存じの緊急地震速報を気象庁はどのように発表しているのかをまとめていきます。
↑気象庁資料より引用
1. 単独観測点処理
全国1700点ほどある気象庁と防災科学技術研究所の観測点が地震を常時監視しています。
これらの観測点それぞれが波形解析を行っていきます。
1-1. 自動検測・主成分分析法・B-δ法
a. 自動検測: ノイズレベルの定数倍の振幅を観測したタイミングをトリガとして検知->処理開始
b. 主成分分析法: P波検測時刻から1秒間の変位波形を用いて地震波がどの方向から到来したのかを求める
c. B-$\delta$法: 1秒間の加速度波形の絶対値波形を作成し、それを$y(t) = Bt\cdot e^{-At}$にフィッティングし、係数$A,B$を求める。係数$B$はマグニチュードによらず、震央距離$\delta$と相関関係があり、おおよその震央距離を求めることができる。
1-2. ノイズ識別
1-1.の処理と並行してノイズ識別処理が行われます。
上下動と水平動の振幅比、B-$\delta$法の係数$A,B$の値、加速度振幅最大値等と基に処理を行います。
1-3. レベル法のための閾値超過検出
レベル法とは、上下動振幅 $100gal (1gal=1cm/s^2)$超過を検出した場合に特別な処理を行います。
詳細は後の震度予測手法で述べます。
1-4. リアルタイム震度演算
観測点において地震毎に1つの値をとる「震度」や「観測震度」とは別に逐次的な揺れの大きさを示す「リアルタイム震度」を計算します。
これらの単独観測点処理によって求まった値を逐一 処理中枢に送信し、次のステップ 2.中枢での処理に移ります。
2. 中枢での処理
単一観測点のデータを処理中枢が各種震度予測処理を行っていきます。
大きく2つの手法に分かれています。
2-1. 震源要素を用いる震度予測
地震波を検出した観測点の情報に基づき、震源・マグニチュードを自動決定して震度予測を実行
2-2. 震源要素(震源地・マグニチュード・発生時刻)によらない震度予測
2-1. 震源とマグニチュードによる震度予測手法
2-1-a. 震源決定手法
-
IPF法(
Integrated Particle Filter)法: これまでに発生した地震分布・回数に基づく事前確率と観測点データを最も満足させる震源をパーティクルフィルタにより推定 -
着未着法: 防災科学技術研究所のHi-net観測網のデータを用いる。
地震が到達したとみられる着状態の観測点と、地震が到達していないと考えられる未着状態の観測点について、検出した時刻と周辺のグリッドに配置した仮想震源群をもとに、理想検出時刻と実際の差が少なくなるようにグリッドサーチを行う。
十分収束した地点を最終的な推定震源とみなす。 -
EPOSによる自動処理: 波形データを処理中枢 EPOS(
Earthquake Phenomena Observation System) に集め、S波到達時刻も含めた上で震源決定を行う。
2-1-b. マグニチュード決定手法
1.の処理によって得られた震源と各観測点の最大振幅を用いてマグニチュードの計算を行います。
P波の部分(P波M)とS波以降(全相M)の2種類の計算式がアリ、主要動(=S波)が到達されたと考えられる時間に対応して計算式を消えり替えます。
2-1-c. 品質管理処理
震源要素によらない震度予測の一つ、PLUM法を併用し、震源を決定できないような場合の見逃しを防ぎます。
また、不適切な震源決定を棄却する処理も行います。
2-1-d. 予測震度と主要動到達予測時刻算出処理
推定された震源要素(緯度・経度・深さ)とマグニチュード 予測地点の地盤増幅率 を用いて各地点の震度を距離減衰式という計算式を用いて予想します。
気象庁が行っている距離減衰式による震度推定を自作アプリ EQMonitor内でも実装してあるのでぜひこちらもご覧ください。
緊急地震速報によって発表された震源要素を用いて 距離減衰式で各地点の震度を予測し、一般に発表することは気象業務法 第13条 予報及び警報に違反するので注意してください。
ただし、気象業務法 第17条 予報業務の許可の規定により、気象庁による認可があれば 予報業務を行うことができます。
(くわしくは気象庁 予報業務の許可についてをご覧ください)
2-2. 震源要素によらない震度予測
- レベル法: 上下動振幅 $100gal (1gal=1cm/s^2)$超過を検出した場合に、震源決定や震度予測を行わずに「観測点近傍で震度5弱以上の揺れ」として発表
-
PLUM法(
Propagation of Local Undamped Motion法): 観測点で検出した揺れの周辺地点の揺れを予測する手法
PLUM法は、令和4年3月16日 23時36分頃の緊急地震速報(観測最大震度6強)の発表に利用されました。これは、同日の23時34分頃に同じ地域で震度5弱を観測する地震が発生しており、適切な震源決定ができなかったからPLUM法での発表となったとされています。
 |
 |
 |
 |
 |
↑ 気象庁資料 令和4年3月16日23時36分頃の福島県沖の地震についてより引用
このように、地震が発生してから緊急地震速報の警報地域(=黄色塗りつぶし地域)が広がっていることがわかるかと思います。
これは、時間経過により地震動が広がり 揺れを観測する地域が広がり 観測した地震動から周辺地域の震度を推定したからです。
3. 発表処理
気象庁が緊急地震速報を発表します。
緊急地震速報の種別
あまり知られていないかもしれませんが、緊急地震速報には大きく2つ種類があります。
「緊急地震速報(警報)」と「緊急地震速報(予報)」です。
この2種類では、発表する条件や電文・用途が異なります。
緊急地震速報(警報)
こちらが、テレビ等でよく聞く一般的な緊急地震速報の類です。
発表条件
- 2観測点以上での解析結果により、予想最大震度が5弱以上 もしくは、長周期地震動階級3以上を予想した場合となったとき
更新条件
- 警報が発表されていない予報区で新たに予測最大震度が5弱以上となったとき
予想震度 4以上 もしくは 予想長周期地震動階級 3以上の地域に対して発表されます。
緊急地震速報(予報)
高度利用者向け緊急地震速報とも呼ばれています。
機器制御への応用や、個人の端末などで地点の予測震度や主要動到達予想時刻を表示する等に利用されています。
発表条件は、警報に比べてゆるく、1日に1回くらいは出ています。(←個人の主観なので、緊急地震速報（予報）発表状況をご覧ください。
発表条件
- 観測点における加速度振幅が$100gal$を超えたとき(レベル法)
- 推定マグニチュードが3.5以上か、予測最大震度が3以上となったとき
以上が主な緊急地震速報の発表までの流れ・仕組みです。
一般人は緊急地震速報をどうやって入手できるの?
1. [緊急地震速報を除く地震情報] 気象庁ホームページを通じて公開する気象庁防災情報XMLフォーマット形式電文をPuLL型で入手
気象庁が発表した地震情報をXML形式で取得することができます。しかし、緊急地震速報を入手できないほか、毎分更新のため迅速な配信が求められる今回のケースには適していないため、利用を見送りました。
詳しくは、気象庁HPをご覧ください。
2. [緊急地震速報] 強震モニタのAPIを利用(推奨しません)
強震モニタのAPIから、緊急地震速報を取得することができます。以下の理由から利用を見送りました。
1. 遅延が(ときどき)ひどい 数秒から数十秒単位で遅延することがあります。
2. 取消報は配信されない
3. 深さ150km以上の深発地震や特殊な緊急地震速報(PLUM法・レベル法・IPF法(1点)など)は配信されない
3. P2P地震情報のAPIを利用
P2P地震情報という、気象庁が発表する地震情報・津波情報に加えて、ユーザ同士の「揺れた!」レポートを基にした地震完治情報をP2Pネットワーク上で共有するサービスです。
JSON APIの仕様書も整備されており、利用しているユーザも多そうですが、自分が試した時は緊急地震速報が全く配信されずに却下しました。
「内容や配信品質は無保証です。」と明記されています。
4. [緊急地震速報などの地震情報] 気象業務支援センター(JMBSC)から入手する
各事業者が地震情報を入手する際に利用される手法です。
気象業務支援センターHPより引用
しかし、JMBSCから地震情報を取得するには学生にとってお先真っ暗になるレベルの費用を払う必要があります。(詳しくはJMBSC 負担金ページをご覧ください。)
高校生が、「サブスク入ったわ〜」って言って、月に数万円以上支払い続けるのはあまりに現実的でありません。
いつか働くようになったら契約したいな と妄想していますが。
そこで、上記の図の右下、気象業務支援センターからの情報を再配信している事業者を探してみます。
4-1. IIJエンジニアリング 防災情報連動型コンテンツ配信パッケージ EqCare Type-G
様々な情報をWebSocket/REST APIで取得することができるようです。
仕様書を見ていると、地震情報以外にもミサイルで話題になるJ-ALERTにも対応しているようです。
気になるお値段は......
あ、ごめんなさい.... 厳しいです....
4-2. Project DM-D.S.S (利用中)
Project DM(Disaster Mitigation)-Data Send Service
先ほどのEqCareと同様にWebSocket/REST APIにて地震情報・津波情報・気象警報等を入手することができます。
このサービスはもっと「手軽に生の情報を素早く得たい」、という運営者の思いによって2020年04月に正式誕生しました。
JQuakeやKyoshinEewViewer for ingen、Quarogといった、様々なPC向け地震観測アプリケーションも、このDM-D.S.Sに対応しています。
気になるお値段は...!!!
緊急地震速報(予報)は1,650円/月で入手できます。
(決して安くはないけれど、即時性と信頼性を考えたら)めちゃくちゃ安いです。
私は、2022年3月からずっとDM-D.S.Sにお世話になっております。
現状全く不満がなく、何かあった時もこのサービスの運用・開発者のそうし(@soshi1812)さんに問い合わせると、快く対応していただけます。
これらのサービスを表にまとめてみました。
| サービス | 緊急地震速報 | 地震情報 | 速報性 | 価格 |
|---|---|---|---|---|
| 1. 気象庁防災情報XML PuLL型 | × | 〇 | × | -(無料) |
| 2. 強震モニタ | 〇 | × | △ | - |
| 3. P2P地震情報 | △ | 〇 | 〇 | - |
| 4-1. EqCare Type-G | 〇 | 〇 | 〇 | × |
| 4-2. Project DM-D.S.S | 〇 | 〇 | 〇 | 〇(許容範囲内) |
EQMonitorで用いている緊急地震速報の再配信手段について
前章で述べた通り、Project DM-D.S.Sを用いて緊急地震速報の再配信を行います。
情報をどんな形式で受信しているのか
情報を再配信する前に、DM-D.S.Sからのデータがどのような形式なのかを理解する必要があります。
一部例外を除く地震情報/緊急地震速報は以下の形式で受信することができます。
現行公開しているバージョンでは、Project DM-D.S.SのWebSocketでJSONデータを受信し、それをそのまま再配信している形になっていますが、次期バージョンから、アプリケーションで必要なデータのみ削減して再配信を行う予定です。
型定義はすでにしてあり、アプリケーション内部で扱うデータ構造もそれに沿って変更しています。
コード
class EqmEew {
//...
final int eventId;
final int serialNo;
final TelegramInfoType infoType;
final TelegramStatus status;
final String? hypoName;
final LatLng? hypo;
final double? magnitude;
final int? depth;
final EewDepthCondition? depthCondition;
final EewAccuracy? accuracy;
final bool? isWarning;
final bool isCanceled;
final bool isLastInfo;
final bool? isPlum;
final String? headline;
final String? text;
final EewIntensityForecastMaxInt? forecastMaxInt;
final EewIntensityForecastMaxLgInt? forecastMaxLgInt;
final List<EewIntensityRegion> regions;
}
この構造体をMessagePack形式でバイナリデータに変換し、gzip圧縮、base64変換を経てWebSocketで配信を行います。
「各地方の予想震度(regionsフィールド)をデバイスに送り、デバイス上で通知するかの条件分岐を行いたい。しかし、データをJSON形式でそのまま送ると数百kBになってしまう。」
という問題をMessagePackを用いて解決することができました。
サーバ構成
Oracle Infrastructure CloudのOsaka Regionの無料枠を利用してCompute VMを借りています。
このようにDMDATA.JPより、2本WebSocket接続をして再配信を行っています。
1つは、通知配信・DB保存用、2つ目は、アプリ起動中に接続する自前サーバ<-->アプリ間の再配信に利用しています。
インスタンス内のDockerコンテナについて説明します。
docker-composeでコンテナを管理しており、設定ファイル等はGitで管理しています。
-
EQServer
EQMonitorのサーバの要です。後述するPostgreSQLへの保存、通知データの作成、震度分布図の生成を担っています。
EQMonitorと同じDart言語で記述してあり、スキーマ情報をコピー&ペーストで修正することができ、とても助かっています。
震度分布図の生成に関しては、かている(@cateiru)さんが開発しているearthquake-alertを内部で利用しています。
-
PostgreSQL
地震履歴の管理、緊急地震速報発表履歴を管理しています。
データベース本体は定期的に自宅のRaspberry Pi 4へバックアップを行っています。しかし、DMDATA.JPのREST APIから過去の地震情報は取得可能なので必要になることはない気もします。(が、一応...)
初期化SQL
CREATE TABLE IF NOT EXISTS telegram(
id bigint GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
type TEXT NOT NULL,
time timestamp with time zone NOT NULL,
url TEXT NOT NULL,
image_url TEXT,
headline TEXT,
data jsonb,
maxint TEXT,
magnitude real,
magnitude_condition TEXT,
depth integer,
depth_condition TEXT,
lat real,
lon real,
serial_no integer,
event_id TEXT,
hypo_name TEXT ,
hash TEXT NOT NULL
);
CREATE TABLE IF NOT EXISTS eew(
id bigint GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
url TEXT NOT NULL,
data jsonb NOT NULL
);
CREATE TABLE IF NOT EXISTS information(
id UUID PRIMARY KEY DEFAULT uuid_generate_v7() NOT NULL,
title TEXT NOT NULL DEFAULT '',
body TEXT NOT NULL DEFAULT '',
author TEXT NOT NULL DEFAULT 'Developer',
tags TEXT[] ,
created_at TIMESTAMPTZ NOT NULL DEFAULT CURRENT_TIMESTAMP
);
CREATE TABLE IF NOT EXISTS earthquake_v2(
id bigint GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
type TEXT NOT NULL,
origin_time timestamp, --地震発生時刻
arraival_time timestamp NOT NULL, -- 地震検知時刻
hypocenter jsonb, -- 震源要素
magnitude jsonb, --マグニチュード要素
maxint text, -- 最大震度
maxlpgmint text, -- 最大長周期地震動階級
telegrams jsonb[] NOT NULL -- 電文リスト
);
データが重複しており、DB構造としてはまったく良くない気がしているので、近いうちに作り直すつもりです。
-
PostgREST
上のPostgreSQLをREST API形式でGET・POST等することができます。
これで、ユーザからの地震履歴取得要求・EQServerからのデータ追加要求を対応しています。 -
Kong API Gateway
API Keyの認証やリバースプロキシを担っています。 -
nginx
静的データ(震度分布図など)のホスティングを行っています。 -
EQAPI-dmdata-proxy
DMDATA.JPからの情報をEQMonitor用のデータ構造に変換し、WebSocketで再配信を行っています。
内部実装は、Denoを利用してみました。接続数等の情報を確認するエンドポイント(ローカルからのみ)もおいてあります。
いつか、後述するNetdataと連携したいと考えています。 -
Traefik
HTTPS化・リバースプロキシ・レート制限を担っています。
Dockerとの親和性が非常によく、お気に入りです。 -
Netdata
モニタリングツールです。Netdata Cloud(無料)と連携させると、自前サーバに直接アクセスしなくても、Webから情報を確認でき、アラートも設定可能です。複数サーバの管理にも非常に便利で、PostgreSQL,nginx VTS, traefikのデータをnetdataで監視しています。
(いつか、スマホから良い感じのUIで監視できる自分用のアプリを作りたいなと妄想しています)
まとめ
読み返してみると、ほとんど緊急地震速報の資料をまとめただけ みたいになってしまいました...
(一応分かりやすいようにまとめたつもりなので) 緊急地震速報について興味を持っていただけたら幸いです。
私自身、まだまだ緊急地震速報について知らない部分が多くあると思っています。
もし、この記事に関して誤った情報を掲載していたらコメントいただけると幸いです。
Buy me a coffee
現在学生で、資金面で相当ギリギリです。
もし、このアプリに興味があり支援いただけるようでしたら、下記リンクより支援していただけると非常に幸いです。
(記事のいいねでも、モチベ爆上がりします!!)