Ellyn,
I believe that the valid_range and actual_range attributes are intended to only list non-fill values. The actual range should fall inside the valid range, and both should exclude invalid values.
Grace and peace,
Jim
Jim Biard
Research Scholar
Cooperative Institute for Climate and Satellites
Remote Sensing and Applications Division
National Climatic Data Center
151 Patton Ave, Asheville, NC 28801-5001
jim.biard at noaa.gov
828-271-4900
Follow us on Facebook!
On May 23, 2013, at 8:43 AM, Ellyn Montgomery <emontgomery at usgs.gov> wrote:
> Seth-
>
> Thanks very much for the information and pointer to the ticket documenting the issue!
>
> Do you know if NaN is an allowed value for actual_range? In our historical data, a variable is retained if it was collected, even though the sensor failed completely (and all the data was replaced by _FillValue). In this case, actual_range would be [NaN NaN] for that variable.
>
> I appreciate the help!
> Ellyn
>
> On 05/22/2013 05:04 PM, Seth McGinnis wrote:
>> Hi Ellyn,
>>
>> According to CF Trac Ticket #31 (slated for inclusion in the update to CF 1.7),
>> the way to cache minimum & maximum values in metadata is to use an attribute
>> named "actual_range" and store them as a pair.
>>
>> (I kind of think this is a bad idea, and wish that ticket was still open. I
>> missed this discussion when it happened, but my experience with actual_max type
>> attributes in practice has convinced me that it's SO easy for them to become
>> inconsistent that it would really be better not to include them at all.
>> Computing the min & max on the fly is cheap, and approximating it is even
>> cheaper, so why introduce the uncertainty? But if they do need to go into
>> metadata, I think it would be better to use a name that highlighted the fact
>> that they're potentially unreliable. Maybe something like "nominal_range"
>> rather than "actual_range"?)
>>
>> Anyway, the details on how actual_range works can be found here:
>> https://cf-pcmdi.llnl.gov/trac/ticket/31
>>
>> Cheers,
>>
>> --Seth
>>
>>
>>
>>> The second part of the question involves variable attributes we now call
>>> minimum and maximum. Do these names have special meanings? In our files, we
>>> include the actual minimum and maximum computed for each non-coordinate
>>> variable's data. I want to be clear about the content of these attributes,
>>> and wonder if others use different terms to avoid confusion with valid_min and
>>> valid_max? Would calling these attributes "computed_minimum" (maximum) or
>>> "actual_minimum" (maximum) be better?
>>>
>>> Thanks for any suggestions!
>>> Ellyn
>
>
> --
> Ellyn T. Montgomery, Oceanographer and Data Manager
> U.S. Geological Survey
> Woods Hole Coastal and Marine Science Center
> 384 Woods Hole Road, Woods Hole, MA 02543-1598
> (508)457-2356
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130523/b6c38a3e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CicsLogoTiny.png
Type: image/png
Size: 15784 bytes
Desc: not available
URL: <
http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130523/b6c38a3e/attachment-0001.png>
Received on Thu May 23 2013 - 06:49:44 BST
