I suppose it would be useful to find another venue to reach consensus
on a basic approach, and then hammer out some more details, without
the fits and starts inherent in an email list, and without swamping the
members of this list who aren't concerned with this topic.
Trac would be fine, or we could draft a short report, with recommendations,
over on the MMI site ...
Speaking of details, I'm having a little trouble with John's 3
categories ...
some comments in line.
John Graybeal wrote:
> Here are the data types I see that aren't covered now:
>
> (1) fundamental geophysical properties that are correctly named by an
> existing standard name (or could be), but have arbitrary non-standard
> units (which may or may not be convertible with just a scale and offset);
If the scale and offset are known, they can be specified with the
attributes (already part of the CF standard) scale_factor and
add_offset, and the units can then be compliant. I think this case
only covers something like a sensor output that's in counts, or a
resistance value, that could be converted to a geophysical parameter.
As you indicated, using a standard name only provides the ability
to discover this data, not to use it.
> (2) a fundamental measurement/value for a property, but one that is
> made for an _instrument_ property rather than a geophysical property
> ('temperature_of_sensor_head'; also could be an instrument-impacted
> property, like 'processed_sea_water_temperature');
Not sure I understand - is this a component, or ... something else? If it's
not a component (like the temperatures and thermopile voltages from a
radiometer, which are processed into longwave radiation) then I don't
see where those fit in your list of categories. Could you please define
this
a little more? (I'm also not grokking processed_sea_water_temp.)
> (3) a calculated value that is useful for diagnostics or other
> purposes, but is neither (1) nor (2).
Maybe calculated, or maybe another instrument output, like percent_good
from an adcp, or the orientation parameters from a Direct Covariance Flux
System. If I understood what comprised #2 a little better, I'd probably
be happier with this definition.
> For (1), the motivation is finding additional science data that is
> directly applicable. For (2) and (3), the motivation is
> characterizing metadata for a measurement or instrument, ideally in a
> way that recognizes its association with both the affected data and
> the related instrument, and thereby supporting its discovery by those
> who need to discover it. In this latter case (2+3), I suggest the
> people who need to discover these parameters are analysts who are
> already working with the data set, not someone trolling around the net
> looking for sensor head or QC data.
>
> On Apr 21, 2009, at 11:40 AM, Nan Galbraith wrote:
> > It seems we have several kinds of 'problem variables' to deal with:
> >
> > - Components of geophysical variables (like voltage and
> > temperatures from a radiometer, or the sensor temperature from
> > an oxygen probe; these can be useful in troubleshooting or
> > recalculating the geophysical variables),
> >
> > - QC kinds of parameters (like percent good, or error velocity,
> > from an ADCP),
> >
> > - Raw instrument output that could be converted directly into
> > geophysical data. I'm not sure if something like rain level
> > is an example of this, or if the kinds of data that Roy mentioned
> > are different in some way.
--
*******************************************************
* Nan Galbraith (508) 289-2444 *
* Upper Ocean Processes Group Mail Stop 29 *
* Woods Hole Oceanographic Institution *
* Woods Hole, MA 02543 *
*******************************************************
Received on Wed Apr 22 2009 - 13:07:26 BST
