NOTE: The cf-pointobsconvention mailing list is no longer active. The list archives are made available for historical reasons.
but I've been following the discussion and might as well speak up now.
> Could I ask data providers to chime in : how much z info are you > willing and able to put in your files?
For subsurface mooring and shipboard data, we provide measurement depth, normally a single value for each sensor, not a time series that reflects changes due to mooring/ship motion or waves. For surface (met) data, whether on buoys or ships, we normally set z to 0 and put the sensor height (numeric, in meters) in an attribute for each measured parameter. We always use mean sea level as our reference surface, but are not explicit
about it, assuming that that is the default definition.Recognizing that there may be datasets for which there really isn't a meaningful z value, I'd still argue in favor of having it be part of the standard, for the simple reason that in practice, in most cases, data providers need to be "strongly encouraged" to include this information. We have many old datasets with SST, with no record of the depth at which the measurements were taken, although that value was readily available when the data were collected. (My apologies to those who have already heard me complain about this
many times.)For data where there is truly no meaningful z because of the type of data, the value 0 could be used - with no chance of misunderstanding, if the parameter is really clearly
not related to a specific height/depth.
I like John Greybeal's suggestion to require something, and allow some standard "dont know" string to allow the possibility that its unknown. I realize this is a matter of style, since the effect is the same (unknown Z). ...
In this case, where a z value would be appropriate but is unavailable, why not just use a fill float? A required numeric value simplifies processing, a null (fill float) is easy to understand, and one or more standard, required attributes
that describe the accuracy and precision of the z value could be used to provide more information in this case - as well as in cases where the valueis available. I'd much prefer to see a fill float instead of a string, with the attribute used to describe the situation, using John's idea of suggested standard
terms for "don't know".
> Just to be clear: this is not about making assumptions about where > the z value is (sorry i said that earlier), in fact its the > opposite: requiring the data provider to explicitly specify the z > position of point data, in order to be CF compliant.
At least 1 parameter in CF is defined explicitly as not having a z value:'Sea surface temperature is usually abbreviated as 'SST'. It is the temperature of sea water near the surface (including the part under sea-ice, if any), and not the skin temperature, whose standard name is surface_temperature. For the temperature of sea water at a particular depth or layer, a data variable of sea_water_temperature with a vertical coordinate axis should be used.'
(Please note: I'm not especially happy with this part of the convention, because it allows for sloppy use. Further apologies, to those mentioned above. )
Cheers - Nan -- ************************************************************** * Nan Galbraith Upper Ocean Processes Group * * Woods Hole Oceanographic Institution Woods Hole, MA 02540 * * http://uop.whoi.edu (508) 289-2444 * **************************************************************
cf-pointobsconvention archives: