WESTERN REGION TECHNICAL ATTACHMENT
NO. 00-04
MARCH 21, 2000
WRSPOT
A COLLECTION OF WEBPAGE SCRIPTS
FOR HANDLING SPOT FORECAST
REQUESTS AND FORECASTS
Tim Barker - WFO Missoula
Discussion
The WRSPOT programs are a set of perl Common Gateway Interface (CGI) scripts and associated datasets, that provide a way for users to request fire weather spot forecasts, and a way for National Weather Service (NWS) forecasters to post those forecasts to the Western Region (WR) Web Server. It was developed with three main design principles: 1) ease of use for the spot forecast requestor, 2) speed up the production of spot forecasts at the NWS office, and 3) provide a ‘one-stop-shopping' location on the web for weather information pertaining to a particular burn or wildfire.
The programs were originally developed to solve several problems with spot forecast production at the NWS office in Missoula, MT. The programs have been re-written to give considerable flexibility to other WR NWS sites with a minimum of effort, but complete control of all aspects of "look and feel" are not yet possible. Other features may be added in future versions of the software.
If you decide to use the programs in their current state, please send me an e-mail (timothy.barker@noaa.gov or Barker, Timothy in cc:Mail) or a phone call (406-329-4715) so that I can put you on an e-mail list for notices about program updates, documentation updates, etc. If you want to use the detailed maps feature of the software, I also need to know the latitude/longitude extent of your display area from the configuration file (see the configuration section), so that I can download the appropriate maps from the USGS for your site.
So, to summarize, to setup the programs to run in their current form at a Western Region site, you need to do the following:
1. Complete the configuration Actions defined below on pages 6-15 (that sounds like a lot, but it really shouldn't take too long).
2. Contact me (Tim Barker) so you can be notified of changes
3. You might want to modify the "Requestor Instructions" section of this documentation and hand it out to your users (I put screen images of the various webpages in mine - but you will want your screen images to match what you have after you complete your configuration).
4. You might want to modify and use the "NWS Instructions" section of this documentation to train your forecasters in using
If you want to see the programs themselves, you can find them on the WR Web Server in the directory /http/cgi-bin/wrspot, and the programs are described in more detail below (well, not yet, that part is not done yet).
Some of the features that these programs provide for spot forecast development may be better provided by other tools in other offices, or the tools provided here may be unnecessary for some offices. These programs were never intended to provide all the tools needed to produce spot forecasts at all offices, nor were they intended to define HOW spot forecasts SHOULD be produced at other offices. My hope is that unique local office solutions to local office problems will still be encouraged. However, since many people have requested similar tools for their NWS offices without having to learn a lot about perl or CGI programs, I am providing them here for anybody that wants them. I would encourage persons who are better CGI programmers than myself to come up with other solutions that might be better suited to individual offices. I personally feel that if the NWS wants to make spot forecasts officially available over the web, then the NWS needs to provide web infrastructure and programming support for such projects, so that NWS forecasters can get back to concentrating on the weather.
History
Prior to 1998, most spot forecast requests for the Missoula office were received and disseminated via a Forest Service Computer terminal located in our operations area. In 1998, the forest service upgraded their computer system and offered to provide a new terminal to our office. However, to simplify system management and local training problems, we decided to look for other solutions for spot forecast production. In 1998, we tried to use e-mail as a mechanism by which forecasts could be requested and disseminated, but we encountered many problems because e-mail systems are often subject to considerable delays. In 1999, we developed a system on our office website where users could request spot forecasts, and the completed forecasts were posted back to the website. This system was well received by most of our users, and requests to expand the service beyond the Missoula office were the motivation behind the current programs.
Features
The programs center around a daily spot forecast "monitor" page that shows all the spot forecast requests for a particular office on a particular day. Links are provided on this page to (1) view the detailed information for each spot forecast, (2) request a spot forecast, and (3) view other information for other days. The ‘detailed' web page for each spot forecast contains information about the request, maps of the area, as well as the completed forecast, and is set to automatically update on most browsers as information is released.
The text portion of the forecast looks very similar to the spot forecasts that the NWS has provided for years, with the exception that the requestor can specify which parameters are provided. We introduced this feature so that our forecasters would not have to spend valuable time providing information that was not important to the user. In the past, we provided the same forecast parameters for every spot request. In many cases, we would spend time worrying about precise temperature forecasts when the user ‘couldn't care less' about the temperature but was very worried about the winds. By allowing the users to specify what parameters are provided, we help the user get just the information that is important to them and, in many cases, we help speed up the process of providing spot forecasts by the NWS. Of course, forecasters need to be careful to provide important information even if the user did not request it, such as alerting users to potential dispersion problems even if they did not request such information.
Problems
Bugs
Several bugs remain that are keeping detailed maps from working for all locations. To further complicate the issue, the detailed USGS data that I am using is not available everywhere yet. There are many applications that can give you an ‘image' of the USGS quadmap at a specified location, but they can require user intervention (like inserting a CDROM), may have problems on quadmap boundaries, or restrict us to seeing all the text and graphics on the printed USGS maps. I am developing this map software so quadmap boundaries are transparent, and we can completely control what is displayed on the map, color the image by topography rather than by vegetation, etc. I believe I should have this working soon, but I will still need to know which sites desire to have detailed maps generated - since there is not enough disk space on the WR Web Server to allow data for the entire country to be stored there.
The monitor map is not placing city labels correctly when there are overlap problems.
When a forecast is issued and a question was not earlier posted, a "blank" question window shows up anyway.
Security
Anything posted on a website is, essentially, available to anybody in the world. This poses some problems in this case, where some information about fires may be considered ‘sensitive', such as the exact location of prescribed burns, contact phone numbers, etc. One solution would be to restrict access to this information and require passwords be provided to view such information. However, we have NOT adopted this approach for several reasons.
First of all, fire weather information may be needed by a wide variety of people that often ‘come and go' during the time when the information is needed. For example, crews coming in from ‘out-of-state' to work on a burn may want to see specific weather information before they arrive. If password access were very restrictive - perhaps having a different password to access information about each particular burn - it was thought that it would produce an unnecessary burden on the users to communicate the ‘password' to others who need to know it. On the other hand, if passwords were more lenient - perhaps a single password to enter the ‘secure' area - the large number of people that would need to know the password would quickly render it ineffective, such that virtually everyone would know it.
In addition, passwords produce extra ‘systems management' burden that is certainly not needed during busy times. During the fire season, users typically have many temporary staff that may need to view spot forecast information. This means that the users would have to develop ways to communicate the password among temporary staff. It is likely that with staff changes prevalent during the fire season, there would be times when passwords were forgotten, and new passwords would need to be issued (often, urgently) and would force users to communicate new passwords within their organizations. In addition, the NWS office would need to more systems management tools to issue new passwords, reveal forgotten passwords, etc. This would likely be most needed during times of heavy spot forecast loads - producing added stress to NWS personnel.
Instead, we decided to restrict information based on the Internet protocol (IP) addresses of each computer. All requests for information from the website come with the IP address of the computer that wants the information. Lists of computer addresses that can see all information, some information, etc. are kept internally by the software.
There are some problems with this approach. Users that connect to the Internet via dial-up connections through an Internet service provider (ISP) are typically issued a different IP address every time they connect. Thus, the same person may appear to have different addresses at different times, and may be restricted from seeing all the information about a spot request that they originated! In the future, I may add the ability to use web "cookies" to solve this problem - allowing detailed access for users with known IP addresses, or ones with the proper "cookie" information.
Editing
Providing forecast requests and dissemination via the web is great, but doing EVERYTHING on the web may not be ideal. In the current version, all editing of the forecast needs to take place using the web browsers from editing tools. While these tools are pretty adequate (providing typical cut, copy, and paste functions) they lack the ability to set margins, do spell checking, etc., that are important to completing forecasts quickly and accurately. Also, on pages with links, forecasters have to be especially careful to save any text editing before using a link to jump to another website (which is VERY easy to forget about). Future versions of the software may allow forecasters to edit the forecast portion on AWIPS workstations and then "import" these forecasts into the webpage information.
Future Plans
I am still in the process of fixing some problems, but was under pressure to provide the system as quickly as possible, so the following will be fixed rather quickly:
--Problems with detailed map generation
--Legal to lat/lon conversion is not working in all states
--Implementing cookies so that users accessing webpage via dialin ISPs that have different IP addresses each time can view/edit their requests.
These are added features I would like to add in the near future:
--Many more links on the forecast pages. I can link to the Satellite loops already on the WR Web Server, as well as add links to data from the nearest RAWS sites, etc.
--Check for whether a spot request is in your fire weather area of responsibility, rather than just using a simple latitude/longitude box. These should be available soon since Arcview maps of all fire weather districts are being draw.
--Add a way to edit the forecast on AWIPS rather than using the web browser editor. I think the initialization would still take place at the WR Web Server, but you could import the text for editing, and then export the text back to the WR Web Server when you are done editing.
--A way to mark users as "known" or "unknown" to provide a little more security so that somebody in Florida cannot request a spot in your area and make it look good enough that you spend time working on it. I envision that the first time a user makes a request and you do not know who they are, they would have to call you - then you could add their address to the "known" list by a single click. After that, they would be accepted every time.
--A way to automatically add addresses to the "block" list. I am worried that at some point a hacker will try to kill us with a "denial of service" attack and we will need a quick way to start ignoring thousands of requests from a particular site.
These are things that I have thought about that might be added someday, but will take considerably more time:
--A way to specify the location using an interactive map that you keep clicking on and zooming in, rather than relying on the user specified legal or lat/lon. Location errors are still the most common problem.
--Allow the detailed maps of the area to be more interactive, perhaps allowing pan and zoom capability, and the ability to add/subtract features.
--Automatically produce time-height sections or model sounding graphics for the specified location using data available on LDAD. This would save the time of having to generate these yourself using D2D, and having to continually move the Point A, B, C, etc. on AWIPS.
Security
Not yet completed
Configuration
To configure the WRSPOT programs to run for a Western Region office, there are four basic steps:
1) Edit main site configuration file on WR Web Server
2) Edit cities file if desired and if mapping functions are enabled.
3) Edit computer access lists
4) Setup AWIPS to accept alarms from WR Web Server
Each of these are described in more detail below.
Most options are controlled by a few configuration files on the WR Web Server. Each office has a directory where their configuration files are kept at /http/cgi-bin/wrspot/config/xxx where xxx is your modernized office id (in lowercase). Contact your office webmaster if you do not know how to access the WR Web Server.
You probably will want to keep a copy of the configuration files on your local computers in case your configuration information is ever destroyed on the WR Web Server.
Edit main site configuration file on WR Web Server
Most configuration options are controlled by the file config.dat in your office configuration directory (/http/cgi-bin/wrspot/config/xxx). You could create this file yourself, but you might find it easier to copy another site's existing configuration file to your directory, and then edit that file.
For example, you could use the following commands to copy Missoula's configuration file to your directory (and to make it so that modifications can only be made by your site):
telnet maul.wrh.noaa.gov
cd /http/cgi-bin/wrspot/config/mso
cp config.dat ../xxx
cd ../xxx
chmod 640 config.dat
You could then edit this file using any editor.
Specifying configuration options in config.dat
Configuration options are specified in config.dat with lines like:
OPTION=value
The options never have spaces in their names, always underscores (i.e., OFFICE_NAME). Values may have spaces or other formatting information (i.e., there may be multiple options separated by commas). Blank lines are ignored and comments are indicated by a # character (which means all the rest of the characters on the line are ignored).
Configuration Options:
OFFICE_NAME
This is the office name that gets displayed on the main monitoring page. It should be your office's name, with proper capitalization.
BLINK
BNAME
This controls the one link out of the wrspot programs. The BLINK is the URL of the link, and the BNAME is the text that is displayed for the link. For those familiar with HTML, this specifies the <A> link, with BLINK specifying the HREF part and BNAME specifying the text of the link.
OFFICE_TZ
This controls the times shown in various places in the WRSPOT pages. It should indicate the timezone in effect at the location of your office. The format is the same as the UNIX TZ environmental variable. For Western Region offices, this will be MST7MDT for Mountain time zone locations and PST8PDT for Pacific time zone locations, although Arizona locations that do not go on daylight savings time should be MST7.
MONMAP
The WRSPOT monitor page shows a list of spots for a particular day. If you also want a map with dots showing the location of the spot requests, along with the ability to click on the dots to view the spots forecasts, set MONMAP to 1 or YES. If you turn this option on, then you will need to specify many other options to control the appearance of the map.
MONMAP_CLAT
MONMAP_CLON
This is the central latitude and longitude for the map on the monitor page. All longitude/latitude values are specified in decimal degrees with west longitude values specified as negative numbers. It usually looks best to pick a location in the center of your CWA or area of fire weather responsibility.
MONMAP_LL_LAT
MONMAP_LL_LON
MONMAP_UR_LAT
MONMAP_UR_LON
These lines specify the latitude and longitude of the Lower Left (LL) and Upper Right (UR) corners of the map on the monitor page. The Upper Right point MUST be further North and East than the Lower Left point, or you are asking for trouble. The central lat/lon basically sets up the map projection, and these points specify the area to show in the map. The central lat/lon does not even have to lie within the range of lat/lon values specified here - but the map will look better if it does. It will likely take a little bit of experimentation with these values, and the monmap pixel width (specified below) to get the desired map.
MONMAP_WIDTH
This is the width of the map on the monitor page (in pixels). The height of the map is chosen such that there is no distortion based on the Upper Right and Lower Left corners of the map that were specified above. Larger maps take longer to draw, so you should not specify anything really outrageous. A value of about 300 pixels draws quickly and (in my opinion) is pretty legible.
STATES
On the spot request form, when a user specifies a Legal location, they need to indicate which state it is from. If you serve only one state - you are in luck - and you need only specify it here with the normal Postal Service abbreviation (i.e., STATES=WA). If you serve more than one state, you put the state abbreviations in a list separated by commas (i.e., STATES=MT,ID). The first state in the list will be the default, which means it is pre-selected when the form is started.
TIMEZONES
On the spot request form, when a user specifies a time for a burn, they need to indicate which timezone it is from. For offices that deal with multiple timezones, you specify the options separated by commas. For each time zone, you need to specify how it will be shown on the screen, and the UNIX timezone code, separated by a colon. For example, a site that only deals with burns in the Pacific timezone would have a line like TIMEZONES=Pac:PST8PDT, while sites that deal with both Mountain and Pacific timezones would have a line like: TIMEZONES=Mtn:MST7MDT,Pac:PST8PDT
The first timezone in the list is the default, which means it is the pre-selected when the form is started..
MAX_OBS
This specifies the number of lines in the form for specifying observations. We have found that most users will not specify more than a couple of observations, and if you put a lot of lines in the form, they simply take up space on the form - which can require more scrolling - which makes it more difficult for the users to fill out the form correctly. We feel that 4 lines for observations is about right - but you can do whatever you like. Keep in mind that users can always specify more observations in the remarks section, if necessary.
FCST_ELEMENTS
This specifies the number of possible forecast elements that a user can request in any period. They are described in more detail in the following section, but the number here MUST match the number of element lines specified in the following lines.
ELEM#
This specifies the text and options associated with each possible forecast element. The # should be replaced by a number (i.e., ELEM1=, ELEM2=, etc.). The order that they appear is also the order in which they appear on the form and in the forecast. There are at least 5 parameters on each element line (and a maximum of 7 parameters) and each parameter is separated by a bar character (|). The first three parameters specify whether the element is FORCED to appear on forecasts, whether the user specifies it or not. A 1 means that the parameter will be forced to appear, and a 0 means that the parameter will only appear in the forecast if the user asks for it on the form. The three parameters control it for prescribed, WFU and Wildfire types of burns. For example, if an element is specified with 1|1|1, it means that the parameter will appear in all forecasts whether the user check it on the form or not. If the element is specified with 0|0|1, it means that the parameter will only appear on prescribed and WFU forecasts if it is requested on the form - but will ALWAYS appear on wildfire forecasts.
The 4th parameter is the text that will be displayed on the form with the check-boxes for requesting this forecast element.
The 5th through 7th parameters are the format the text will take in the forecast for time periods 1 through 3. At least one must be specified, but if the 6th or 7th parameter are missing, they are copied from the last one provided. Any text within angle brackets (<>) will be put in the text when a forecast is being initialized from scratch, but will not be searched for when copying forecasts from one to another. Multiple lines in the forecast can be specified by
putting the characters "\n" on the configuration line where the line
break is desired..
FCST_BOTTOM
Any text that you want placed at the bottom of any initialized forecast.
FCST_UPPERCASE
If you want to convert all forecast text to uppercase, then set this option to YES.
WARN_ELEMENTS
If the user requests more than this many elements in any forecast period, a gentle warning will be issued. If you do no want such a warning issued, set this equal to FCST_ELEMENTS.
MAX_ELEMENTS
If the user requests more than this many elements in any forecast period, a more serious warning will be issued. If you do not want such a warning issued, set this equal to FCST_ELEMENTS.
MAX_ELEVATION
MIN_ELEVATION
Maximum and minimum expected elevations (in feet). If the user specifies an elevation outside this range, it warns them of a possible error.
LDAD_ADDRESS
LDAD_USER
LDAD_PASSWORD
AWIPS_ALARM
These specify the parameters for sending alarms to your AWIPS via LDAD when a spot is requested or changed, etc. See the section on setting up AWIPS alarms, for more information. The LDAD_ADDRESS should be the IP address of your "ls1" computer in ###.###.###.### form (see your ESA if you do not know this). The USER and PASSWORD should be what an FTP session to your ls1 computer should use. The AWIPS_ALARM is the keyname that you will use for alarms on your AWIPS.
ALARM_ALL
Normally, you only want to be alarmed by requests and changes made by computers outside your office. However, during testing, you may want to be alarmed for requests initiated by computers inside your office as well. If so, set this value to YES.
SPOTMAP
Set to yes if you want the detailed maps displayed (if possible) in each spot forecast page.
Setup Cities File if desired and mapping functions are enabled
The file cities.dat in your site's configuration directory (/http/cgi-bin/wrspot/config/xxx) controls city names that are displayed on the main monitor map and on the detailed maps. If you are not using the mapping functions, or if you do not want city names plotted on your maps, then you do not need to create this file.
Since most offices have probably done extensive editing to the AWIPS CitiesInfo.txt file to support warning operations, the format of this file is the same as the AWIPS CitiesInfo.txt file. In fact, there is a program that you can use to cut out the applicable cities from your CitiesInfo.txt file and place them in cities.dat (see below). Unfortunately, the codes used in CitiesInfo.txt control how cities will be listed in WARNGEN warnings, and in the wrspot cities.dat file they control which cities will be plotted on the maps - so you will probably need to edit the cities.dat file somewhat.
Each line contains the information for a city name (separated by spaces):
latitude (decimal degrees)
longitude (decimal degrees - west longitudes are negative numbers)
plot priority (higher numbers plot before lower numbers)
state (2-letter postal abbreviation)
City and code (code separated from City name by a | )
For WRSPOT, the code is used to determine on what map cities will be plotted and in which priority. Code 1 cities are plotted on the main monitor map, whereas code 2 cities are shown on intermediate scale maps and code 3 cities are shown on the detailed maps.
For example, this entry specifies that Missoula will be plotted on the main spot monitor map:
46.87222 -113.99306 500 MT MISSOULA|1
This entry specifies that Great Falls will be plotted on intermediate and detailed maps:
47.50480 -111.29060 590 MT GREAT FALLS|2
Cites are plotted on the maps in the order of the codes (1s first) and then by the plot priority numbers (highest number first). Cites will not plot "on top" of each other, so it is possible that a higher priority city will keep a lower priority city from plotting.
The trimCities.pl program is available to copy all the cities from your CitiesInfo.txt file that are within specified latitude/longitude bounds into a cities.dat file. To use this program, copy your AWIPS CitiesInfo.txt file to your site configuration directory on the WR Web Server (/http/cgi-bin/wrspot/config/xxx). Then, telnet into the WR Web Server, get into your config directory and then run the /http/cgi-bin/wrspot/trimCities.pl program. For example:
telnet maul.wrh.noaa.gov
cd /http/cgi-bin/wrspot/config/xxx
/http/cgi-bin/wrspot/trimCities.pl
The program will prompt you for the name of the input and output file, and for latitude/longitude limits for cities to include in the file. You will probably want to name the output file cities.dat, and make further modifications with a text editor.
Setup computer access lists
There are four access files that control what computers can see and do within the WRSPOT system. For example, you probably do not want anybody on a computer anywhere to be able to edit the forecast section of your spot forecasts! You probably only want computers within your office (and possibly your backup office) to be able to edit the forecasts. In addition, most users can only see sensitive details of a spot request if they are at the same computer that made the original request. There are some groups of users, however, that should be enabled to see details of any request. For example, in Missoula, we allow all computers in Region 1 of the Forest Service to see all the details of any other request.
To properly setup the access files, you need to know the IP addresses of the computers that you want to put in each list. These addresses consist of 4 numbers separated by periods (.). You do not need to know each address individually because you can set up "ranges" of addresses. For example, if all the addresses in your office have the same first 3 numbers in the address, say 132, 45 and 78, and the fourth address number ranges from 25 to 75, then you can setup the access list with an entry like: 132.45.78.25-75. You can also specify lists like: 132.45.78.25,32,46,73, or wildcards like: 132.45.78.*.
The addresses of computers in your office and your backup office should be available from your ESA. However, most agencies will probably be rather reluctant to provide you with the IP addresses of their computers, since it is a bit of a security breach for them to do so. However, if you explain what you need the information for, and if you tell them you only need a "range" of addresses rather than each specific address - they will sometimes comply. If not, you will not be able to allow "enhanced access" for sites, but they will still be able to use the WRSPOT system in its normal way.
In each file, you specify addresses with lines that start with either ALLOW: or DENY:. Each line then contains either "ALL" or addresses in the form #.#.#.#. Each number can also be a list separated by commas, or a range specified by a dash, or a wildcard specified by an asterisk. Comments are specified by the number character (#) which means that the rest of the characters on the line are ignored. For example, to indicate that you want to allow an address of 176.245.16.12, you would have a line like:
ALLOW:176.245.16.12
If you wanted to allow both the above computer and the one at address 176.245.16.15, you could either specify two ALLOW lines like this:
ALLOW:176.245.16.12
ALLOW:176.245.16.15
or you could specify a list like:
ALLOW:176.245.16.12,15
If you wanted to allow ALL addresses between 176.245.16.12 through 176.245.16.23, you could either specify all 12 addresses explicitly or in a list, or (most simply) in a range like:
ALLOW:176.245.16.12-23
If you wanted to allow ALL addresses with the first three address numbers of 176.245.16, then you could specify a wildcard entry like:
ALLOW:176.245.16.*
The order of entries in your list can be important if you deny access for some computers and allow it for others. The lines are processed in the order they appear in your file. For example, if you allow a specific address and then deny a range that includes it, you essentially wipe out the access for the specified computer, as in this example:
ALLOW:176.245.16.23
DENY:176.245.16.*
It is generally a good practice to deny features for all addresses and then add it back in for specific computers or ranges that you desire, such as:
DENY:ALL
ALLOW:176.245.16.*
The four access files reside in your office WRSPOT configuration directory on the WR Web Server: /http/cgi-bin/wrspot/config/xxx where xxx is your modernized location ID (in lowercase). The files are:
ipaddress.block addresses to block from all access to WRSPOT - probably only needed if a hacker or malicious user is flooding you with unauthorized spot requests.
ipaddress.known unused at this point - eventually addresses of known computers
ipaddress.view addresses to allow unrestricted access to all spots - even those that they do not own explicitly
ipaddress.edit addresses allowed to edit spot forecasts.
The files define access in an order as listed here. In other words, if you add the computers in your office to the "edit" list, they do not need to be added to the "view" list, because they are already allowed to view all information for any spot request.
The "block" list is slightly different than the others, because you probably want to ALLOW everybody, and only DENY a few (if any).
Here are the contents of the files for Missoula:
ipaddress.block:
ALLOW:ALL
ipaddress.known
ALLOW:ALL
ipaddress.view (give Region 1 of Forest Service ability to see all spots)
DENY:ALL
ALLOW:166.7.*.*
ipaddress.edit (give all computers in our office the ability to edit spots)
DENY:ALL
ALLOW:xxx.xxx.xxx.*
You can edit these files however you like. You will probably want to start with a copy of the files from some other site. For example, you could telnet into the WR Web server and copy the files from Missoula's config directory to your config directory with the following commands:
telnet maul.wrh.noaa.gov
cd /http/cgi-bin/wrspot/config/mso
cp ipaddress.* ../xxx
cd ../xxx
chmod 640 ipaddress.*
You could then edit the ipaddress files using any editor.
Setup AWIPS to accept alarms from WR Web Server
The WRSPOT programs are designed to send an alarm to you when somebody requests a new spot forecast, or a request is changed or deleted, etc. To do this, your AWIPS system must be setup to accept and properly handle the alarms through your ls1 computer. To do this, you must perform 3 steps:
1. Setup FTP to ls1
2. Setup AWIPS software to handle incoming alarms
3. Setup AWIPS keyname to alarm
4. Make changes to configuration file
1. Setup FTP to ls1
You could use any username to ftp into your ls1, but for security reasons, you may want to add a new user to your ls1 system, that is allowed very limited access. For example, in Missoula, we setup a user on our ls1 system that is only allowed ftp access, it is put in the /data/Incoming directory of ls1 when it logs in, and it is ONLY allowed to write files to that directory. At a minimum, the user must be able to cd to /data/Incoming on ls1, and write data to that directory. The username and password for this user are specified in the main configuration file config.dat that is described above. If router security, ftp wrappers, or other security measures are in place on your systems, then you may have to modify them to allow access from the WR Web Server and it's backups.
2. Setup AWIPS software to handle incoming alarms
You can get this software from the WR AWIPS development server and install it by the following steps (your ESA or AWIPS focal point should be able to do the following):
1. telnet into your ds1 as user fxa
2. change directories to the LDAD binary directory:
cd /awips/fxa/ldad/bin
3. ftp to the WR AWIPS Development Server
ftp xxx.xxx.xxx.xxx
cd wrspot
get preprocessWRSPOT.pl
bye
4. Make the file executable and ldad the owner
chmod 775 preprocessWRSPOT.pl
chown ldad:fxalpha preprocessWRSPOT.pl
5. Copy this executable to ds2 in case of ds1 failure
rcp preprocessWRSPOT.pl ds2:/awips/fxa/ldad/bin
6. Add the following line to the file /data/fxa/LDAD/data/LDADinfo.txt
wrspot|WRSPOT|256|257|CVS_TYPE|mesonet|preprocessWRSPOT.pl |
3. Setup AWIPS keyname to alarm
In Missoula, we chose for spot alarms to come in under the keyname:SPOTALARM. This is specified in the config.dat file as described earlier. You also need to add this keyname to the list of alarms for one or more workstations. You can do this by clicking on the "Alarm/Alert" button on the text workstation, then clicking on "Product List", then clicking on "New Entry", then adding the keyname and clicking on the ALARM box (if desired), and then clicking on OK. If desired, you can also have the AWIPS Focal Point add it to the list of alarmed products that cannot be removed.
4. Make changes to configuration file
As mentioned earlier, you will need to specify in config.dat the username and password of the account that will be used to ftp data to your ls1, as well as the keyname used for alarming.
You should be able to send and receive spot requests and forecasts at this point. The main link into the WRSPOT programs for your office should be:
http://www.wrh.noaa.gov/cgi-bin/wrspot/spotmon?site=xxx
where xxx is your modernized site ID (in lowercase letters).
Program Details
Not yet completed.
Data Format Details
Not yet completed.
Spot Requestor Instructions
You can request spot forecasts via our spot forecast page located at ______________________, which is easily reached from our main website at ______________________.
The main spot forecast page updates every minute and shows you the location and status of any spot forecasts that have already been requested for today. You can view these other forecasts, as well as request a new spot forecast of your own.
Each request has its own webpage where all the information about that request is displayed, including maps, information about the request and, eventually, the forecast. Sensitive information about the request (such as phone numbers, names of contact persons, and the exact location of the burn) are NOT visible by everyone - but only on the computer that made the original request and NWS computers.
When you request a new spot forecast, you provide information in a web-based form that is similar to the D-1 form that you are probably used to using. The information you provide on the form is checked for consistency, and after you complete the form, the NWS is notified of a new request and a new webpage is created for this burn.
Once you have submitted a request, you will probably want to view the webpage for your burn - or check back frequently to view it's status. To view the webpage for any burn or wildfire, go to the main spot forecast webpage, click either on the name of the burn in the listing, or on the dot on the map for the burn. This page will also automatically update every minute so that when new information becomes available, you will see it right away. If we find any errors in your request, we might even send you a question that will show up on this page. You can answer the question, or make other changes to your request from this webpage, but ONLY from the computer that made the original request. Since the forecast screen is automatically updated very minute, you will see the forecast within a minute of it being issued.
When the forecast is complete, you can print the webpage, or do whatever you want with the information. From the main spot forecast page, you have the ability to switch to a similar screen for days other than today. You can use this to send us feedback on earlier forecasts, or to copy the information from one request to a new request for today.
If you have any questions or problems, we are still available by phone at _____________.
Spot Forecast Monitor
The main spot forecast monitoring page shows you all of today's spot forecasts on the map and also in the list at the bottom of the page.
This page auto-updates every minute, so as new spot forecasts are requested or their status changes, you immediately see the changes on the page.
The dots on the map show the locations of the burns, and the status of the spot forecast requests. Green squares indicate requests that are still pending. Purple squares indicate burns where questions have been asked. Red squares indicate burns where the forecast has been completed. You can either click on the dots on the map, or the list of spot names at the bottom of the page to view the individual webpage for each request.
You can use the arrow buttons next to the date to view spot requests from other days, or you can use the "CALENDAR" link to move to other days more quickly.
To request a spot forecast, click on the button labeled "Submit a new Spot Request", and you will be taken to the Spot Request Form.
Spot Request Form
You fill in this form with the information needed to request a spot forecast.
The first time you fill out a spot request, almost all the boxes will be empty. After that, many of the boxes will be filled in with information that shouldn't change very much from one request to another (such as your name and phone number).
The elements highlighted in red are required for us to complete your spot forecast. While the other items may not be necessary, they are very important to our ability to make an accurate and useful forecast.
The form is broken down into seven sections. Lets look at each section individually, and the parameters you will need to fill in:
Project Name Section
You need to provide a name for your project. The name cannot be the same as any other project for the same day - and you will be alerted if you pick a name the same as an existing burn.
You should use the buttons to indicate whether the fire is a Wildfire, WFU or Prescribed Fire (Prescribed fire is chosen by default when you enter the form). For prescribed fires, you should indicate the ignition time and date using a 24 hour clock (and the time zone if necessary). The form defaults to an ignition time about ½ hour in the future.
Requesting Agency Section
You need to tell us who you are! Here you provide your agency name, your phone number for both voice and fax (please include the area code) and your name. All this information will be helpful to us if there are problems or questions and we need to contact you. You will only need to enter this information the first time you request a spot forecast. After that, it will be filled in with the same information as your last request.
Location Section
In this section you tell us the precise location of the burn. You can either specify the legal location or the latitude/longitude. If you use the legal method, you should provide something like: T5N R12E Sec24. If you use the latitude/longitude method, you can either specify degrees like: 45.1486 or degrees/minutes/seconds like: 45 13 34.
If you can, please specify the name of the 7 ½ minute USGS quadmap where the burn is located. We will check that against the legal or lat/lon location that you give. The elevation (in feet) at the top and bottom of the burn should be entered in the "Elevation" boxes. If the burn is on flat ground, you can enter a value in only one of the boxes. Enter the name of the nearest drainage in the "Drainage" box. This helps us further locate the burn when the legal or lat/lon location still leaves some ambiguity. Enter the slope aspect, such as NE or S (or possibly FLAT) in the "Aspect" box. This helps us further locate the burn. Also, please enter the size of the burn (in acres) in the "Size" box.
Fuel Section
Please indicate the type of fuel, either using fuel model numbers, or a description of the fuel such as "grass", "ponderosa pine", etc. Also, if you can indicate the amount of fuel sheltering, it helps us tremendously in providing accurate wind forecasts.
Observation Section
In this section you provide us with local observations near the burn. For each observation we need where it is in relation to the burn (for example, "base camp", "1 mile NW" or something like that), the elevation (in feet) and the time (preferably using a 24 hour clock). The wind (in miles per hour) can be specified as "N12 Gust 25" or something like that. The temperature and wetbulb values (in degrees F) should be entered and the RH (in percent) and Dewpoint (in degrees F) can also be entered if known (they will be calculated from the Temperature/Wetbulb/Elevation if you do not provide them). Finally, any remarks about clouds, weather or other important information should be entered in the final box. If you have more than 4 observations (and we like that!) please put them in the comments section below (or fax them to us!).
Forecast Elements Section
Not all spot requests are created equal! In this section we are asking you to tell us what are the forecast elements you need, or are particularly important. If you have a grass fire that will be out by later today, we don't want to waste time worrying about the temperature for tomorrow, unless you really need it. Likewise, if the wind direction is particularly important for you, we want to know about it. Pick the parameters that you need for today, tonight and tomorrow. If we think something is particularly noteworthy, we will let you know - even if you didn't request it. If you are submitting a request in the evening for the next day - keep in mind that you are requesting parameters for the day of the burn. For wildfires, we will provide all parameters (except smoke dispersion), so you do not need to waste time filling this in, unless you have a parameter that is particularly critical for you (in which case, this is a good place to indicate that).
Comments Section
If there is something else that you think we need to know, or something you couldn't fit elsewhere on the form, please enter it here. There is virtually no limit to what you can put here.
Submit the form
When you are ready to submit the form, just click on the "Submit Request" button at the bottom of the page. If you want to cancel the request you can click on the "Cancel Request" button, and if you want to clear the form and start over again, you can click on the "Clear Form" button.
When you submit the form, various checks are performed on the data you have entered. Some problems make it impossible for your request to be accepted (for example, if you forget to enter a name for the burn), which other will produce warnings and messages for your information. If an error is found, you will be given the opportunity to go back and fix the form, or cancel the request. Once you are confident there are no more errors in your request, it will be submitted and we will be automatically notified through our computer systems. If you have the time, we appreciate it if you could still call us, just in case something goes wrong on the web and we don't get notified of your request.
Spot Forecast Webpage
After you have submitted a spot forecast request, an individualized spot forecast webpage becomes available for that burn. This page automatically updates every minute so that as new information becomes available for the burn, you see it immediately. Detailed maps of the area around the burn are generated and displayed when they become available. Keep in mind that "sensitive" information like your name, phone number, and the exact location of the burn are NOT visible to others - only to you and the NWS.
If we have questions about your request, we may send you back a question about it. If this happens, you will see a big red box in the forecast page, with our question. Usually, there is some problem with the request that you can probably fix (use the links at the bottom of the page to change the request) or you can call us.
When your forecast is complete, it will show up in the spot forecast webpage automatically, and a box to provide feedback will become available. We hope that you can provide us feedback with how the forecast worked out, perhaps later in the day or several days down the road. This feedback helps us tremendously in improving our forecasts.
At the bottom of the forecast page are links for actions that you can take. For example, you can go "Back to Spot List" to return to the monitor page. If you are at the same computer that made the original request, you can click on "Change Request" to change the details of your request, or "Delete Request" to delete the request.
You can also click on "Copy Info to New Spot Request". This is helpful for burns that last over several days. Rather than having to re-enter the data in the form in order to get a new forecast - you can view the previous forecast and then copy all the location parameters to a new request using this link. This will save you some time when filling out the request form.
Invariably, something will go wrong at some point, and you might not be able to request or receive spot requests via the webpage (for example, your computers might go down, or our web server may fail). In such cases, we would like you fill out the paper version of the request form (as it appears on the next page) and fax it to us. We will fax you back the forecast when it is complete. Please keep in mind that this should be used as a last resort. Spot Forecast Requests received via the webpage will be completed more quickly.
NWS Instructions
You should first be familiar with the process of requesting a spot forecast that the users are going through (See the instructions for "requesting a spot" above).
When a spot is requested, you should receive an alarm on your AWIPS workstation alerting you that a new spot request was received, and giving you the name of the burn. Then, from the main spot forecast monitoring page, you should be able to see the burn and click on it (either the name or the dot on the map) to take you to the webpage for this burn.
The screen you see with burn information is identical to the one that the spot requestor sees, except that there are several more option links at the bottom of the page: (1) Send a question, (2) Initialize Forecast, (3) Edit Forecast, and (4) Send Forecast
These actions are usually taken in that order. For example, a question is asked if there are errors in the request. The forecast is initialized with the text that is constant on every forecast. The forecast is then edited to add in the specific information for this forecast. Finally the forecast is "sent", meaning that it is released so that the user and others can see it on the webpage.
Send a question
Sometimes there is obviously erroneous, or conflicting information on the spot request form that we would like to clarify. Certainly we can call the requestor, using the phone number and contact information that are provided on the form, but if there are numerous requests pending, it is sometimes more efficient to send a question via this method. The link takes you to a screen where you can type in any message, and then click on "SEND QUESTION". If the user is looking at the forecast page, it will automatically update within a minute, and show your question within a big red box. The intent is that the requestor will change some information on the form, or call you with more information. When the user changes the data on the form in any way, the system will, once again, alarm you on AWIPS.
Initialize Forecast
This link takes you to a screen where you can initialize the text for this forecast. If this is the first forecast for the day, the forecast is initialized with a blank discussion and forecast However, if there are already other spot forecasts available for this day, you have the option of copying the discussion or the forecast text from one of those other spot forecasts. This can save considerable time when nearby spot forecasts will have much of the forecast or discussion in common. After initializing the forecast, you will be brought back to the spot forecast screen. Notice, however, that the forecast portion now has some text displayed. A red banner is displayed around this text so that you know that the user can not yet see this forecast that is ‘in progress'. Typically, you would next move on to editing this forecast - but you can do other duties in the meantime as well.
Normally, you only initialize the forecast once, but it can be done again if you want to erase everything from the forecast and start over. If initializing the forecast would delete any current information, the screen makes it clear that the current forecast text will be lost if you continue.
Edit Forecast
This link takes you to a screen where you can edit the text of the forecast. The browser provides basic cut and paste functions, as well as normal cursor movement with arrow keys or the mouse. One thing to keep in mind is that you MUST save your editing before leaving this page! Since you are editing with a web browser it is VERY EASY to forget and click on the "back button" or another link, or a bookmarked page. If you do this before clicking on the SAVE EDITS button - YOU WILL LOSE ALL OF YOUR EDITING. This is very important to remember. Typically, you will edit forecast a little bit, then click on the SAVE EDITS button and go to other web pages to view other data to help you formulate the forecast. You may come to the editing page several times, editing the forecast a little bit each time. Keep in mind that the requestor cannot see any of your forecast while it is "in progress". They continue to see a screen that says that the forecast is "not yet complete".
Send Forecast
When you have finished editing the forecast, and wish to "release" the text so that the user can see it, this link takes you to a screen where you confirm that you want to release this forecast to the public.
Once the forecast is complete, auto-updating of the webpage stops. It is possible to make changes to your forecast (you can even re-initialize it and start from scratch if you really want to). However, keep in mind that users have now seen the completed forecast, and they may not be expecting any changes to the forecast. If you update the forecast - you need to "Re-send" it, and then you probably should give the requestor a call - to let them know that an updated forecast is available.
Feedback
The requestor of a spot forecast can also fill in a feedback entry after the forecast is complete. They may use this to give you feedback immediately or several days later. When feedback is received, an AWIPS alarm is generated as always - and it will tell you the date of the burn if the feedback was for a burn from a previous day.
Alarms for future spot requests
There is nothing to stop users from requesting spot forecasts for days in the future, etc. In fact, we designed the system this way so that we can have a "heads up" about upcoming prescribed burns, and plan for busy days. However, this can also be a source of confusion and frustration. Our local policy has always been that a spot forecast is a detailed mesoscale forecast that cannot be reasonably issued until, at most, several hours before the burn. Since requestors can send in spot requests for "tomorrow", there is a tendency for them to send in a request for tomorrow's burn and get the forecast today. We have had to be diligent in our explanation to users that the purpose of allowing future spot requests is so that we can plan for busy days, call in extra staff, etc. It is NOT a way for them to get detailed extended-range forecasts for their burns. We stress that we are always available by telephone for consultation about general conditions expected in the extended range. When users specify an ignition time for a prescribed burn that is more than 18 hours in the future, the form checker tells them that we will not work on the forecast until the ignition time is near.
It is also easy to forget about future spot requests. The AWIPS alarm only comes when the request is submitted. There is no alarm when the ignition time is approaching (future enhancements to the program may provide such alarms). It is a good idea to keep checking the spot forecast monitoring page occasionally to make sure there are no requests pending that have been accidentally forgotten.
Backup
Anything that can go wrong, probably will at some point. There are three levels of failure and backup that should be kept in mind.
1. If the WR Web Server goes down, users will not be able to request spot forecasts, and you will not be able to edit and send spot forecasts in this manner. Your backup office will also not be able to issue forecasts using the WR Web Server either. In this case, your users should know to call you for any requests, and you should be prepared to generate forecasts in some other way (i.e., using a standard word processor) that could be faxed back to the requestor.
2. If the WR Web Server is up, but there is a problem with the user's computers, or they cannot access the WR Web Server, then you need some way to get requests from them, and provide forecasts. You should urge users to fax you a paper copy of the web form (we provide a clean copy in the instructions above, so that they have it available if their computers are down). You can then enter in the information into the form yourself, and then generate the forecast in the usual manner, print a paper copy of the output, and fax it back to them.
3. If the WR Web Server is up and users can send in requests, but you cannot access the WR Web Server (either because computers are down or the connection between your office and the WR Web server is down), then you might want to consider having your backup office prepare any spot forecasts until your computers or connections are restored.