Re: [cf-pointobsconvention] Should Z Coordinates be required?

NOTE: The cf-pointobsconvention mailing list is no longer active. The list archives are made available for historical reasons.

Not sure if input based on experience with time series data is appropriate here,
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 value
is 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 Galbraith            Upper Ocean Processes Group       *
* Woods Hole Oceanographic Institution Woods Hole, MA 02540  *
*      (508) 289-2444                    *

  • 2007 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the cf-pointobsconvention archives: