Can someone tell me if we have reached an agreement on whether
to provide either a set of standard names or a mechanism for generating
them for instrument data that can't be expressed in canonical units and/or
does not directly represent a geophysical quantity?
John G started this discussion, and there was a good exchange about it,
but no actual agreement on it that I can find. Does this question need to
move to the trac system, or are we all making our own decisions on
how to handle this kind of data?
I'm looking for a way to describe precipitation measurements as a level,
as output from a rain gauge, before the data is normalized and differenced
into a rain rate. Different users may want to use different methods of
converting to a rate, so the raw values are useful to pass along with the
'final' data set.
I liked the suggestion of appending 'reading' and suspending the udunits
requirement for these variables - and didn't see any strong opposition to
that in the thread.
Thanks -
Nan
>> Dear John
>>
>> It appears from your examples that these "raw" values are very
>> specific to the technology being used. Under what circumstances can
>> they be compared usefully from different data sources, without
>> knowing the identity of the equipment? If they can't usefully be
>> compared, why do they need standard names? (Sorry if these questions
>> reiterate points you made initially.)
>
> The use case is that I'm searching for sea water temperature data.
> (I'm using standard names because that is one of the best ocean
> science data naming conventions available.) Currently I will not find
> data that is in netCDF files in the searched repository, but is not
> convertible to canonical units. By allowing these standard names I
> can find that data. Once the data is found, I can either: (a)
> manually examine the metadata to see if transformation algorithms are
> supplied, (b) query the provider of the data, or (c) attempt to infer
> or derive appropriate transformations from other information that is
> available.
>
> The key (missing) piece that is being supplied by the standard name is
> the discovery piece.
>
> (As often happens today, when people go back into old data sets --
> which itself is happening more and more often -- they find themselves
> executing one of steps (a) thru (c) anyway, due to insufficient
> metadata about the source of the data and the processes used to create
> it. I have seen proposals elsewhere for improving that situation in
> netCDF files, and it is my expectation that CF will evolve to
> accommodate that need, sooner or later. Then the process of using the
> newly discovered data can become more automated.)
>
> John
>
>
> On Mar 13, 2009, at 12:58 AM, Jonathan Gregory wrote:
>
>> Dear John
>>
>> It appears from your examples that these "raw" values are very
>> specific to the
>> technology being used. Under what circumstances can they be compared
>> usefully
>> from different data sources, without knowing the identity of the
>> equipment?
>> If they can't usefully be compared, why do they need standard names?
>> (Sorry
>> if these questions reiterate points you made initially.)
>>
>> Best wishes
>>
>> Jonathan
--
*******************************************************
* Nan Galbraith (508) 289-2444 *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 *
*******************************************************
Received on Thu Apr 09 2009 - 11:07:17 BST
