nina_xmpp icon indicating copy to clipboard operation
nina_xmpp copied to clipboard

No messages for "Hochwassermeldungen"

Open sandwm opened this issue 1 year ago • 0 comments

To say it upfront: This seems to be more of an issue of the data provided by LHP / BKK in the json file and less of a bug in nina_xmpp itself, but it might be worth noting it in the README (or at least here in the issue tracker).

I noticed that within the ~1.5 years since I registered with your instance on [email protected], there were no messages from the "Länderübergreifendes Hochwasserportal" aka https://warnung.bund.de/bbk.lhp/hochwassermeldungen.json while e.g. FediNINA has them.

I couldn't reproduce this on a new test instance of nina_xmpp, which was confusing until I found that the identifiers, which nina_xmpp uses so as not to send the same message multiple times, seem to be (always?) the same for the same federate state. (My new instance of course had no pre-existing database, so all identifiers were "new".) So today in hochwassermeldungen.json there was:

{
  "identifier": "HOCHWASSERZENTRALEN.DE.NW",
  "sender": "[email protected]",
  "sent": "2023-04-02T13:25:00+02:00",
  "status": "Actual",
  "msgType": "Alert",
  ...,
  "info": [
    {
      ...,
      "urgency": "Immediate",
      "severity": "Severe",
      "certainty": "Observed",
      "effective": "2023-04-02T13:22:00+02:00",
      "onset": "2023-04-02T13:22:00+02:00",
      "expires": "2023-04-03T14:22:00+02:00",
      "senderName": "Nordrhein-Westfalen",
      "headline": "Hochwasserinformation Nordrhein-Westfalen",
      "description": "An einem Pegel werden Schwellenwerte überschritten - es liegen Lageinformationen vor",
      "web": "<a href=\"http://www.hochwasserzentralen.de/bericht_nw.htm\">Länderübergreifendes Hochwasserportal</a>",
      "contact": "Landesamt für Natur, Umwelt und Verbraucherschutz NRW<br/>Nachrichteneinsatzzentrale"
    }
  ]
}

In other json feeds used by nina_xmpp (specifically biwapp and mowas - dwd and katwarn are currently empty), the identifiers look like they could be unique and indeed that's what I would expect given the name, but that doesn't seem to be the case for hochwassermeldungen.json.

The text ("An einem Pegel werden Schwellenwerte überschritten - es liegen Lageinformationen vor"), as far as I have seen in FediNINA, is always more or less the same in NRW (not word for word, but no more information than this). This "severe" warning was issued for all of NRW because 1 gauge (north of Bonn) out of 85 in NRW reached "Informationsstufe" 1 out of [none, 1, 2, 3]. See https://www.lanuv.nrw.de/umwelt/wasser/wasserkreislauf/wasserstaende/pegeldaten-online at the end of the page for a description of those levels.

The other warnings all had the same identifier except for the abbreviation of the federate state (so e.g. "HOCHWASSERZENTRALEN.DE.BY" for Bavaria), urgency: "Immediate", "severity": "Severe" and "certainty": "Observed". (The federate states were Bayern, Hessen, NRW, Saarland, Thüringen.) I didn't look further into the information provided on the websites specific to other federate states.

So nina_xmpp misses some messages. I was a bit concerned this could affect important messages. However, regarding the "Hochwassermeldungen" (which are triggered even when just some farm land 100km away from you could get a bit more water than it asked for) I'm actually rather happy nina_xmpp doesn't spam me with those. Don't get me wrong - warnings about high water can be very important, life-saving even, and for that very reason the data reported in hochwassermeldungen.json should be improved. But given how things currently are, I think it's probably better that nina_xmpp doesn't send those messages (at least in NRW - again, didn't look further into other federate states, although they look the same in the json). I simply ignore them in FediNINA since it is always just a really unhelpful "es liegen Lageinformationen vor". Given that even the minimal trigger of "Informationsstufe 1" at 1 out of 85 gauges in NRW was reported as "severe" and in general most fields apart from the timestamps seem to be more-or-less static, I don't see how this could be filtered sensibly.

Do you see a way to handle this better? Or should this maybe just get a note in the README and/or the output of the feeds command, so that users don't expect to get warnings on high water which never come (at least from this source – I hope that the other sources would push out their own warnings on real high water emergencies)?

sandwm avatar Apr 02 '23 22:04 sandwm