On 5/26/2010 2:25 PM, Ken Knapp wrote:
Raw satellite data are generally stored as integers (DN=digital
numbers) that are then
1. converted to radiances linearly (or sometimes non-linearly) that
can then be
2. converted to brightness temperatures.
With steps that are nonlinear, the scale factor offset doesn't work.
If a coefficient is tweaked/corrected, then the entire variable would
need to be rewritten.
Satellite data often use lookup tables to more easily and quickly
convert from DN to whatever (radiance/temperature). Updates would then
be made to calibration tables, rather than equations.
So I would propose something like the following CDL where variable
/image/ has range from 0-255 and its attribute /lookup/ means that the
table to convert to meaningful units is /table_1
/
dimensions:
lat = 100
lon = 100
num_bins = 256
int image(lat,lon)
image:long_name = "GOES Water vapor channel"
image:units = "digital number"
image:lookup = "table_1"
image:valid_range = 0, 255
float table_1(num_bins)
table_1:long_name = "Brightness temperature"
table_1:units = "Kelvin"
Thoughts?
-Ken
Hi Ken:
This seems to me to be a reasonable idea. Also applicable beyond
satellite data.
Some details in above example: Seems like this could be
byte image(lat,lon);
(always nice to reduce file size by 4x).
Netcdf-3 has a convention that one can interpret a byte as unsigned by
adding the "_Unsigned" attribute:
byte image(lat,lon);
image:_Unsigned = "true";
Then you dont need the valid_range attribute. Also new CF attributes can
(should?) be prefixed by "CF:", so we have:
byte image(lat,lon)
image:long_name = "GOES Water vapor channel";
image:units = "digital number";
image:CF\:lookup = "table_1";
image:_Unsigned = "true";
Where the "\" is needed just in the CDL (the actual attribute name is
"CF:lookup".
Also. I guess you are suggesting that once the lookup is applied, one
should use the "units" from the lookup table?
