Dear Jonathan,
Hopefully, the absence of an underscore between "rate" and "raw" in "rainfall_rate raw_data" is a typo and not a deliberate syntactic structure within the Standard Name to indicate a modifier. These labels may well be included in URIs and embedded spaces are therefore not a good idea.
Otherwise, I'm comfortable with what you're saying. Whilst I agree in with John Graybeal's point that in priciple it's better to identify the phenomenon (geophysical quantity) rather than the sensor with raw data Standard Names, there are time where this may not be possible for the reasons that you state. For the specification of a standard I'm much happier with universally applicable rules and therefore would prefer 'rain_gauge_reading' or 'rain_gauge_raw_data' to 'rainfall_rate_raw_data'.
As regards the units, I can see cases where these will be valid UDUNITS such as Volts but I can also see other cases (such as ADC output) where the units should be dimensionless.
Cheers, Roy.
>>> Jonathan Gregory <j.m.gregory at reading.ac.uk> 4/10/2009 9:02 am >>>
Dear Nan et al.
A possible way to deal with raw data would be to regard it as a kind of
ancillary data and use a standard name modifier to indicate it (CF 3.3
and appendix C) e.g. raw_data. In your case the standard_name attribute would
then contain "rainfall_rate raw_data". In Appendix C we could specify that
the units are 1 i.e. dimensionless if there is a raw_data modifier. The
definition of the modifier would clarify that there is no standard for how
the raw data is to be converted to the geophysical quantity, but you could
record some information about that in the dataset in a comment.
This would work if there is a one-to-one correspondence between raw data and
geophysical quantity. It has been commented that some raw datasets might be
be the basis of more than one geophysical quantity. Likewise, I expect that
some geophysical quantities depend more than one raw dataset. I think that
if it's raw data which can be described more precisely as being the output of
a particular kind of sensor, and it is in physical units, we should give it
its own standard name; in such cases, the raw data would have more of a
standard meaning, and standard algorithms could be applied to derive geo-
physical quantities from it, I imagine. However, the above approach might be
suitable for your unstandardised raw data. What do you think? If it would be
a useful way forward, it would need to be proposed on trac as a modification
to the CF standard.
Best wishes
Jonathan
_______________________________________________
CF-metadata mailing list
CF-metadata at cgd.ucar.edu
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
This message (and any attachments) is for the recipient only. NERC
is subject to the Freedom of Information Act 2000 and the contents
of this email and any reply you make may be disclosed by NERC unless
it is exempt from release under the Act. Any material supplied to
NERC may be stored in an electronic records management system.
Received on Sun Apr 12 2009 - 09:47:58 BST
