Adaptive Plan View Plotting refers to an AWIPS capability that allows one to add new kinds of plan view plots or change the way existing ones look simply by changing plain text static metadata.
In order to make this work, the data to be plotted need to be in a self describing format. To this end, the plotting of all point data sets is done from netCDF files. In 5.0, all pre-existing netCDF files were enhanced by adding some additional variables and attributes. However, none of the existing variables or attributes was changed, so existing applications that read netCDF point data still work.
While there is a performance penalty for this additional flexibility, it is not prohibitive. The additional flexibility should be extremely useful for LDAD data, allowing each site to plot whatever data ends up in their LDAD netCDF files.
Under the new paradigm, menu entries and product button entries work exactly as before to display a given depict key. Depict key and data key entries are somewhat different.
The new design files are used in two ways, for plan view plots and soundings.
Here is a sample depict key entry; we are using the standard METAR plot from depictInfo.manual:
120 |72 |82,27001,1003| |0,1003|1 |METAR |METAR Plot |1|0|1| | |900
Depict key entries for plan view plots include two changes. First, all entries have a depictable type (second vertical bar delimited column) of 72. This is because all of these displays use the same software module to create the display; what makes them different is the associated static metadata. Second, column three, which is the list of associated data keys, contains a new entry (27001 in this case), which points to what is refered to as a `design file.' For the new adaptive plan view plotting, the first data key must point to the data directory, the second must point to a design file, and the third optional key must point to a static progressive disclosure file.
Here are the associated data keys from dataInfo.manual:
82 | | | | | | |point/metar/netcdf | | |metar.cdl METAR decoded reports 27001 | | | | | | | |metarStdDesign |.txt |standard metar Plot design file 1003 | | | | | | | |MTR |.spi |METAR station map data
Notice that the data directory key has the associated cdl file name in the description field. This refers to a version of this cdl residing in localization/nationalData/. It allows the localization (-dirs task) to automatically publish this cdl to the data directory, using ncgen, as the template file. A default version of each of the design files also can be found in localization/nationalData/.
For a static data set, the depict, design file, and static progressive disclosure (if needed) key entries are analogous, but the key for the data file is a little different. This example is for a new spotter sampling display.
61 | | | | | | | |spotters|.nc|spotters.cdl netcdf spotters data set
Note that there is no directory entry (eighth column) but there is a file and extension entry (ninth and tenth column). In this case, the localization (-station task) would expect a file called spotters.dat to be available to the program reformatTest (see reformatTest.doc.html) to initialize the file spotters.nc. There is a bogus example spotters.dat in nationalData/, but it is expected that in practice this would be replaced by a customized one on site. Actually, for any data key entry that conforms to the above pattern and for which there is a corresponding *.cdl and *.dat file, this initializaton will occur.
Sounding displays (profiler time-height, RAOB skew-Ts), use the new paradigm only for gathering data from netCDF files. The difference is evident in the depict keys, as in these examples:
11006|17|11006,27108|profTH|11000|2|Winfield LA (kts)|WNFL1|8|0|0|18,100 9016|7 |9016,27503 |PASNraob|9000|1 |PASN Skewt |PASN |1 |0 |0 |
Although there is a design file specified in each of these, it is not used in the same way as those governing plan view plots. First, note that the depict type here is not 72. Second, an examination of the design files (profTHdataDesign.txt and raobSkewtDesign.txt, according to dataInfo.manual) reveals that they include no display methods, just data-gathering functions.
This is the most important section of this document, because the design files are where one exerts most of the control over how plan view plots are created. All of the default design files exist in nationalData/ and have file names that look like *Design.txt. They are subject to copy override from realization, site specific, and customization files (for more info on file override, see section 5 of localization.html).
We will begin by discussing the overall structure of design files. Then an example of a design file will be presented and discussed in detail. Finally, we present some notes on local modification and testing.
Design files are plain text files. As the text for a design file is interpreted, any line that is all spaces, blank, or begins with // is ignored. A backslash at the very end of a line is considered a line continuation. Each interpreted line consists of a keyword followed by one or more space-delimited arguments. (Within this document, except in actual examples, keywords will be `quoted' and their arguments will be italicized.) A keyword and its arguments must appear on the same line; the continuation can be used to make long entries more readable. Because arguments are primarily space delimited, the user is allowed to use a tilde (~) to stand for a space in string arguments. In such strings, an escaped tilde (\~) is used to represent a tilde. Spaces are not allowed in file names, item IDs, keywords, and other reserved words, so escaping is generally ignored for these.
A design file is broken into two major sections, the global definitions and the item definitions. The global definitions are all entries that refer to the design file as a whole; the item definitions are all entries that refer to a specific item. All global definitions must appear before any item definitions, but the individual global definitions can be in any order. A complete list of keywords for both global and item definitions can be found in Appendix 1.
The presence of an `item_id' keyword is what triggers the existence of an item. The entries that define an item span from that `item_id' to the entry immediately before the next `item_id.' `item_id' is always the first entry of an item definition, but within an item definition other individual entries may appear in any order. Also, the items as a whole may appear in any order.
An item is a logical entity that may contain raw data from a netCDF file, the result of a function, a constant, or a display method. Each item that contains a display method must also contain raw data or a function result. Containing raw data, a function result, or a constant are mutually exclusive, and it is not permissable to have a display method associated with a constant.
Each item is defined by its characteristics and the data it contains. Here we will focus on what these characteristics mean; how they are determined will be discussed later. One primary characteristic of an item is its dimensionality (keyword `dimension'), which can be constant, scalar, or list. A constant item contains just one constant value, a scalar item contains one value per station or record, and a list item contains two or more values per station or record. Another primary characteristic of an item is its indexing; most items contain data on a per station basis, but some contain some data on a per netCDF file record basis. Station versus record indexing is meaningless for a constant item. A third primary characteristic is the base data type. The base data types are float, int, short, and string. It is also possible to talk of the major data type of an item, which is either string or numeric. Constants have only a major type, string versus numeric.
The most important characteristic of an individual data value is whether or not it is null. Each base data type has a corresponding well-defined null value, 9e99 for doubles, 1e37 for floats, 2147483647 for ints, 32767 for shorts, and a zero length string for strings. The null double value is important because numeric constants are held as doubles and all numeric values from lookup tables are presented as doubles. Where it is important to assign an arbitrary non-null value to a data item, 0 is used for numeric values and "0" is used for strings.
A constant item contains only one additional entry beside its item_id, with a keyword of `constant.' If the first argument is a single equals sign followed by another argument that is a numeric value, then the constant will be numeric. Otherwise, the first argument will be used to define a string constant. Spaces are allowed in string constants, so here a tilde should be used for a space. It is possible to override the value of a constant in a design file directly from the associated depict key entry. This is done in the 13th vertical bar delimited field, the so-called extraInfo field, which contains a list of comma-delimited strings. In this case, each pair of strings is assumed to be the ID of a constant item followed by an override value.
An item is identified as containing raw data primarily by the presence of a `netcdf_id' keyword. This keyword is followed by the name of the netCDF variable from which it reads data. The most common other keywords for a raw data item are `type,' `dimension,' and `record.' If the argument of the `record' keyword is true, then that item will contain values corresponding to records in the netCDF file. Otherwise, it will contain data for each station. This distinction is important because a single station may have data available at multiple times. The possible arguments for the keyword `type' are string, float, int, and short. The reason the user supplies this information rather than it being obtained from the netCDF file is so that the validity of function relationships can be determined when the design file is parsed. The possible arguments for the keyword `dimension' are scalar and list. If scalar, there is one value for each record, meaning that variable should be dimensioned in the netCDF file as (recnum), or (recnum,strlen) in the case of a string. If list, then there are multiple values for each record, meaning that variables should be dimemsioned (recnum,listlen), or (recnum,listlen,strlen) in the case of a string. Here recnum must refer to the UNLIMITED dimension, and listlen and strlen to any valid dimension appropriate for the variable.
An item is identified as containing a function output primarily by the presence of a `function' keyword. This keyword is followed by the function name (see Appendix 2 for a complete list of available functions). A function item must also contain an entry with an `inputs' keyword. The arguments that follow `inputs' are a list of the item_ids that are input to the function. These may be other function outputs, raw data, or constants, depending on the requirements of the function. (Note that numeric strings cannot be used as function inputs; any additive or multiplicative value must be pre-defined. This is not true of display keywords, for which numeric inputs are allowed, as demonstrated in the example in the next section.) There is no need to specify the data type or dimensionality of a function; that is all determined by the characteristics of the inputs and the function used.
An item is identified as having a display method primarily by the presence of the keyword `placement.' The kind of display is determined by the argument to the keyword `method.' For some methods, the placement is predetermined by the method and the argument to the keyword placement is just free. Otherwise it is one of nine predefined placement positions (upper_left, center, etc.). While most display methods require only one input, some require multiple inputs, in which case a special function called `gather' is used to hand multiple items to a single display method. The reader is directed to Appendix 3 for a complete list of display methods.
What follows is a sample design file. Again we use the standard METAR plot (nationalData/metarStdDesign.txt) as an example.
// Standard metar plot size 45 time_step 3600 //stations_path metar_stations.
In this example the last global definition is "time_step 3600" and the first item definition is "item_id RT." The entry "size 45" specifies that each plot model is to be treated as 45 pixels in size for the purpose of calculating progressive disclosure. The entry "time_step 3600" means that each graphic of this type in a time sequence will be separated by one hour, which is 3600 seconds. All time periods in design files are in units of seconds.
item_id RT type string dimension scalar record true indexing_table rank_report_type.txt netcdf_id reportType
Normally, when the code figures out which data record to copy to a station, the record with a time closest to the valid time of the whole data set is used. Here, the item RT is used to specify that we prefer to use observations with a report type of METAR if avaliable, instead of a SPECI that may be closer to the data set time. To make this work, this item is specified to be a record item and an entry with the keyword `indexing_table' is supplied. The file rank_report_type.txt contains the data for what is called a Lookup Table. This particular table is a string to number lookup table, and is used to assign arbitrary rankings to the strings METAR and SPECI.
item_id TXT type string dimension scalar netcdf_id rawMETAR sample true
This item is reading in the raw text of the METAR. Since the keyword `sample' is there with the argument of true, this text is what is presented for sampling. In order to sample, an item must be a scalar string type with station indexing.
item_id CLOUDS type string dimension list netcdf_id skyCover
This item pulls in the cloud information but does not directly display it. That will be done by a later item (and note that the display does not have to be done by the immediately following item). This item has a list argument to its `dimension' keyword because there can be multiple cloud decks.
item_id DPTYP type short dimension scalar netcdf_id pressChangeChar
item_id DPVAL type float dimension scalar netcdf_id pressChange3Hour
item_id DP3 function gather inputs DPVAL DPTYP method trend placement right multiplier 0.1 format %3.2d
DPTYP and DPVAL are used to pull in the characteristic and amount of the pressure change. DP3 uses the gather function, which is a special function used only to pass one or more previously defined items to a display method. The display method here is trend, which is specifically tailored for the task of displaying pressure change data. In the design of the capability, we have tried to avoid specifically tailored functions or display methods, but a few exist. Note that the units conversion from pascals to tenths of millibars is done with the generic `multiplier' keyword rather that being folded into the method.
item_id SPD type float dimension scalar netcdf_id windSpeed
item_id DIR type float dimension scalar netcdf_id windDir
item_id GUST type float dimension scalar netcdf_id windGust
item_id WIND function gather inputs SPD DIR GUST method barb placement free multiplier 1.944
SPD, DIR and GUST are used to pull in the wind speed, wind direction, and gust speed, respectively. The item WIND uses gather to present these to the barb method. Note than since this method predetermines the placement of what is being plotted, free placement is used. The multiplier is used to convert from meters per second to knots.
item_id WX type string dimension scalar netcdf_id presWeather placement left method translation table_file wx_symbol_trans.txt alt_char_set weather
This is an example of a raw data item that is immediately handed to a display method. The method translation specifies that a string to string lookup table is expected, and the recursive translation method of that table will be called to produce the text for output. The `table_file' keyword is used to supply the name of the file containing the lookup table. All text that cannot be translated will be shown as plain ASCII, but the text that is translated will be displayed using the weather character set.
item_id TC type float dimension scalar netcdf_id temperature
item_id TdC type float dimension scalar netcdf_id dewpoint
item_id T10 type float dimension scalar netcdf_id tempFromTenths
item_id Td10 type float dimension scalar netcdf_id dpFromTenths
item_id T function or inputs T10 TC placement upper_left method formatted multiplier 1.8 offset -459.67 format %d min_trans -60 max_trans 130
TC is used to pull in the value decoded from the regular temperature field in the METAR, which is in degrees Celsius. U.S. METARs also sometimes have a temperature in tenths (used to recover the precision of the Fahrenheit observation) in the remarks section; the T10 item is used to pull that in. Then the T item pulls these two in using the or function and displays them. The order is important: by putting T10 first, it will use the T10 value if available, and revert to using the TC value otherwise. These kelvin temperatures are converted to Fahrenheit using the multiplier and offset of 1.8 and -459.67. The `min_trans' and `max_trans' keywords are used to supply sanity check limits to the results of the units conversion. A completely analogous thing happens with the items TdC, Td10, and Td (below) in order to display the dewpoint.
item_id Td function or inputs Td10 TdC placement lower_left method formatted multiplier 1.8 offset -459.67 format %d min_trans -60 max_trans 100
item_id SLP type float dimension scalar placement upper_right method formatted multiplier 0.1 netcdf_id seaLevelPress format %5d trim_count 2 min_trans 8000 max_trans 11000
This is yet another example of handing raw data directly to a display method. The multiplier of 0.1 turns pascals to tenths of millibars, and %5d is used to format that result. Keyword `trim_count' is followed by the number of characters to strip off the front of the formatted string before displaying it. This is how we follow the convention of not displaying the hundreds of millibars in the pressure field.
item_id VV type float dimension scalar netcdf_id vertVisibility
item_id OBSstr constant OBS
item_id OBS function and inputs OBSstr VV
What happens here is that OBSstr is defined as the string "OBS". Then, if VV is non-null, the "and" of OBSstr and VV will be that same string (because the first item is passed forward). Thus, the item OBS will be either null or "OBS". This is used below as input to the CEILING definition.
item_id CLGDECK function select function_table cloud_select.txt inputs CLOUDS
This is a list item; select is used to choose one value from the list, based on the CLOUDS field assigned above. The file named as the argument to the `function_table' keyword is a string to number table that is used to assign arbitrary rankings to each cover type; the cover type with the lowest ranking number is used.
item_id CEILING function or inputs OBS CLGDECK placement center method lookup table_file cloud_chars.txt alt_char_set special
CEILING will be OBS (string "OBS" - obscured) if that's been set, else CLGDECK determined above. The display method used is lookup, which means use a lookup table to do a simple translation (not the recursive one done for WX) to produce the output text. The table used is a string to string table defined in cloud_chars.txt, and the result is displayed using the special character set).
As noted, files delivered with an installation reside in nationalData/. Suppose you want to change the profiler perspective plot to use arrows instead of barbs. By examining dataMenus.txt (button 3998), depictInfo.manual (3998 uses design file 27109), and dataInfo.manual, you'll find that the design file for this product is profPerspPlotDesign.txt. You can put a copy of this file in your localizationDataSets/<LLL> directory, then modify it and see the results. A caveat is that the design file is read only when the display first needs it. Thus, you have ten chances to see the effect of changes (by swapping in side panes on both displays). Once you've used up all the IGC processes, you'll need to restart D2D, or you can kill one or more IGC_Processes and then use Options->Restart Dead Panes... to get a fresh canvas.
As mentioned before, lookup table files are a means by which a user can perform arbitrary data converions. Lookup table files are plain ASCII files, with blank lines and those that begin with `//' ignored, just as with design files. There are four types of lookup table files. The first line of any lookup table file is a three character string that designates its type. All of the default lookup table files exist in nationalData/ and have file names that look like *_*.txt. Just like design files, they are subject to copy override from realization, site-specific, and customization files. Since space-delimited parsing is used in these files, one needs to use a tilde (~) to designate the existence of a space in an input string. An escaped tilde (\~) can be used to designate a tilde.
See Appendix 5 for a listing of standard lookup table files.
The first line of a string to string lookup table is "s2s". A string to string lookup table is used to convert some arbitrary string to some other string. Most entries are a line with a lookup string followed by a result string to which to translate it. Sometimes, there is a need to have characters in the result string that are unprintable in ASCII. In that case, the result string can be expressed with a colon followed by a list of integers designating the character codes (all space delimited). It is also possible to make an entry with only a lookup string, which means that the result of translating that string will be an empty string.
There are four special keywords that are recognized in a string to string table. Once a line has been encountered that does not have one of these keywords on it, further occurences of these keywords will be treated as a regular lookup string. Normally, if an attempt is made to translate an input string that does not exist in the table as a lookup string, the output will be some constant default string. The keyword `pass,' if present, indicates that if the input string is not available as a lookup string, then the resulting translation should be the input string. The usual default string is an empty string, but using the keyword `default' allows one to supply a different default string. There is a special type of translation available for the string to string table that will attempt to translate all possible substrings in the input string, as well as the entire string. The keywords `left' and `right' allow one to perform an edit operation on the input string before it is translated in this case. The arguments after the `left' or `right' keyword are a lookup and result string expressed exactly as in a regular entry. For `left,' the first occurence of the corresponding lookup string is located, and all text up to that occurence is replaced with the corresponding result text. `right' works analogously with the last occurence and the end of the string to translate.
The first line of a string to number lookup table is "s2n". Such a lookup table is used to convert some arbitrary string to some numeric value. Most entries are a line with a lookup string followed by a numeric value to which to translate it. Internally, numeric values in a string to number table are held as doubles.
There are three special keywords that are recognized in a string to number table. Once a line has been encountered that does not have one of these keywords on it, further occurences of these keywords will be treated as a regular lookup string. If an attempt is made to translate an input string that does not exist in the table as a lookup string, the output will be some constant default value. Normally, this default value is 9e99, universally recognized by the PlotDesign class as a null double value. Using the keyword `default' allows one to supply a different default numeric value. There is a special type of translation available for the string to number table that will attempt to scan all possible substrings for a possible lookup string, as well as the entire string. The keywords `left' and `right' allow one to perform an edit operation on the input string before it is translated in this case. The arguments after the `left' or `right' keyword are a lookup string and a translation string. For `left,' the first occurence of the corresponding lookup string is located, and all text up to that occurence is replaced with the corresponding translation string. `right' works analogously with the last occurence and the end of the string to translate.
The first line of a number to string lookup table is "n2s". An n2s lookup table is used to convert some arbitrary numeric value to a string. Most commonly, entries are a single number or a pair of numbers (representing a range), space delimited, followed by a result string. If there are overlapping ranges, order is important because the first range that matches will be used. Sometimes, there is a need to have characters in the result string that are unprintable in ASCII. In that case, will be expressed with a colon followed by a list of integers designating the character codes (all space delimited). It is also possible to make an entry with only one or a pair of numbers, which means that the result of that lookup will be an empty string. Internally, numeric values in a number to string table are held as doubles.
There is one special keyword that is recognized in a number to string table. Normally, if an attempt is made to look up a number that does not exist in the table or is outside all specified ranges, the output will be an empty string. Using the keyword `default' allows one to supply a different string to be output in the case of a failed lookup.
The first line of a number to number lookup table is "n2n". This type of table is used to convert some arbitrary numeric value to another numeric value. Most commonly, entries are a list of two, three, or four numbers, space delimited. Two numbers means translate the first number to the second. Three numbers means that if the input number falls between the first two numbers, the result is the third number. Four numbers means that if the input number falls between the first two numbers, do a linear interpolation to the range represented by the last two numbers.
There are two special keywords that are recognized in a number to number table. Normally, if an attempt is made to look up a number that does not exist in the table or is outside all specified ranges, the output will be 9e99, universally recognized by the PlotDesign class as a null double value. Using the keyword `default' allows one to supply a different number to be output in the case of a failed lookup. If keyword `pass' is present, then a failed lookup results in the number input to the lookup being passed through.
By convention, keywords are all lower case with underscores. This discussion will divide keywords into five categories: global, item, raw data, function, and display. Unless otherwise mentioned, the reader should assume that each keyword takes one and only one argument. The reader should also note that all time periods in design files are in seconds.
All global keywords must appear in the design file before any keywords from other categories. Global keywords refer to the file as a whole; all other keyword are specific to their corresponding item.
| Keyword | Argument | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| size | The number of pixels in size to assume each station model plot is. This is used for progressive disclosure calculations. | ||||||||
| time_step |
The number of seconds separating the valid times of each displayable
frame. For example, 3600 would be one hour; thus a graphic would be
created with valid times on the hours. By default, this could
potentially contain observations ranging in time from 30 minutes
before to 30 minutes after the hour.
time_step must be greater than or equal to filePeriod divided by nInventoryBins, as defined in the CDL. |
||||||||
| default_period |
|
||||||||
| predefined_only |
|
||||||||
| dyn_prog_disc |
This keyword is used to control whether and how progressive disclosure
is calculated on the fly based on which data is available. One can
divide stations to plot into two categories, those with static
progressive disclosure and those without.
|
||||||||
| stations_path | A fragment of a file name to which the list of stations rendered will be written each time a frame is drawn. It is written into the localizationDataSets/<LLL>/ directory and has an extension with the process ID encoded. | ||||||||
| hard_accums |
|
||||||||
| sample_format | Normally, when sample text is output, whatever text is in the item designated as being the sample item is just written to the screen as is. `sample_format' can take one or more arguments, each being a separate line of formatting information. The standard ~ is used as a place holder for a space. As the text to be formatted is scanned, each %c results in the next character being used in the output, and each %s results in the next space-delimited word being used in the output. If the last format specification is %s, then that format specification will be replaced with whatever text is left regardless of spaces. If in the course of formatting, the text to be formatted is exhausted, the rest of the format specifications will be replaced with empty strings. | ||||||||
| diag_dump |
A numerical argument, causing diagnostics to be written to stderr as
the design file is parsed and used to obtain data.
|
| Keyword | Argument | ||||
|---|---|---|---|---|---|
| item_id | The presence of this keyword triggers the existence of an item. The entries that define an item span from its `item_id' to the entry immediately before the next `item_id.' This keyword is always the first entry of an item definition, but within an item definition other individual entries may appear in any order. | ||||
| sample | This keyword must be applied to an item that has a scalar string type and is station indexed. When present with an argument of true, it will cause the text from this item to be used for sampling. This keyword should be used on only one item. | ||||
| remove_by | This keyword must be applied to an item that has scalar dimensionality and is record indexed. All basic data types, string, float, int and short, have a well defined null value. When present with an argument of true, it will cause all records for which this item has a null value to be removed from consideration for plotting. This keyword should be used on only one item. | ||||
| indexing_table | This keyword must be applied to an item that has scalar dimensionality and is record indexed. This allows the value of the data item to be taken into account when selecting which of multiple records applying to the same station should be selected for display. The argument must be the filename of a lookup table with numeric output and input appropriate to the item. This table is used to convert values in this item into arbitrary rankings; lower ranking numbers are most preferred for display. This keyword should be used on only one item. | ||||
| goodness_table | This keyword must be applied to an item that has scalar dimensionality and is station indexed. This allows the value of this data item to be taken into account when calculating progressive disclosure. The argument must be the filename of a lookup table with numeric output and input appropriate to the item. This table is used to convert values in this item into goodness values; higher goodness values are most preferred for display. The reader is directed to va_driver.doc.html for more information on goodness values. | ||||
| accum_period | This keyword must be applied to an item that is station indexed. Furthermore, it should be applied only to an item that is also raw data or is the result of a call to the `rec_to_sta' function. The value associated with the `valid_period' keyword for this item directly affects the result of using this keyword. When a non-zero value for the accum_period keyword is present (0 is the default), then an alternate method is used to map record indexed data to station indexed data for the associated item. An attempt is made to add up values over a period in time equal to the accum_period, assuming each individual value represents the state over a period in time equal to the valid_period. The number of record indexed values used in the summation is essentially the accum_period divided by the valid_period. If that number is greater than one, then this results in values being added up over some period of time. If there is only one valid_period within the accum_period, then this routine can be used to find a non-undefined value amongst several record indexed values irrespective of what the default record to station mapping may be. | ||||
| valid_period | Defaults to the value of the `default_period' keyword, which defaults to the value of the `time_step.' It is meaningful to specify a value for the valid_period keyword only when a value has also been supplied for the `accum_period' keyword for the purpose performing an accumulation. For individual records closer in time than this, only one will be considered for accumulation. | ||||
| constant |
A "constant" item contains only one additional entry beside its
item_id, with a keyword of `constant.'
|
| Keyword | Argument | ||||
|---|---|---|---|---|---|
| netcdf_id | An item is identified as containing raw data primarily by the presence of this keyword. The keyword is followed by the name of the netCDF variable from which it reads data. | ||||
| record |
|
||||
| type | Used to specify the base data type of a raw data variable, possible arguments are `string', `float', `int', and `short'. The reason the user supplies this information rather than it being obtained from the netCDF file is so that the validity of function relationships can be determined when the design file is parsed. | ||||
| dimension |
|
||||
| subset | Raw data read from a netCDF file must have the UNLIMITED dimension as its first dimension. Normally beyond that, there can be only one more dimension on the variable (two if string). `subset' allows one to read data with more dimensions by fixing some dimensions and letting others float. For any item, the subset keyword must have an argument for each dimension beyond the UNLIMITED dimension. An argument of -1 allows a dimension to float, and an argument zero or greater fixes the dimension at that index. Considering numeric variables, if all dimensions are fixed by a `subset' keyword, then the item becomes scalar, and if all but one dimension is fixed it becomes list. For string data, one floating dimension means scalar, two means list. | ||||
| time_offset | Normally, records for an item come from a time period centered at the time of the graphic being created. Using this keyword, it is possible to specify an arbitrary offset for the center of that time period for any item. For example, a time_offset argument of -86400 would allow one to read data one day previous to the time of the graphic. | ||||
| min_valid | For numeric types, any value read that is less than the argument will automatically be converted to the null value appropriate for the base type. This keyword has no meaning for strings. | ||||
| max_valid | For numeric types, any value read that is greater than the argument will automatically be converted to the null value appropriate for the base type. This keyword has no meaning for strings. |
| Keyword | Argument |
|---|---|
| function | An item is identified as containing a function output primarily by the presence of this keyword. The argument is a function name. (See Appendix 2 for a complete list of functions.) |
| inputs | Every item that has a `function' keyword must also have an `inputs' keyword. The argument to this keyword is a list of item IDs that represent the data input to the function. Depending on the function being used, order is usually very important. |
| function_table | Some functions may need a lookup table to do their work and others may optionally be able to apply one. For any such functions, the argument to this keyword is the name of that table. |
| parameters | One or more strings, the interpretation of which is dependent on which function is being used. A function is set up to take parameters when there is a desire to change the behavior of a function in a way that is not suitable to do with arguments, but does not result in a behavior that is fundementally different enough to warrant an entirely different function. Parameters are never required to make a function work; the code will always provide meaningful defaults. |
| Keyword | Argument(s) |
|---|---|
| placement | An item is identified as having a display method primarily by the presence of this keyword. For some methods, the placement is predetermined by the method, and at other times the user may decide to supply specific coordinates. In these cases, the argument is free. Otherwise it is one of nine predefined placement positions: upper_left, top, upper_right, left, center, right, lower_left, bottom, and lower_right. | method | The argument determines the manner in which the data in the item are to be displayed. Most methods require only one input; some require multiple inputs, in which case special function `gather' is used (see Section A2.1). A complete list of display methods is found in Appendix 3. | location | A pair of coordinates that are in units of numbers of characters offset from the center of the station model, right and up being positive. These coordinates need not be integers. The value of the `placement' keyword must be free for these coordinates to be used. | format | Some display methods require a C format specification, supplied here. When formating string values, the core of the format must be a %s type. When formating numeric values, the core of the format can be %d, %f, or %g type. The default format is simply %d. | trim_count | The number of characters to strip off the front of a formatted string before displaying it. It defaults to zero - trim no characters. | multiplier | `multiplier' works hand in hand with `offset' to allow units conversions to be performed on numeric values before displaying them. Numeric values are multiplied by the `multiplier' argument and then the `offset' argument is added before formatting for display. The default value is one. | offset | `offset' works hand in hand with `multiplier' to allow units conversions to be performed on numeric values before displaying them. Numeric values are multiplied by the `multiplier' argument and then the `offset' argument is added before formatting for display. The default value is zero. This keyword is not applicable for units conversion with vector display. | min_trans | A lower bound for a final sanity check on a value to display after it has gone through the units conversion check. This is not applicable for vector display. | max_trans | An upper bound for a final sanity check on a value to display after it has gone through the units conversion check. For vector display, this is applied to the magnitude. | table_file | the name of the file containing the data for a method-required lookup table | undef_string | By default, when a display method is given a null value to display or the value fails the final sanity check, nothing will be displayed. Here the user can supply a string that should be displayed in that case. | magnification | A magnification factor for whatever is being plotted. The default is one and non-integral values are meaningful. | alt_char_set | Allowable arguments are ascii, large_ascii, weather, special, and large_special, specifying the character set to use to display text; the default is ascii. These character sets are described and illustrated in characterSets.html. |
The data type of a function item is determined by the specific function used and the inputs. With some execptions, most functions will take any base data type as input. There are some broadly applicable rules about compatibility among inputs when there are multiple inputs to a function. One can never mix record indexed and station indexed items, nor can one mix record indexed items that have different values for the `time_offset.' With rare exceptions, one cannot mix list inputs that have different list sizes. However, one is usually free to mix scalar, list, and constant items as inputs, with the exception that it is usually not meaningful to have all inputs be constant. When mixing input items of different dimensionality, the result has the largest dimensionality. Inputs to functions can be raw data or other function results.
Here we will divide functions into six broad categories; special, conversion, mathematical, meteorological, logical, and list handling.
| Function Name | Description |
|---|---|
| gather | This function exists solely for presenting a list of items to a display method. The most common use is to present multiple items to a method that needs more than one item, such as displaying vectors. Another use is to pass a single item to an additional display method when the item as defined already has a display method. `gather' cannot take constant or record indexed inputs, and only rarely takes list inputs. The specifics of what is allowed is dependent on the particular display method used (see Appendix 3). |
| rec_to_sta | This is used to convert one record indexed item to a station indexed item. It is the only function that can generate a result with an indexing type different from its inputs. If `accum_period' is not present, it will use whatever default record to station mapping has been established for the time_offset of the item. If `accum_period' is present, then an accumulation will be performed, depending on the argument values for `accum_period' and `valid_period.' |
| sta_id | `sta_id' takes no arguments. The output is a scalar station indexed item of string base type, which contains the ID of each station as obtained from static metadata. The fact that this function exists does not prevent one from reading the station ID from a netCDF variable. |
| state_check | This is a very specialized function, with three or more inputs. The first one or more inputs are items to check against a bit mask (a numeric constant) which is the last input. The next to last input is a string constant that is a list of characters corresponding to each possible state. The number of possible states is two to the number-of-check-items power. For example, if there were five total inputs, there would be three inputs besides the last two constant inputs, and there would be eight possible states (two to the third power), and thus eight characters in the string constant. For each check input in turn, whether it has any of the bits on in the mask is determined, and this yes/no answer is converted to a digit in a binary number, starting with the least significant bit. The resulting number is then used to index into the string constant to get a single character, which is the function result. |
Conversion functions take one non-constant input and convert it to an item with a specified base data type, but with the same indexing and dimensions. By default, the conversion will be done by casting among numeric types, and through standard C format conversion between string and numeric types. The conversion can also be done with a lookup table, assuming compatibility between the input major type, requested output major type, and the flavor of the lookup table. If a value is null in the input, it will become null in the output unless a lookup table has been designed to provide a non-null translation for a null input.
| Function Name | Description |
|---|---|
| string | Converts any arbitrary input to a string item. This is the only conversion function that can take parameters. The first parameter is the length of the strings in the output item and the second is the format to use for data conversion. If not provided, meaningful defaults will be provided for the parameters. The parameters are meaningless if a usable lookup table is provided. |
| float | Converts any arbitrary input to a float item. |
| int | Converts any arbitrary input to an int item. |
| short | Converts any arbitrary input to a short item. |
Mathematical functions will operate on any numeric type as input, but not on strings. When base data types are mixed, the output type will be whichever of the input types has the greatest range of values. With the exception of `accum,' if any of the inputs for a given station/record and list index (if applicable) is null, then the result will be null.
| Function Name | Description |
|---|---|
| diff | Two inputs; result is the first input minus the second. |
| div | Two inputs; result is the first input divided the second. |
| add | Two or more inputs; result is the sum of all inputs. |
| accum | Two or more inputs; result is the sum of all non-null inputs. This differs from `add,' where the presence of any null input will result in a null output. However, if all inputs are null, the result will still be null. |
| mult | Two or more inputs; result is the product of all inputs. |
| lintrans | Two or more inputs. If I1, I2, etc., are the inputs and R is the result, then R = I1*I2 + I3*I4... Using standard mathematical precedence, all the multiplications take place before the additions. If there is an odd number of inputs, the last is simply added to the result without being multiplied by anything. |
Meteorological functions operate only on float or numeric constant item types; any null inputs will result in a null output.
| Function Name | Description |
|---|---|
| ucomp | Two inputs, a magnitude and a direction; result is the u component of that vector. |
| vcomp | Two inputs, a magnitude and a direction; result is the v component of that vector. |
| heat_index | Two inputs, temperature and dewpoint in kelvins; result is the Heat Index in kelvins. |
| wind_chill | Two inputs, temperature in kelvins and wind speed in meters per second; result is the Wind Chill temperature in kelvins. |
| dewpoint | Two inputs, temperature in kelvins and relative humidity in percent; result is the dewpoint in kelvins. |
| temperature | Two inputs, potential temperature in kelvins and pressure in millibars; result is the temperature in kelvins. |
| theta | Two inputs, temperature in kelvins and pressure in millibars; result is the potential temperature in kelvins. |
| alt2press | Two inputs, altimeter setting in millibars and elevation in meters; result is the surface station pressure in millibars. |
| height_of | One input, a numeric constant which is a pressure in millibars; result is a scalar station indexed item of float base type, which contains the corresponding height of that pressure surface for each station, interpolated from gridded data. The user may supply via a `parameters' keyword a list of gridded data source names to try; otherwise a default list will be used. If gridded data access fails, the result will be based on a standard atmosphere. |
| elev | No arguments; result is a scalar station indexed item of float base type, which contains the elevation of each station as obtained from static metadata. (The existence of this function does not prevent one from reading the elevation from a netCDF variable if such a variable exists in the data set.) |
Logical functions have the same output base type as the first argument, but the maximum dimensionality of all the arguments. With a few exceptions, they will take any mix of base types as input. In general, logical functions test the truth of some relationship among the inputs. If true, the first non-null value among the inputs is placed in the output; if false, the output is a null value. Where the first non-null value is string and the output is numeric, the value 0 will be placed in the output. Where the first non-null value is numeric and the output is string, the string "0" will be placed in the output.
| Function Name | Description |
|---|---|
| or | Two or more inputs; result is the first non-null value among the inputs. `or' is different from all other functions in that it will work even if some of its inputs are not definable because of mismatches between assumed and actual netCDF variable names. |
| and | Two or more inputs; if all inputs are non-null, then the value from the first input will be placed in the output. |
| nor | Two inputs. If both inputs are null, then a non-null (0 for numeric, "0" for string) will be placed in the output. |
| xor | Two inputs. If one input is null and one input is non-null, then the value of the non-null input will be placed in the output. |
| not | One input. If the input is null, then a non-null (0 for numeric, "0" for string) will be placed in the output. |
| == | Two inputs, which may not mix string and numeric types. If the two inputs test as equivalent, then the first input is copied to the output. |
| != | Two inputs, which may not mix string and numeric types. If the two inputs test as not equivalent, then the first input is copied to the output. |
| > | Two inputs, which may not mix string and numeric types. If the first input tests as greater than the second input, then the first input is copied to the output. |
| < | Two inputs, which may not mix string and numeric types. If the first input tests as less than the second input, then the first input is copied to the output. |
| >= | Two inputs, which may not mix string and numeric types. If the first input tests as greater than or equal to the second input, then the first input is copied to the output. |
| <= | Two inputs, which may not mix string and numeric types. If the first input tests as less than or equal to the second input, then the first input is copied to the output. |
| min | Two or more inputs, which may not mix string and numeric types. If any values are non-null, then the first non-null value that tests as being less than or equal to all the others is copied to the output. |
| max | Two or more inputs, which may not mix string and numeric types. If any values are non-null, then the first non-null value that tests as being greater than or equal to all the others is copied to the output. |
| bit_none | Two inputs, which must have a short or int base type or be a numeric constant. If there are no bits turned on in both inputs, then a value of zero will be placed in the output, otherwise a null output will result. |
| bit_any | Two inputs, which must have a short or int base type or be a numeric constant. If there are any bits turned on in both inputs, then a value of zero will be placed in the output, otherwise a null output will result. |
| bit_all | Two inputs, which must have a short or int base type or be a numeric constant. If every bit that is on in the first input is also on in the second output, then a value of zero will be placed in the output, otherwise a null output will result. |
| none_there | Two or more string inputs. If none of the remaining inputs appears in the first input as a substring, then the first input will be placed in the output, otherwise a null output will result. |
| any_there | Two or more string inputs. If any of the remaining inputs appears in the first input as a substring, then the first input will be placed in the output, otherwise a null output will result. |
| all_there | Two or more string inputs. If all of the remaining inputs appear in the first input as a substring, then the first input will be placed in the output, otherwise a null output will result. |
| Function Name | Description |
|---|---|
| down_interp | Performs vertical interpolation in the case where the value of the vertical coordinate being used increases downward. This function takes three inputs. The first, a float list, is the vertical coordinate list; the second, also a float list, is the list of values to interpolate; and the third, a scalar float or numeric constant, is the specific vertical coordinate value to which to interpolate. The resulting item is a scalar float, and the interpolation is linear versus the log of the vertical coordinate. By default, it is possible to interpolate data from within a gap 2 levels wide (one missing level). The size of this gap can be specified optionally as an input to a `parameters' keyword. |
| up_interp | Performs vertical interpolation in the case where the value of the vertical coordinate being used increases upward. This function takes three inputs. The first, a float list, is the vertical coordinate list; the second, also a float list, is the list of values to interpolate; and the third, a scalar float or numeric constant, is the specific vertical coordinate value to which to interpolate. The resulting item is a scalar float, and the interpolation is linear versus the log of the vertical coordinate. By default, it is possible to interpolate data from within a gap 2 levels wide (one missing level). The size of this gap can be specified optionally as an input to a `parameters' keyword. |
| down_sample | Performs vertical sampling in the case where the value of the vertical coordinate being used increases downward. Sampling means directly using the value from the nearest level rather than interpolating. This function takes three inputs. The first, a float list, is the vertical coordinate list; the second, also a float list, is the list of values to sample; and the third, a scalar float or numeric constant, is the specific vertical coordinate value to use. The resulting item is a scalar float. By default, it is possible to sample data from within a gap 2 levels wide (one missing level). The size of this gap can be specified optionally as an input to a `parameters' keyword. |
| up_sample | Performs vertical sampling in the case where the value of the vertical coordinate being used increases upward. Sampling means directly using the value from the nearest level rather than interpolating. This function takes three inputs. The first, a float list, is the vertical coordinate list; the second, also a float list, is the list of values to sample; and the third, a scalar float or numeric constant, is the specific vertical coordinate value to use. The resulting item is a scalar float. By default, it is possible to sample data from within a gap 2 levels wide (one missing level). The size of this gap can be specified optionally as an input to a `parameters' keyword. |
| find_first | One input, which can be any kind of list. The result is a scalar int item, which contains the list index of the first non-null item in the list. |
| find_last | One input, which can be any kind of list. The result is a scalar int item, which contains the list index of the last non-null item in the list. |
| find_max | One input, which can be any kind of list. The result is a scalar int item, which contains the list index of the first non-null item in the list that tests greater than or equal to all the others. |
| find_min | One input, which can be any kind of list. The result is a scalar int item, which contains the list index of the first non-null item in the list that tests less than or equal to all the others. |
| index | Two inputs, the first of which is any kind of list. The second must be either a numeric constant or a scalar int, most often from one of the functions `find_first,' `find_last,' `find_max,' or `find_min.' The value in the first input whose list index corresponds to the second input is placed in the output item, which is a scalar of the same base type as the input. |
| select | One input, any kind of list. A lookup table must be supplied using `function_table.' The table used must have numeric output, and its input must be compatible with the major type of the list. The table is used to arbitrarily rank each item in the list. Whichever item has the lowest rank number is selected and placed in the output item, which is a scalar of the same base type as the input. |
| catenate | One or more string inputs of any dimensionality. This is one of only two functions that can take list items of different lengths. Each individual string, whether it is part of a list or scalar, is catenated to the eventual result string. The output item is a scalar string type. The default delimiter between each string is an empty string. One can optionally supply a different delimiter as an argument to a `parameters' keyword. |
| group | Two or more inputs that all have the same base type but any dimensionality. This is one of only two functions that can take list items of different lengths. Each individual input value, whether it is part of a list or scalar, it added to the eventual resulting output list. The output item is a list of the same base type as the inputs. |
| Method | Description |
|---|---|
| formatted | One scalar input of any base type. This method plots a data value using a C format specifier provided in the `format' keyword. The positioning of the plotted element responds to the nine standard position options available as an argument to the `placement' keyword, or to the coordinates supplied as arguments to `location' if the placement is free. If numeric, the value undergoes a units conversion based on the arguments to `multiplier' and `offset,' and will be plottable only if the converted value is within the bounds set by the arguments to `min_trans' and `max_trans.' If the value is null or otherwise deemed unplottable, the string supplied as an argument to `undef_string' can be plotted instead of nothing. A character set other than ASCII can be used to plot the resulting string based on the argument to `alt_char_set.' It is possible to strip a specified number of characters off of the front of the formatted string before plotting by supplying an argument to the keyword `trim_count.' The size of the item plotted can be made different from the default size by supplying an argument to the keyword `magnification.' If the item being displayed is numeric, the format can be determined by the output of a string to number lookup table provided the file name of the table is supplied as an argument to the `table_file' keyword. |
| lookup | One scalar input of any base type. This display method plots the result of a simple lookup table translation. The lookup table, the file for which is supplied as an argument to the `table_file' keyword, needs to have string output and input compatible with the major type of the item being plotted. The positioning of the plotted element responds to the nine standard position options available as an argument to the `placement' keyword, or to the coordinates supplied as arguments to `location' if the placement is free. An alternate character set can be selected using `alt_char_set,' and the plotted size of the item can be modified by supplying a `magnification.' |
| translation | One scalar string input. The output string is generated by performing a recursive translation using a string to string lookup table, supplied as an argument to the `table_file' keyword. Any text that is successfully translated will be displayed by whatever character set is specified as an argument to `alt_char_set.' Untranslated text will be shown in plain ASCII. The positioning of the plotted element responds to the nine standard position options available as an argument to the `placement' keyword, or to the coordinates supplied as arguments to `location' if the placement is free. The plotted size of the item can be modified by supplying a `magnification'. |
| trend | This is a specialized method used to display the standard coding for the three hour pressure tendency. Inputs are the change amount (float scalar) and the pressure change character (short scalar). Any desired units conversion for the change amount must be supplied as an argument to `multiplier,' but `offset' is ignored. The formatting of the change amount can also be set via `format.' The positioning of the plotted element responds to the nine standard position options available as an argument to the `placement' keyword, or to the coordinates supplied as arguments to `location' if the placement is free. The plotted size of the item can be modified by supplying a `magnification.' |
| barb | This method displays vector data as wind barbs. It takes two to four inputs, which must all be scalar floats. These are wind speed and direction, and optionally gust speed and direction. If gust speed is supplied without direction, the direction will be taken to be the same as input two. When gust information is available, it is plotted as an additional arrow with the gust speed labeled in ASCII. The position is predetermined by the method, so free `placement' is required. `max_trans' can be used to specify a maximum valid wind speed. Speeds are assumed in knots; `multiplier' can be used for units conversion. `min_trans' specifies the smallest gust speed that will be plotted as such, and `offset' states the minimum vector difference that must exist between the wind and the gust before a gust will be plotted. The argument to `magnification' is overloaded: its magnitude is the size relative to the default of the barb to be plotted, while if it is negative, "calm" circles will not be plotted. If the barb as a whole is deemed unplottable, normally nothing will be plotted, but `undef_string' can be used to specify some ASCII string to plot in that case. |
| arrow | This method displays vector data as arrows. The two scalar float inputs represent wind speed and direction. The length of the arrow is fixed, and the speed is plotted in ASCII at the end of the arrow. The position is predetermined by the method, so one must specify free `placement.' If supplied, `max_trans' specifies the maximum wind speed considered valid. Speed units conversion is accomplished through `multiplier,' but `offset' is not used. Relative arrow size is specified using `magnification.' If the arrow as a whole is deemed unplottable, normally nothing will be plotted; `undef_string' can be used to specify an ASCII string to plot in that case. |
| barbuv | Like `barb', this method displays vector data as wind barbs. The inputs differ however. Two to four float inputs are accepted. If there are only two inputs they are scalars representing u and v components of the wind, and a single barb is plotted. For three or four inputs, all are lists, representing u component, v component, height, and QC parameters, respectively. If there are three inputs, then a stack of wind barbs is plotted. If four, the wind barbs in the stack are colored according to the speed and the QC information. free `placement' is required, since the position is predetermined by the method. `max_trans' can be used to specify a maximum plottable wind speed. Speeds are assumed in knots; `multiplier' can be used for units conversion, but no `offset' is applied. The argument to `magnification' is overloaded: its magnitude is the relative size of the plotted barb, while if it is negative, "calm" circles will not be plotted. If the barb as a whole is deemed unplottable, normally nothing will be plotted, but `undef_string' can be used to specify an ASCII string to plot in that case. |
| arrowuv | Like `arrow,' this method displays vector data as arrows. Two to four float inputs are accepted. If there are only two inputs they are scalars representing u and v components of the wind, and a single arrow is plotted. For three or four inputs, all are lists, representing u component, v component, height, and QC parameters, respectively. If there are three inputs, then a stack of arrows is plotted. If four, the arrows in the stack are colored according to the speed and the QC information. free `placement' is required, since the position is predetermined by the method. `max_trans' can be used to specify a maximum plottable wind speed. Speed unit conversion is accomplished through `multiplier,' but no `offset' is applied. The argument to `magnification' is overloaded: its magnitude is the relative size of the plotted arrow, while if it is negative, "calm" circles will not be plotted. If the arrow as a whole is deemed unplottable, normally nothing will be plotted; `undef_string' can be used to specify an ASCII string to plot in that case. |
Before one attempts to manipulate the display characteristics of point data sets, it is helpful to understand the enhancements that have been made to the netCDF files to support this. Here, in CDL format, are the variables and attributes that have been added:
The main reason to be familiar with these enhancements is so that in the event that one needs to add an additional variable or attribute to an existing netCDF file, one can avoid using these reserved variables and attributes. We refer to these enhancements as `record management' variables and attributes. An implementor also needs to understand that the record management variables are not displayable.
Of all the new global attributes, the :cdlDate attribute is the most important. If one ever changes the structure of the data files in a directory (add, delete, or move a variable) the value of the :cdlDate attribute needs to be changed. This allows the software to recognize that it has to treat the new files differently.
Several lookup tables are included with the AWIPS software. They are listed here by type, followed by an example of each for reference.
| Type | Files |
|---|---|
| s2s | cloud_chars.txt cloud_chars_nom.txt qc_check_bad.txt qc_check_fmt.txt qc_check_good.txt wx_symbol_trans.txt |
| s2n | cloud_select.txt rank_report_type.txt |
| n2s | fractions_lookup.txt ldad_prcp_formats.txt maritime_cloud_chars.txt prcp_formats.txt raob_dd_char.txt |
| n2n | prcp_goodness.txt |
wx_symbol_trans.txt
s2s right VC -SHRA : 45 54 +SHRA : 180 54 SHRA : 79 54 -SHSN : 46 54 +SHSN : 179 54 SHSN : 89 54 -TSRA : 45 41 +TSRA : 79 88 TSRA : 180 41 -TSSN : 46 41 +TSSN : 179 88 TSSN : 89 41 FZRASN : 71 89 BCBR : 35 MIBR : 36 BR : 34 FZFG : 173 BCFG : 63 MIFG : 64 FG : 53 TS : 41 +TS : 88 FC : 43 +FC : 137 PO : 32 DRSN : 59 +DRSN : 60 BLSN : 61 +BLSN : 62 FU : 28 HZ : 29 -SH : 54 SH : 78 DU : 30 SA : 31 SS : 55 DS : 55 +SS : 58 +DS : 58 -FZRA : 70 -FZDZ : 68 FZRA : 71 FZDZ : 69 GR : 80 IC : 76 PE : 77 PL : 77 GS : 75 DZRA : 73 RADZ : 73 RASN : 47 SNRA : 47 -RA : 45 +RA : 180 RA : 79 -DZ : 44 +DZ : 181 DZ : 67 -SN : 46 +SN : 179 SN : 89 -UP : 174 +UP : 176 UP : 175 IP : 77 SG : 75 VA : 177 PRFG : 178 SQ : 42 BLDU : 31
(The output weather string represents one or more weather symbols.)
rank_report_type.txt
s2n METAR 1 SPECI 2
(The standard MTR plots prefer a METAR over a SPECI if both are available in a given hour.)
prcp_formats.txt
n2s -0.005 0.005 ~T 0.005 0.015 ~.o1 0.015 0.025 ~.o2 0.025 0.035 ~.o3 0.035 0.045 ~.o4 0.045 0.055 ~.o5 0.055 0.065 ~.o6 0.065 0.075 ~.o7 0.075 0.085 ~.o8 0.085 0.095 ~.o9 0.095 0.495 %4.2f 0.495 9.995 %5.2f 9.995 100 %6.2f
(The "o" is used instead of "0" arbitrarily to distinguish low-precip reports. C-style formats are used for higher amounts, with a break at .50" to emphasize heavier precip.)
prcp_goodness.txt
n2n 0 1 0 100000
(This allows higher precipitation amounts to automatically be favored by the progressive disclosure (declutter) mechanism.)