見出し

強震モニタの観測点をリポジトリに独立させました

   2025年12月03日     6分で読めます

この記事は 防災アプリ開発 Advent Calendar 2025 の3日目の記事です。

はじめに

僕は KyoshinEewViewer for ingen というアプリを趣味で開発しています。

このアプリは強震モニタの画像から観測点データを抽出して表示する仕組みを持っているのですが、観測点データはアプリ本体に組み込んでいました。

OSS として開発しており GitHub 上でソースコードを公開しているため観測点データは公開されていましたが、いくつかの問題がありました。

問題点

  1. 更新の手間: 観測点データを更新したとき、再度ビルドしてリリースする必要があった
  2. 更新のリスク: アプリケーションのリリースが必要なため、新機能などをテストしているバージョンなどが存在すると更新が遅れることや、更新漏れが発生する可能性があった
  3. 再利用性: OSS にもかかわらず独自形式でパックしていたため、他のプロジェクトで再利用しづらかった
  4. 現行データ形式の限界: 現状のデータ形式は KyoshinMonitorLib で使用しているデータ形式そのままでしたが、以下のような課題がありました
    • KyoshinMonitorLib 自体がすでに作成(2017年!?)から時間が経っている
    • データは作り直しているものの、EqWatch のデータ形式を参考にしていたため未使用のデータフィールドが存在する
    • 強震モニタ画像上の座標が1ピクセルで指定するだけだったため未割当の観測点を検出する機能などの開発が困難
    • 過去バージョンのクラス定義では日本測地系の座標情報が非nullとなっており、観測点データが正常に読み込めるとは言えない状況だった

こういった問題を解決すべく、v0.20 で観測点データを独立したリポジトリに分離すべく作業を行いました。

仕組みの検討

今利用しているファイルのリポジトリを独立させるだけならファイルをそのまま持って行っても良いですが、バイナリデータのためそれだと git の特徴である変更の追跡などが困難になります。

データ形式の変更

今までのアプリは、MessagePack＋LZ4圧縮 を行った状態で保持していましたが、目的としては容量の圧縮が主でした。

これを独自リポジトリとして独立させるにあたり、まずはマスターデータとしてすべてのフィールド･データを保持したファイルを用意し、 そこからリリースに合わせて必要な形式にファイルを変換してアプリなどに提供を行うことを目指すこととしました。

オフセット概念の追加

強震モニタのデータは1観測点 3x3 ピクセルで表されます。そのため理論上そのピクセルがどの観測点かを把握できれば、新しい観測点の検出や漏れが自動で検知できるようになるはずです。

しかし現実のところ日本には高密度で観測点が設置されており、画像上でも観測点は重なっているため一括で 3x3 ピクセルの範囲を観測点と断定することが出来ません。

そこで、観測点データを作り直し、3x3 ピクセルの中心座標+オフセットで画像上のピクセルを判別することとしました。

それに合わせ観測点エディタのリニューアルなども行い、観測点の範囲外となるピクセルの検出機能なども備えました。

観測点エディタのスクショ

KMOP ファイル

ファイル形式自体も既存の KyoshinMonitorLib から読み込める Json, CSV, MessagePack+LZ4 に加え、新たに Kyoshin-Monitor Observation Points File として kmop 形式を開発することにしました。

kmop 形式は既存の MessagePack をシリアライズするだけではなく、ファイルにヘッダを用意し独自の圧縮形式やシリアライズを行うことでデータ容量の削減を行っています。

全体のファイル構造として以下のようになっており、

+------------------+
| Magic Header     |  4バイト: "KMOP" (ASCII)
+------------------+
| File Header      |  MessagePack形式
+------------------+
| Data Body        |  MessagePack形式（圧縮可能）
+------------------+

MagicHeader ですぐにフォーマットを判断できるようにしつつ、File Headerでメターデータの定義をしています。

このメタデータでボディ部分の圧縮形式を定義し、ボディ部分はただの配列としています。

このボディ部分のエンコードにも工夫を入れており、観測点の座標は1000倍して数値として保存することにより約100m程度の誤差を許容して節約を可能にしたり、増えた情報である中心座標とオフセットの概念についても、オフセットの座標をX座標、Y座標を4ビットに押し込み1バイトとして扱うことでファイル形式が変わって情報が若干増えたにもかかわらず観測点ごとの容量は削減できるように力を入れました。

その数バイトの努力がなにに生きるのかは謎です。

わざわざオフセットを含めたのはクライアント側で検出機能を利用できるようにしたかったためですが、いらなかったかもしれません…。

リリース処理

先述の通り、マスターデータはすべてのプロパティを持った json ファイルを使用することにしました。

タグをプッシュしてリリース処理が始まると、リポジトリに同梱している変換アプリがその json ファイルを読み取り各データ形式に変換し、リリースを作成します。 現状出力している形式は、

  1. 元のマスターデータの json
  2. Json
  3. CSV
  4. MessagePack
  5. MessagePack+LZ4
  6. KMOP

の6種類です。要望があれば増やしていきたいと思います。

観測点座標のオフセットについては、旧形式には存在しないため、合算した値を出力するようにしてあります。

自動更新

拙作のアプリ KyoshinEewViewer for ingen ではバージョン 0.20 からその観測点情報の自動更新を実装しています。

実装としては簡単で、GitHub API を使用して最新リリースを取得、リリースの作成時刻と現在読み込んでいる観測点情報ファイルの作成時刻を比較して、一定以上 GitHub 側の方が新しければリリースに添付しているファイルをDLし、再起動後に読み込まれて適用されるという仕組みです。

完成したもの

https://github.com/ingen084/kyoshin-monitor-observation-points

です！

今後について

データ形式としては、フィールドを増やす形で地域のデータを増やす予定です。○○県○○地方 の地方の部分です。

各種形式は現状リポジトリ内と KyoshinEewViewerIngen リポジトリ内に置いてあるだけであり、まだライブラリとして汎用的に利用できる状態ではありません。

今後 KyoshinMonitorLib 側も更新を行い新形式に対応させる予定ですので、よろしくお願いします。

さいごに

今年もアドベントカレンダーの時期が始まってしまいましたね…。

防災アプリ開発アドベントカレンダーはまだまだ空きがあるので興味のある方はぜひご参加ください！

僕は、他に参加者がいなければもう一つぐらい記事を(書けたら)書こうと思います！

宣伝

KyoshinEewViewer for ingen では2025年の利用者アンケート を開始しています！

アプリを利用したことのあって、もし興味のある方がいらっしゃいましたら回答いただけると非常にありがたいです。

今後とも、よろしくお願いいたします。