| Test Case ID Number |
DCS Number |
DCS Description |
Test Scheduled (Date) |
Test Completed (Date) |
| Build_4.2-1 |
AWIPS_DCS_1 |
Set up area for data with write protections |
10/12 |
|
| Build_4.2-2 |
AWIPS_DCS_2 |
Write the archiver/purger script for this data-similar to the
Off.
User Products archiver/purger. |
10/12 |
|
| Build_4.2-3 |
AWIPS_DCS_3 |
Set up area for radar storage for archiving (Bruno
Thuy?) |
|
|
| Build_4.2-4 |
AWIPS_DCS_4 |
PUP archive GUI to select products for archiving. |
Chris 10/12 |
|
| Build_4.2-5 |
AWIPS_DCS_5 |
Write GUI for specifying products for one-time-archive. |
Chris 10/12 |
|
| Build_4.2-6 |
AWIPS_DCS_6 |
Modify existing storage script to only store the selected
products. |
10/12 |
|
| Build_4.2-7 |
AWIPS_DCS_7 |
Add a button and indicator to turn on and off continuous
archive mode. |
10/12 |
|
| Build_4.2-8 |
AWIPS_DCS_8 |
Disallow turning on automatic store if the correct 'store'
tape is
not loaded. |
10/12 |
|
| Build_4.2-9 |
AWIPS_DCS_9 |
Write a GUI for restoring a set of data from tape as a case. |
10/12 |
|
| Build_4.2-10 |
AWIPS_DCS_10 |
Must allow for display of inventory of all data on current
loaded tape.
Come from OmniBack database. |
|
|
|
none |
Must allow for display of storage time ranges for data
on tapes
that are not currently loaded. Must come from separate "data
base." |
|
|
|
none |
User requests new tape load - ESA |
10/12 |
|
|
none |
No restore while continuous store going |
10/12 |
|
| Build_4.2-11 |
AWIPS_DCS_11 |
Install a set of case data on the restore disk. |
10/12 |
|
| Build_4.2-12 |
AWIPS_DCS_12 |
Write a GUI for switching the display software. |
10/12 |
|
| Build_4.2-13 |
AWIPS_DCS_13 |
GUI that the WS is in case mode. |
10/12 |
|
| Build_4.2-14 |
AWIPS_DCS_14 |
Implement terminal server configuration to connect: -
dedicated modem
bank; - dial-in hunt group. |
9/28 |
|
| Build_4.2-15 |
AWIPS_DCS_15 |
Implement CO_server process 3-sec spin to accept files coming
into
the LDAD server. |
9/14 |
|
| Build_4.2-16 |
AWIPS_DCS_16 |
Modify mesonet decoder software to be driven by
self-describing metadata
file. Decouple decoder/storage. |
9/28 |
|
| Build_4.2-17 |
AWIPS_DCS_17 |
Add meonet data into netcdf and plot files. |
9/28 |
|
| Build_4.2-18 |
AWIPS_DCS_18 |
Implement hydro storage in SHEF format into hydro database?
into plot
files? into textdb? |
9/28 |
|
| Build_4.2-19 |
AWIPS_DCS_19 |
Implement PC ROSA software on LDAD server. |
9/28 |
|
| Build_4.2-20 |
AWIPS_DCS_20 |
Implement BlackBox DTMF converter. |
9/28 |
|
| Build_4.2-21 |
AWIPS_DCS_21 |
Implement ROSA storage in netcdf and plot files Access/plot? |
9/28 |
|
| Build_4.2-22 |
AWIPS_DCS_22 |
Implement acquisition software to identify station ID;
initiate process
throught socket connections. |
9/14 |
|
| Build_4.2-23 |
AWIPS_DCS_23 |
Implement software for scheduled acquisition. |
9/28 |
|
| Build_4.2-24 |
AWIPS_DCS_24 |
GUI for scheduled acquistion. |
10/12 |
|
| Build_4.2-25 |
AWIPS_DCS_25 |
Localization should accomodate LARC guage data within their
area. |
9/14 |
|
| Build_4.2-26 |
AWIPS_DCS_26 |
Implement validity check (qcstg1_2) |
9/28 |
|
| Build_4.2-27 |
AWIPS_DCS_27 |
Implement internal consistency check (qcstg1_2) |
9/28 |
|
| Build_4.2-28 |
AWIPS_DCS_28 |
Implement temporal consistency check (acstg1_2) |
9/28 |
|
| Build_4.2-29 |
AWIPS_DCS_29 |
Add SC results into the qc database (qcstg3) |
9/28 |
|
| Build_4.2-30 |
AWIPS_DCS_30 |
QC processing |
9/28 |
|
| Build_4.2-31 |
AWIPS_DCS_31 |
Implement single QC database (save SC IC VC TC) |
9/28 |
|
| Build_4.2-32 |
AWIPS_DCS_32 |
Put together a component which identifies data arrival events. |
9/21 |
|
| Build_4.2-33 |
AWIPS_DCS_33 |
LDAD - Encode and send data arrival information to the DAD
server. |
|
|
| Build_4.2-34 |
AWIPS_DCS_34 |
Modify BBS for user product_id request |
9/21 |
|
| Build_4.2-35 |
AWIPS_DCS_35 |
Implement XYZ modem (kermit) |
10/19 |
|
| Build_4.2-36 |
AWIPS_DCS_36 |
Implement FAX dissemination |
9/21 |
|
| Build_4.2-37 |
AWIPS_DCS_37 |
Implement GUI/monitoring system for LDAD internal/external
processess |
10/5 |
|
| Build_4.2-38 |
AWIPS_DCS_38 |
Implement site configuration system for community
communications interface |
? |
|
| Build_4.2-39 |
AWIPS_DCS_39 |
Implement site configuration system for acquisition qc and
dissemination
subsystems. |
? |
|
| Build_4.2-40 |
AWIPS_DCS_40 |
Implement a depictable for those observations that have been
stored. |
? |
|
| BUILD_4.2-41 |
AWIPS_DCS_41 |
Checklist of new and modified products provided by OSF to
ensure all
listed products exist. |
No Test |
|
| Build_4.2-42 |
AWIPS_DCS_42 |
Ensure that Layer Composite Turbulenceh ave been removed from
the request
menus |
9/14 |
|
| Build_4.2-43 |
AWIPS_DCS_43 |
Add a capability to the "Add" and "Edit" selections on the
RPS list |
9/21 |
|
| Build_4.2-44 |
AWIPS_DCS_44 |
Add a selection to the One-time request application for a
Severe Weather
Analysis Package. |
9/21 |
|
| Build_4.2-45 |
AWIPS_DCS_45 |
Add a selection to the One-time request application to
request a list
of RPG products. |
9/21 |
|
| Build_4.2-46 |
AWIPS_DCS_46 |
Add capability to decode the product list; format the text
message
and store the text in the text database. |
9/21 |
|
| Build_4.2-47 |
AWIPS_DCS_47 |
Add a one-time dial-out request capability to enable the user
to make
the following selectionsRPG, product, interval, duration. |
9/21 |
|
| Build_4.2-48 |
AWIPS_DCS_48 |
Sent out the request |
? |
|
| Build_4.2-49 |
AWIPS_DCS_49 |
Add a Scheduler (Multi-Request Handler) which will receive
the request
schedule for radar data to an RPG (Radar Multiple Request). |
9/21 |
|
| Build_4.2-50 |
AWIPS_DCS_50 |
Provide user with capability to extend the duration on the
Scheduler
(RMR). |
9/28 |
|
| Build_4.2-51 |
AWIPS_DCS_51 |
Get list of products for the maintenance RPS list. |
No Test |
|
| Build_4.2-52 |
AWIPS_DCS_52 |
Update capability to check the radar mode. If in mantenance
mode read
the maintenance RPS list and send it out. |
9/21 |
|
| Build_4.2-53 |
AWIPS_DCS_53 |
Display cell trends |
9/14 |
|
| Build_4.2-54 |
AWIPS_DCS_54 |
Display layer composite max reflectivity with AP removed. |
9/14 |
|
| Build_4.2-55 |
AWIPS_DCS_55 |
Display extended TVS. The display MUST
be in RED. |
9/14 |
|
| Build_4.2-56 |
AWIPS_DCS_56 |
Remove layer composite turbulence. |
9/14 |
|
| Build_4.2-57 |
AWIPS_DCS_57 |
Display hybrid scan reflectivity graphic. |
9/14 |
|
| Build_4.2-58 |
AWIPS_DCS_58 |
Display the volume coverage pattern and the max/min value (if
available)
and display in the lower left corner of the display. |
9/14 |
|
| Build_4.2-59 |
AWIPS_DCS_59 |
Identify which image products have graphical overlay (Paired
Products) |
9/14 |
|
| Build_4.2-60 |
AWIPS_DCS_60 |
Provide capability to overlay an image with an associated
graphical
product. |
9/14 |
|
| Build_4.2-61 |
AWIPS_DCS_61 |
WSR88D - A site providing backup shall be able to access
WSR-88D for
the area being backed up (if available) via radar dialup. |
9/21 |
|
| Build_4.2-62 |
AWIPS_DCS_62 |
LDAD - The site providing backup can acquire local data for
the area
being backed up via dialin or dialout to/from its LDAD. |
9/14 |
|
| Build_4.2-63 |
AWIPS_DCS_63 |
Dialin - The site providing backup can receive and process
ASOS microART
and ROSA for locations in the backup area. |
9/14 |
|
| Build_4.2-64 |
AWIPS_DCS_64 |
Dialout - The site providing backup can acquire and process
LARC and
CMAN for locations in the backup area. Need more info on the CMAN data
sites! |
9/14 |
|
| Build_4.2-65 |
AWIPS_DCS_65 |
All SBN data needed for the backup area shall be acquired
routinely
at the site. It is assumed that the backup area is included in the
region
of site providing backup. |
9/21 |
|
| Build_4.2-66 |
AWIPS_DCS_66 |
The site must routinely store all necessary data for the
areas that
it backs up including hydro sites, LDAD configuration information
(dialout sites, bbs users, dialin sites, authorized products, etc.),
IFP
data, etc. |
9/21 |
|
| Build_4.2-67 |
AWIPS_DCS_67 |
Display - The site shall be able to display all local data
and SBN
data acquired for the area being backed up. The data shall be
displayable
on the AWIPS local scale (state scale) with appropriate map backgrounds. |
9/14 |
|
| Build_4.2-68 |
AWIPS_DCS_68 |
The site providing backup can create all assigned text
products for
the area being backed up. Including warnings, watches and statemnts
generated
by warnGen and other products created manually on the text workstation
with appropriate header information automatically prepended. |
9/14 |
|
| Build_4.2-69 |
AWIPS_DCS_69 |
Local dissemination - The site will provide access to its
LDAD BBS
for authorized dialin users from the backup area. |
9/28 |
|
| Build_4.2-70 |
AWIPS_DCS_70 |
AWIPS distribution - Products created for the backup area
shall be
transmitted on the AWIPS WAN as appropriate. |
9/28 |
|
| Build_4.2-71 |
AWIPS_DCS_71 |
AFOS distribution - Products created for the backup area
shall be transmitted
on the AFOS network as appropriate. |
9/21 |
|
| Build_4.2-72 |
AWIPS_DCS_72 |
Intersite communication - AWIPS shall provide the capability
to send
and receive messages to/from all other AWIPS sites using the MHS. |
10/28 |
|
| Build_4.2-73 |
AWIPS_DCS_73 |
Message headers - Header information for prducts will be
based on the
AWIPS ID. |
10/28 |
|
| Build_4.2-74 |
AWIPS_DCS_74 |
Addressees - Destination addresses will be based on a 3
character ID
for Build 4.2 (The design should accommodate 4 character ids.)
Destination
groupings shall also be supported such as all adjacent offices, backup
offices, etc. |
10/28 |
10/28 |
| Build_4.2-75 |
AWIPS_DCS_75 |
Default addressing - Products shall be assigned a list of
AWIPS destinations
by default based on the AFOS or AWIPS product IDD. |
10/5 |
|
| Build_4.2-76 |
AWIPS_DCS_76 |
Error conditions - AWIPS shall notify the user when a
significant error
has occurred in transmitting messages over the WAN. (this will
include
acknowledgement failures for high priority messages.) A dialog box will
open on the display from which the message was sent. It will contain
the
product id, time, and teh natureo f the error. The dialog box will
require
acknowledgement in oder to clear. A log file will be maintained of
significant
and other error messages. |
10/5 |
|
| Build_4.2-77 |
AWIPS_DCS_77 |
Initiate the request: Display a request window on the text
workstation.
The window should resemble the Text Header Block window. Input should
include
afos id information for one product: originating site (ccc), product
categoray
(nnn), product designator (xxx), and addressee (3 cahr afos site id).
The
address field should display DEF by default. |
10/5 |
|
| Build_4.2-78 |
AWIPS_DCS_78 |
Get the user's input. Each product id field (ccc, nnn, xxx)
should
contain no more than 3 character, although fewer characters are
allowed.
The addressee default value should be FRC, the special address
idicating
the servicing RFC. The user should be able to enter a different site's
id if requesting local data that may not be found at the RFC. |
10/5 |
|
| Build_4.2-79 |
AWIPS_DCS_79 |
Send the request to the MhsRequestClient process |
10/5 |
|
| Build_4.2-80 |
AWIPS_DCS_80 |
Send the request from the MhsRequestClient process to the
addresse
(RFC or neighboring site, via the WAN, using msg_send. |
10/5 |
|
| Build_4.2-81 |
AWIPS_DCS_81 |
Satisfy the request: Retrieve the most recent version of the
requested
product from the text database. |
10/5 |
|
| Build_4.2-82 |
AWIPS_DCS_82 |
If the retrieved product has a more recent time than the time
indicated
in the request, send the product to the originating site. |
10/5 |
|
| Build_4.2-83 |
AWIPS_DCS_83 |
If the product can't be found in the database, or if the
retrieved
product does not have a more recent time than the time indicated in the
request, forward the request to the NCF if appropriate. If the request
can't be satisfied at the NCF, return the request and a status message
indicating the problem to the requesting site. |
10/5 |
|
| Build_4.2-84 |
AWIPS_DCS_84 |
Notify the user if the request hasn't been staisfied by the
time the
request becomes inactive (set a time and handle its expiration). |
10/5 |
|
| Build_4.2-85 |
AWIPS_DCS_85 |
If an error occurs at the requesting site or if an error
message is
received from a site trying to satisfy the request: Cancel the request.
Remove the request from the list, and do any clean up necessary. |
10/5 |
|
| Build_4.2-86 |
AWIPS_DCS_86 |
At the requesting site maintain a list of requests that
haven't been
satisfied. If there are already 10 requests in the list when another
request
is mad, notify the user of this confition, and don't send the request. |
10/5 |
|
| Build_4.2-87 |
AWIPS_DCS_87 |
Display the error message on the text workstation that
initiated the
request. Use a dialog box requiring and acknowledgment. |
10/5 |
|
| Build_4.2-88 |
AWIPS_DCS_88 |
Maintain a counter of the number of sites that have tried to
satify
the request. Initially, the two sites will be the servicing RFC, and
the
WFO at the NCF, but this might change in the future. |
10/5 |
|
| Build_4.2-89 |
AWIPS_DCS_89 |
If the request can't be satisfied at the RFC send the request
back
to the requesting site, along with a status message indicating what the
problme was (for example, error reading the text database, product not
found, etc.). |
10/5 |
|
| Build_4.2-90 |
AWIPS_DCS_90 |
When a request is returned if the request has only been sent
to one
site, send it to the NCF. If it has already been to two sites,
cancel
the request and notify the user. |
10/5 |
|
| Build_4.2-91 |
AWIPS_DCS_91 |
Maintain a list of incoming requests that need to be
satisfied. If
the list size is 50 when a request isrecived, send the request back to
the requesting site along with an error message. |
10/5 |
|
| Build_4.2_92 |
AWIPS_DCS_92 |
Send error message or cancel request and notify user if there
is a
problem with a product request. |
10/5 |
|
| Build_4.2-93 |
AWIPS_DCS_93 |
At the requesting site, include the time of the most recent
product
in the product request. If the site satisfying the request doesn't have
a more recent product, return the request and a status message
indicating
the problme to the requesting site. |
10/5 |
|
| Build_4.2-94 |
AWIPS_DCS_94 |
Send error message or cancel request and notify user if there
is a
problem with a product request. |
REJECT - CLOSED |
|
| Build_4.2-95 |
AWIPS_DCS_95 |
Write the product requested from NCF, WFO, RFC, int the text
database.
Do not send it to the data ingest system, because there will not be a
CCB
header, which the decoders look for. |
10/5 |
|
| Build_4.2-96 |
AWIPS_DCS_96 |
Implement cancel request for products from NCF, WFO, RFC. Do
any clean
up needed. |
10/5 |
|
| Build_4.2-97 |
AWIPS_DCS_97 |
Notify the RadarStorage process when the radar is in precip
mode. Develop
a new message containing radar id nd mode; the RadarServer process will
send this message to RadarStorage. RadarStorage will have to register
with
its DataController for the message, so create a pattern. |
10/5 |
|
| Build_4.2-98 |
AWIPS_DCS_98 |
When RadarStorage process starts up, have it read the
state info
file created by the RadarServer. This will allow RadarStorage to stay
in
synch with the mode of the RPG. |
10/5 |
|
| Build_4.2-99 |
AWIPS_DCS_99 |
Put product id and WMO header of the products to be sent in a
text
file. Have RadarStorage use the info in the file to decide whether or
not
to send products that are reeived from an RPG. |
10/5 |
|
| Build_4.2-100 |
AWIPS_DCS_100 |
RadarServer should forward the product file name to the
MhsRequestServer
process. Develop a new message for doing this. |
10/5 |
|
| Build_4.2-101 |
AWIPS_DCS_101 |
MhsRequestServer: Add functions to MhsRequestServer process
to do the
following: Read the radar data from a file specified in the
notification
message. |
10/5 |
|
| Build_4.2-102 |
AWIPS_DCS_102 |
MhsRequestServer: Add functions to MhsRequestServer process
to do the
following: Add the WMO header; use the product file created in step 1
to
determine the header. |
10/5 |
|
| Build_4.2-103 |
AWIPS_DCS_103 |
MhsRequestServer: Add functions to MhsRequestServer
process to
do the follwoing: Use msg_send to send the x.400 file to the WAN. |
10/5 |
|
| Build_4.2-104 |
AWIPS_DCS_104 |
Receiving radar data: the NCF will send radar data to field
sites via
the SBN. Add radar data patterns to acqserver pattern file. Strip off
the
wmo header (maybe in the acqserver), and write file into radar raw
directory.
Send notification to CommsRouter. |
10/5 |
|
| Build_4.2-105 |
AWIPS_DCS_105 |
Address the message to the NCF using the DEFAULTNCF special
address.
The NCF will route the message to the SBN. |
10/5 |
|
| Build_4.2-106 |
AWIPS_DCS_106 |
Create a file for each site, containing the ids of the radars
for which
data should be sent to the WAN. |
10/5 |
|
| Build_4.2-107 |
AWIPS_DCS_107 |
Modify the RadarStorage code to read the file and use the ids
to decide
whether or not to send incoming data to the WAN. |
10/5 |
|
| Build_4.2-108 |
AWIPS_DCS_108 |
NOT Implemented in Build 4.2. |
Closed |
|
| Build_4.2-109 |
AWIPS_DCS_109 |
Add functionality to RadarStorage to check a flag (probably
an environment
variable) before sending products to the WAN. |
10/5 |
|
| Build_4.2-110 |
AWIPS_DCS_110 |
Write a program or script that resets the flag. |
10/5 |
|
| Build_4.2-111 |
AWIPS_DCS_111 |
Add a button to the D-2D workstation to run the program or
script. |
10/5 |
|
| Build_4.2-112 |
AWIPS_DCS_112 |
Set an environment variable indicating which vcp number to
use. Have
RadarStorage software check this flag to decide whether or not to send
products to the WAN. |
10/5 |
|
| Build_4.2-113 |
AWIPS_DCS_113 |
Pre-commissioning - An AWIPS site will forward all messages
to both
AFOS and the AWIPS WAN. The messages on AWIPS shall have test header
designation. |
10/5 |
|
| Build_4.2-114 |
AWIPS_DCS_114 |
Develop a UI to do this task (probably just a program or
shell script). |
10/5 |
|
| Build_4.2-115 |
AWIPS_DCS_115 |
In the current code, replace the sendAFOS flag with sendWAN
flag. sendWAN
will control whether or not a product is sent over the WAN. |
10/5 |
|
| Build_4.2-116 |
AWIPS_DCS_116 |
Create a global flag sendAFOS that's initialized through an
environment
variable. When Build 4.2 is first implemented in the field, sendAFOS
will
be set to true. When the WAN is enabled, sendAFOS should be set
to
false, which will disable the code that sends to AFOS. |
10/5 |
|
| Build_4.2-117 |
AWIPS_DCS_117 |
Develop a UI to do #24 task (probably just a program or shell
script),
i.e. When RadarStorage process starts up, have it rad the state info
file
created by the RadarServer. This will allow RadarStorage to stay in
synch
with the mode of the RPG. |
10/5 |
|
| Build_4.2-118 |
AWIPS_DCS_118 |
If an error occurs at the requesting site or if an error
message is
recived from a site tryin to satisfy the request: Send the error
message
to the text workstation that initiated the request. Display the error
message
in a dialog box, requiring acknowledgment. |
10/5 |
|
| Build_4.2-119 |
AWIPS_DCS_119 |
Add functions to MhsRequestServer process to do the
following: Add
the wmo header; use the product file created in step 1 to determine the
header. |
10/5 |
|
| Build_4.2-120 |
AWIPS_DCS_120 |
Replace the afos2awips.txt file with a file that contains
valid headers.
Restart the text workstations. |
10/5 |
|
| Build_4.2-121 |
AWIPS_DCS_121 |
If an error occurs at the requesting site, or if an error
message is
received from a site trying to satisfy the request: Send the error
message
to the text workstation that initiated the request. Display the error
message
in a dialog box, requiring acknowledgment. |
10/5 |
|
| Build_4.2-122 |
AWIPS_DCS_122 |
Add functions to MhsRequestServer process to do the
following: Add
the wmo header; use the product file created in step 1 to determine the
header. |
10/5 |
|
| Build_4.2-123 |
AWIPS_DCS_123 |
Replace the afos2awips.txt file with a file that contains
valid headers.
Restart the text workstations. |
10/5 |
|
| Build_4.2-124 |
AWIPS_DCS_124 |
Construct a product request, including the following product
id information:
wmo id (ttaaii), originating site (cccc: four character AWIPS site id),
product category (nnn), product designator (xxx), time of the most
recent
product, product type ("TEXT"), and afos id (this will eventually be
phased
out, but is still needed for 4.2). Use the afos2awips.txt file to
convert
the afos site id into the AWIPS site id. The request can also contain
the
addressee, if the user specified it, and an indication of how long the
request should remain active. Use the MhsProductRequest class to
construct
the request. |
10/5 |
|
| Build_4.2-125 |
AWIPS_DCS_125 |
Extract CPU monitor code from Xiangbao's monitor, including
choice
of sampling interval. Develop summary button for all ds, as and ws
nodes.
Add hook to process monitor to display it. |
9/21 |
|
| Build_4.2-126 |
AWIPS_DCS_126 |
Expand disk monitoring to include workstation partitions. |
9/21 |
|
| Build_4.2-127 |
AWIPS_DCS_127 |
Add SHEF decoder to process monitor and restart. |
9/21 |
|
| Build_4.2-128 |
AWIPS_DCS_128 |
LDAD monitor - The site monitor shall include LDAD devices
and processes
outside the firewall as well as those inside the firewall. LDAD monitor
shall be incorporated into the existing AWIPS monitor in a manner
consistent
with the current monitor. |
9/14 |
|
| Build_4.2-129 |
AWIPS_DCS_129 |
Develop script to report on unauthorized attempts to login to
LDAD
system. |
10/5 |
|
| Build_4.2-130 |
AWIPS_DCS_130 |
Develop techniques and scripts to modiy non-LDAD monitor
confiuration. |
10/12 |
|
| Build_4.2-131 |
AWIPS_DCS_131 |
Evaluate current use of logStream tags in
ingest/decoder/display logs.
Analyze verbosity of messages. |
? |
|
| Build_4.2-132 |
AWIPS_DCS_132 |
Revise logStream tags and messages. |
10/5 |
|
| Build_4.2-133 |
AWIPS_DCS_133 |
Modify displayLogPref to turn off usage logging. |
10/5 |
|
| Build_4.2-134 |
AWIPS_DCS_134 |
AWIPS shall provide an ingest filtering mechanism which can
limit the
data which is captured andstored or fed to an application. It shall be
able to limit the product type andthe geographic area to that needed at
a WFO (including backup responsibilities or an RFC). |
9/21 |
|
| Build_4.2-135 |
AWIPS_DCS_135 |
Product type - The system can filter by product type based on
the 10
character WMO header. |
9/21 |
|
| Build_4.2-136 |
AWIPS_DCS_136 |
Geographic area - The system can filter based on geographic
area based
on the 10 character WMO header. |
9/21 |
|
| Build_4.2-137 |
AWIPS_DCS_137 |
Two level filtering - Both product type and geographic area
filter
ing may be used in combination to achieve the desired degree of data
filtering. |
9/21 |
|
| Build_4.2-138 |
AWIPS_DCS_138 |
Configurability - The local site shall be able to control the
filtering
by adding/deleting entries ina table or file. Normallythe entrieswill
be
part of the WMO or AWIPS id. |
9/21 |
|
| Build_4.2-139 |
AWIPS_DCS_139 |
Changes in the filtering shall be applicable with a restart
of the
appropriate ingest processes. |
9/21 |
|
| Build_4.2-140 |
AWIPS_DCS_140 |
Determine the portions(s) of the code which casue duplicates
to be
stored or do not prevent them from being stored. |
10/5 |
|
| Build_4.2-141 |
AWIPS_DCS_141 |
Design a test or tests (such as comparison of product IDs,
time, or
other key protions of a product) that will efficiently check for
duplicates. |
10/5 |
|
| Build_4.2-142 |
AWIPS_DCS_142 |
Design a procedure to discared any duplicates. |
10/5 |
|
| Build_4.2-143 |
AWIPS_DCS_143 |
Write and test code or 2 and 3. Need
more
info!!! |
10/5 |
|
| Build_4.2-144 |
AWIPS_DCS_144 |
In the decoder for collective messages (CollDBDecoder.C),
identify
the portion of the code which searches for and skips the type name. |
10/5 |
|
| Build_4.2-145 |
AWIPS_DCS_145 |
Replace the code identified in (1) with a procdure that
determines
the report type and stores it in a temporary TextString variable. The
string
contained in this variable will serve as the beginning of each
station
report. The remainder of the report will then e appended onto this
strin,g
and the result will be inserted into the database. |
10/5 |
|
| Build_4.2-146 |
AWIPS_DCS_146 |
Identify redbook graphics for display system. |
10/12 |
|
| Build_4.2-147 |
AWIPS_DCS_147 |
Create RedbookStorage routine similar to RadarStorage (no
decoding
needed). |
10/12 |
|
| Build_4.2-148 |
AWIPS_DCS_148 |
Modify data, depict, menu tables (and acqserver) to reflect
new directory
structure. |
10/12 |
|
| Build_4.2-149 |
AWIPS_DCS_149 |
Modify purging script to purge new tables and modiy ds
crontab. |
10/12 |
|
| Build_4.2-150 |
AWIPS_DCS_150 |
Unpack the bitmap section. |
9/21 |
|
| Build_4.2-151 |
AWIPS_DCS_151 |
Create tables (Originating Centers Models (Generating
Process) Grids
(Projection) Parameters Units Level Types). |
9/21 |
|
| Build_4.2-152 |
AWIPS_DCS_152 |
Create code to read tables and create dictionaries of
parameters. |
9/21 |
|
| Build_4.2-153 |
AWIPS_DCS_153 |
Update the accessor code for the display software to use new
table-driven
implementation. |
9/21 |
|
| Build_4.2-154 |
AWIPS_DCS_154 |
Image color tables - AWIPS usersshall be able to store a
custom color
table under a name specified by the user in an area that is stratified
by username in a manner similar to procedures. (Usernames are selected
from the select user name menu opened from the File pulldown menu.)
Users
shall be able to recall saved color tables on any graphic workstation
at
the local site. Custom color tables shall also be available for recall
as part of a bundle/procedure. $$What happens if a color table is
subsequently
deleted, what does the procedure do? Return an error message?$$ |
9/21 |
|
Build_4.2-155
|
AWIPS_DCS_155 |
Bundles/procedures - The information used to create displays
in product
maker shall be captured as adisplay bundlesuch that the same display
may
be recreated atanother time from a workstation procedure. Product maker
bundles shall have the same user functions as other D2D display bundles. |
9/14 |
|
| Build_4.2-156 |
AWiPS_DCS_156 |
Contour interval - As an option, Product maker shall allow
the user
to specify contour interval prior to generating a contour graphic. Ther
user shall specify avalue as an anchor contour and/or an interval.
These
values shall be specifiedthrough a dialog box opened from the main
product
maker dialog. Inappropriate values shall be ignored by the contouring
routines.
A help function to assist the user in specifying appropriate values is
desirable. |
9/14 |
|
| Build_4.2-157 |
AWIPS_DCS_157 |
Moving station depictable - AWIPS shall provide a plot of non
fixed
reporting platforms (e.g. ships, floating buoys, aircraft). Plots shall
include an identification for reference purposes (id does not have to
be
displayed until zoomed.) Parameters appropriate for the kind of plot
shall
be displayed in a station plot format. |
9/14 |
|
| Build_4.2-158 |
AWIPS_DCS_158 |
AWIPS shall support the automatic genreation of watch
information.
The responsibility for generating severe weather watches will
transition
from a national center to local offices. Responsibility for issuing
other
watches will transition from WSFOs to WFOs. The watch generation
capability
must support the transitions. We were mistaken on the requirement. Carl
Bullock was gone and we guessed that the requirement meant drawing and
encoding the SAW products. We are now removing this as a task. |
REJECTED |
|
| Build_4.2-159 |
AWIPS_DCS_159 |
Other watches - Watches such as winter storm, flash flood,
etc. shall
be based on WSFO areas of responsibility initially. AWIPS shall allow
responsible
offices to issue watches using warngen for their area of watch
responsibility
which typically is larger than their CWA. ($$ AWIPS will need some way
of identifying the area similar to that used for CWA.$$) AWIPS shall be
able to support watch generation through the various transition phases
culminating in watches begin issued by all WFOs. |
9/14 |
|
| Build_4.2-160 |
AWIPS_DCS_160 |
Severe weather watch redefining statements - Former WSFOs
shall issue
watch redefining statements (for their WSFO area of responsibility.
AWIPS
shall automatically generate a draft message (WRKSLS) based upon a
current
watch (SAW). Only the portion of the watch that is part of the
WSFO
area of responsibility shall be included. ($$ AWIPS will need some way
of identifying the area similar to that used for SWA. $$) The user will
indicate which SAW is to be used as the basis for the statement. This
shall
be run from any text window. |
9/14 |
|
| Build_4.2-161 |
AWIPS_DCS_161 |
Y2K - Identify potential problems. |
10/12 |
|
| Build_4.2-162 |
AWIPS_DCS_162 |
Y2K - Programmers evaluate code. |
10/12 |
|
| Build_4.2-163 |
AWIPS_DCS_163 |
Y2K - System Engineering Team evaluate issue with input from
operations. |
10/12 |
|
| Build_4.2-164 |
AWIPS_DCS_164 |
Y2K - Repair identified problems. |
who?? |
|
| Build_4.2-164 |
AWIPS_DCS_165 |
Y2K - Contact freeware vendors regarding compliance
statements. |
10/12 |
|
| Build_4.2-165 |
AWIPS_DCS_166 |
Y2K - Prepare Test Plan, test, verify. |
10/12 |
|
| Build_4.2-167 |
AWIPS_DCS_167 |
Version command - A local site administrator shall be able to
change
the number of versions stored of a text product. Wildcards shall be
available
to change versions if one or two of the three fields (CC NN XXX) are
specified.
Changes in version number shall be effective without restarting
Informix. |
9/14 |
|
| Build_4.2-168 |
AWIPS_DCS_168 |
Read command - The textdb -r command shall function
continuously without
the need for a periodic (every 2 wee crash) restart. |
9/14 |
|
| Build_4.2-169 |
AWIPS_DCS_169 |
For 4.2 AWIPS shall upgrade netCDF to a current operationally
tested
version (which is 3.4). As appropriate AWIPS shall take advantage of
new
features in the latest version such as compression, C++ interfaces, etc. |
9/14 |
|
| Build_4.2-170 |
AWIPS_DCS_170 |
For 4.2 AWIPS shall add data ingest, processing (including
decoding
of defined formats) and display of ship reports. Display of these new
data
sets shall include station plots. |
9/14 |
|
| Build_4.2-171 |
AWIPS_DCS_171 |
For 4.2 AWIPS shall add data ingest, processing (including
decoding
of defined formats) and display of drifting buoys. Display of these new
data sets shall include station plots. |
? |
|
| Build_4.2-172 |
AWIPS_DCS_172 |
For 4.2 AWIPS shall add data ingest, processing (including
decoding
of defined formats) and display of Coast Guard data. Display of these
new
data sets shall include station plot data. |
? |
|
| Build_4.2-173 |
AWIPS_DCS_173 |
For 4.2, AWIPS shall include changes in station table
information for
surface metar reporting sites. |
? |
|
| Build_4.2-174 |
AWIPS_DCS_174 |
For 4.2, AWIPS shall include changes in station table
information for
upper air reporting sites. |
? |
|
| Build_4.2-175 |
AWIPS_DCS_175 |
Fpr 4.2, AWIPS shall include recent changes to WMO
identifications
of text messages and their corresponding AFOS pil identifications,
which
are used to store these products in AWIPS. |
? |
|
| Build_4.2-176 |
AWIPS_DCS_176 |
Ability to forward notifications without any delay for time
critical
products such as radar data. |
9/14 |
|
| Build_4.2-177 |
AWIPS_DCS_177 |
Ability to specify differenttime delays for different
classes
of products. |
9/14 |
|
| Build_4.2-178 |
AWIPS_DCS_178 |
An inventory caching mechanism for time critical products. |
9/14 |
|
| Build_4.2-179 |
AWIPS_DCS_179 |
Cleanup of inventory times to prevent notifications from
getting lost. |
9/14 |
|
| Build_4.2-180 |
AWIPS_DCS_180 |
Revised radar mosaic algorithm - For 4.2, AWIPS will use a
revised
algorithm in compositing radar mosaics. The algorithm will use a 6
minute
time frame interval and assign radar products to a frame on a nearest
time
basis. (This may mean that a site in clear air mode may have the same
product
repeated in consecutive frames.) |
9/14 |
|
| Build_4.2-181 |
AWIPS_DCS_181 |
warnGen shall e revised for 4.2 to accommodate backup.
For service
backup, the user shall be able to identify the office for which the
local
site is performing backup on a pulldown menu in the warnGen dialog.
warnGen
shall automatically limit the area included in warnGen products to that
portion of the CWA for which the local office has responsibility . |
9/14 |
|
| Build_4.2-182 |
AWIPS_DCS_182 |
warnGen shall berevised for 4.2 to accommodate Valid Time and
Event
Code (VTEC). Additional menus required for VTEC shall be added to the
warnGen
dialog, and the appropriate information shall be added to the products
generated by warnGen. |
9/14 |
|
| Build_4.2-183 |
AWIPS_DCS_183 |
|
REJECTED |
|
| Build_4.2-184 |
AWIPS_DCS_184 |
Merge the foundation classes used by IFPS and WFO-A
development teams
to one version. |
|
|
| Build_4.2-185 |
AWIPS_DCS_185 |
Number for tracking bug fixes. |
|
|
| Build_4.2-186 |
AWIPS_DCS_186 |
Change the alarm/alert handling of radar status messages so
that alert
area cancellations flash in the radar status line instead of popping a
red banner. |
|
|
| Build_4.2-187 |
AWIPS_DCS_187 |
Modify color tables used by radar images so that they
correspond
to those used on the PUP. |
|
|
| Build_4.2-188 |
AWIPS_DCS_188 |
Assign red color to ERVS product, green to hail product, and
yellow
to mesocyclone product. |
|
|
| Build_4.2-189 |
AWIPS_DCS_189 |
Convert units to knots, feet, and elevations to MSL. |
|
|
| Build_4.2-190 |
AWIPS_DCS_190 |
Volume browser - make changes to reflect changes in the
gridded product
suite planned for the build 4.2 timeframe. These shoudl include RUC II,
new mesoeta grids, UKMO, ECMWR, and the change to 4 runs per day of
several
models. It should also include grids for non CONUS WFOs. As an option
it
should also include the ability to access and display data from a local
mesoscale model. |
|
|
| Build_4.2-191 |
AWIPS_DCS_191 |
Make appropriate changes in configuration files, decoder,
display information,
and storage routines to accommodate changes in gridded data stream. |
|
|
| Build_4.2-192 |
AWIPS_DCS_192 |
Make modifications necessary to install and operate AWIPS at
locations
outside the CONUS. Some initial change es were implemented as part of
4.1,
this will complete that work. Changes will be needed in the
localization
software. |
|
|
| Build_4.2-193 |
AWIPS_DCS_193 |
Modify scale definitions to accommodate non CONUS sites. |
|
|
| Build_4.2-194 |
AWIPS_DCS_194 |
Modify user interface to accommodate non CONUS sites. |
|
|
| Build_4.2-195 |
AWIPS_DCS_195 |
Modify data acquisition to accommodate non CONUS sites. |
|
|
| Build_4.2-196 |
AWIPS_DCS_196 |
Change data storage and management to accommodate non CONUS
sites. |
|
|
| Build_4.2-197 |
AWIPS_DCS_197 |
Allow the WeatherKey/SubKey allowable combinations to be
configurable.
The WK/WSK will use a Weather Definition which is stored in the
GridDatabase.
The ifpServer is modified to sotre this definition, and export it to
clients.
The WeatherKey/SubKey is modified to use the weather definition. |
|
|
| Build_4.2-198 |
AWIPS_DCS_198 |
The ifpServer weather key/subkey has been modified to allow a
flexible
weather definition. The gfe components of WeatherColorTable,
ImageVisual,
and BoundedAreaVisual may have to be changed. The legend and edit tools
may also have to be changed to be compatible. This DCS covers
compatibility
issues only, therefore, the visibility and optoinal attributes are
ignored
(but preserved) by the GFE. |
|
|
| Build_4.2-199 |
AWIPS_DCS_199 |
The optional attributes and visibility fields are to be used
by the
gfe. This affects the visuals, edit tools, and WeatherColorTable. |
|
|
| Build_4.2-200 |
AWIPS_DCS_200 |
Initialization (ifpInit) must be updated to use the flexible
weather
definition and new WeatherKey/WeatherSubKey. At the same time, the
visibility
scalar grids should be removed from the ifpInit code. |
|
|
| Build_4.2-201 |
AWIPS_DCS_201 |
The gfe.config specifies the initial displayed set of map
backgrounds.
The gfe ignores this list and therefor there are never any default maps
displayed. The problem is that the MsgHandler needsMapIDs in its
notification
messages and the gfe.conif only has map names. The algorithms need to
be
changed to allow the MapMgr to convert the map names into MapIDs
(throught
the use of ifpServer) and then send out the message. |
|
|
| Build_4.2-202 |
AWIPS_DCS_202 |
The ifpServer currently provides map backgrounds throught its
interface;
however, these maps must be determined at server startup time. The
on-the-fly
technique provides the capability for the client to request a custom
bounded
map at anytime. |
|
|
| Build_4.2-203 |
AWIPS_DCS_203 |
The topography data sets provided to the ifpInit from
ifpServer contain
elevation and depth information. ipfInit currently asumes that there
are
no values below 0. Modify ifpInit to treat all topography values of
less
than zero feet (below sea level) to be sea level. Note this may cause a
problem in those areas that truly are land-based which are below sea
level
(e.g. Death Valley). |
|
|
| Build_4.2-204 |
AWIPS_DCS_204 |
PoP needs to be added to ifpInit slider bar initialization
routines
per request of Dave Ruth at TDL to support IFPS. |
|
|
| Build_4.2-205 |
AWIPS_DCS_205 |
Routine maintenance of shapefiles for map backgrounds and
other uses. |
|
|
| Build_4.2-206 |
AWIPS_DCS_206 |
This DCS is for spelling changes, grammar changes, format
changes.
Other DCSs are provided for information content changes. |
|
|
| Build_4.2-207 |
AWIPS_DCS_207 |
The warnGen and w/w/a programs need to be integrated so that
when warnings
are issued from warnGen, that the generated information is sent to the
W/W/A program. This is accomplished by an API provided by TDL. This DCS
covers the changes made to warnGen to complete the required data
structure
and call the w/w/a API. The API is not part of the WFP-A tree at
present,
so the API function will be stubbed out for later completion by TDL
developers. |
|
|
| Build_4.2-208 |
AWIPS_DCS_208 |
The current ifpInit uses sbEta for the "model" of the
database. Now
that other code has been fixed, the type of this database should "sb"
and
the model "eta". |
|
|
| Build_4.2-209 |
AWIPS_DCS_209 |
The coordConversion program used to be in the level3 AFPS
software
tree and was accidentally left out of the level4 and level5 trees. This
DCS covers the reintroduction of the coordConversion program and
modifications
necessary to work with the new TextString projection identifier. |
|
|
| Build_4.2-210 |
AWIPS_DCS_210 |
An interface to the C++ Thermo code for python is needed,
which will
be Thermo.i. |
|
|
| Build_4.2-211 |
AWIPS_DCS_211 |
Create the Utah and Mass. serverConfig.py files for the Mod
Prod Conference. |
|
|
| Build_4.2-212 |
AWIPS_DCS_212 |
Develop the prototype fire weather formatter for the
modernized product
workshop. |
|
|
| Build_4.2-213 |
AWIPS_DCS_213 |
Update makefiles for ifpAG and ifpGRIB to make the static
build work. |
|
|
| Build_4.2-214 |
AWIPS_DCS_214 |
The tab control widget does not exhibit proper behavior when
resized.
It does not expand/contract its client area (where tab pages are
displayed)
when its over all size is changed. In order to make the tab control
useful
in resizable windows, it must perform resizing properly. |
|
|
| Build_4.2-215 |
AWIPS_DCS_215 |
Static product buttons in the D-2D menus re showing blank
green times.
They should not be showing any green times at all, since they are
static. |
|
|
| Build_4.2-216 |
AWIPS_DCS_216 |
Develop a graphical forecast viewer capability in java that
is compatible
with the ifpServer and LDAD. The viewer capability is for the NWS
ModProd
workshop. |
|
|
| Build_4.2-217 |
AWIPS_DCS_217 |
The following user-style documents need to be version
controlled and
placed into PCMS into workset DOCUMENTATION: User's guide, Quick-start
guide, system manager's guide, asciiGrid user's guide, ifpGrib user's
guide.
Each doc should be placed in its own directory. The following
design/spec
documents need to be added to PCMS: GRESpecs_may98, WxChanges. The
GFESpecs_May98
guide should be broken into two documents - one for the ui changes, and
one for smart tools per the directory names below. The format for the
documents
may be FrameMaker. The workset path for these |
|
|
| Build_4.2-218 |
AWIPS_DCS_218 |
This is for the maintenacne of the CDLs, volume browser
tables, selection
list, and gridded data tables. These items are changed when the
received
grid stream changes. |
|
|
| Build_4.2-219 |
AWIPS_DCS_219 |
|
|
|
| Build_4.2-220 |
AWIPS_DCS_220 |
Fix Makefiles to allow the master build to run error free. |
|
|
| Build_4.2-222 |
AWIPS_DCS_222 |
Software chanes needed for the compatibility between the FSL
localization
and TDL localization |
|
|
| Build_4.2-227 |
AWIPS_DCS_227 |
Fix bug in TextString: remove TrailSpcs() and ensure that the
stringTest
program tests this method. |
|
|
| Build_4.2-228 |
AWIPS_DCS_228 |
Fix bug in ReferenceRegion.i (afps software). |
|
|
| Build_4.2-232 |
AWIPS_DCS_232 |
The field offices have been asking for the surface level
pressure for
the product maker. |
|
|
| Build _4.2-233 |
AWIPS_DCS_233 |
If an empty TextString is sent to ReferenceID or SampleID
constructor,
then a logBug will occur in TextString since the constructor (in
ReferenceID/SampleID)
indexes the length of the string - 1 which is out of bounds. A check
should
be placed in these two classes to bypass the searches. A logBug can
also
be added to the code so that an invalid ReferenceID or SampleID is
immediately
noted. This logBug should list out the ascii textString that was given
to the constructor and should be surrounded by a []. |
|
|