jessehamner / weatherwidget Goto Github PK

Add functionality to produce delimited text files (JSON, primarily, but also .tsv) and html tabular output for all text products (forecast, alerts, hazardous weather outlook, spotter activation, and current conditions).

The NWS doesn't release new forecasts every hour, but it does release new radar images many times an hour. Therefore it makes no sense to retrieve forecasts, area forecast discussions, or current weather observation data on the same schedule as retrieving radar images and alerts data.

The main script should implement docopts such that individually useful data can be retrieved with the temporal granularity that is warranted by the frequency of the data being updated. Then the scheduled execution of the main script could be easily configured to gather data as needed. This move should improve overall performance and avoid wasting both bandwidth and time.

Enable raw METAR parsing.

https://github.com/python-metar/python-metar

It's possible to use several web API calls (with JSON returns) to determine many abbreviations, location identifiers, and settings that are currently entered by hand in settings.yml. The script should provide a one-time or on-demand functionality to retrieve as many of these settings as possible to simplify setup.
Many locally applicable settings are contained in these API URLS:

• https://api.weather.gov/points/2-decimal-LAT,2-decimal-LON
• https://api.weather.gov/gridpoints/

See especially

• Local observation stations: https://api.weather.gov/gridpoints/FWD/78,120/stations
• Hourly forecast by grid coords: https://api.weather.gov/gridpoints/FWD/78,120/forecast/hourly

https://www.wpc.ncep.noaa.gov/basicwx/93fndfd.gif

Proposed: a "status table" or "dashboard" composed of an aggregated JSON file that contains go/no-go and, where practical, at least a category of failure, for each subcomponent of the project. Thus, if the forecast map fails but everything else is obtained okay, the table would be mostly "green", with perhaps an indicator marker of "yellow", indicating the user might want to see what has gone wrong.
Individual subsystems could put their diagnostic data into the standard JSON output, that could then be collected by a new class, and served up as a discrete JSON API endpoint using Flask, as most of the data is already served up that way.

Consolidate shell script functionality that munges graphics files using convert -- move functionality into Python library using PythonMagick.

Leverage the value of the metpy library, and use it to generate derived variables instead of a local function set.

In mid-December 2020, NOAA stopped posting the composite reflectivity images and image layers to the "ridge" URLs. Thus, the functionality has broken for making radar and time-series radar images. The new images are available for download as TIFFs and/or KML files. The TIFFs include no other layers but the false-color radar information.

print statements have got to go, except for a small subset of use cases.

See, for example, images at https://www.weather.gov/fwd/drought and https://twc.tamu.edu/kbdi

Pull maps, kmz, text, and/or data from

https://www.spc.noaa.gov/products/outlook/day1otlk.html
https://www.spc.noaa.gov/products/spcacrss.xml
https://www.spc.noaa.gov/products/spcrss.xml

or from (for example) https://www.spc.noaa.gov/products/outlook/archive/2020/day1otlk_20200512_1630.kmz

Should be possible to pull some information from the raw Area Forecast Discussion, enclosed in slashes, like '/NEW/', '/Issued HHMM [A|P]M TZ Wkday Mon Day YYYY/', '/Next Week/', '/Through Sunday Morning/', and so forth, into the JSON for use as additional header text, and resulting in a more compact HTML pane.

Basically, she's asking for the Zone Forecast Product, plus a way to display it on the webpage.

Files might be overly large if the script generates 24 hours of sequential images, but it could pull hourly images or thereabouts.

Timestamp function should write a black box over current time stamp position before writing new time stamp.