Re: [cf-pointobsconvention] Draft 2

Hi John-

John Caron wrote:

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.

It seems like the possible options are:

1. z coordinate required, with values convertible to height (eg meters), with a vertical datum (reference surface like "mean sea level") specified.
  2. z coordinate required, with values convertible to height (eg meters).
  3. z coordinate required, with values in any vertical coordinate system.
  4. z coordinate required, may be a "nominal" value (just a string description)
  5. No z coordinate required.

I would lean towards 4, but could be convinced of 5 or 3. We should however recommend the data provider add as much info as possible, and make sure there is a standard way to do so.

I think it should be 5, but if there is a Z value, it should be 3.
In the atmosphere, raobs measure pressure and it is converted to
height so the "real" z coordinate is not convertible to meters.
And as I mentioned earlier, if you require 1 or 2, you cannot store
satellite derived winds in that format because you have no height

One of the things to consider is how to get existing datasets into
this structure.  So for example, if I have an IOSP that reads
ASCII point ob files and spits out CF and there is no Z value,
what do I do if you go with 4?  Just have a string called "unknown"?

What is the compelling reason to have to have a Z coordinate?
That's not required for 2D grids in CF (e.g. total_precipitation)
so I'm not sure why it would be required for point data either.

Could I ask data providers to chime in : how much z info are you willing and able to put in your files?

Someone who writes an adapter from one non-CF format to CF
will also have to consider this, not just those creating
CF compliant files.  If there is no Z information in the
native format (e.g NDBC buoy files), requiring one would be
requiring the adapter to make something up.

Don Murray                               UCAR Unidata Program
dmurray@xxxxxxxxxxxxxxxx                        P.O. Box 3000
(303) 497-8628                              Boulder, CO 80307