Derrick,
Yes, correct -- in each case the standard name 'base' must correspond
to what is actually sensed, not what the measurement will eventually
become. That said, I was trying to give examples where I was actually
sensing something that had a CF standard name, like water
temperature. It's just the result of the sensing was in volts, not in
degrees centigrade or the equivalent.
I am explicitly *not* trying to create a technique for defining
processes or compositions of measurements. So the SensorML mechanisms
(which don't stretch to semantic naming anyway) do not apply in this
case.
John
On Mar 5, 2009, at 5:12 PM, Derrick.Snowden at noaa.gov wrote:
> Hi John,
>
> Sounds like a tricky problem, but probably one worth solving. My
> initial reaction to your question
>
> " Is there a standard technique that would let me convert any
> existing standard name to a 'raw units' standard name?"
>
> is that this could potentially lead down a difficult road as the
> mapping is not one to one. A satellite may measure radiance across
> several wavelength bands which are combined together with
> independent parameters in an algorithm to estimate SST. Similarly,
> the same volts measurement from a CTD temperature sensor must be
> combined with volts measurements from an oxygen sensor (and
> algorithm parameters) to estimate dissolved oxygen, but
> independently, the first volts measurement, plus different algorithm/
> parameters can yield water temperature.
>
> I'm no CF guru, but it seems like the full complexity of mapping raw
> data (possibly many) + parameters + algorithm = measured value
> within the CF conventions might be tough. I know SensorML is
> designed around this idea though, so perhaps there are ideas that
> can be borrowed from that framework????
>
> I realize this isn't overly helpful but I suppose my point is that
> during the conversation that might hash out a solution for this
> within CF, my vote would be for creating standard names for the
> variable that is actually measured (e.g. volts) rather than
> semantically try to link engineering unit measurements to physical
> unit measurements since that relationship is not always
> straightforward.
>
> I look forward to hearing more from the group.
>
> Best regards,
> Derrick
>
>
> ----- Original Message -----
> From: John Graybeal <graybeal at mbari.org>
> Date: Thursday, March 5, 2009 6:44 pm
> Subject: [CF-metadata] standard names for variables in 'raw
> engineering' units
>
>> Here's a question about observational variables. Many of our
>> sensors
>> measure variables that are in the standard names list, but the data
>> is
>> not yet converted to science units, for example temperature or
>> oxygen
>> concentration.
>>
>> These measurements are typically represented by a unit like
>> 'volts' (or even 'counts') -- definitely not directly convertible
>> to
>> the canonical units! Is there a standard technique that would let
>> me
>> convert any existing standard name to a 'raw units' standard name?
>>
>> If not, to start the conversation perhaps I can suggest one of the
>> following to indicate such metrics?
>> suffix: _in_engineering_units
>> suffix: _in_raw_units
>> prefix: raw_measure_of_
>>
>> This capabilitiy will be important for finding data that
>> potentially
>> can be converted to the desired values, but has not yet been
>> converted. (Some of our collected parameters are not the primary
>> purpose of the experiment, and they remain in raw units unless
>> someone
>> needs them converted.)
>>
>> 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
>>
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 Thu Mar 05 2009 - 22:48:21 GMT
