Handling fill_value in plot_data_plane

[DanielAdriaansen]

I am wondering how plot_data_plane chooses to color fill_value when drawing plots.

I started with this file:
/d1/projects/METplus/METplus_Data/model_applications/precipitation/QPE_Data/20170510/qpe_2017051004.nc

First test was to plot P24M_NONE using plot_data_plane:

/d1/projects/MET/MET_releases/MET-12.0.0-beta2/bin/plot_data_plane qpe_2017051004.nc p24m_none.ps 'name="P24M_NONE"; level="(0,*,*)";' -v 5

For a second test, I opened the NetCDF file and replaced all values ==0.0 with the floating point value of -9999., which I understand to be the "missing data" value MET respects. This produced the following image:

Why are all the areas with values of -9999. shaded with a gray color that is not the lightest shade in the colorbar? Is some other gray color being inserted? Using the "display color meter" on my mac, I am able to see that the RGB value for this gray is 150/150/150, which is not an RGB value used in any of the grays in the colorbar.

I wonder if there should be a special color reserved for fill_value in plot_data_plane that is more distinct than this gray color, since grays are included in the default color bar? Or maybe white should be reserved for this purpose and excluded from the default color table?

I found this comment: dtcenter/MET#2557 (comment)

Which recommends using censor_thresh and censor_val, however this is for grouping valid data values to another valid value (i.e. setting valid values <=0.5 to 0.0, where 0.0 is a valid value), so I don't think this is useful for fill_value.

[JohnHalleyGotway]

Hi @DanielAdriaansen I see you have a question about how bad data values are plotted by the plot_data_plane tool in MET.

Let me provide some details about plot_data_plane to help clarify.

The plot_data_plane usage statement includes a [-color_table color_table_name] option. It is optional, not required, but can be used to override the default color table, met_default.ctable, that's used.

Here's a selection from that color table:

-9999       { 150, 150, 150 } // -9999 indicates bad data
0.000 0.000 { 255, 255, 255 }
0.000 0.025 { 175, 175, 175 }
0.025 0.050 { 161, 161, 161 }
...
0.950 0.975 { 209,   0, 111 }
0.975 1.000 { 234,   0, 191 }

Note the following:

• The first line defines the RGB colors corresponding to the bad data value of -9999. And {150, 150, 150} is the shade of gray that you're asking about.
• Each subsequent line defines min/max data values followed by a corresponding RGB color.
• The range of values in the color table is 0 to 1.

All of the color tables found in this colortables directory can be referenced in MET config files and command lines as MET_BASE/colortables/{color table name} since they are copied into the installation directory when make install is run.

Here's how these color tables work in MET...

• Obviously the line for -9999 defines the color used to plot bad data.
• There is special logic for colortables that start at 0 and end at 1. They are AUTOMATICALLY RESCALED to match the min/max values of the data being read. That's convenient because it makes reasonable looking plots regardless of the input data, but also not great, because as the data values change from time to time, so do the meaning of the colors.
• The -plot_range min max command line option, if specified, defines the rescaling of the color table to produce more repeatable plots.
• Or you can define a color table like nws_radar_precip.ctable to explicitly define value ranges and no rescaling will occur.
• Ultimately, this line of the create_image() function calls ColorTable::interp(double z_in) to convert a data value to a color.
  • If the value falls inside one of the color table bins, that exact color is used.
  • If it falls outside the range of color table values, the nearest color is used.
  • If it falls between two color table bins, then the final color is interpolated using the colors "above" and "below".

Users are encouraged to copy/modify existing color tables and modify the range of values or colors to meet their needs.

[DanielAdriaansen]

Thanks @JohnHalleyGotway!