NOTE: The cf-pointobsconvention mailing list is no longer active. The list archives are made available for historical reasons.
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 value. 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 ************************************************************* Don Murray UCAR Unidata Program dmurray@xxxxxxxxxxxxxxxx P.O. Box 3000 (303) 497-8628 Boulder, CO 80307 http://www.unidata.ucar.edu/staff/donm *************************************************************
cf-pointobsconvention archives: