• Tropical cyclone tracks
• NHC discussions
• NHC public advisories
• HLS products from coastal WFOs

VTEC outlines are already available for tropical weather and will be handled in the interim by the generic parser.

It's inefficient to open and close pipes constantly. Make it to we can have long-running processes to ingest data. Also, make it to where we can explicitly select the parser that will be used to save a few milliseconds of autoloading because I like complexity.

For reusability's sake, we'll want the parsing tools created in this milestone to be more modular than stuffing everything in a Parser namespace.

Currently, the ingestor only respects the first VTEC string in a product. However, multiple VTEC strings are often used in the tropical breakpoint products (and can be used in some situations upgrading watches, etc.)

The parser and associated methods need to be updated to permit multiple VTEC strings.

Impact-based warnings come with some machine-readable HAIL...WIND...TORNADO... tags. Ensure these are properly parsed out.

Set up tables for the following:

• Convective Watches
• VTEC'd Watches/Warnings/Advisories
• Special Weather Statements
• Mesoscale Convective/Precipitation Discussions
• SPC Outlooks
• Local Storm Reports
• Tropical Products
• River Flood Products
• Forecast data

Implement parsing local storm reports.

LSRs should export the type, magnitude, description, time, and location (in GeoJSON coordinates) of the report.

Parse and store SPC outlook points to allow us to generate maps and alerts based on outlook.

We would want to parse watch probabilities so that we can generate graphics with these probabilities, as well as identify watches as PDS watches.

Go big or go home. Performance and language improvements combined with having total control over the servers make this worth it.

The incoming arguments should look like this:

--wmo=WMON00 --office=OOOO --time=DDDDDD --afos=AFOS [--corrections=CCA]

This will help generate events directly to parsers without having to figure everything out. Saves some time.

Implement detection of impact-based warnings and expose that data in events so listeners can take advantage of the additional metadata.

At some point, add support for Hydrologic Valid Time Extent Code for better flooding-related metadata.

May save on disk I/O and other potentially fun race conditions.

Need some basic logging in the beta version beyond just writing to stderr. LDM loses track of that, apparently.

The bot needs an administrative interface of some kind for easily manipulating configuration.

Add a backing store for alerts. Backing store is ideally pubsub-capable.

Initial implementation will be RethinkDB, but this should be abstracted away to allow different engines in a future iteration.

• Implement storage initialization for first-time use
• Consider table schema for the DB
• Implement schema for DB
• Set up product routing/saving accordingly

Special Weather Statements and Significant Weather Advisories. NWS Charleston, SC does not issue significant weather advisories by name, but many other offices do, so we'll work a little support in.

SPSes can be polygonal or zone-based depending on how they are issued. We should interpret polygonal SPS products in the “significant weather advisory” column. You can also see SPS products for full forecast zones.

Recently, impact-based bullets have made it to the SPS/SWA, so we can perhaps parse those out, too.

As the number of events the system processes increases, we'll almost certainly need some sort of queueing backend to handle the load.

Parsing could stand to have some concerns separated for easier unit testability.

When looking at a parsed product in the DB, the issued_time is always null. Need to nail this down.

To fix in 2.1.

Parsing the mesoscale discussions from SPC allows us to alert on watch probabilities. These may also be helpful for syndication to other advanced platforms.

Parsing mesoscale precipitation discussions may be less helpful for public consumption. Could be good for alerting for more advanced users.

Allow climate products to be parsed and stored in the database.

Often times special weather statements and warnings will include a TIME...MOT...LOC string from which the time of the storm fix, the storm motion, and the coordinates of the storm can be derived. Add awareness to the parser to send this data along.

Begin work on a small API to allow external sites (such as chswx.com) to display our parsed warnings.

This engine needs to be refactored into a publish/subscribe system, which will allow easy implementation of multiple ways to route products (to the Web, to a XMPP chat room, to e-mail, to multiple Twitter accounts, etc.)

Devise a scheme to allow endpoints to subscribe to events generated by the parser. The NWSChat model is not a bad one to follow.

Todos for this to get us back to some sort of operational parity with the current release version:

• Debugger for output in debug mode
• New logging endpoint for overall logging ops
• New Twitter endpoint
• New Email endpoint

Give parsers the ability to search for and properly encode polygon warnings.

Expire date should always be shown for tweets indicating an expiry on the following day. Current behavior counts 24 hours ahead and is susceptible to confusion as well as errors when using Daylight Saving Time.