Subject: file dependencies
Date: Wed, 01 Mar 2000 09:34:00

Text item: Part 1

afos_lookup_table.dat

If you add something here, there will probably be new products coming
out of the StdDBDecoder. These need to go in afosMasterPIL.txt.
Nothing breaks if they don't - the products go in the database and can
be retrieved, just not via the text browser. Should you change or add
a new CCC then there will need to be changes to afosMasterPIL.txt
(because the old CCC is replaced by a new one). For a new CCC, you'll
want to make an entry in textOriginTable.txt to say where it belongs
in the browser, and to textCCChelp.txt to identify the CCC.

afosMasterPIL.txt

Changes here don't need to be reflected anywhere else.  However, 
changes elsewhere come here.

bit_table.dat

This is a rather static table. Again, if you make changes here (such
as the only one made in the last 4 years), there will be changes to
make in afosMasterPIL.txt.

BUOY.goodness

As you may have noticed, the latest version of this file is empty. I
don't really see a future need to populate it.

collective_table.dat

Once again, changes here will no doubt result in new products getting
to the text database, which should be reflected in afosMasterPIL.txt
and textCCChelp.txt. If you're adding METARs, then you'll probably be
needing to add some stations to metarStationInfo.txt.

ispan_table.template

Again, if you add products here, you'll want to add them to
afosMasterPIL.txt. There's as much "remove" maintenance to this file
as "add." Many entries aren't needed, either because the WMO IDs are
no longer in use, or because the products are AWIPS compliant (i.e.,
they have the AWIPS ID on line 2). The latter is true for many PHFO
products in Build 4.3, as we made a change to the StdDBDecoder that
will let them be processed without appealing to the ispan_table.

maritimeStationInfo.txt

No dependencies here, since we're not using BUOY.goodness.

metarStationInfo.txt

Changes here should be reflected in MTR.goodness, if the station is
already there. It's really not necessary to add to MTR.goodness. 
If I change the station name field, then I'll go into textCCChelp.txt 
and update that to match.


MTR.goodness

About the only maintenance needed here is if a station name changes.
Then the old name probably should be removed (or goodness factor set
to zero), to avoid having two station IDs plot on top of each other.

national_category_table.template

Changes here are generally in conjuction with other items, rather than
the other way around. New entries here will no doubt also require
modifications to afosMasterPIL.txt and possibly textCCChelp.txt. Of
course, if it's a new METAR, it goes in metarStationInfo.txt.

selsAnchors.txt

No dependencies here.

station_table.dat

A change here may well require a similar addition to
national_category_table.dat, since the "right side" item here needs
to be a "left side" item in the latter.

textCategoryClass.txt

If you add or change a class associated with an NNN, there are no
dependencies. A new NNN should be accompanied by an entry in
textNNNhelp.txt and addition(s) to afosMasterPIL.txt.

textCCChelp.txt

Again, no dependencies for mods. A new entry probably means new
products, which should be added to afosMasterPIL.txt.

textNNNhelp.txt

Ditto here, with the additional need for textCategoryClass.txt update
if a new NNN.

textOriginTable.txt

Same here. Only if a new CCC is added will any other files need an
update.

upair_table.dat

Essentially similar to collective_table.dat, but for the METAR
connection.