WESTERN REGION TECHNICAL ATTACHMENT
NO. 98-10
March 17, 1998

AN INTRANET OBSERVATION MONITOR

David Zaff - WRH, SSD Salt Lake City, UT

Introduction

In the fall of 1997, NWSFO Salt Lake City implemented a UNIX/LDM-based program which serves as an Intranet observation monitor. This program is designed to alert the forecaster to significant weather occurring in a given forecast area. The program accepts observational input in a specific format for some station, determines whether data meet certain criteria, and then updates a HTML file with any needed changes. Stations that have significant weather are placed into the HTML file with their latest observation time (in LST), and a color coded link to that station's time series file.

The idea behind this program is to compliment the various ways in which one observes observations. It was originally designed for the Aviation Forecaster, but has applications for the Public Forecaster as well.

This program is currently designed to work with Salt Lake City's METAR decoding function found in web_page.c (see LSA-02 or TA96-33), as well as Salt Lake City's boi_raws.c program. In fact, it will accept input from any program so long as that input is sent to this program in a specific format (examples are shown below). For example, Salt Lake City uses this program to work with data coming in from the University of Utah.

The HTML file serving as the monitor can be loaded from any Internet browser, and is designed to reload itself once per minute. Thus, there may be up to a one-minute delay in alerting the forecaster. This has not been a problem in Salt Lake City, and, in fact, observations are often noticed on the monitor before they are picked off of AFOS.

For a real-time example, see http://nimbo.wrh.noaa.gov/saltlake/obs_monitor.html

Please note: While this link is available to the public, the Salt Lake City office has chosen not to publicize it, since resetting the monitor at the office would lead to confusion to those not monitoring the weather for an extended period of time.

Program Tasks

1. Determine observation filename links. (Current programmed possibilities include:

METAR...assumed link name: KXXX.html
where XXX is some 3-letter station ID. (file probably generated from web_page.c)

RAWS....assumed link name: RAWS.ST.XXXXX.html
where ST is some 2-letter state ID and
XXXXX is the first name of the RAWS station. (file probably generated from boi_raws.c)

UofU....assumed link name: UofU.XXX.html
where XXX is some 3-letter station ID. (file probably generated from UofU_data.c)

2. Determine UNIX time for "Green Time" appearing at the top of the monitor - designed to clue the forecaster in on whether the monitor is up to date.

3. Get local hour - used for removing data that's been on the monitor for over one hour.

4. Read in monitor file, except ignore lines that contain the current observation (prevents the observation from appearing in the monitor more than once), and ignore old data (see 3.)

5. Create new monitor file, checking to see if input data meets any desired criteria. Links are color coded.

NOTES:

Salt Lake City has found that it tends to stop reloading after a period of time. Thus, some JavaScript code and an additional file was created: obs_monitor.html to deal with this bug. The JavaScript code allows obs_monitor.html to open a special window containing the file obs_monitor_toolbar.html. obs_monitor.html will reload itself, and, in addition, force reload obs_monitor_toolbar.html once every five minutes. So, as long as obs_monitor.html is available somewhere (usually minimized), the actual monitor itself should continue to update at generally regular intervals. The file obs_monitor.html, while not entirely necessary, will minimize "hang time".

obs_monitor.html also sets the initial size of the obs_monitor_toolbar.html, and removes some of the icons that normally appear in browser windows.

Calling This Program from Other Programs

For those that plan on creating local programs, or want to existing local programs to run this, the following format is required. (You can use this format to manually test how the program works, too.)

monitor obs wind vsby sky1 sky2 wx1 wx2 wx3 wx4 wx5 LST cObsType

Example for a Salt Lake City METAR:

METAR KSLC 180650Z 18015KT 5SM -RA SCT010 BKN025 08/04 A3011 RMK SLP182 T00840036 51007

proper input to this program:

monitor SLC 18015KT 5SM SCT010 BKN025 -RA 00 00 00 00 12:50AM METAR

For RAWS Data:

RED DOME, UT

Date hour MDT wind dir/spdwind dir/gsttemp Fdwpt F RH accum pcpn fuel temp 10 hr fuel mstr
Oct 18 8:04AM MDT 1817 19G35 51 51 100 4.78 48 12.9
Oct 18 7:04AM MDT 1815 19G32 50 50 100 4.72 48 12.9

proper input to this program:

monitor RED 19035KT 10SM SKC SKC PCPN LGT 00 00 00 8:04AM RAWS

(The gust can be used as a replacement for the regular wind here. In addition, since there is no visibility or sky condition, these are set to 10SM and SKC respectively. Precipitation is determined by examining the previous observation (all of this is done within boi_raws.c) Note: measurable RAWS precipitation may be a result of melting snow.

The variables cObsType and obs will be used to create a filename. If you plan on using your own programs to run this one, MAKE SURE you understand how this program will be used to make a filename.

Monitor.c is available at http://nimbo.wrh.noaa.gov/wrh/LSA/lsa-36/ and http://nimbo.wrh.noaa.gov/saltlake/web_programs/