Weather alert feature

[toland]

We want to alert users to significant adverse weather events (and other natural disasters) near them. We should pull data from national and state sources like the US National Weather Service and alert users when we become aware of an adverse event near them, or they move into an area where an adverse event is expected.

[toland]

After working on the prototype to pull NWS alerts into the system, I propose a table structure something like the following:

CREATE TABLE safety_alerts (
    id uuid PRIMARY KEY,
    created_at timestamp with time zone NOT NULL,
    updated_at timestamp with time zone NOT NULL,
    expires_at timestamp with time zone,
    title text NOT NULL,
    summary text NOT NULL,
    geometry geometry NOT NULL,
    data jsonb NOT NULL DEFAULT '{}'::jsonb
);

The top-level table design has enough common information to display the alert, with all of the details from the upstream service stored in the data parameter.

In terms of data ingestion, I think we should create a Ruby base class that sets up the database connection and defines helpers for inserting the records into the database. We could define a callback that would return a list of objects that contain the right data, and the base class would then insert that data into the database. We could wrap all of that in a base image that would make it easy to spin up new Lambda jobs with different import services.

@bernardd Thoughts?

[bernardd]

Sounds like a good starting point to me.

[bernardd]

Just looking at that schema, I think we should add two more fields: source (which service we got it from) and an indexed native_id (what ID the alert has on that service). That allows us to do quick index lookups to update existing warnings.

[bernardd]

Also probably worth having a link field since plenty of these kinds of events are likely to provide (or be able to have generated) a link to the relevant authority.

[bernardd]

Also also, on reflection I'm not sure the data field should be json - it's entirely conceivable that other agencies will use other formats.

[toland]

Also also, on reflection I'm not sure the data field should be json - it's entirely conceivable that other agencies will use other formats.

Sure, the NWS uses CAP in XML. I was thinking that we would store the parsed alert in the data field, not that we would store the alert in whatever native format. I certainly don't want to be trying to figure out what native format an alert was provided in when referencing it from Wocky.

[toland]

What do you think about establishing a convention for the source names? Maybe a two-letter country code, followed by a state code (if applicable), and then the service acronym. For example:

• US National Weather Service: "US_NWS"
• NSW Rural Fire Service: "AU_NSW_RFS"

I'm thinking this might help disambiguate the myriad of TLAs that we are likely to encounter.

[toland]

In general, I think Wocky should own its database. I've created a migration in a branch to create the safety alerts table: https://github.com/hippware/wocky/blob/safety_alerts/apps/wocky/priv/repo/migrations/20200224225018_safety_alerts.exs