This is an interesting problem. Can you simplify or explain this
example for those of us not familiar with AIRS, MODIS/Terra, etc.?
My simple analogy is sea water conductivity, which can be made into
salinity. Yet I suggest the way to handle that is to label the
measurement as conductivity (itself an actual geophysical property),
rather than describing the instrument (whether as a Seabird CTD,
generic CTD, or as a 'salinity-producing instrument'). I think the CF
standard names have a specific function which would be confused by the
addition of instrument names.
While I *also* want to encourage a separate set of attributes for
capturing the instrument/process that generated the data (for the
problem you describe, among others), I propose pursuing that
separately. (I'm willing to create a TRAC ticket if others will
support it/help review it.) The rest of this post follows up on that
idea.
Here is the observational analysis paradigm I see as the issue, which
may differ from a typical modeling use case. Scientists often tell me
that it is not enough to see that data is labelled as 'good salinity
data', they have to know how the data was created (and in many cases,
by whom) in order to know whether to have confidence it is applicable.
(And, to consider older data credible, they must know the instrument
that generated that data.)
The CF standard does not deal with this kind of provenance; while I
think that is a significant weakness, I do not think it is one that
can or should be dealt with in the standard names. They perform a
specialized service in the way they capture just the measured
geophysical quantities (and their units).
Three approaches have been pursued that I know about. One, by
OceanSITES [1], references a separate (likely SensorML; details TBD)
description of the configuration of the system. A second, by MBARI [2]
and undoubtedly others, incorporates additional provenance metadata in
the header and variable attributes. A third was recent proposed by
Nan Galbraith as an optional enhancement to the OceanSITES parameter
attributes. I would start by suggesting some combination of these as
an optional extension to the CF specification.
John
[1] OceanSITES data format:
http://www.oceansites.org/data/index.html
[2] Example of MBARI netCDF file:
http://dods.mbari.org/cgi-bin/nph-nc/data/ssdsdata/deployments/m0/200607/hourlyM0_20060731.nc.html
On Mar 13, 2009, at 4:14 AM, Lynnes, Christopher S. (GSFC-6102) wrote:
> With the diversity of proposals being floated for raw predecessors
> to geophysical measurements, we should not lose sight of the fact
> that some raw measurements spawn many, many geophysical property
> measurements, particularly in the case of multi-spectral and
> hyperspectral remote sensing data. In these cases, for example, it
> would seem that the instrument name might need to be in the standard
> name, yes? Else how can we distinguish AIRS raw measurements from
> MODIS/Terra from MODIS/Aqua, etc. Unless we explicitly scope the
> discussion below to include only "raw measurements that are
> predecessor to a single geophysical property". (So far that scope
> seems to be implicit.)
> ________________________________________
> From: cf-metadata-bounces at cgd.ucar.edu [cf-metadata-bounces at cgd.ucar.edu
> ] On Behalf Of John Graybeal [graybeal at mbari.org]
> Sent: Thursday, March 12, 2009 8:59 PM
> To: Karl Taylor
> Cc: cf-metadata at cgd.ucar.edu
> Subject: Re: [CF-metadata] standard names for variables?in?'raw?
> engineering' units
>
> On Mar 12, 2009, at 4:15 PM, Robert Muetzelfeldt wrote:
>
>> What is the actual (scientific) value of having units associated
>> with raw measurements?
>
> (see below)
>
> On Mar 12, 2009, at 4:19 PM, Karl Taylor wrote:
>
>> Can you remind me what you have proposed in place of
>> ctd_fluorometer_voltage for the example under discussion? Would
>> "fluorometer_reading" be an appropriate standard name, and you could
>> attach a units attribute indicating the measurement is in volts.
>> (The thing being measured is clearly *not* temperature, even though
>> you might be able to estimate the temperature based on the
>> measurement, so I see no reason to include temperature in the
>> standard_name.)
>
> Hmm, 'reading'. Might work. Or 'measure'.
>
> I don't know what Roy's fluorometer measures (example from which the
> 'ctd_fluorometer_voltage' notion came), but ours measures fluorescence
> among other things (CDOM, chlorophyll). I am picking the WetLabs ECO-
> FL fluorometer for this example (I apologize if I get any of the
> subtle details wrong here).
>
> The instrument can produce raw values corresponding to the
> fluorescence signal. This value is in counts (in digital mode), or
> the instrument can produce volts (in analog mode). In answer to the
> first question above, it is useful to know whether the value in the
> netCDF file is the volts or the counts. [1]
>
> The instrument can also produce what it calls 'engineering units' in
> micrograms/liter for the signal. (To do this, it uses calibration
> values that have been entered beforehand.)
>
> So while my scientific expertise is a little uncertain here, one of
> the conversions can be for chlorophyll, so let's use that example: the
> first standard name will be
> concentration_of_chlorophyll_in_sea_water_reading (or _raw, or
> _variant_units)
> and the second will be
> concentration_of_chlorophyll_in_sea_water
>
> I would *not* use the name of the instrument (or platform) in the
> standard name. This instrument, for example, can measure and report
> multiple phenomena (even within one record). As the existing standard
> names largely correspond to geophysical properties, this proposal
> makes it possible to name preliminary measurements of those
> geophysical properties. So the names should still correspond to the
> geophysical properties in question.
>
> John
>
> [1] I appreciate that we still need a scale factor and offset to get
> from *either* counts or volts to the science units, so the science
> application is less immediate. But a key point is that if I have a
> copy of the metadata produced from the instrument before the relevant
> deployment, that metadata will give me the information that lets me do
> that conversion, recovering the science data -- but I need to know
> whether to convert volts or counts. (Though you might argue that's
> still a bad example, because I could inspect the values for a decimal
> point with this particular instrument -- but the volts/counts
> difference is deterministic, _and_ can even be automated in
> appropriately designed systems. )
>
>
>
>>
>>
>>
>> John Graybeal wrote:
>>> Thank you all for all your thoughts on this.
>>> Jonathan Gregory <j.m.gregory at reading.ac.uk> 03/12/09 9:57 PM >>>
>>>> I don't really know what it is, of course, but it sounds like it
>>>> could have a standard name of ctd_fluorometer_voltage and units of
>>>> V. <snip> Here, the quantity being named relates specifically to a
>>>> means of measurement, not to the final product.
>>> I must quibble. The quantity being named relates specifically to
>>> the _units_ of the measurement, not the means of measurement. And
>>> the reason this (new standard name) must be done is that Standard
>>> Names are specifically tied to units (via the canonical units
>>> requirement), and so the strange unit forces a different standard
>>> name.
>>> And so for purest reflection of meaning, we are back to something
>>> like 'variant_unit' (instead of 'raw'). I discourage incorporating
>>> the unit in the standard name ('voltage' in Jonathan's example)
>>> because there is no way to know if *this* temperature_voltage
>>> variable is interoperable with *that* temperature_voltage, unless
>>> attributes for conversion to canonical units are provided. So the
>>> units attribute can name the units, and this standard name should
>>> just make clear that the units are not canonical units.
>>> And, can we make it an item in appendix C, please?
>>>> What are example of non-udunits? V is a udunit, all right. Perhaps
>>>> a non-udunit
>>>> is just a count of something? Does that need units? It could
>>>> simply be
>>>> regarded as dimensionless.
>>> Addressed in other thread; no non-udunits have been identified so
>>> far relating to raw geophysical data.
>>> John
>>> --------------
>>> John Graybeal <mailto:graybeal at mbari.org> -- 831-775-1956
>>> Monterey Bay Aquarium Research Institute
>>> Marine Metadata Interoperability Project: http:// marinemetadata.org
>>> _______________________________________________
>>> CF-metadata mailing list
>>> CF-metadata at cgd.ucar.edu
>>> http:// mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>>
>> _______________________________________________
>> CF-metadata mailing list
>> CF-metadata at cgd.ucar.edu
>> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
>
>
> John
>
> --------------
> John Graybeal <mailto:graybeal at mbari.org> -- 831-775-1956
> Monterey Bay Aquarium Research Institute
> Marine Metadata Interoperability Project: http://marinemetadata.org
>
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
> _______________________________________________
> CF-metadata mailing list
> CF-metadata at cgd.ucar.edu
> http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
John
--------------
John Graybeal <mailto:graybeal at mbari.org> -- 831-775-1956
Monterey Bay Aquarium Research Institute
Marine Metadata Interoperability Project:
http://marinemetadata.org
Received on Fri Mar 13 2009 - 11:33:41 GMT
