Thank you Jim!
When we transition our older files to CF, I'll have to leave out the
variables for which there is no good data.
Best, Ellyn
On 05/23/2013 08:49 AM, Jim Biard wrote:
> 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 <http://www.cicsnc.org/>
> Remote Sensing and Applications Division
> National Climatic Data Center <http://www.ncdc.noaa.gov/>
> 151 Patton Ave, Asheville, NC 28801-5001
>
> jim.biard at noaa.gov <mailto:jim.biard at noaa.gov>
> 828-271-4900
>
>
>
> Follow us onFacebook <https://www.facebook.com/cicsnc>!
>
> On May 23, 2013, at 8:43 AM, Ellyn Montgomery <emontgomery at usgs.gov
> <mailto: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 <mailto:CF-metadata at cgd.ucar.edu>
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
--
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130523/716bb5a2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 15784 bytes
Desc: not available
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20130523/716bb5a2/attachment-0001.png>
Received on Thu May 23 2013 - 09:04:46 BST
